RE: Mapping Specs to the Architecture

Mapping Specs to the ArchitectureDavid,

You're raising very important questions and I wish I had a solution.

As a vendor which specification do you pick to be in the 'winning circle'?

WSDL 1.2, SOAP 1.2 and UDDI 3.0 look promising but are not yet at the point
where we can use them. WSDL 1.1, SOAP 1.1 and UDDI 1.0/2.0 are here and
working but will be superceded by later versions. There's a cost involved in
supporting old and new versions, and a risk involved in supporting one
version and not the other. Like it or not, during some transition period
we'll have to hedge out bets and support them all.

I know the discussion was not about which version of WSDL the WSA
references. It was about specifications that have different names and
different owners. But I think the analogy serves a purpose. Technically
speaking, the difference between, say BPEL4WS and WSCI, is not much bigger
than the difference between any two versions of SOAP or WSDL. Different
namespace, slightly different syntax, different list of authors, but can
anyone spot the "big difference"?

Yes, there are differences, and I can spend all day discussing the various
merits, limitations and curiousities of the different coordination,
choreography and RM specs. But at the end of the day, most of what these
specs are intended to do they do in pretty much the same way, and if you've
done one you've pretty don them all.

Our architecture, strangely enough, does not discuss any specific XML format
for expressing transaction contexts, choreographies or reliable messaging.
We could have easily made a decision to support one combination, say WSCI +
WS-Tx + WS-RM, or maybe BPEL4WS + BTP + TRP, or any of the other combination
(is anyone keeping count?) Instead, we made a decision to do choreography +
coordination + RM. Import/export deals with the rest.

That's a recommendation for the version 1.0 of the WSA document. Keep
talking in abstract terms, define what choreography means, why coordination
is important, where RM fits in, and let the dust settles before saying which
spec does what. After all, when I wake up tomorrow morning, there's a pretty
good chance that I'll find 'yet another' spec waiting for me to read.

But that's not a solution for Web services. I can manage an abundance of
specs in 2003. But if we still have this problem in 2004 then we have to
admit failure of the Web services model.

Web services, as I understand them, help our customers by reducing barriers
and throwing integration problems out the window. An abundance of
specification creates barriers, integration gaps and makes it too damn hard
to make an educated decision. We're at a high risk of moving forward by
repeating the mistakes of the past. Did we not learn a lesson from the CORBA
vs DCOM wars? OSI vs TCP? J2EE vs .Net?

Clearly, the industry will benefit if we can bring some sanity and educe
redundancy by addressing one well defined problem with exactly one spec. Tim
BL's was asking why the emperor is naked. The fact that we can't answer such
a simple question should be a concern on everybody's mind. And it's the
WSA's task to find an answer.

But not by picking a "winning" spec. The proliferation of specs actually
does a service to the industry. It brings innovation. Maybe one spec
overlaps with another by 80%, but the remaining 20% - that's innovation.
I've read through all these duplicate specs and I firmly believe that each
one brings some value to the table. Picking one spec because our name is on
it or because we already have an implementation - that's the industry's
equivalent of tossing a coin.

We should work towards consolidation, but we should also leverage innovation
not merely discard it. It's not easy, but that's our job.

After we've  acknowledged the value of each and every spec, and thanked the
vendors that took the time to create and publish them, we should all be
working to reduce the clutter on our desks. The W3C, OASIS and other bodies
provide a forum where multiple vendors could come in together and bring
their unique expertise to create better and fewer specs. The WSA represents
a diverse collective of companies from all over the spectrum - it's in a
unique position to put multiple vendors around the same table and work out
how to make that happen.

So which choreography language would it be?

In 2003 our product will have to support at least two specs, maybe even
three. But I truely hope that come 2004, my company and every other vendor
would all be able to standardize on a W3C Recommendation and feel confident
that the best interest of our customer has been served in the creation of
that spec.

arkin


  -----Original Message-----
  From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of David Orchard
  Sent: Tuesday, March 11, 2003 5:03 PM
  To: 'Champion, Mike'; www-ws-arch@w3.org
  Subject: RE: Mapping Specs to the Architecture


  I agree we could do it in principle.  Indeed, I do this in my talks to
show some of the range of possibility.  But that's typically me showing the
lay of the land.  One could argue sure, the wsa could do the same thing.
But why?

  Let's go down the trout pond slightly:

  We talk about choreography.  So now we list a few acronyms.  Then we start
describing them.  Oh, and now we better compare them.  Then I see value
judgements emerging "In this particular scenario, foo is better than bar".
But I as a vendor will have opinions about those values.  Which means we
need to pick winners.  Ouch.  As soon as we start "documenting" the lay of
the land, I think we will end up being in trouble.

  I guess where I'm going, is that I'm also torn on this.  Doing an
architecture that doesn't mention a single spec other than soap, wsdl is
probably not as useful as it could be.  But where do we draw the line on
what we mention, and thence compare?  Should it be on areas where there is
no obvious disagreement, say ws-security?

  I ask again, what would the point be? Is the ws-arch to provide
educational material, ala conferences/books?  There's a big difference
between doing an architecture for education reasons vs doing an architecture
for describing properties/constraints.

  Cheers,
  Dave
    -----Original Message-----
    From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Champion, Mike
    Sent: Tuesday, March 11, 2003 1:49 PM
    To: www-ws-arch@w3.org
    Subject: RE: Mapping Specs to the Architecture



      -----Original Message-----
      From: michael.mahan@nokia.com [mailto:michael.mahan@nokia.com]
      Sent: Tuesday, March 11, 2003 4:34 PM
      To: dorchard@bea.com; UCorda@SeeBeyond.com;
RogerCutler@chevrontexaco.com; www-ws-arch@w3.org
      Subject: RE: Mapping Specs to the Architecture


      I would have to concur with DO here. I think that performing this
mapping is not in our scope, and puts us into the troutpond of choosing
winners and losers and having to actively be comparing and contrasting all
the specs which swirl about in this space. I think this work is better
served by our respective corporate product stategists and the slew of techno
journalists.

    I guess I see this argument better now.  But on the other hand, if we
can't say something like "BPEL,. WSCI,  BPMI, .... all share the following
properties [A, B, C ... whatever they are] that characterize "choreography"
in the WSA."  Assuming for the sake of argument that such a thing were
possible, what's the objection?  Perhaps it would take to much effort to
figure out what all the acronym soup really does at a level of detail and
that we should leave the analysis of how our concepts and relationships map
onto specific specs to the pundits and product marketers ... but would
people agree that this is something that we should be able to do in
principle?