Re: [ebsoa] Scope of TC (was SOA and Shared Semantics / Editors ActionItem, et al)

[Duane Nickull <dnickull@adobe.com>]

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).

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.

Second example:

We have a set of patterns showing something that aggregates data 
elements into a metadata artifact that is used at runtime to constrain 
payload instances.  It works with a context mechanism (also defined by a 
set of patterns/blueprints).  These show functionality that is abstract 
of any implementation.

In our second document, the Best Practices, we can actually point at a 
specific technology for the above (it is three letters long, starts with 
a "C" and ends with an "M") ;-)

Bad example:

If we had just said in the architecture specification to "use CAM", then 
CAM evolves into something other than what we need, our architecture is 
now deprecated and broken.  Since we cannot be prescriptive, it will 
lessen the usefulness of our work.

Duane

-- 
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com