[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebsoa] Blurb about ebSOA Work (For Interview)
Duane writes: I would suggest lifting a sentence or two from our charter document for the interview. It captures the intent perfectly. Since we have had no formal meetings since the announcement, we cannot tweak it since that may not be reflective of the groups consensus. How about: "The TC is focused on building a modern Service Oriented, Event Driven Architecture specifically applying the web service paradigm to the arena of global electronic business. The TC's output will be to reflect advances in convergence between web services and ebXML stacks and capture that output in a revision to the ebXML Technical Architecture." Dale wonders> I unfortunately had a conflict during the informal Friday call last week. I personally think that some charter bashing will be in order at New Orleans to clarify just what's in scope in ebSOA. Some of us signed on to this group understanding that it was a continuation of the Architecture work of ebXML, and was a new friendly home for these efforts. What bothers me is saying "building." My understanding of Architecture was that it was mainly to be descriptive and not constructive. So, for example, ebMS has a version 3.0 feature preview that is migrating to a version 3.0 requirements. Places for SOAP 1.2, WSDL, WSS, WS Reliable Messaging (OASIS flavor), SAML, and other stuff is under consideration. This mundane header block convergence probably does involve viewing the ebMS MSH as doing some more WS-ish than it has done before. CPA 2.x and beyond will, eg, allow WSDL descriptions of the interfaces exposed by a MSH. BPSS 2.x and 3.x will incorporate WSDL described processes within a BPSS Process Specification in some manner. The result may be something like a SOA with a document literal flavor, but I am uncertain that ebXML is driven by identical requirements as WS SOA. For example, is ebXML really all that concerned with strongly dynamic WS? Do we care if we don't pass WSDL service descriptions in messages that are then dynamically invoked by a service on a different service? [This may be a cool WS analog of passing pointers to functions but is it really something we want to put into ebusiness? How about dropping a function pointer that serves as a sink for all your customer information, is that something you want to dynamically invoke based on some client's wsdl service callback? I suspect that the forklift would eventually get invoked to remove such a platform from my data center.] There are also fundamental security, business practice, trust, and legal aspects to all this dynamism that we must consider. This makes we wonder whether "event driven" SOA will really be descriptive of ebXML at the 3.0 level. [I assume it is the dynamism, and not the publish-subscribe sense, that the phrase "event driven" was adding. Maybe I'm wrong. But at any rate, even if I misunderstood, my point remains that this needs careful scope debate!]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]