[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]