RE: [ebsoa] Scope of TC

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

2 positive comments in line.

Duane writes:
"This is a good conversation however I think we had agreed in New
Orleans 
that this TC will use the patterns syntax to define our first work, not 
formal specifications of other groups.  There were several really good 
reasons for this and it does not limit us in any way.  Let me explain.

1. We keep everything defined using a non technology specific pattern. 
 Example:

abstract = sending a message

The implementors can use these to implement a concrete messaging format.

concrete = ( ebXML Messaging || SOAP )

The item they need to correlate is the feature sets and their 
requirements (something BCM can help with)."


+1 
I had not read this connection between patterns and abstraction level
before. Sounds like a good approach to me to not tie architecture
component/functional specification to implementation. The last sentence
is a little too cryptic for me. Will BCM define the feature sets and
requirements for ebSOA?

Duane writes:
"2. The danger is we rely on other specifications is that we are no 
longer a valid architecture if they change their normative functionality

outside the scope of the architectures requirements.  We are defining 
patterns and blueprints for what a component must do.
Example:
The patterns and blueprints show how a human actor sets a token into a 
message for a bilateral service level agreement.  SOAP does not have 
this function, therefore we have a dilemma.  ebXML messaging does and is

a good fit for use within our architecture although it is not 
normatively called out."

Your main point about getting involved in relying on specifications
sounds OK, but the example is possibly misleading.

I think that WS arena has several candidate technologies for bilateral
service agreements. WSPL, XACML and eventually WS-Policy may partly
implement that functionality. The W3C announced an October discussion
meeting on these topics, so there may be an(other) open specification on
these matters. [I know there is interest in the ebXML CPPA as to how one
could xslt transform between the approaches if it becomes just a matter
of tag names and syntax.] WS-CDL may also partly implement process
agreements. Maybe WSDL, being an interface/binding  definition language,
can be viewed as specifying a contract for which a human could set a
token (endpoint value, e.g.). ebXML has CPPA and BPSS to specify aspects
of the contract. Initially I think the totality of WS specifications
seemed to be missing a few parts present in the collection of ebXML
specifications, but gradually the collections are moving toward a
functional parity. ebXML's current convergence tactic (3.0) is to adopt
functionally equivalent WS specifications to reduce the implementation
burdens on developers and users alike. I find it particularly ironic as
the two sets of specifications grow functionally comparable, that
architectural people are urging the ebXML stuff to be thrown out. On
what basis?  I would hate to see ebSOA degenerate into the kind of
technical marketing buyer's guide that the w3c architecture document did
(captured perfectly in their mantra that a web service is something that
uses SOAP and WSDL and UDDI, or at least 2 out of 3).