RE: Layers in the WSA (was RE: [Fwd: UN/CEFACT TMG Releases e-Bus ines s Architecture Technical Specification for Public Review])

> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Friday, February 14, 2003 10:13 AM
> To: 'Assaf Arkin'; Dale Moberg; Duane Nickull
> Cc: Burdett, David; www-ws-arch@w3.org
> Subject: RE: Layers in the WSA (was RE: [Fwd: UN/CEFACT TMG Releases
> e-Bus ines s Architecture Technical Specification for Public Review])
>
>
> Assaf
>
> You said ...
>
> >>>We stand to loose if we put too much static
> information inside the SOAP (or other) header. If you move static
> information to the headers then predictibility becomes so complex it is in
> fact impossible. Static information best belongs in the CPA, WSDL, or any
> other service definition and should remain there.<<<
>
> Let's not dismiss the idea of putting information in the header
> too quickly.
> Let's think about the options.
>
> PUT EVERYTHING IN WSDL/CPA
> This can work, but WSDL would need to be extended to support additional
> features like how to sign messages, whether reliable messaging, etc was
> being used as is currently in the ebXML CPA. If the WSDL allows no choice
> e.g. whether RM is used or not, then there is no need for any additional
> information in the header as the recipient would know, if the
> WSDL required,
> that they had to send an acknowledgement and any other behavior
> required of
> the RM protocol.
>
> However, although not strictly necessary, I would be more
> comfortable if the
> message contained an assertion that it was following a particular WSDL/CPA
> definition probably identified with what ebXML calls a  CPA ID. This would
> also allow multiple WSDL definitions s to be supported by the same URL.

I think we achieve that by identifying the operation that is being
performed. Multiple services can support the same operation and a service
can have multiple end-point for invoking the same operation. When you send a
SOAP message to some service on any of its end-points you identify which
operation is begin performed, and if that operation is part of a
choreography, also the context in which that operation is being performed.


> PUT EVERYTHING IN THE MESSAGE
> A lot of the stuff in WSDL/CPA is used to create the message and therefore
> needs to be known in advance of sending it. So what's left to go in the
> message? Some of the things I can think of are:
> 1. Signature information - which you could need anyway to secure
> the message
> 2. Use of RM - which is probably a single item
> 3. Perhaps some type of choreography identifier to identify which
> document/message choreography is being followed
>
> So I don't think this is much of an issue - or am I missing something.

I understand everything to mean everything: the authentication mechanism,
the token service, the transaction service, the security policy, and other
end-point metadata. With the 'everything' approach even stuff that can be
determined from the service definition is contained in the message.


> HYBRID APPROACH
> This is really where everything that is static goes in the
> WSDL/CPA and the
> Message contains the override information. So, for example if a service
> could take part in multipe choreographies then you would >need< a
> choreography identifier.
>
> So perhaps the real issues, are:
> 1. How do you define WSDL/CPA type of document so that you can
> allow a range
> of different features to be used. WSDL, at the moment is, IMO, too
> lightweight, and the ebXML CPA is too heavy.

By defining an extensible framework and then defining a set of extensions
and allowing these extensions to be marked as optional or mandatory. That
way we can begin with a very lightweight framework and extend it to a more
heavyweight framework (all the B2B information we could possibly need and
then some). The means for extension: <xsd:any>, substitution groups, etc are
defined by XML Schema so any spec can elect to use them. WSDL does that:
WS-Policy is then defined as an extension of WSDL, WSCI is defined as an
extension of WSDL, and so forth. CPA could take the same approach to
layering and we can combine multiple layers together to get the information
we need, whether it's lightweight or heavyweight or middleweight.


> 2. Do specs like WS-Policy have a role to play here of defining a general
> way of asserting how a service behaves and therefore whatinteractions with
> the service must do?

WS-Policy only addresses security. Security is not the only thing we are
interested in, but definitely one of the problems we want to solve first. I
haven't read it in too much detail, but I think it illustrates the right
model for extending WSDL and SOAP to define information about the service
type, service and message itself, reusing and referencing definitions in all
three places. So I would look at WS-Policy as a specific problem to a
specific solution, but also as proposing a model which other specifications
should follow when addressing other problem spaces (e.g. transactions,
choreography).


> 2. Should WSDL and ebXML CPA merge, in some way, in some forum yet to be
> determined?

I think that would solve a lot of interoperability problems.

arkin

>
> Thoughts?
>
> David
>
> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Thursday, February 13, 2003 9:53 PM
> To: Dale Moberg; Duane Nickull
> Cc: Burdett, David; www-ws-arch@w3.org
> Subject: RE: Layers in the WSA (was RE: [Fwd: UN/CEFACT TMG Releases
> e-Bus ines s Architecture Technical Specification for Public Review])
>
>
> > One reason actually provided for discussing CPAs instead of putting
> > all the CPA information in various SOAP headers in every message was
> > simply to avoid the repetition of the same unchanging configuration
> > information in each of the messages. A retailer replenishing stocks from
> > its manufacturer in effect sets up a "delivery channel" for message
> > traffic whose security, reliability and other Features do not change
> > over a scale of months, even years. When this aspect of collaboration
> > dominates, interest in "dynamic" contextless access drops off
> > considerably. Interest in predictability, monitorability, and simplicity
> > of lifecycle management of collaboration configuration information go
> > way up.
>
> I am not a big fan of the way CPA handles various bits information, nor of
> the fact that it mixes the SLA with the protocol binding configuration. I
> think the SLA belongs in the application and the sender identification is
> best done using PKI. I also think negotiation of anything is a form of
> interaction, hence my preference for the mobile agent approach.
>
> On the other hand your statement is very accurate and applies to
> just about
> any specification in this space. We stand to loose if we put too
> much static
> information inside the SOAP (or other) header. If you move static
> information to the headers then predictibility becomes so complex it is in
> fact impossible. Static information best belongs in the CPA, WSDL, or any
> other service definition and should remain there. Only data that changes
> from one message to another, or must be encoded in the message
> (and the less
> the better) belongs in the message.
>
> I can't give a concrete example right now, but I've seen one or two SOAP
> extensions that include information that is best left to the WSDL
> definition.
>
> I also agree that URLs are not enough, but I think WSDL gives a good
> framework for describing a port which can include a variety of information
> in addition to the URL. It's just that little attention has been paid to
> extending the port type definitions to allow more complex transport rules.
> I'm sure that will come in due time.
>
> arkin
>
> >
> >
> > -----Original Message-----
> > From: Assaf Arkin [mailto:arkin@intalio.com]
> > Sent: Thursday, February 13, 2003 7:44 PM
> > To: Duane Nickull
> > Cc: Burdett, David; www-ws-arch@w3.org
> > Subject: RE: Layers in the WSA (was RE: [Fwd: UN/CEFACT TMG Releases
> > e-Bus ines s Architecture Technical Specification for Public Review])
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Duane Nickull [mailto:duane@xmlglobal.com]
> > > Sent: Thursday, February 13, 2003 8:51 AM
> > > To: Assaf Arkin
> > > Cc: Burdett, David; www-ws-arch@w3.org
> > > Subject: Re: Layers in the WSA (was RE: [Fwd: UN/CEFACT TMG Releases
> > > e-Bus ines s Architecture Technical Specification for Public Review])
> > >
> > >
> > >
> > >
> > > Assaf Arkin wrote:
> > > > For example, you can have a service level agreement that need to be
> > > > pre-negotiated and all messages have to carry the SLA number to be
> > > > processed and the SLA can be started and managed by some WSDL
> > > operation.
> > > > There is no need to negotiate messaging-level agreement, and the
> > > > negotiation of another agreement could be in itself a service.
> > > >>>>>>>>>>>
> > >
> > > I thought of that in ebXML as well, however I personally pushed for
> > > the CPA to be required and processed in the outermost envelope.  This
> > > was an architectural decision based on the rising popularity of DOS
> > > attacks (denial of service).  It is foreseeable that someone could
> > > pump in 1000's of bogus messages if they wanted to tie up a specific
> > > BSI (Business Service Interface).  The TA team was constrained by
> > > making sure we thought of hacker attacks, no single point of failure
> > > etc..
> > >
> > > By parsing and comparing the CPA ID in the outermost envelope at the
> > > messaging layer (probably by slurping the first 500 bytes via SAX),
> > > it requires far less processor resources than to open the envelope
> > > first, then route the message payload to another resource before
> > > trying to validate the service level agreement.
> >
> > Security by obscurity ;-)
> >
> > If the message is not encrypted it's easy for an attacker to obtain a
> > CPA ID and use that for a DoS. If the message is encrypted then the
> > signature is used to filter bogus messages from real messages.
> > Signatures is the only solution I am aware of for the generals problem
> > which is basically this form of attack (attacker masquarading as
> > sender).
> >
> > I assume we all agree WS-Security provides a better framework for
> > identifying the sender and determining whether or not to accept a
> > message from that sender in a manner that is truely secure and with
> > multiple mechanisms.
> >
> > I basically think it's wrong for a specification to try and solve
> > problems that are outside it's jurisdiction. On the other hand, it
> > should use an open framework to allow such solutions to be used in
> > combination. So one of the value statements of WSDL is that it allows
> > such specifications to exist. You can always create a better security
> > specification and use it to reference WSDL operations to which the
> > security policy applies. (And a million other things, like transactions,
> > business commitements, billing, analytics, etc).
> >
> > arkin
> >
> > >
> > > For right or wrong,  that was the thinking.
> > >
> > > Duane
> > >
> > >
> > >
> > > --
> > > VP Strategic Relations,
> > > Technologies Evangelist
> > > XML Global Technologies
> > > ****************************
> > > ebXML software downloads - http://www.xmlglobal.com/prod/

Received on Saturday, 15 February 2003 20:43:13 UTC