CPS714 Advanced Web Technologies

Topic 4 The Object Web

Component Architectures

Developers are turning to creating components rather than monolithic applications to free themselves from slow, expensive application development, and to build up a portable, reusable code base. This enables developers to quickly attack new market opportunities, new joint development opportunities, and new ways to sell smaller packages of software.

JavaSoft and Microsoft currently are battling to get you to involved into JavaBeans and ActiveX/COM, their respective component frameworks. CORBA, a standard for object communications that is maintained by the Object Management Group (OMG), is also a competitor to Microsoft's DCOM technology. In this paper I present a brief technology overview of Javabeans, COM and CORBA and take a look at their respective component models.

Javabeans

JavaBeans takes Java's "Write Once, Run Anywheretm" capability and extends it to include "reuse everywhere". "JavaBeans is a portable, platform-independent component model, written in Java." With it, you create small, reusable, software components. A visual "builder" program combines components from disparate sources to create applications quickly and easily.

JavaBeans is a complete component model. It supports the standard component architecture features of properties, events, methods, and persistence. In addition, JavaBeans provides support for introspection (to allow automatic analysis of a JavaBeans component) and customization (to make it easy to configure a JavaBeans component).

Beans Architecture:

A Bean is a JavaBeans component. Beans are independent, reusable software modules. Beans may be visible objects, like AWT components, or invisible objects, like queues and stacks. A builder/integration tool manipulates Beans to create applets and applications.

Beans consist of three things:

• Events
• Properties
• Methods

Also, since Beans rely on their state, they need to be able to be persistent over time.

Technology Comparison to ActiveX/COM

• JavaBeans is a framework for building applications out of Java components (Beans).
• ActiveX is a framework for building compound documents with ActiveX controls.
• A Bean is very similar to an ActiveX control. However, a Bean is written in Java, so has Java's security and cross platform nature.
• ActiveX controls written in Java is possible, however they require a port of Microsoft's Common Object Model (COM) to be used outside of Microsoft Windows.
• More frequently, programmers create ActiveX controls in Visual Basic or Visual C++ and compile them into native libraries.

Recently, JavaWorld contained two articles comparing the technologies. The first article is a strategic analysis of the two. The second article is a head-to-head comparison.

Javabeans Reference:

Some web-based resources:

• JavaBeans Home
• The JavaBeans Advisor
• JavaBeans FAQ
• JavaBeans Tools
• JavaBeans API Definitions
• JavaBeans Related APIs
• JavaBeans-ActiveX Bridge

The Component Object Model

The Component Object Model (COM) is a software architecture that allows applications to be built from binary software components. COM is the underlying architecture that forms the foundation for higher-level software services, like those provided by OLE. OLE services span various aspects of commonly needed system functionality, including compound documents, custom controls, interapplication scripting, data transfer, and other software interactions.

COM Fundamentals

The Component Object Model defines several fundamental concepts that provide the model's structural underpinnings. These include:

• A binary standard for function calling between components.
• A provision for strongly-typed groupings of functions into interfaces.
• A base interface providing:
• A way for components to dynamically discover the interfaces implemented by other components.
• Reference counting to allow components to track their own lifetime and delete themselves when appropriate.
• A mechanism to identify components and their interfaces uniquely, worldwide.
• A "component loader" to set up component interactions and, additionally (in the cross-process and cross-network cases), to help manage component interactions.

COM Solves the Component Software Problem

COM addresses the four basic problems associated with component software:

• Basic component interoperability
• Versioning
• Language independence
• Transparent cross-process interoperability

Additionally, COM provides a high-performance architecture to meet the requirements of a commercial component market. (Details refer to Microsoft COM .)

COM Reference:

• COM spec
• DCOM Protocol
• ActiveX, DCOM, ATL
• COMponents
• Tutorial Samples
• COM Cookbook
  
• Rolling Thunder Computing
  Visit this site to learn more about Rolling Thunder's training and books for developers on COM, OLE, ATL, Windows NT, and more.
• Chappell & Associates
  Visit the site hosted by Chappell & Associates to learn more about their seminars, videos, and articles on distributed computing, objects, and more.
• DevelopMentor
  Visit the site hosted by DevelopMentor to learn more about their courses, special events, and developer resources.
• CNET ActiveX.com
  This CNET-sponsored site contains an extensive library of free downloadable ActiveX controls, articles, and a newsletter.
• DCOM for the Enterprise site by Software AG
  This site contains links to Software AG's DCOM downloads for Solaris, DEC Unix, and Linix.

CORBA

The Common Object Request Broker Architecture (CORBA) [OMG:95a] is an emerging open distributed object computing infrastructure being standardized by the Object Management Group (OMG). CORBA automates many common network programming tasks such as object registration, location, and activation; request demultiplexing; framing and error-handling; parameter marshalling and demarshalling; and operation dispatching.

The following figure illustrates the primary components in the OMG Reference Model architecture.



(This figure is adapted from Corba Overview by Douglas C. Schmidt.)

Both DCOM and CORBA frameworks provide client-server type of communications. To request a service, a client invokes a method implemented by a remote object, which acts as the server in the client-server model. The service provided by the server is encapsulated as an object and the interface of an object is described in an Interface Definition Language (IDL). The interfaces defined in an IDL file serve as a contract between a server and its clients. Clients interact with a server by invoking methods described in the IDL. The actual object implementation is hidden from the client. Some object-oriented programming features are present at the IDL level, such as data encapsulation, polymorphism and single inheritance. CORBA also supports multiple inheritance at the IDL level, but DCOM does not. Instead, the notion of an object having multiple interfaces is used to achieve a similar purpose in DCOM. CORBA IDL can also specify exceptions.

CORBA Reference:

• IBM SOM
• OMG Management Group Technical Report
• The CORBA FAQ
• Distributed Object Computing with CORBA by Douglas Schmidt (very helpful!)
• A Brief Tutorial on CORBA

Corba implementation

• Component Broker
from IBM - C/C++/Java
• Corbus
from BBN Systems and Technologies - C/C++/CommonLisp - free evaluation
• Chorus/COOL
from Chorus - C++ -free evaluation
• DAIS
from ICL - C/C++/Eiffel/COBOL/Java(client-side only) - free evaluation
• DOME
from Object Oriented Technologies Ltd - C++ - free for personal use
• Distributed Smalltalk(DST)
from ParcPlace-Digitalk - Smalltalk
• Electra
by Silvano Maffeis - C++/Java/Tcl/Tk -free with source
• MICO (MICO Is CORBA)
- C++/Java - free with source code
• NEO
from Sun - C++/Java(only Client side)
• Oak
from Paragon Software, Inc. - C++ -ObjectiveC

Go back to class home page