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.

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.

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.
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?
2. Should WSDL and ebXML CPA merge, in some way, in some forum yet to be
determined?

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 Friday, 14 February 2003 13:13:53 UTC