By Paul Dreyfus, View Source staff
Summary
With the release of its Communicator client and SuiteSpot server product lines, Netscape Communications is adopting the important Common Object Request Broker Architecture (CORBA) and extending it across the Internet. Since it was first proposed by the 700-member Object Management Group earlier this decade, CORBA has been adopted by an increasingly large group of companies to provide their users a completely cross-platform method of providing interoperability of software objects distributed across the network. This article explains why CORBA is important, how and why Netscape is enabling CORBA for the Internet and intranets, and how you and your users can benefit from Netscape's CORBA strategy.
You can either jump to the specific section that interests you by following these links, or read the article from beginning to end.
Introduction: The Rush to CORBA
CORBA Developer Action Items
CORBA Theory From Marc Andreessen
A Short History
The Netscape Vision and CORBA
CORBA Practice
Architecture and ORBs
Interface Definition Language
Multitiered Applications: How CORBA Works
Creating CORBA Objects
Creating
New Objects
Reusing
Existing Code
CORBA Limitations/Opportunities
Netscape: Enabling CORBA for Internet and Intranet
Users
The CORBA Promise and You
Further Reading
You need to know about CORBA.
Why? Because Netscape Communications is making the CORBA standard one of its cornerstone technologies, integrating it with every client and server solution Netscape sells from now on and working closely with IBM, Sun, Oracle, and others to develop the standard and its related technologies. CORBA - which stands for Common Object Request Broker Architecture - has already been implemented by many organizations, and thousands of CORBA applications are currently in use, most of them behind corporate firewalls. Netscape and its partners want to make CORBA and the Internet Inter-ORB Protocol (IIOP) as ubiquitous as HTML and HTTP, making Internet-based services as widely available as Internet-based content is today.
Some of you have already implemented CORBA, and your users are already benefiting from its distributed computing model, with small software objects working together over a network. Most of you, however, are probably only marginally familiar with CORBA’s visionary promise and how it can dramatically broaden the capabilities of the Internet. As a developer, though, you're probably less interested in dramatic visions than in current, practical realities. You probably want to know the steps you can take today to increase your business, improve your Web applications, and make the Internet safe for democracy - all that, and also get home sometime before dawn.
This article is intended for those of you who haven’t yet adopted CORBA so you can see why you need to consider adopting it; I'll describe the CORBA vision and why Netscape is helping to make it a reality. Mostly, though, I'll try to make the concepts behind it concrete so you can see what CORBA means to you and what you can do to adopt it, giving your users - and users around the Internet - access to an expanding variety of Internet-based services.
CORBA - the Common Object Relation Broker Architecture defined by the influential Object Management Group (OMG) - defines how software objects distributed over a network can work together independent of client and server operating systems. There's much more to CORBA than that, which I'll get to in a moment. But first, for those who like to know what to do before hearing all the whys and wherefores, I'll start with the three main "developer action items," organized roughly by developer types:
I'll come back to each of these items later, so don't worry if you aren't entirely satisfied by the above descriptions. If you want to read more about the first two items right away, see "Creating CORBA Objects" later in this article; for more about the third item, see "CORBA Limitations/Opportunities." Also, if you want to read about the specific steps Netscape is taking to integrate CORBA with its products and extend the reach of CORBA, go to the section "Netscape: Enabling CORBA for Internet and Intranet Users." For now, I'll tell you about the CORBA vision and its underpinnings.
CORBA Theory From Marc Andreessen
Netscape Technology Senior Vice President Marc Andreessen briefly described the CORBA vision in a recent Techvision column about the CORBA network protocol, IIOP. As Marc emphasizes, the chief benefit of CORBA is that it lets Internet users gain access to a range of services - using databases, tracking inventory, keeping medical records, controlling corporate finances, searching for information - in addition to the kinds of content and applications they're used to seeing today. These services are implemented as objects stored on servers of all types; CORBA lets objects written in virtually any language interact over the Internet. Additionally, each of these objects are small software components rather than large applications; they can be updated and distributed far more quickly and easily than older, traditional software.
That vision is becoming more real as you read this: The 700-plus members of the OMG - including IBM, Apple Computer, Oracle, Hewlett-Packard, Digital Equipment Corporation, and even Microsoft - have already endorsed it, and many companies are currently implementing CORBA-based information technology solutions.
The first step in Netscape's CORBA strategy is to integrate software into all its products, thereby letting your Netscape ONE applications - and your users - take advantage of CORBA. This software, called an object request broker (ORB), will let Netscape Communicator and SuiteSpot use the services of the thousands of CORBA applications that already exist, and the many thousands of CORBA-compliant software objects that Netscape expects to be written in the near future. As announced at the October 1996 Netscape Developers’ Conference in New York City, Netscape has licensed technology from Visigenic Software, Inc., to speed the integration of CORBA across the Netscape product line. (For more about Netscape's implementation of CORBA, see the section of this article called "Netscape: Enabling CORBA for Internet and Intranet Users.")
The next steps are largely up to you; Netscape wants you to give your users access to CORBA's benefits by following the action items I just outlined. Before getting to CORBA practice, though, I'll tell you more about CORBA theory so you can understand those benefits.
Long ago, before the popularity of the Internet and the Web - that is, way back in 1989 - the OMG formed to define an open software architecture that would let different vendors' software objects work together over a network. The OMG founders saw that the proliferation of different proprietary network and operating systems often demanded that good folks like you develop entirely different versions of the same network-based, client-server applications. They wanted to define an open way to write these applications such that the same code could be used regardless of the operating system and network connection. Since then, the OMG has grown to become the world's largest software consortium. Its members' collective work resulted in the CORBA 2.0 specification, adopted in 1994, which achieved the goals of defining an open architecture for platform- and network-independent object computing.
CORBA grew at the same time as three influential trends, which lent credence to the CORBA vision. First, the software development community realized the importance of object-oriented programming techniques, even though they’d been around for the better part of two decades. Second, industry leaders - including IBM, Microsoft, and Apple - were advocating new application models based on small, task-specific components instead of large, general-purpose monoliths. The components would be easy to write and update, since they were small. Developers could more conveniently, and cheaply, upgrade only those parts of their software that were out of date, and users wouldn't have to purchase entirely new versions of the entire package. And the small components could be distributed over a network more easily than their gargantuan ancestors. The more enlightened of these component architectures promised a cross-platform future, where all components could work together entirely independent of the underlying operating system.
Third, just after the release of CORBA 2.0, in early 1995, the Java programming language burst forth, almost as a proof of the concepts behind the object-oriented, component software architecture visions. Java provided an object-oriented development environment for producing small software components that could run on any operating system with a Java virtual machine. And Java added a new wrinkle to the vision: The components could be used over the Internet, which by then was well into its popularity surge.
CORBA easily fit the new component- and Internet-based approach to building and using software. It defined a way of dividing application logic into objects that would be distributed over a network, some sitting on clients, others on a variety of servers. It also defined a way for those objects to communicate and use each others' services.
CORBA also ingeniously specified a way for older software to be reused in the new environment. In that way, unlike many competing schemes, CORBA formed a two-way "bridge" for software developers and users. The CORBA specification bridges the past of proprietary code with the present of open, Internet-based applications; it also bridges the present with the future of distributed Internet-based object computing, where users will be able to search not just for subjects within simple HTML pages, but objects that can perform services.
Given CORBA's openness, and its bridge to the past and future of computing, it's no wonder that hundreds of companies and institutions have adopted CORBA already and that Netscape is making CORBA one of its cornerstone technologies. In his new vision paper "The Networked Enterprise," Marc Andreessen describes "crossware" and the "extranet," which he anticipates to be the next major innovations made possible by Internet technology. CORBA enables these innovations to become a reality.
Crossware, to use Mark's definition, "describes on-demand applications that run across networks and operating systems, and are based entirely on open Internet standards like HTML, Java, and JavaScript." You can think of crossware as next-generation client-server applications, parts of which sit on the client and other parts of which reside on any number of servers or hosts connected to the network, inside and out of corporate firewalls. Each of these parts is written to be independent of the server platform it sits on and any client that wants to use it. The components speak to each other using current open, platform-independent Internet protocols.
Crossware has obvious applications within corporate intranets, but it gets really interesting when corporations expand their private intranets into extranets. The term extranet describes a part of a private intranet that's been opened up for use by other specifically designated institutions or people. Extranets enable businesses to share their private information with - or collect information from - other businesses, clients, and customers.
How does CORBA fit into this vision? As I said earlier, CORBA defines an architecture for the communication of software services, in the form of objects, to communicate with each other over the network. Client objects, using the IIOP protocol, communicate with other objects sitting on servers, or even on older host systems connected to the network. Working together, these objects are said to be a distributed application - an application with parts distributed across the network.
CORBA enables crossware and the extranet to become real. The CORBA specification gives you a way of writing crossware objects that can communicate with other CORBA crossware objects across the network, regardless of the language used to create them or the server’s operating system. With CORBA, you can write an object that sits on a client system within one corporation, and that object can then reach out across an extranet and use the services - or view the information - contained in another object, or set of objects, sitting on a server in another corporation. CORBA provides some of the technologies that Netscape will be building on - and asking you to build on - to make its vision real.
That's the CORBA theory. I'll spend the rest of this article describing CORBA's more practical aspects.
CORBA can be described in terms of its "component" parts:
If you're highly technical and very interested in CORBA, you can read details about each of these components in the CORBA 2.0/IIOP Specification. I'll provide a general description of each of these elements here.
CORBA defines a protocol - IIOP, the Internet Inter-ORB Protocol - governing how objects communicate over the network. For those of you familiar with the Open Systems Interconnect (OSI) model of network protocols, IIOP runs atop TCP/IP on the Application Layer. Unlike HTTP, which is a stateless protocol, IIOP allows state data to be preserved across multiple invocations of objects and across multiple connections.
The CORBA architecture also provides a set of services that help objects interact with each other. (The term services here might be confusing. In the CORBA world, services means both the services provided by the CORBA architecture to help objects communicate and the services provided by the objects themselves.) The services are among the efficiencies provided by CORBA: You write your objects' code - the code that provides the object’s services - and IDL specification; CORBA takes care of how your object identifies itself, finds other objects, learns of network events, handles object-to-object transactions, and maintains security. The services include the following:
Fundamental to the architecture are the ORBs. For any client or server to be a part of the CORBA scheme, it must include an ORB to help it find and communicate with CORBA objects. Once outfitted with an ORB, a client or server can use the services of any CORBA object on any server or host on the network, communicating using the IIOP protocol.
CORBA also defines a special language - IDL -which provides a language-neutral way of describing a specification for a CORBA object and the service(s) it provides. IDL lets components written in different languages communicate with each other using IIOP and the rest of the CORBA architecture. (Objects with IDL-defined interfaces are said to be CORBA-compliant.).
Currently, it’s easiest to provide an IDL specification for objects written in C, C++, and Java, because the OMG has completed mapping schemes - or translation guides - from IDL to those languages. Also, there are already compilers that employ those mapping schemes to translate IDL to C, C++, and Java. (OMG is currently working on IDL mappings for ADA, SmallTalk, and other languages.)
CORBA objects may sit on different types of systems - Windows or Unix servers, IBM 3090 or DEC VAX mainframes. They may even be written in different languages. In fact, the objects don't need any inherent knowledge of each others' existence. As long as the interface to the service provided by the object is written in IDL, all the objects can communicate and use each others' services through ORBs sitting on clients, servers, database systems, mainframes, and other systems on the network.
Multitiered Applications: How CORBA Works
Because CORBA objects can reside on such a variety of systems, CORBA is said to enable "multitiered" applications. Through the ORB sitting on the user’s browser, he or she can have access to the services of objects sitting on a multitude of servers and hosts. A CORBA object, using IIOP and the client ORB, can use the services of an object on a Web server (through the server ORB), which in turn can use one or more objects on relational databases or legacy systems (as long as each system includes an ORB). In that way, an object can be both a client and a server object: An object that resides on a server or host - acting as a server - can provide services to a client object. The same object - acting as a client - can request the services of another server object.
A client object requests the services of other objects through an ORB that resides on the client system. (It’s not called a request broker for nothing.) Using IIOP, the client ORB then reaches across the network, looking for ORBs on other systems and the server objects that can provide the requested services. Each object has a unique name, provided according to the CORBA naming service, which identifies it and its services to other objects. Once the ORB has found the requested service/object, the client object communicates with the server object, still using IIOP. Each object’s IDL interface tells the other object how to use its services and how to construct the results generated by those services.
An example will make this more compelling; let’s look at a parcel-tracking application. (This example is based on a similar example used by Visigenic Software in its white paper about CORBA, Distributed Object Computing in the Internet Age, which is available from Visigenic as a PDF file.) Let's say that, using the Internet, a user wants to track delivery of a package. The user enters a URL into a Web browser (the client, or tier 1) that points to the delivery company's Web server. The server (tier 2) uses HTTP to send a Web page to the user; that page contains an embedded Java applet, which is the client component of the parcel-tracking system. Note that so far, nothing is different from a traditional HTTP Web transaction.
Next, the user enters a parcel-tracking number into the appropriate field in the Java applet. Using the client-side ORB, the applet then generates and sends an IIOP message across the network, looking for a specifically named server object that can obtain the status of the parcel. The ORB on the server (tier 3) with the appropriate parcel-tracking object picks up the message and invokes the object's status-finding method. Through the server ORB, the object then generates another IIOP message looking for an object on a legacy system (tier 4) that contains all the parcel company's data.
Upon obtaining the last request through its ORB, the mainframe containing the data-tracking object determines that status of the parcel from its database, and returns an IIOP message with the information to the server object. The server then routes the information - again with IIOP and the ORBs - to the Java applet running on the client, which displays the results to the user.
The architecture and ORBs provide the mechanism for CORBA communications - that is, the rules objects have to pay attention to if they're to work together. The objects themselves are small software modules that provide some kind of a service, such as access to a database, account management, or inventory tracking. There are two general ways to create CORBA objects, depending on whether you're creating new objects or trying to turn existing code into an object.
Creating New Objects. If you're starting from scratch, you can most easily develop CORBA-compliant objects using Java or C++. That’s because IDL-to-Java and IDL-to-C++ compilers are readily available to you as integral parts of Netscape’s soon-to-be-released Enterprise Server 3.0 product, part of the Netscape SuiteSpot server suite. You can also find IDL-to-C compilers - and other compilers, as well - from other vendors. Soon, you’ll be able to follow the same process using other languages, including SmallTalk, ADA, and others.
Whether you use Java or C++ depends on your preferences and the solution you’re trying to develop. Java is probably more flexible, although C++ may give better performance, depending on your server environment. If everything is equal, I’d suggest using Java, because of its cross-platform nature. Your Java object will work on any operating system with a Java virtual machine.
To give you a feel for what’s at stake in the creation of a Java or C++ CORBA object, here are the basic steps you’d follow:
The specific techniques you’d use to create new Java and C++ CORBA objects are described in the Netscape Internet Service Broker documentation that's part of the current Enterprise Server 3.0 beta 2 release. You’ll want to start with the Netscape Internet Service Broker for C++ Programmer's Guide and the Netscape Internet Service Broker for Java Programmer's Guide.
Reusing Existing Code. One of the advantages of CORBA is that it provides a path for advancing legacy systems, and other existing code bases, into the cross-platform, Internet-based present and future. If you're involved in this kind of project, you have some tough decisions to make. Should you throw out what exists and start from scratch, say with Java? Should you try to reuse your entire system? Or should you proceed on the middle path - rewriting some services, retaining the existing code for others?
Helping you make that decision is far beyond the ken of this article. If you've decided, however, to reuse your code, your course will often be similar to the one you'd take if you were creating new CORBA objects. You first need to decide which parts of your code you’d like to reuse, and then define a specification for them using IDL.
What you do with the IDL specification for the code, and the code itself, will differ widely depending on your specific situation, and creating stubs and skeletons for existing code, and then connecting them to the code itself, can be quite complex. Netscape is currently developing resources to help you do this; once they’re complete, we’ll tell you about them in View Source. In the meantime, please send email to me with your general questions about creating CORBA-compliant objects out of older code; this will help Netscape create the resources you need.
CORBA Limitations/Opportunities
While CORBA is a mature, time-tested technology, it’s not without its limitations; for example network security is still an issue, because you can’t communicate across a firewall directly with IIOP. To overcome this and enable IIOP transactions across a firewall, CORBA currently uses HTTP tunneling, converting IIOP packets into HTTP packets so the firewall can recognize and direct them. Netscape is currently working with OMG, IONA, and others to enable transparent IIOP communications across firewalls; one potential fix to the security issue is an object proxy that would work with firewalls so that proxy servers could understand IIOP. Also, OMG is currently developing a guide to using SSL (Secure Socket Layer) for sending IIOP packets.
Another limitation happens to be a great opportunity for those of you developing tools for Internet application development. As I said earlier, language-specific IDL compilers constitute a crucial part of the CORBA object development process, taking IDL specification code and turning it into native language stubs (for client objects) and skeletons (for server-based objects). However, CORBA currently supports only a handful of languages, and there are now very few IDL compilers, even for the supported languages.
If you develop Internet application tools, you can both differentiate your product and move the CORBA vision a little closer to reality by including IDL compilers - at least for C, C++, and Java - with your tool. If you're the kind of developer who wants to boldly go where others haven't, you can also determine mappings from IDL to the unsupported languages of your choice. Additionally, you can provide tools to create IDL specifications from object interfaces written in other languages, for example a Java-to-IDL or C++-to-IDL processor. This would allow developers to define objects in their favorite language without having to learn IDL. In any case, there's a huge opportunity - and a great need - for tools that support CORBA object development and CORBA component developers. Wouldn't you rather offer CORBA support with your tools than have your competitor do it first?
Additionally, there’s a need for tool vendors to provide support for integrating CORBA objects with Web-based applications. Many Web application development tools support a variety of standards and languages, letting developers build applications using Java, JavaScript, C, C++, UNIX, and other components. Netscape’s Visual JavaScript tool, previously named Palomar, supports integration of CORBA objects with Web applications; you’ll want to build similar support into your tools to take advantage of increased demand for CORBA services.
Despite these limitations, Netscape is betting heavily on CORBA. True, adoption of CORBA is not as widespread as its backers might like it to be, and, even though most CORBA-compliant objects currently sit behind firewalls, CORBA solutions currently number in the thousands. More than 700 companies support CORBA through membership in the OMG. Additionally, a variety of companies have very publicly lined up behind - and/or adopted CORBA. These companies include IONA, which has produced its own ORB products, Oracle, McDonnell Douglas Aerospace, Digital Equipment Corporation, MITRE Corporation, Andersen Consulting ,and - of course - Netscape. (You can read the stories of these and other successful CORBA adopters at the OMG Web site.) In the next section, I’ll describe how Netscape is adopting CORBA.
Netscape: Enabling CORBA for Internet and Intranet Users
As I said at the beginning, Netscape’s goals are to turn CORBA into a commodity, enabling it for use across intranets, extranets, and the Internet by integrating it into its product line and working with others to extend IIOP and other CORBA technologies. Toward that end, Netscape has licensed technology from Visigenic Software, and it recently announced partnerships with Sun, IBM, and Oracle to develop CORBA-based technologies.
The first step of Netscape's CORBA strategy, in line with its vision of the networked enterprise, is to make CORBA an integral part of every client and server across its installed base. Netscape includes the following with its new Communicator and SuiteSpot product lines:
Unlike other CORBA solutions that are based on proprietary protocols, Netscape's implementation makes strict use of IIOP, which is an open protocol that runs on top of TCP/IP. For now, the Netscape Internet Service Brokers support only the CORBA naming service, however Netscape engineers are working on updates that will include support for the event, transaction, and security services after the releases of Communicator and Enterprise Server 3.0. Further, Netscape and several of its partners are currently working to extend the naming service to enable easier interoperability between different vendors’ ORBs.
As I hope you've seen from this article, contributing to the progress of the CORBA vision holds great promise for you and for your users. You can develop software objects that are reusable, or turn your existing code base into reusable objects. Or, if you develop Web application-building tools, you can incorporate CORBA support into your products.
The Internet world is moving rapidly toward CORBA, for the three main reasons I’ve described:
As I look at it, it's fairly simple: If you don't support CORBA, though, you risk having to redo your software yet again for future, not-yet-conceived solutions. If you adopt CORBA, you join a great many others in giving your software an immediate place in today’s and tomorrow's networked enterprise.
Don't you think you need to know about CORBA?
Thanks to Basil Hashem, David Huntley, and Eckart Walther of Netscape Communications and Prasad Mokkapati and Jonathan K. Weedon of Visigenic Software for their assistance in preparing this article.
Distributed Object
Computing in the Internet Age (Visigenic CORBA white paper. available
only in PDF format)
IIOP
and the Distributed Objects Model
Netscape
Internet Service Broker for Java Programmer's Guide
Netscape
Internet Service Broker for C++ Programmer's Guide
CORBA 2.0/IIOP Specification
Paul Dreyfus is the editor of View Source magazine. After living with CORBA for the better part of the last month, Paul took his family for a few days of spring skiing. Although skiing always has a negative impact on Paul's desire to work, he promises to be back - with a positive attitude - in time for the next View Source. Welcome him back to work with an email message, and let him know what you'd like to see in future issues of View Source.
|
DevEdge Online FAQ
Developer Response Center Join DevEdge Program |
Copyright © 1998 Netscape Communications Corporation.
This site powered by: Netscape Enterprise Server and Netscape Publishing System 1.6. |