In-Depth

Containers: A sign components are growing up

• By Neil Ward-Dutton
• May 29, 2001

Today's three main component standards, COM, CORBA and JavaBeans, are presently evolving from specifications of component architectures to specifications of full component runtime environments. There has been a lot of hype from vendors of "application servers" (products that provide runtime services for server-side components, often combined with Web integration) about how this evolution will help future-proof applications by insulating developers from differences in underlying middleware platforms.

An important development waiting in the wings is the component "container," which automatically invokes components specified by developer policies. Such containers should shield developers from component complexity.

Still, whether it is containers, components or component models, users must often wonder whether vendors and standards bodies are really telling the truth when they promote their offerings. Both EJB and the CORBA CCM can be described as cross-platform standards, although EJB is Java-language-specific. Both EJB and CORBA CCM are very much paper specifications today. The Microsoft COM standard is ahead in terms of implementations, but it is best described as a single-platform solution. All three of the specifications are undergoing repeated change, and the key software vendors are still lining up decisively behind particular models.

Components are not very interesting in and of themselves. Because the componentware concept was developed largely to aid in the creation of modular software, almost all real-world instances of components will execute as part of a larger system. Components must therefore be able to collaborate in order to perform the functions of a larger software system.

Component architectures have emerged from two different technologies:

• Compound document frameworks, in which Microsoft technology battled against technology from a consortium of Apple, IBM, Novell, Oracle, Taligent, WordPerfect and Xerox. Both Microsoft's Object Linking and Embedding (OLE) and Component Integration Labs' OpenDoc aimed to give users of office productivity software the power to author "compound documents," while being able to use their favorite tools to build individual document elements.

• Distributed object middleware in which, once again, Microsoft technology battled against a consortium (the OMG). Both camps' middleware technologies (DCOM and CORBA, respectively) required the use of Interface Definition Languages (IDLs) to enable software written using different languages to communicate. In both cases, IDL is used as a least-common-denominator translation mechanism.

All-important is the component architecture. This is the medium via which components collaborate. It specifies how components represent themselves to each other and to their execution environment, and it is the mechanism by which components can communicate at runtime. Sorting through such architectures can be a complex task.

Microsoft's COM

Microsoft's rather confusingly monikered Component Object Model (COM) was the first component architecture to be used on a significant scale outside suppliers' laboratories - it was originally released in 1994. COM now underpins all Microsoft's "modern" 32-bit software - including its Office 97 desktop productivity suite, Windows 95 and NT operating systems, and development tools.

COM defines a binary standard for the definition of component interfaces - in other words, for each combination of operating system and hardware that Microsoft supports, COM defines a standard memory layout for a COM interface. Part of this standard is a specific set of supported data types (such as integers and floating-point numbers) that can be passed as arguments of operations in component interfaces. COM is not just a specification; it is implemented by Microsoft on each of its operating system platforms.

A programmer can use any language - whether object-oriented or not - from a long list to build COM components. Language independence is one of the main reasons for COM's popularity thus far among the ISV community. COM developers can now choose from a wide range of commodity development tools, and the production of COM components within the tools is now frequently a painless process.

COM was originally positioned as a client-side component architecture that underpinned small, GUI-centric components - and, at the time, this made a lot of sense because Microsoft had no server platform. But through its simplicity, and precisely because of all the things it does not specify, COM is suitable for any environment and any type of component. It has emerged as a "lowest-common-denominator" software layer that can underpin Microsoft runtime services in any context.

The OMG's CORBA

The Common Object Request Broker Architecture (CORBA) is a de jure Object Request Broker standard, managed by the Object Management Group (OMG). Version 3.0 of the CORBA specification is now complete and has just been approved - this new version includes (among other things) a component architecture.

CORBA specifies a language- and platform-independent distributed object architecture. Importantly, the OMG does not provide an implementation of CORBA (unlike Microsoft's COM) - just a set of specifications. It is up to vendors of CORBA-conformant ORB products to define binary standards for component interfaces.

Like COM, CORBA is a language-independent distributed computing architecture. But CORBA, unlike COM, supports abstract data types - which makes mappings of CORBA IDL to languages like Ada, C and C++ more complete. The CORBA standard identifies mappings of its IDL to the following programming languages: C, C++, Smalltalk, Java, Ada and COBOL. Many development tools vendors (such as Borland, Forté and Dynasty Technologies, to name a few) generate code that works with CORBA-compliant ORBs.

JavaBeans

Several possible rivals appeared in the years following Microsoft's release of COM - the most promising being OpenDoc. But most recently, the JavaBeans architecture, which forms a part of the overall Java platform, has emerged as COM's main competition.

JavaBeans was originally positioned to provide largely GUI-centric functionality to Java applets and applications - as evidence of this, we need look no further than the early JavaBeans documentation from JavaSoft, which stressed the importance of support for graphical layout facilities and for scripting environments in a component architecture.

JavaBeans is defined as part of, and shipped along with, the newer versions of the Java Development Kit (JDK) and Java Runtime Environment (JRE). The Java- Beans runtime libraries run, like other Java code, inside the Java Virtual Machine (JVM).

Since the JVM smooths out the differences between operating environments and hardware platforms, JavaBeans does not have to provide a binary compatibility specification - it is already provided "for free" by the JVM. And, since the JVM only supports the Java language, there are no cross-language issues (such as incompatibilities in data type support) to deal with.

The "killer app" for components

Slowly but surely, over the last two years, these standards have been augmented to make them fit the "killer app" for components - server-side, component-based applications that can bridge between all those tiresome legacy systems and the Web.

Microsoft has been working on an enhanced version of COM called COM+, which is a building block of its new Windows DNA 2000 server architecture; Sun has produced the EJB specification (now on its second revision); and the OMG has rubber-stamped Version 3.0 of the CORBA specification - which includes a server-side CORBA component model specification (the CORBA "CCM").

To shed some light on why these developments are important, I will attempt to answer two key questions:

• What benefits are these evolved component models promising?

• Which features and benefits do the models actually provide?

Containers and components

As middleware has become more sophisticated, and vendors and standards bodies have developed and formalized more high-level runtime services (such as transaction support, directory services and security services), middleware products have become harder to program. Where application servers present basic component architectures to developers, those developers have to code explicit calls to high-level services - to start or commit a transaction, for example. In the kind of sophisticated environment required to implement a multi-user, server-based application, the array of programming interfaces that must be used can get pretty bewildering.

Component "containers" hide the interfaces of runtime services from component developers, and instead automatically invoke them using developer-specified policies (see Fig. 1). Policies allow developers to specify the "quality of service" they want provided to components at runtime. A policy might, for example, state that a given component sends sensitive information and must also be placed under transaction control, because its methods update data in a number of remote databases. This policy directs the container to automatically invoke the application server's security and transaction processing services as necessary.

Figure 1

There are significant promised benefits to the new "container-" based models. The owners of the new specifications, and the software vendors who support them, are talking about two important benefits - simpler development of multi-user, server-based apps (which are pretty hard to build); and runtime environment portability (where platform typically refers to a middleware product, rather than an operating system).

COM+, CCM and EJB include container specifications that make it easier to develop and deploy multi-user component-based apps. More ambitiously, container "standards" are also touted as enabling developers to develop application components separate from the app server to which they will be deployed. The theory is that they will protect users against rocketing application usage demands (users can buy a more powerful app server and leave the application unchanged) and vendor demise.

Containers will make app servers much more easy to program than other, more "traditional" middleware products. The theory that container "standards" will allow users to "plug and play" with app servers is bogus, however. App server vendors all provide proprietary runtime services (even where the CORBA spec is strictly adhered to, vendors implement supersets of the standards). Most users will want to use non-standard features, as they represent the true value-add of application server products. Those non-standard features may be hidden by containers, but other application servers may not support them.

Windows DNA 2000 and COM+

Most of Microsoft's server-side component infrastructure is being made available to its customers as part of its new Windows 2000 operating environment. Because the infrastructure is built to work with COM components, it is applicable to code written in any tool or language that supports COM.

Elements include:

• Microsoft Transaction Server (MTS), which can manage distributed transactions on behalf of COM components.

• Microsoft Message Queuing (MSMQ), a message-queuing product.

• Internet Information Server (IIS), which can be used as a front-end server (enabling server-based COM components to be invoked via HTTP requests).

• A new In-Memory Database (IMDB), which improves database lookup and manipulation, and allows components to store transient state somewhere "safe."

• Other services, including an event notification service, and a role-based security service that allows developers to set authorization policies down to the level of individual component methods.

• COM+, a container architecture that binds COM components to services provided by all the elements listed above. Developers configure the COM+ container using policies (called "declarative attributes" in COM+) attached to each COM component at design time, and a COM+ compiler then generates associated helper code to bind correct runtime elements together.

Unlike CORBA, Microsoft's infrastructure does not currently support container-managed persistence, and so persistence management is left to developers. COM+ and the associated Windows 2000 services support only one type of component: a type that allows components to store transient state and have transient identifiers - a type that is analogous to EJB's and CORBA's session components.

While Microsoft's container infrastructure may only be suited to one type of component, and may not help with persistence management, it does supply developers with a good set of choices as to how they can invoke server-based components. Components can be invoked directly via COM RPC, or indirectly via IIS using HTTP or via MSMQ (something that Microsoft calls "queued components" - a solution that allows asynchronous communication between components). With COM+, COM components can also communicate indirectly using the new event notification service.

The J2EE platform and EJB

Enterprise JavaBeans (EJB) is an extension of the JavaBeans specification that aims to make Java components suitable for server-based application development. The EJB specification has two main elements:

• A design-time element that specifies an extension of the JavaBeans component model. EJBs are JavaBeans with extra capabilities. The architecture of the component model lets EJB developers add capabilities (like transaction processing support or persistence) to their beans without writing explicit service or function calls.

• A deployment-time element that specifies how beans are packaged and executed at runtime by a server.

The Enterprise JavaBeans model specifies two types of bean:

• Sessions provide business logic services to a client. They are generally not persistent - so while they may be transactional, they are not recoverable.

• Entities are representations of persistent data (typically from an RDBMS), and are transactional and recoverable. Unfortunately, the current version of the spec does not mandate the implementation of container-managed persistence; individual middleware or app server vendors are therefore free to implement this service in a proprietary fashion or not at all. Note: Sun does not yet provide a generally available implementation of the EJB spec.

  The CORBA components spec

  The new CORBA CCM, formalized in the CORBA 3.0 specification, was submitted by a group of vendors led by IBM, BEA, Oracle, Iona and Inprise - and from Ovum's analysis of those vendors' own application server technology, has its roots in some work that originally found its way into IBM's ComponentBroker product.

  The CORBA CCM is a cross-language superset of Sun's EJB specification - in fact, one of the key sections of the specification dictates how EJBs should interact with CORBA components. The CORBA CCM specifies a number of different container aspects that support, between them, four different varieties of server-based components:

  • Services, which are stateless components that have behavior, but no identity - they are best suited to implementing simple command execution components (for example, the "wrapping" of a legacy transaction).

  • Sessions, which are transient components that have behavior, but only need to take account of state for short periods of time, and do not need to have persistent identifiers - they are best suited to implementing things like shopping baskets within e-commerce applications.

  • Processes, which are like sessions, but with persistent identities, and the ability to store their state persistently.

  • Entities, which have behavior, persistent state and a persistent entity that is accessible to application developers via a primary key (just like a row in a database table).

  Processes' and entities' behavior can involve the execution of transactions - and for both of these component types, transaction execution and persistence can be delegated to the container or explicitly managed by programmers (if they so desire).

  Components are described using an extension to CORBA IDL called CIDL, which allows developers to describe not only a component's interfaces, but also the "policy" that will dictate how the component will be managed at runtime. These descriptions are used by tools to generate all the "helper" components that manage the interactions between application developers' components and a CORBA CCM container.

  In the CORBA CCM, components can present multiple interfaces; process and entity components can also be "partitioned," with each component partition's persistence being managed independently by the container. This feature is aimed at enhancing efficiency: When a partitioned component is deployed and a client requests a component operation, only the component partition associated with the requested operation is brought into memory. Each component partition is generated by a CCM-aware development tool as a separate "programming artifact" - in an OOPL like C++, this corresponds to a class definition.

  Some closing points

  Component standards remain a moving target, and recent developments in the component world bear watching.

  Recent word that Sun was pulling bits of the Java environment out of the European Computer Manufacturer's Association (ECMA) standardization process do not enforce the perception that EJBs are fully an industry standard. The retreat from standards on Java creator Sun's part will be a letdown to a lot of people who were banking on the ECMA standard process for stability of the Java - and EJB - platform. [See "Sun toys with free Forté, closes door on ECMA," this issue, p.14.]

  Meanwhile, indications are that the OMG CORBA Component Model will, over time, look very much like the EJB model - at least the two will be engineered to be very compatible. There had been a danger of CORBA users being left out in the cold as EJB moved forward. CCM gives these people a well-defined path.

  In fact, with the development of container technology, CCM may ease the task of CORBA development, which until now required developers to become familiar with a very extensive set of API calls, a very non-trivial task to say the least. Container architectures hide the complexity inherent in the underlying middleware system.

  For its part, Microsoft has significantly enhanced its component story of late. Specifically, the company's SOAP platform allows communication between components using XML over HTTP. For some Internet apps, this will be preferable to the original COM component model that, at heart, utilizes an RPC mechanism. XML over HTTP could be a very powerful solution, vastly speeding the development of third-party component markets, as components built in Visual Basic, for example, can be accessed over the Internet.

  Neil Ward-Dutton is a senior analyst at London-based research firm Ovum. He specializes in application development, middleware and systems management technologies.

  Comparing The Models

  Given what we know about these three models for server-side component development and deployment, which is best? The table below sets out a few preliminary measures by which it is worth examining the models as they stand today. The first and second rows ("component types supported" and "container-managed services") together provide a measure of how flexible the model is: We can see from the table that a software product or suite supporting the whole of the CORBA CCM specification will be able to host quite a wide range of application functionality - whereas the benefits of COM+ are only really applicable to a much smaller functionality set. Microsoft's model has the advantage that an implementation exists; however, both EJB and the CORBA CCM are paper specifications only. Unfortunately, we are still in the early days of component models - all three of the specifications are continually enduring alterations. Because of the historical animosity between the proponents of the different models, the positioning of the models and the marketing of the products that support them will be driven not only by a desire to serve customers' requirements, but also by political maneuvering. The CORBA CCM specification seems to present by far the most inclusive, flexible server-side component model of the three; but until now, the EJB specification has received the most attention from tools and middleware vendors - partially because, until recently, it has been the only alternative to Microsoft's model. However, EJB cannot really be called a serious standard today; because of various holes and the lack of a compliance suite, the vendors implementing the specification are free to implement some critical services in quite proprietary ways. - Neil Ward-Dutton