[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
At this point, I am still skeptical about "metaservice"
<myTurnToDuck> providing me anything critical. If we have any
dynamic element, there will be services that understand and negotiate
(or can make use of specific capabilities that do this) among options
and ambiguities. I'll name them something special when I really
understand the special they are doing.
Ken
At 04:34 PM 3/2/2006, Chiusano Joseph wrote:
>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
> > /
> >
> > --------------------------------------------------------------
> > --------------------
> >
> >
--
---------------------------------------------------------------------------------
/ 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]