(October 25, 2002) - One area that I have taken a real interest in over the last year is component-based development. Currently, there is a JSR (# 159) named Java Process Component API. The status of this JSR has not reached Public Review yet. I recently had an e-mail thread with Mark Hapner from Sun, who is the spec lead for 159, and he explained that the expert group was still working on the direction that the spec was going to take.

Here is the overview of the JPC API right from the JSR detail page: "The Java Process Component (JPC) model will allow developers to directly represent a component as a service process that interacts via XML schema based events, produced and consumed through its typed ports. It will provide a facility for combining a group of process components into a collaboration that defines the linkage between their ports and their content types. It will also define a conversation mechanism that allows a developer to specify a stateful interaction sequence between ports."

"JPCs will allow developers to directly model event based services as individual components and collaborations. JPC will define both synchronous and asynchronous interaction modes. The JPC container will provide the infrastructure for life cycle management, transactions, security, content flow and content transformation. In addition, JPC containers will provide facilities for exposing JPCs and JPC collaborations as a Web service and support the use of a Web service within a JPC collaboration."

"An important goal of JPC is to enable visual tool based customization and composition of process components."

Well, after reading that, I understand why this was accepted as a JSR over a year ago and they still don't have a public draft available. However, what they do have available is a link to an existing document from the OMG that describes an Enterprise Distributed Object Computing Component Collaboration Architecture. The available document, located at http://www.omg.org/cgi-bin/doc?ad/2001-06-09, is a PDF that is nearly 500 pages long and chock-full of information on the OMG spec - this includes full UML diagrams and plenty of useful information. What this document reminded me of was reading the book Objects, Components and Frameworks with UML - the Catalysis Approach, by Desmond D'Souza and Alan Willis, which is 700+ pages.

So, what is a component and why does it take so much time and paper to define a component specification? First, let's look at a couple of definitions.

First, we will look at a definition from the Catalysis book (p. 387): "A coherent package of software implementation that (a) can be independently developed and delivered, (b) has explicit and well-specified interfaces for the services it provides, (c) has explicit and well-specified interfaces for services it expects from others, and (d) can be composed with other components, perhaps customizing some of their properties, without modifying the components themselves."

Next, we will take a look at a shorter definition from the "Developing with Apache Avalon" guide written by Berin Loritsch (http://jakarta.apache.org/avalon/index.html), that says roughly the same thing: "A Component is the combination of a work interface, and the implementation of that interface. Its use provides a looser coupling between objects, allowing the implementation to change independently of its clients." Stay tuned to this column for a future discussion of Avalon.

This leads very nicely into the last item, which is from the great book "UML Components," written by John Cheesman and John Daniels. They write (and I am paraphrasing here from pages four to six, and vastly simplifying): "So, what exactly is a component? A better question, and one that we can answer simply, is, what features does a component have and how does our view of it change during a project life cycle? It starts with a component standard, and then you have a component specification, the component interfaces, the component implementation, the installed component and finally the component object."

As you can see, a component is more than just some class that offers functionality. A component is typically some larger unit of functionality that can be manipulated, replaced, improved, etc without changing the interface by which the components services are offered. Think of a Rule Engine as being a prime candidate for componentization, or perhaps a Workflow engine. In fact, let's break down a workflow engine even further and say that a workflow engine can be comprised of a Resource Allocation component among other things and the composition of those components provides workflow functionality.

What we have today with JavaBeans and Enterprise JavaBeans - these are two component standards - specifications for the components themselves. One of the main goals that the Process Component API aims to do is provide a specification for component interaction, truly a great addition for Java Component Based Development (CBD).

I would be curious to hear if people are interested in this API, whether or not people are actively engaged in CBD, and what standards and specifications you are using. Please e-mail me at jonstrande@yahoo.com.