[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] [Somewhat OT - "Contextual SOA"] FW: [xml-dev] Schema Extensibility
Makes sense Ken. I wonder if a "metaservice" <duck> is what would be used to create the various versions of the execution contexts (kind of like how one could have a "master" XML schema and generate sub-schemas from it as needed for given scenarios, as the Global Justice XML Data Model (GJXDM) does). Just a thought. Joe Joseph Chiusano Associate Booz Allen Hamilton 700 13th St. NW, Suite 1100 Washington, DC 20005 O: 202-508-6514 C: 202-251-0731 Visit us online@ http://www.boozallen.com > -----Original Message----- > From: Ken Laskey [mailto:klaskey@mitre.org] > Sent: Thursday, March 02, 2006 4:28 PM > To: Chiusano Joseph; soa-rm@lists.oasis-open.org > Subject: Re: [soa-rm] [Somewhat OT - "Contextual SOA"] FW: > [xml-dev] Schema Extensibility > > To me this sounds like the interacting entities have > established an execution context and, having done the hard > work once of negotiating policies and constraints (both > business and technical), they saved the result and just reuse > it on a regular basis. While it can be looked at as > point-to-point, it is reusable by anyone taking on the > characteristics of one of the points and the saved execution > context can be modified (versioned?) with either the original > or the modified being used since you would identify the EC > you are using. > > A barely thought-out response but does it make sense? > > Ken > > At 02:00 PM 3/2/2006, Chiusano Joseph wrote: > >Yeah, I know we've been through the "SOA and Context" thing already, > >but...: > > > >Forwarding an e-mail from the XML-DEV listserv yesterday - it's > >actually a reply by me to a question of XML schema > extensibility (is a > >good thing, what are the dangers, etc.) that later transitioned into > >the SOA realm. > > > >In my reply, I brought up the notion of "Contextual SOA" - > essentially > >SOA-based exchanges between multiple partners in which one or more > >require a specific "context" for their exchange that sets them apart > >from the others - e.g. an additional element in a message, an > >additional message, etc. My use of the term "Contextual SOA" > here means > >that such "exceptions" can be handled in a robust manner, perhaps > >according to a > >(to-be-developed) standard. > > > >More below - the SOA portion is the latter portion. > > > >Surprisingly (to me at least), no one on XML-DEV contested > my thoughts. > >Anyone here? > > > >Joe > > > > > >Joseph Chiusano > >Associate > >Booz Allen Hamilton > > > >700 13th St. NW, Suite 1100 > >Washington, DC 20005 > >O: 202-508-6514 > >C: 202-251-0731 > >Visit us online@ http://www.boozallen.com > > > >-----Original Message----- > >From: Chiusano Joseph [mailto:chiusano_joseph@bah.com] > >Sent: Wednesday, March 01, 2006 8:09 AM > >To: Fraser Goffin; xml-dev@lists.xml.org > >Subject: RE: [xml-dev] Schema Extensibility > > > > > So, in part the question is, should a schema allow for unknown > > > extensions for unknown purposes (but in specified > > > locations) and still be considered as 'compliant', or > should schema > > > authors attempt to constrain (eliminate) that behaviour. I can't > > > help feeling the attraction of the second model, but my > 'gut' tells > > > me that > > > > > something as inflexible will soon become a business > constraint and > > > that will signal it's demise. > > > >I believe this is a case-by-case basis, that depends on the specific > >scenario(s) and business need, and - ultimately - what the level of > >risk regarding "unknown extensions" is, and whether or not > that level > >of risk is acceptable for the particular case. > > > > > With my SOA hat on I would recognise the importance of > > > interoperability and the significant role that standardised > > > vocabularies have to play. I also don't especially want > to promote > > > the > > > > > myriad of point-to-point relationships that 'going > private' implies > > > and instead want to leverage the 'reach' of a market standard. > > > >Extensibility can also play a significant role in SOA-based > scenarios > >(service-oriented systems). This can be handled via > "contracts" between > >parties that specify a particular data model associated with > a service, > >that may be different than that used by other parties that > base their > >exchanges off the same "base" schema. Is it easy to do right now? No. > > > >I have long believed that a standard is needed for > "Contextual SOA" - > >i.e. cases in which one or more parties that engage in a particular > >exchange have a special need for extensibility, and the system that > >handles the messages (assume SOAP messages here) for that party > >automatically knows to expect the additional constructs > (message parts, > >messages, etc. - possibly further up than that in the WSDL > hierarchy?) > >from that party and to handle them according to a specified contract > >involving that party. We'll get there... > > > >Joe > > > >Joseph Chiusano > >Associate > >Booz Allen Hamilton > > > >700 13th St. NW, Suite 1100 > >Washington, DC 20005 > >O: 202-508-6514 > >C: 202-251-0731 > >Visit us online@ http://www.boozallen.com > > > > > > > -----Original Message----- > > > From: Fraser Goffin [mailto:goffinf@hotmail.com] > > > Sent: Wednesday, March 01, 2006 6:48 AM > > > To: xml-dev@lists.xml.org > > > Subject: [xml-dev] Schema Extensibility > > > > > > For a while I have been continuing a thread which started out > > > thinking > > > > > about versioning of XML schema types, in particular enums. The > > > debate broadened and a variety of helpful and interesting > views were > > > voiced about versioning in general and as a related > subject extensibility. > > > Personally I have been relating these comments to XML schema > > > structures but I could have easily been talking about the service > > > interface supported by those schema. This has highlighted some > > > different opinions about the value of various approaches to this > > > problem which I hope have resonated with those following > the thread. > > > > > > I have become quite interested in the UBL work that Ken > Holman has > > > introduced and the position UBL is taking about the separation of > > > the validation of structural conformance versus value based. > > > > > > I guess the thing that I am still mostly undecided about is to do > > > with > > > > > whether to allow for schema extensibility (using xs:any together > > > with the 'sentry' approach proposed by David Orchard (and > others) or > > > whether this is a recipe for an uncontrollable vocabulary. > > > > > > I think the battle-ground is in part characterised by a schema (or > > > service) that, once published is considered as immutable, > hence any > > > changes REQUIRE a NEW VERSION with a NEW NAMESPACE, > versus a schema > > > which allows non breaking changes to be introduced by both the > > > schema owner and non schema authors and supports both forward and > > > backwards compatibility. > > > > > > The first situation is a 'clean' and explicit model where the > > > semantics are guaranteed not to be usurped by a non > schema owner but > > > where even relatively minor change requirements can have a large > > > impact to implementations (especially when there are a > large number > > > of > > > > > external users of this vocabulary). > > > Changes often take a relatively long while to surface > through into > > > the > > > > > standard and this may impact business priorities. > > > Versioning is enabled through support for one or more of the > > > available > > > > > schema where, from time to time, old versions may be deprecated. > > > > > > The schema extensibility approach promotes the idea that > > > organisations > > > > > may want to represent private relationships using data carried at > > > specified points within the standard schema in such a way > that that > > > data is only relevant between those parties (using a foreign > > > namepsace) and all others can safely ignore it (and that > the schema > > > author should not necessarily attempt to constrain this type of > > > usage). It recognises that the pace of change to a > standard schema > > > often lags behind the operational requirements of user > > > organisations, but those organisations don't want to > throw out the > > > whole standard and > > > > > 'go private'. It can imply that some TP extensions may be > > > incorporated > > > > > back into the main body of the standard at a later point in which > > > case > > > > > anyone pair or parties using that extension can agree a > move back to > > > the standard definition, at a time of their choosing. It > also allows > > > the schema owner to add non breaking 'compatible' > > > change to a schema. The down sides seem to be, that a TP could > > > introduce changes which subvert the intended semantics, and that, > > > over > > > > > time, what might have started out as a temporary expedient, turns > > > into > > > > > an entrenched working implementation that is unlikely to be > > > allocated budget to be re-synchronised with the standard. > > > > > > So, in part the question is, should a schema allow for unknown > > > extensions for unknown purposes (but in specified > > > locations) and still be considered as 'compliant', or > should schema > > > authors attempt to constrain (eliminate) that behaviour. I can't > > > help feeling the attraction of the second model, but my > 'gut' tells > > > me that > > > > > something as inflexible will soon become a business > constraint and > > > that will signal it's demise. > > > > > > With my SOA hat on I would recognise the importance of > > > interoperability and the significant role that standardised > > > vocabularies have to play. I also don't especially want > to promote > > > the > > > > > myriad of point-to-point relationships that 'going > private' implies > > > and instead want to leverage the 'reach' of a market standard. > > > > > > Personally I still have no definative conclusion that I feel > > > comfortable in turning into a recommended approach within my own > > > organisation and within the industry standards body that > I work with > > > from time to time, so I thought I'd give it one more go. > > > > > > Some of the issues and comments highlighted by the earlier thread > > > are provided below. Some are direct quotes from > contributors, others > > > are excepts from various ramblings :-) > > > > > > Cheers > > > > > > Fraser > > > > > > ======================== > > > > > > - extensibility is a critical aspect of any data [or > service] model. > > > Without extensibility all changes (however minor) > effectively 'break' > > > all provider and consumer implementations. > > > > > > - there are no 'minor' changes, any change implies a semantic > > > difference. > > > > > > - backwards compatible yes (the previous version of a > schema must be > > > a > > > > > valid instance of the new version), but not necessarily the other > > > way around > > > > > > - xs:any together with the 'sentry' approach proposed by David > > > Orchard > > > > > (and > > > others) provides a mechanism that allows XML schema to be > extended > > > by both the schema namespace owner and a non schema author > > > independantly, > > > > > in a manner which supports forwards and backwards > compatibility for > > > instance documents. That is, some category of change can be > > > accomodated which do NOT cause either the consumer or provider > > > implementation to REQUIRE change. Of course extensions > added by non > > > schema owners represent a private relationship between the > > > communicating parties and therfore require an out of band > exchange > > > of the type definitions and semantics. Also such > extensions can only > > > be applied to specific locations in the base schema AND using a > > > foreign namespace. This is sometimes referred to as the > 'must ignore' > > > pattern. > > > > > > - A 'big bang' approach to versioning is not usually > achievable in > > > any > > > > > practical sense. That is, it is generally not possible to > enforce a > > > 'breaking' change on all users of a schema/service simultaneously > > > (or even within a constrained time window). > > > > > > - Support for a version of a schema/service can in some cases be > > > self regulating. That is, if provider A only supports > version 1.0 of > > > a service whilst the majority of consumers expect to be able to > > > integrate with version > > > 1.1 (or 2.0), then chances are that provider A will be > unable to win > > > any business and will therefore be forced to upgrade. > > > If a consumer supports version 1.0 but all potential [preferred] > > > providers have upgraded to a later version, the consumer > may not be > > > able to place any business on behalf of its customers, and will > > > therefore be forced to upgrade (assuming that version 1.0 > and later > > > versions are NOT backwardsly compatible). > > > > > > - a schema or service interface is immutable. Once published it > > > should > > > > > never be changed (perhaps this is better stated as the operations > > > which make up the service interface should never be changed). > > > > > > - support for concurrent versions of a schema/service is more > > > effective method of dealing with change than through schema > > > extensibility. It makes versions explicitly typed without the > > > ambiguity of untyped sections (xs:any) which require some out of > > > band mechanism to be entered into by each participant. > > > Implementing an explicit new version has the crucial > advantage that > > > it > > > > > is guaranteed NOT to break a consumer implementation using the > > > current > > > > > vesion unless the provider removes that version. > > > > > > - Any change to a schema represents a semantic difference and > > > therefore cannot be considered as 'minor' and therefore > requires a > > > new > > > > > version. > > > > > > - We have come to the conclusion that semantically the > definition of > > > an enumerated field is its enumerations. > > > Therefore changing the enumerations changes the definition. > > > Adding enumerations locally seems like a poor practice. > > > > > > - Adding a new value to a enumeration is not a compatible > change if > > > that value could be returned to a consumer who currently doesn't > > > know about it (using the previous schema definition). If > it's just > > > of the receiving side, it MAY be compatible since the previous > > > version remains a valid sub-set. > > > > > > - schema's defined and managed by a standards body often move too > > > slowly to accomodate the business priorities of particpants. > > > Allowing local extensions can enable an organisation to gain > > > advantage from the > > > > > broader 'reach' of the base standard to the majority of > its partners > > > whilst supporting specific third party relationships > which require > > > additional [private] data not [currently] available > within the base > > > standard. Sometimes this additional data can represent a > 'candidate' > > > standard which may be encorporated at a future time. > > > > > > - When standards become an inhibitor to business operations they > > > will be usurped by local arrangements. > > > > > > - Value based validation can be implemented as a separate > layer, on > > > top of structural conformance. > > > > > > - Synchronisation of schema variants is necessary at the > point when > > > the number of variants indicates that the original semantics may > > > have become obfusticated or a new semantic ecosystem > [related] is emerging. > > > > > > - If a large number (more than 1 :-) of buisness transactional > > > schema include a common complex type, and that complex > type needs to > > > be changed, this can create a synchronisation problem. So > is there a > > > differnt approach to dealing with versioning of shared types ? > > > > > > - We are undertaking a new position where the schema are > going to be > > > used solely for structural validation, and code list value > > > validation (as agreed upon by trading partners) is a > separate step. > > > > > > > > > > > > ----------------------------------------------------------------- > > > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > > > initiative of OASIS <http://www.oasis-open.org> > > > > > > The list archives are at http://lists.xml.org/archives/xml-dev/ > > > > > > To subscribe or unsubscribe from this list use the subscription > > > manager: <http://www.oasis-open.org/mlmanage/index.php> > > > > > > >----------------------------------------------------------------- > >The xml-dev list is sponsored by XML.org <http://www.xml.org>, an > >initiative of OASIS <http://www.oasis-open.org> > > > >The list archives are at http://lists.xml.org/archives/xml-dev/ > > > >To subscribe or unsubscribe from this list use the subscription > >manager: <http://www.oasis-open.org/mlmanage/index.php> > > -- > > -------------------------------------------------------------- > ------------------- > / Ken > Laskey > \ > | MITRE Corporation, M/S H305 phone: 703-983-7934 | > | 7515 Colshire Drive fax: > 703-983-1379 | > \ McLean VA 22102-7508 > / > > -------------------------------------------------------------- > -------------------- > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]