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
|