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

["David RR Webber" <david@drrw.info>]

Dale,

That certainly summarizes the gumpf Duane posted - but you still
need to tie it in to the audience - G2C, G2B, etc... I'm sure Joe
can manage that though.

DW.

----- Original Message ----- 
From: "Dale Moberg" <dmoberg@cyclonecommerce.com>
To: "Duane Nickull" <dnickull@adobe.com>; "Chiusano Joseph"
<chiusano_joseph@bah.com>
Cc: "ebSOA" <ebsoa@lists.oasis-open.org>
Sent: Friday, April 02, 2004 1:19 PM
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!]