"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.