OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebsoa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


In the Best Practices document, does current and project future level of
adoption of an initiative/standard factor into whether or not we cite
it, along with level of vendor implementation?

I am highly concerned that we are basing "best practices" on foundations
that are not implementable or adoptable. If this is the case, they
cannot be "best" - they should be titled "Possible Practices".

Joe

Duane Nickull wrote:
> 
> 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

-- 
Kind Regards,
Joseph Chiusano
Associate
Booz | Allen | Hamilton


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]