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

[Duane Nickull <dnickull@adobe.com>]

David et al:

The official "gumpf" has to be in alignent with the charter.  While 
anyone could say whatever they want to the press, if it conflicts with 
the TC's consensus, that may not serve the TC or the press.  There is 
already enough confusion in how technology gets reported.  

Let's not say anything more at this point until we meet face to face to 
discuss.  There is certainly enough SOA excitement to keep the press 
happy for 3 weeks.

ciao

Duane


David RR Webber wrote:

>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!]
>
>  
>

-- 
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com