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

>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 agree that CPA/CPP approach of encapsulating and aggregating
variious b2b collaboration that are really just SOAP features
is a bit mixed up which makes it hard to just get at the
bits you need to do a various ranges of SOAP message exchanges,
i.e., some not as complicated as the others.

Furthermore, having ability to remotely access the SLA or
other message exchange features (signature, encryption, 
transport, etc.) should be standardized, perhaps via WS-Policy,
WS-Policy Attachment, WS-Policy Assertions in a way that
they are employed only to produce or consume SOAP messages
rather than be attached as a header extension to them. These
specifications, not yet standardized, are very much designed
around WSDL descriptions which can either contain policies
and/or have references to them at external source.

However, CPP/CPA are the only real, interoperable solutions
in this space for SOAP message exchanges today. The only
problem is that they are geared towards more complex message
exchanges for (heavier footprint) B2B applications.

If we can eventually merge CPP/CPA towards WSDL such that
we also can develop standardized vocabularies to describe
policies, SLA, and other relatively static configration
properties of services using some of the building blocks
in the evolving standards then that would be step in the 
right direction towards policy interoperability and 
combinations among the current crop of web services 
products.

thanks,
Zahid Ahmed


-----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 01:52:08 UTC