Download Critique by Jack Cole (Presenter) and Wei Lui (Discussant) of the

"Colombo: Lightweight middleware for service-oriented computing"
by F. Curbera, M. J. Duftler, R. Khalaf, W. A. Nagy, N. Mukhi, and S. Weerawarana
IBM Systems Journal, Vol. 44, No. 4, 2005, Page(s): 799-820.
Critique by Jack Cole and Wei Lu.
Summary
This paper discusses research exploring the achievability of efficient middleware architectures for
Service Oriented Computing (SOC). The work was conducted at IBM's Thomas J Watson Research
Centre, the home of their "Websphere" Web Services offering.
Colombo is a platform for developing, deploying, and executing Web Services and Service Oriented
applications. The goal is to explore and understand architectures that are designed specifically for SOC,
to determine if they are appropriate to the task. To that end, Colombo and the services it supports, were
purposefully developed "from scratch", avoiding the constraints of legacy systems which offer web
services based on non-SOA designs.
Colombo is both an implementation of a Programming Model for web services development, and a
Runtime Environment for the deployment of these services.
Four principles and requirements governed the creation of Colombo.
1. It must be a faithful realization of the Web Services protocol stack;
2. It must fully respect and incorporate Quality of Service (QoS) statements from all service
providers and requestors;
3. Web Services must be driven by meta-data in the form of machine-readable service descriptions
(XML, WSDL, WS-Policy) and
4. It must provide native support for service creation and composition.
The unit of development and deployment within Colombo is the "servicelet", which is the embodiment
of the "business logic" – the programming behind the service – in Java, or BPEL, or some other
language. Any language can be used, as long as a "Servicelet Manager" is developed to integrate that
language's runtime with the Colombo runtime.
Servicelets interact with other services and the outside world via "conversations" of SOAP messages.
The Colombo runtime handles the routing, transfer and dispatch of messages to servicelets. Servicelets
and conversations maintain what is effectively state information in dedicated "contexts", and in SOAP
message headers. When a servicelet is activated it receives both a message and the servicelet context.
QoS policies for all offered ("client") and utilized ("partner") services, and for the platform as a whole,
are integrated and enforced at the conversation level.
The paper discusses the challenges of some aspects of the Colombo development environment and
runtime, going into considerable detail in the description of servicelet creation, message processing,
routing via WS-Addressing, and the duties of the policy framework. There is no discussion of actual
implementation, nor concrete examples of experience using the platform.
The authors introduce the paper by claiming that Colombo is lightweight and optimized, and greatly
simplifies SOC application development and deployment. However, their summary indicates that the
evaluation of the platform for usability and efficiency has not yet taken place, and since this article was
published there have been no additional reports on such progress. When (and if) those results are
available they should prove interesting.
Critique
The paper is very technical on the conceptual design of Colombo. However, it provides no details on
how Colombo approaches each of its goals, such as service composition. It also does not address the
semantics in service composition, such as best service selection, composition ordering, etc. There is no
noticeable break-through in theoretical aspects; for example, the use of stubs (servicelet, adaptor, and
stub) was introduced in RPC in the early days. In term of semantics, Colombo only emphasizes on
providing of policies and Quality of Service (QoS), which are business-oriented. If semantics are not
addressed, then the same service composition tasks can be hard-coded with existing Web services.
Colombo is in direct competition with other Web services technologies, such as Java 2 Enterprise Edition
(J2EE) and Microsoft .Net. J2EE, for example, is more mature than Colombo. It is a well-established
platform with actual existing implementations in widespread use. Java programs run natively on a J2EE
application server, utilizing the Web services stack available on the server, providing optimized and
integrated solutions.
While Colombo is still under development, J2EE already has a much more complete implementation of
the Web service stack, including all that of Colombo, and more:
 WS-Policy
 WS-Atomic Transaction
 WE-Addressing
 WS-Coordination
 WS-Security
 WS-Resource Framework
Besides the implementation of the Web service stack, J2EE also provides QoS for business transactions.
Enterprise JavaBeans (EJB) is part of J2EE which provides a programming model for writing and
deploying business logic into an application server. EJB can be stateful, stateless, or message-driven.
Service composition with EJB is as easy as connection different components with a Java IDE. Also, EJB
is still loosely-coupled with well-defined interfaces, and uses SOAP to interact with Web services
implemented in any programming language.
J2EE also has Deployment Descriptors (DD), which is an XML file that captures contextual information
about components and applications. DD helps resolve many service composition issues, such as
resolving references, setting policies, and linking to other components. Java Server Pages (JSP) also
allows the HTML and page design to be separated from the business logic while still providing
integration. JSP, EJB and DD together form a robust service composition engine for J2EE.
From the business aspect, ebXML is a new SOA which is built on Web services technology, for
conducting business online. J2EE fully supports ebXML. On the other hand, Colombo is still based on
the old Web service technology, and is not yet using the UDDI registry for Web services. ebXML
provides better business support than the proposed WS-* services offered in Colombo, which are also
incomplete and non-standard. Also ebXML has been in widespread use in governments and corporations.
In conclusion, Colombo still requires much development and is immature. At the current rate, Colombo
cannot compare with products such as J2EE and MS .NET. It is based on an old technology and fails to
address new technology trends such as ebXML. Although Colombo attempts to be business-oriented,
ebXML does it better and has been in widespread use. IBM should reconsider its strategy with Colombo
in order to provide it with a better competitive edge.
The authors, then, while offering significant conceptual discussion, do not present any evidence that
Colombo has or will achieve the stated goals of efficiency and simplification. Given its technical
weaknesses as discussed above, those results would represent the most interesting part of this paper, and
it is disappointing that they are not present, nor have they been forthcoming.