|
YES ... Sign me up for the ebXML Forum Newsletter
Email Address:
ebXML Forum does NOT send unsolicitied e-mail.
|
Standards for a Service Oriented Architecture
Jean-Jacques Dubray
Technical Architect, Attachmate Corp
Editor's note: Jean-Jacques Dubray, editor of OASIS's ebXML Business Process Specification now in development, gives his views on
the structure of Web services and the role within that structure that ebXML can play.
Long is gone the time of XML, XSL or ebXML specifications where individual contributors could make available all the knowledge and
wisdom accumulated in the trenches of their careers, for the greater good of the rest of us. There is no more room for a Tim Bray, a Jim Clark or a Duane Nickull and their colleagues,
unless they somehow work for one of the "Big Six ". Even the W3C rules seem to be designed to elect the ones that can contribute and donate their resources to specifications. How did we
ever come to believe that we, the craftsmen, would be building the roads and they would be building the cars?
The Web services specification stack is now under the control of one European and five US companies. If the world of standards has not
become simpler or better, it has surely become a lot more political. Writing a specification has become a competition not a mission. Yet despite all this micro-management, muscle and
brain power, a lot of people still ask: Could you point me to THE Web services stack picture?
Actually, there seem to be no end in sight to the Web services stack. When will we get a set of stable specifications, non-overlapping
and interoperable? The latest addition to the stack is Web Services Composite Application Framework or ws-caf, which debuted at OASIS on 31 October, submitted with the help of Oracle
and Sun Microsystems, loosely competing with specifications produced by the other Big Six . So if this specification is part of the stack, we would have to wait for about 18 months
before the stack is complete assuming no other (counter)specification comes along and WS-I needs to police any one of them.
Messages, Services and Service Oriented Architecture
Figure 1 shows a taxonomy for a Web services stack. One of its merits is that it can predict relatively well when the work will end. Specifications are classified along two axes. One
axis deals with the specifications' applicability: run-time, design-time or both. The other axis features the three fundamental concepts of modern computing: Messages, Services and
Service Oriented Architecture (SOA). Some standards can be used at the message level only (this level is often omitted). Specific message interchanges can be composed in Services.
Services can be used by themselves or within a Service Oriented Architecture. In addition, an SOA needs a "fabric" to operate efficiently.
|
Figure 1. Web Services Technologies
Click on image for full-size
|
The Big Six have done a pretty good job at coming up with specifications for the Message and Service levels. Completion is within
reach. They accomplished so far one thing: unifying distributed computing and the Web related technologies. One can now REST an XML document over HTTP with some pre-selected level of
service and describe what to do or supposed to do using some declarative XML-based language. In this process, the message has won over the method.
For the SOA level, we are at crossroads, somewhere within the Silicon Valley, Redmond and Yorktown Heights Triangle. UDDI was the tip
of the iceberg, but the coming 12 months will be decisive. The battle for control of the SOA specifications will happen and the winners and losers will be soon known.
SOA is important, very important. Why? Because the competitive advantage and therefore the value of IT is not a matter of
functionality or infrastructure anymore (i.e. "IT does not matter" ), or just quite yet a matter of business processes. In a massively connected world of "peers", the value of your IT
assets is defined by how efficiently your peers are integrated (coupled) with each other within and across corporation boundaries. Yet, peering Web services into meaningful units of
work that accomplish definite goals -- e.g. something as simple as fulfilling a single order of a series of parts from a buyer to different suppliers -- cannot be efficiently specified
with the existing specification drafts. And it does not matter if that specification is called composition, orchestration, choreography, coordination, protocols or collaboration, just
to mention a few. Which one to choose? Are they the overlapping concepts or complementary?
ebXML's Layer in the Stack and Path Forward
By addressing a large class of business integration problems via true peer-to-peer message interchanges, it would be difficult to argue that ebXML and its concept of Collaboration is
not an integral part of an SOA. Is it enough? No. Will ebXML continue to evolve? Yes. Will ebXML be sometime soon layered on top of Web services related specifications? I wish and hope.
All ebXML specifications will probably sit at the level of Business Agreements Languages level in Figure 1.
So the question is what is the path forward for ebXML and Web services technologies at the SOA level? For instance, today ebXML's BPSS
is a lot of things aggregated in one specification. It was designed that way because at the time we could not rely on any other brick. In September 2003, the Web services choreography
group released the draft of Web Services Choreography Description Language or ws-cdl which specifies the choreography of messages exchanged between peers. In ws-cdl, every message is
equal, whether it is a protocol message like a BPSS business transaction protocol signal or a message carrying a business object (like a purchase order request) or a message notifying
the change state of state of a business object (e.g. Select Quote message).
From there, it takes only one step to think that BPSS could specify the intent and type of messages with business semantics, while
referencing choreography definitions as part of its business transaction, binary and multiparty collaborations definitions. When ws-cdl is published (probably sometime in 2004), it will
not feature any business semantics to enable B2B choreographies or B2B architecture. Why not rely on BPSS in particular, and on the ebXML architecture in general? It is also reasonable
to think that BPSS could use protocol specifications such as Business Transaction Protocol, the newly started specification ws-caf , or other more specialized protocols. ebXML's
Business Service interface could be viewed as a ws-caf coordinator. BPSS could also offer to the Web services stack some of its protocols that enable state-alignment between peers, a
fundamental problem in Service Oriented Architecture.
Collaboration, choreography or coordination are concepts that define the fabric of an SOA. In addition, there is also a need to be
able to efficiently build services that can participate in an SOA. A lot of simple services will probably be able to participate in an SOA as is, however, if all services were to be
simple services waiting for a request to respond, it would be far-fetched to call that an SOA. Most services in an SOA will be orchestrated or composed. Composition is actually a subset
of orchestration. I call these types of services "processing entities". As such, a Service Oriented Architecture has no center. It is merely defined by processing entity peers that
exchange messages.
The behavior of a processing entity in an SOA is like a program, in that it is executed. Unlike traditional programming, their
behavior is long-running, ticked by the sending and receiving messages, most often in an asynchronous manner. This is what orchestration and composition help us specify. They require a
new computing paradigm as procedural languages are showing their limits. If we could redefine a Turing Machine in an SOA, it probably would look like a machine that owns a data set. It
can transform the structure and content of this data set and can either write the result back into its own data set or into the data set of another machine. The write operation would be
synchronized.
|
Figure 2. Standards for SOA
Click on image for full-size
|
The standardization of orchestration and the emergence of a new application model will also benefit from a robust B2B layer, such as
ebXML, in the Web services stack. As a matter of fact, orchestration could take its full dimension from the extension of the business semantics to the application model.
The Service Oriented Architecture is still evolving rapidly. Many working groups and specifications have come and sometimes gone or
otherwise merged. The fact is that composition, orchestration, choreography, coordination, protocols and collaboration specifications are all complementary and not competing (Figure 2).
All these working groups must now work together to enable, as a whole, Service Oriented Architectures. ebXML has definitely a well defined place in the Web services stack at the SOA
level.
Jean-Jacques Dubray is a Technical Architect at Attachmate Corp., in charge of developing a new concept of enterprise
infrastructure software related to SOA. Mr. Dubray has been involved in BPM and B2B related technologies since 1997. He has contributed to many specifications including ebXML BPSS, BPML
0.4, WS-CHOR and OAGIS. He is the editor of the ebXML BPSS 2.0 specification as part of the OASIS ebBP TC and a member of the board of advisors of the Center for XML and Web services
(CUNY).
|