RE: [ebxml-dev] New WSCI spec competes with BPSS.... NOT (very long)

[Jean-Jacques Dubray <jjd@eigner.com>]

Andrzej:

Thank you very much for pointing this specification to us.
________________________________________________________________________
____
Summary

After much blabla and sarcasm I analyze the WSCI spec. Aside from the
fact that this spec is a shameless cut and paste from BPML 0.4, as usual
- and it is now a constant amongst "web services spec writers"- they
treat B2B as an extension of app-to-app integration (with is not the
same as EAI). 

The key semantic of EAI is publish/subscribe. This has been established
for at least a decade with the developments of MOM and yet, the authors
of WSCI try to brainwash us saying that point-to-point integration is
better. You should tell Ford or Boeing about that.

No guys, Collaboration are mostly a B2B concept (see below), and
therefore should have B2B semantics such as non-repudiation, legally
binding, confidentiality, security, tamperproof,... I talk with real
customers every day which need these semantics. I even talked to a
customer today that was pleasantly surprise to hear about Core
Components. He told me this is exactly what he needed as their data
model varies a bit and ofteb with the business partners. I was stunned !
These semantics would not be too hard to add to WSCI, but you guys lack
the understanding of what B2B is about, it is NOT app-to-app integration
over the internet. Where have you been in the last 4 years?

Far from "killing" ebXML this specification represents the missing link
that would allow us to link ebXML with business process definitions. 

I actually feel sorry that someone would like to "kill" another spec.
However, this is good when people use this kind of words, it brings a
lot of suspicion and often signals something without substance.
________________________________________________________________________
____
Disclaimer: all the thoughts expressed here only represent my opinion
and not the one of my company. Some of the comments are for the purpose
of entertainment, given as jokes -french humor- others are an objective
analysis of WSCI/BPSS for the education of the interested reader.

I am sure that some of my comments are plain wrong, out of ignorance or
sarcasm.

I apologize in advance if my comments hurt the sensitivity of the
reader. It must be this hot summer night in wonderful Grotzingen germany
that got me started. Ah... unless it is the mirabelle.
________________________________________________________________________
____

This is always fun to see a new Specification from Intalio (since this
is so much based on BPML 0.4, I assume Intalio is the main driver).
However, it would be nice if they could finish the other specs before
they start new ones, BPML comes to mind. I guess they must be looking
for more funding yet again. We live an extraordinary time, people write
a few paragraphs, add a few ppt figures (you should see BPML 0.1 to
understand what I am talking about), don't forget to fetch a few names
from industry giants, add the smell of "killing" something and boom,
millions of dollars fall from the sky to do more of that, without any
control: does it makes sense? do this guy knows what he is talking
about? If you succeed with the first round, you can even attempt the
second round -the sky is the limit- by changing a little bit your
paragraphs, changing the title, bandwagon the latest hottest idea on the
market, an boom, jackpot again. The odds are far better than the lotto.
I must be in the wrong business.

It is also fun so to see that Intalio finally gets it. Even though I
have a lot of respect for people like Assaf, it would have been only two
years next September that I joined BPMI and try to convince him that
"Collaboration" was a key artifact of the Business Process Definition
metamodel, namely, a Business Process is for the most part a series of
collaborations mediated by the Business Process Engine. This is
represented on figure 1-1 of the WSCI spec. I have shown that kind to
picture in BPMI many times, with all but contempt. In particular this is
what makes the "technical binding" of the operations far easier. The
funny part is that BPML was designed without any alignment with B2B
semantics (as of v0.4) while 90% of the processes that will be defined
with BPML involve B2B interactions! I think that Intalio must not sell
many products so they have not yet integrated notions like orders,
invoices, customer support, negotiation, commitment, fulfillment... They
probably do a lot of internal stuff at this point. 

I commented many times about the "Marketing world" in which we live so
let me comment now on the new ebXML "killer" on the block. As volume,
bass or treble is not an option to carry out your message, the only
thing left is "word inflation". As usual I will try to be as objective
as I can, Assaf is a really smart guy and more than often produces
excellent work: Castor, Tyrex, BPML, I guess WSCI is the exception. 

So let's start dissecting this new killer. The introduction tells us:
"WSCI provides an important foundation for ... application-application
collaboration." Ah..Ah... so they are doing this as an alternative to
EAI.. uhm where is B2B here? .. Ah yes they talk about it later ...
"These business processes may reside entirely within the confines of a
single company, or span across multiple organizations or companies." Yes
this is a constant amongst web services people: lump sum EAI and B2B.
B2B is just application-to-application integration beyond the firewall,
so what's the big deal about B2B? Well, you should try to convince Ford
which has 2500 enterprise systems world-wide, or Boeing which has a mere
84 procurement systems that it has to do application-to-application
integration over the internet with its tens of thousands of suppliers. I
guess Intalio could not be further from the reality. I am surprised that
BEA and SUN could associate their name with this kind of approach. I
would assume, that this is not really SUN or BEA talking just the
individuals eager to paste their names on this kind of sheet (not shit).
However both BEA and SUN don't have much to offer in terms of web
services. BEA has just released a new "IDE for web services" KaKa, Kajun
or something like that but to web service enable what? A few session
beans? SUN is in complete disarray desperately trying to catch up with
.NET and IBM by controlling all the possible web services
specifications. They lost the Java, J2EE, EAI/B2B (Forte) battles with
abysmal market share, to the point that they are now giving away iPlanet
-free, who wants to bet that they will dominate the web services battle?
No the guys that get it are the webMethods, Sybase, IONA's of the world.
Their approach is based on understanding the value and positioning of
Web Services. In particular they are a complementary paradigm to EAI, to
that effect, WebMethods provides the best approach I have seen so far in
the industry, and they don't need to "kill" to sell it (see my summary
on www.ebpml.org/showcase.htm). Yes some of the web service spec and
infrastructure can be reused for B2B but you need the "business
semantics" that WebServices keep lacking. ebXML IS business level web
services, that sits on top of RPC level web services. So let's dive into
this point, boy this is fun.  

First, the acute reader would have noticed that the WSCI bears a strong
resemblance with BPML 0.4., the transaction model, the correlation
model, the choreography model are all direct copy and peste from BPML
0.4. 

In the overview section of the spec, here we go again: "...interactions
between services - either in a business context or not" that statement
suggest to me that they have no Business semantics, I guess that's a
good way to kill ebXML but let's verify that. And they cannot emphasize
this point enough (Thank you guys): "WSCI does not assume that Web
Services are from different companies, as in business-to-business; it
can be used equally well to describe interfaces of components that
represent internal organizational units or other applications within the
enterprise." The problem is that in traditional EAI the business
semantics are an unnecessary burden, while no business semantics makes
the spec unusable in B2B scenarios. This is very layering seems to be
the right thing to do. 

The key semantic of EAI is publish/subscribe. This has been established
for at least a decade with the developments of MOM and yet, the authors
of WSCI try to brainwash us saying that key app-to-app semantics are: 
"Most Web Services, however Participate in longer conversations,
spanning beyond the boundaries of a single operation. In these
conversations, the ability to perform certain operations depends upon
the previous exchange of messages as well as the way to interpret the
content of each message may be influenced by the previous exchange." No
I am sorry, there are very few scenarios in EAI that can be supported by
this kind of approach. You are back to point-to-point, wake up guys ! I
am actually surprised of this approach as Assaf had found a very
interesting concept in BPML (Consume and Produce). However, the spec
breaks the concept with the global model, it is no longer a pub/sub
semantic but rather a binding semantic. Another "detail", I did not find
in the spec the notion of "transformation" though it is a key feature of
EAI system an necessary for loose coupling integrating,... oh yes, this
is the new an improved point-to-point integration model where all
application share the same semantics.

You don't get it, do you? Collaborations are mostly a B2B thing. Yes you
can model some API interaction in point-to-point manner. But, you don't
publish your orders, you send them to your suppliers ! The problem again
is that WSCI does not support any business semantics, not even pub/sub.
Who are you going to convince to use WSCI? Can't use it for B2B, can't
use it for EAI. 

Let's analyze the different aspects of the spec:

First, to be clear, all these concepts are directly repurposed from BPML
0.4. Even the concept of Human Agent is coming from there. I must admit
that I can't wait to see what BPML 1.0 will look like. Maybe a cut and
peste from WSCI? 

I like the distinction between WSDL (Static interface definition) as
opposed to WSCI (dynamic behavior of the static definition). This
approach gives you an automatic binding between the collaboration
definition and the technical parameters of the web service.

"Business processes are increasingly relying upon collaboration", boy
why didn't I think of that before, I guess Assaf, you are finally
getting it. Just change increasingly by "almost exclusively" and you are
there.

"WSCI is not a "workflow description language"": strange, because all
the semantics are coming from BPML 0.4. 

1) Message choreography
"The Action, is the basic construct of WSCI, and it is bound to some
WSDL operation. WSCI specifies how multiple actions are choreographed in
a simple sequence."

An action is actually not a concept really different from operation
here, it is just a bag to add properties to an operation like
correlation and role performing that operation. It is not really an
action in the sense of event condition action, or WfMC actions, the
concept does not relate to "state" or "activity". Actually the best
proof of this is that they stop talking about Action and then talk about
"WSCI describes the behavior of a Web service in terms of choreographed
activities." and "The most common atomic activity is action." This is a
poor choice of word as activity and action have precise semantics in
this context. Also, I sense a design flaw here, do you support the
concept of using an action definition more than once within the
choreography (not part of a loop). BPSS supports the notion of a usage
of a business transaction(~action), this is called
BusinessTransactionActivity which means that the same BT definition can
be reused any number of time. This is a must, this is a very useful
concept. I don't think you have the same thing. Do you?

We can see directly from the example that WSCI is "asymmetric" in other
words, it is designed from the perspective of one side of the
collaboration. So that works well here because the user manages the
collaboration in his head. In a real scenario you need to map the
actions of one side to the one of the other.  Microsoft has struggled a
lot with this asymmetry in XLang, WSFL came out with a more elegant
approach and the concept of global model. I actually can't believe my
eyes, after BPML being a plagiary of XLang (though better), they now
shamelessly "borrow" from WSFL, with the same concept of Global models.
These guys are the champion of cut and peste. As usual, they don't
reference their sources. Your reference list is hilarious. W3C that, W3C
this. How impressive, you guys must be smart to read all these
specifications. See, the worst thing that the web has brought to us is
un-refereed publications. Anybody can publish anything and get away with
it!

In comparison, ebXML is designed in a totally symmetric manner, such
that the business service interfaces of each partner can be configured
from the same collaboration definition. I think that this is a
fundamental flaw of the web services concept when use in collaborative
applications (not in Stock quotes), because you deal with twice as much
xml, plus you need to glue the pieces together. With that respect ebXML
BPSS is far more elegant and efficient. 

The control flow is a "block-structured" control flow and is specified
with the semantics:
Complex processes
Sequential execution
Parallel execution
Looping
Conditional execution

I guess you would have guess by now ... guys this is sick, this is a
shameless cut and peste of BPML 0.4. Unfortunately, I think that block
structured control flow is not the most appropriate choreography model
here. You have definitely negotiation pattern that would be hard to
model with a block structured approach.

Also could you explain me something? Just like ebXML you specify the
choreography of a collaboration, why is it within a <process> element?
Would <collaboration> be more appropriate. It can't be that you read
BPSS too many times, since you have no idea about BPSS semantics. 


2) Transaction boundaries and compensation
In BPSS, we did not find the notion of Roll-back appropriate. So yes
WSCI describes also compensating transaction, which is more the way a
business operates (roll-back is more app-to-app kind of thing). BPSS
does not have that, but we did not find it a hurdle to model real world
collaboration, as they can be modeled anyways, the only difference is
that these business transactions are not tagged as compensating
transactions.

3) Exception handling
The exception behavior is yet a copy/peste from BPML. ebXML BPSS is able
to identity exceptions (technical or business) but let the designer of
the collaboration specify the course of action. It looks more
appropriate to use the WSCI approach (as a java programmer), however,
from a practical perspective, I don't think you gain much there. There
is a key semantic that is missing in WSCI, which I think cannot be
added: BPSS:acceptanceAcknowledgement which signals that a message was
correctly processed by the receiving application. In B2B this is
essential to synchronize the state of two companies. In our world, PLM,
people exchange large CAD files (we have customer which ships a whole
car !). As part of the exchange, you really want to know not only that
your message got there (Via a web service), but that it correctly loaded
in the receiving application whether it is a CAD system, or even if it
is reviewed by a user !!

4) Thread management
WSCI (like BPML) also uses the concept of "correlation" to identify the
collaboration instance of a given message. I personally dislike this
approach and rather carry a cookie around to maintain context. I think
this is more a matter or preference. I feel that the cookie is cleaner
and more general. You don't get stock if the correlation is ambiguous or
need to span several elements of a document. The major advantage of WSCI
approach is in multiparty collaboration as show in their example. But I
don't think they fully solve the multiparty collaboration problem just
yet. BPSS does not either.

5) Properties and Selectors
The property concept is good, as it decouples the choreography
specification from the document formats of the message exchange. BPSS
should use that concept.

6) Connectors
Did not find much about this
7) Operational context
Did not find much about this
8) Dynamic participation
Did not find much about this

So in conclusion, I think they fall short of understanding the B2B
semantics that ebXML implements. I cannot find a customer that told me,
no "I don't need the business semantics provided by ebXML (BPSS in
particular), I can live with XLang or WSFL, and now the new and
turbo-charged WSCI". (Va-va-voom)

However, you do provide the missing piece for linking ebXML to Business
Process Management Systems, which I was trying to introduce when I was
working at BPMI. As I explained in chapter 6 of the book, Professional
ebXML foundation, you need to wrap the ebXML business service interface
into web services in order to let your enterprise systems use the
B2b/Ebxml infrastructure. WSCi represent the missing link which allow me
to strip the business semantics (once you are within your four walls,
you don't need it anymore) and enable a business process management
system to take over and control the b2b collaboration message exchange
with the appropriate interactions of your enterprise systems.

Good work, could do better though. So how long did it take you to write
it? A couple weeks? Maybe a week for the art work? Congratulations on
the coloring scheme, I am sure the VCs will be impressed.

Cheers !  


Jean-Jacques Dubray____________________
Chief Architect
Eigner  Precision Lifecycle Management
200 Fifth Avenue
Waltham, MA 02451
781-472-6317
jjd@eigner.com
www.eigner.com 
 
 

>>-----Original Message-----
>>From: Andrzej Jan Taramina [mailto:andrzej@chaeron.com]
>>Sent: Thursday, June 13, 2002 11:18 AM
>>To: ebxml-dev@lists.ebxml.org
>>Subject: [ebxml-dev] New WSCI spec competes with BPSS....
>>
>>The new Web Service Choreography Interface spec has been developed and
>>released by a consortium including Sun, BEA, Intalio, and SAP.
>>
>>The spec can be found here:
>>
>>	http://titan.intalio.com:8080/intalio/wsci/
>>
>>According to a contact at Intalio (prime movers behind BPMI), and I
quote:
>>
>>> Think of wsci as an ebxml killer and the public interface to any
>>process,
>>> making it reusable and exposing it where needed since that process
is a
>>> private implementation (BPML)
>>
>>Basically, it looks like WSCI is intended to supplant BPSS.  This is a
bit
>>strange,
>>given Sun's participation and support of ebXML initiatives.  WSCI
would be
>>used to
>>specify public processes, whereas BPML would be used to specify
private
>>(internal)
>>processes.
>>
>>It distresses me that the whole world of XML-dialect standards seems
to be
>>splintering as soon as you try to get anywhere beyond the basic specs
>>(XML, SOAP,
>>WSDL, UDDI) that the vendors have all agreed to.  Seems that vendors
are
>>still
>>playing their usual games vying for proprietary lock-in higher up in
the
>>protocol
>>stacks.
>>
>>It behooves the users/customers to loudly complain and demand
standards-
>>based,
>>interoperable solutions.  We've had a taste of the benefits that such
an
>>approach
>>brings to the table....let's keep pounding the vendors till they
deliver
>>on such
>>promises higher in the stack as well.  This also leads me to believe
that
>>there might
>>be market share gain opportunities available to software vendors that
take
>>the high
>>road of global standards compliance (New Era/Sybase come to mind
here).
>>
>>I'ld be interested in hearing from Sun people that hang on this list
as to
>>what their
>>intent is regarding ebXML standards (like BPSS) versus this new WSCI
>>proposal.
>>
>>
>>
>>
>>...Andrzej
>>
>>Chaeron Corporation
>>http://www.chaeron.com
>>
>>
>>
>>----------------------------------------------------------------
>>The ebxml-dev list is sponsored by OASIS.
>>To subscribe or unsubscribe from this elist use the subscription
>>manager: <http://lists.ebxml.org/ob/adm.pl>