[Post-F2F] Re: [ebsoa] Blurb about ebSOA Work (For Interview)

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Looking back at this April 2nd e-mail with a post-F2F perspective: How
well did we address Dale's concerns below?

Joe

Dale Moberg wrote:
> 
> 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!]

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