Figure 1: Netscape ONE Application Architecture
(taken from Netscape ONE whitepaper)
To understand why Web+Object integration can and is happening, it is necessary to understand the evolutionary trend of the Web. We first provide this context with a brief summary of Web evolution. To understand proposed architectural variants of the Current Web Architecture and what integration approaches are feasible, it is necessary to understand the technology that exists today that enables integration. Therefore, we next list and describe each enabling technology briefly. Then we categorize the different proposed architectural approaches to web-object integration, and briefly analyze them w.r.t. their advantages and disadvantages. We conclude with a summary of the prevalent emerging approaches and future directions. Finally, we give a brief description of relevant projects, systems, and products and their underlying technology that have contributed towards Web+Object integration.
But the Web didn't start out this way. Network-centric object computing is the result of a logical technological progression. As originally conceived, it was driven by hypertext documents called Web pages or HTML documents. Initially Web pages had static content in that they contained rich graphics and text, and were interlinked. Browser applications running on user PCs/workstations were used to retrieve documents housed on servers. Helper applications supplemented the browser, handling other document types such as Word, postscript, pdf, graphics, video, and audio. Web pages soon contained dynamic content as helper applications, called plug-ins, were integrated into the browser and CGI scripts enabled users to input data to a Web server and access Internet services, such as a query search, that are executed on the server. Finally, programmatic content was added via Java applets, Visual Basic Scripts, and JavaScripts, to provide further interactive functionality and modify content in-place. These languages enable richer documents, e.g., animation and forms generated on-the-fly. Note that programmatic content can also include server-side execution of code such as accessing a remote database service.
Prior to the addition of programmatic content, the Web was based on a client/server computing model which lacked scalability, common services, security, and a development environment needed to develop and deploy large-scale distributed applications. CGI scripts are not scalable because each requires a separate server-side process to handle each client request, services are limited to accessing database servers via CGI scripts, transaction information (such as credit card information) is not encrypted, and the programming model offered by HTML/HTTP using CGI and a three-tiered system is limiting, e.g., CGI is not object-oriented and offers no type saftey, dynamic interaction with the user is difficult, the interface between the server and database manager is ad-hoc, the interfaces cannot be combined or extended, client data is strings the server must explicitly decode, there are no standard definitions of service interfaces, and interfaces are not self-describing. Consequently, for the limitation point, applications are more error-prone, are harder to maintain, and are not likely to be reusable. With the advent of Java, and the distributed object infrastructures CORBA/IIOP and OLE/DCOM, the stage was set to evolve the Web from a document management system to a platform for distributed object computing and electronic commerce. Bringing distributed objects to the Web offers extensibility (e.g., for applications, services, and APIs built from objects, objects can easily be replaced or added, [list of kinds of? TBD] ), cross-platform interoperability, independent software development, reusable software components, componentware, network services, and better utilization of system resources, to name but a few advantages. Existing legacy applications can even co-exist with distributed objects through the use of object wrappers (cf. the Wrappers section). The interface could either be the client browser or browser-like with superpositioned distributed object infrastructures.
Orfali has dubbed the concept of a distributed heterogeneous object computing network the Object Web, an apt term we also adopt to characterize the integration of the Web/Internet with objects. The Object Web is logically a 3-tiered client/server architecture involving disparate technologies. The 1st tier consists of client objects – HTML pages with forms, Java Applets, COM objects, CORBA objects, and/or client applications – and a CORBA ORB. These client objects invoke server objects in the 2nd tier by sending messages in various protocols – HTTP, IIOP, RMI, DCOM, or RPC. The middle tier contains HTML documents, CGI-scripts, CORBA services, COM services, business objects, other middleware (e.g., OSF's DCE, products based on Microsoft's ODBC or Sun's JDBC that gives clients native access to a variety of databases, security software for secure transacting, and mobile agents), and/or a CORBA ORB. For client and server objects written with different object models to coexist and collaborate in various frameworks, bridges or adapter components are used. Server objects invoke functions in the 3rd tier to access data and legacy systems. The 3rd tier includes TP Monitors, MOMs, DBMSs, ODBMSs, and Email.
The Object Web differs from traditional distributed object computing. Distributed object technology, coupled with a communications infrastructure, enables traditional monolithic client/server applications to be divided into self-managing components, i.e., objects, that can interoperate across disparate networks, platforms, and operating systems. The Internet provides the requisite communication framework for Web-based, distributed object applications. Such applications can be built from new and legacy code encapsulated in objects, run on heterogeneous systems both inside and outside a firewall, and made to interact and communicate with each other through middleware using defined interfaces.
In addition, application areas such as electronic commerce/business are pushing this distributed computing model even further. The next generation business computing is built on the same distributed object computing model plus business objects that embody business entities, processes, and rules. However, distributed business applications have additional requirements beyond conventional Web-based computing – scalability, high availability, ease of administration, high performance and data integrity. Relevant technologies being used for business computing are OMG CORBA for scalability; the CORBA Object Transaction Service for reliable transactions; the CORBA business object facility, infrastructure to support distributed cooperating buisness objects; mobile intelligent agents for sequencing events; the use of component assembly to build business applications; and the OPEN method, a third generation OO methodology with full lifecycle support for process.
Built on top of the CORBA architecture is the Object Management Architecture (OMA). It provides application objects called CORBA services and CORBA facilities. CORBA services are basic standard services need by nearly any object-based application. There are currently 13 base services with 3 more being specified. CORBA facilities are intermediate-level common data types and functionality needed by horizontal (enterprise-wide) and vertical (industry-specific) applications. Most of the CORBA facilities are currently being specified.
Commercial implementations of CORBA include DEC/BEA's ObjectBroker (and here), IONA Technologies Orbix, IBM's DSOM, Sun's Joe/Neo, and Visigenic/Inprise's VisiBroker. A more complete list can be found here.
A brief description of CORBA can be found at TechWeb's Technology Encyclopedia.
Unlike CORBA which is just a specification, there is a reference implementation of DCE. All DCE products are based on the same OSF code which allows all DCE-based ORBs to interoperate via ESIOP. For CORBA there is no reference implementation and ORBs implemented by different vendors initially were not necessarily compatible. The advent of IIOP in CORBA 2.0 allowed different ORBs to interoperate, and the support of DCE ESIOP allowed CORBA ORBs to interoperate with DCE-based ORBs.
DCE also provides a number of services, some of which are similar to those defined by CORBA. The two most significant ones are the naming and security services.The naming services provides a tree-structured namespace. The security services provides authentication, authorization, and privacy in a distributed environment. There is also the Distributed Time Service that synchronizes clocks on all hosts in an administration domain. Other useful aspects of DCE are support for Posix threads used by RPC servers to handle multiple requests concurrently, and the Distributed File System that combines multiple host file systems into a single uniform namespace. DCE also implements functionality that only appears in CORBA specifications. This is why a DCE-based ORB, such as ObjectBroker, is so much more capable than a CORBA ORB, such as Orbix.
OLE is an environment where objects interact. Originally OLE stood for Object Linking and Embedding and was intended to allow people to cut a piece of a spread sheet out of Excel and paste it into Word. It has grown into much more. Now, OLE composes arbitrary objects, not just documents, through strict interfaces. OLE's definition of "object" is quite a bit different than what is traditionally meant. About the only similarity is encapsulation.
OLE encapsulates objects in several dimensions. OLE supports evolution as C++ classes do, but without recompilation. Each incarnation is given a unique identifier and a version stamp. OLE supports heterogeneity of both language and hardware. Language heterogeneity usually refers to programming languages. In this case it also refers to human languages. Encapsulation includes licensing on an object by object basis.
The key to encapsulation, as in other object systems, is interfaces. An object can only be accessed through an interface. The difference in OLE is that objects support many interfaces. Coming from a pure object-oriented background this capability is extremely confusing. It is best to think of OLE interfaces as object-oriented views. An object can have multiple and even semi-redundant views. There is no inheritance or subtyping of interfaces; the space is completely flat. The ability of delegation does not exist within OLE. It is only a pragma or pattern used by implementors. Any object implements any interface in whichever way it chooses.
A client accesses each interface to an object through a distinct handle. Since objects support multiple interfaces, OLE provides a means to query an object for an interface through any handle. In addition, OLE allows objects to store type information in a library available at compile time and run-time. One of the most powerful features of OLE is the ability to bind to completely new services at run-time without recompilation. This flexibility allows for many desirable software management activities such as rapid prototyping, incremental enhancement, and migration to lower cost service providers.
As with other object service architectures, objects are created with a class factory. The class factory enforces licensing restrictions, but it does not prescribe the restrictions. The restrictions are defined by the class itself. Clients bind to objects using abstract monikers defined by the class. A moniker is a COM object that creates and initializes one other object, returning a pointer to it. The process of establishing a connection between a client and an object referred to by the moniker is called binding to the object. Each time an object is bound, a reference count is incremented. When the count returns to zero, the object can free its resources.
OLE is a binary standard that is essentially the run-time environment
of a language which does not exist and is not even specified. ( Since OLE
manipulates binary components and is not concerned with the implementation
language, it is language neutral and the implementation language can be
considered to be hypothetical.) The rules of the language must be internalized
and exercised by programmers implementing in their host language usually
Visual Basic (VB) for OLE clients and C++ for OLE object developers. VB
provides a very high level of support for using objects, but less support
for implementing them. Support for OLE is not provided through C++. Rather,
there is some support in Microsoft's application framework (MFC) and most
of the support is actually in the authoring tool Visual C++ (VC++). MFC
and VC++ do not provide access to the full power of OLE, but only to a
subset suitable for common applications.
Another view is that ActiveX is an integration technology – a component framework that allows component objects, called ActiveX controls, embedded within documents to communicate with one another and with the framework. It enables software components to interoperate in a networked environment using any language. ActiveX essentially extends Microsoft's OLE and COM technologies to the Web. The COM technology is the primary foundation for ActiveX technology. DCOM extends interactions between components across networks.
ActiveX controls, aka OLE controls (OCXs), are reuseable, prefabricated components (objects) that can be inserted into a Web page, another application, or development tool to provide specialized functionality. ActiveX controls are akin to Java Applets/Beans and Netscape plug-ins, but additionally can be used in applications writen in numerous Microsoft programming and database languages. ActiveX controls provided by 3rd party vendors can be found in the ActiveX Component Gallery.
ActiveX licensing ensures downloaded ActiveX controls are safe. When downloaded, a check is made to see if it has been digitally signed by a software publisher using code signing Authenticode™ technology. The software is only downloaded if the client interactively accepts the terms and conditions of the license.
Java applets can interoperate with ActiveX technologies – ActiveX controls, ActiveX documents, and Active scripting. This ability for Java applets to work with other software using ActiveX is made possible by Microsoft's Java Virtual Machine for Java applets and JView for Java applications. (see Web+Java/COM).
ActiveX is a direct competitor with JavaBeans.
A compound document framework is a software infrastructure and protocols that enable separately developed objects to be visually integrated on a desktop. Compound document technology provides the ability to build an application out of components in a standard documen that is the universal client front-end to servers; the compound document framework is built on top of an object bus and core object services. A compound document consists of components and containers. Containers hold related components and provide the context for component interaction. Containers can also be components. Compound documents provide a strategy for using components in a distributed computing environment. By leveraging established distributed computing technologies, such as CORBA, a compound document can provide access to services required by a distributed application. Using scripts, an intelligent document can route work from one machine to the next; functionally this is a form of mobile intelligent agents.
Currently there is no effective Internet-oriented compound document framework, but making Java and JavaScript or ActiveX/DCOM work seamlessly in a Web browser is one possibility as is OpenDoc, a compound document framework layered on top of IBM's CORBA ORB, SOM. However, use of OpenDoc is no longer a viable approach. Apple has decided to discontinue the product past Version 8.0 of the Macintosh operating system, the OpenDoc consortium (Apple, IBM, Novell) is falling apart, application development tools are lacking, and OpenDoc's concept of compound documents does not take the Web into consideration. One effort that may keep OpenDoc alive lies in the OMG's OpenDoc Common Facility. Given the probable demise of OpenDoc, this technology per se will not be covered.
A component model is an architecture and set of APIs that allows software components to be dynamically combined together to create an application. Containers hold related components, and provide the context for component interaction and arrangement. Containers can also be components. The two primary competing component models are Microsoft's ActiveX and Sun's JavaBeans.
Examples: ComponentWare Consortium, Infospheres Component Network, Microsoft's Object Technology Strategy: Component Software.
We had planned on having a comparative analysis section, but decided against it for numerous reasons. First, the prevalent technologies, namely CORBA and DCOM, are going to coexist and converge over time. Todays differences for making a selection are constantly changing and narrowing. (For a detailed architectural comparison, see the Chung et al paper.) Second, Orfali's book on CORBA and Java programming has chapters devoted to comparing Java/CORBA ORBs with its competitors: sockets, HTTP/CGI, RMI, and DCOM plus tables comparing features. Therefore, we have followed this section with a discussion on prevalent directionsandfuture directions.
Only some of the many architectural variations need to survive. The long term goal is an integration architecture that has good performance, is scalable, has a migration path from today's architecture, and is compelling. That is, a proposed solution should provide a path to meet imagined requirements or the ideal architecture, or be a useful stop along the way.
All approaches to Web+Object integration are not considered. For example, the use of CGI to integrate with backend non-CORBA OO systems is excluded. Instead, only those approaches which are expected to dominate are considered. The primary taxonomic categories for Web+Object integration architectures are:
The various Web+CORBA architectures are:
Advantages: simple, no modification needed to CORBA or to WWW.
Disadvantages: a) invokes a new gateway script each time; b) specific gateway scripts for each kind of Corba object; c) memoryless.
Examples: W3Objects, NEXT/Apple's WebObjects and CERC's Web*.
Advantages: no changes needed to Web or OMG architectures.
Examples: DSTC's CORBA Desktop.
Advantages: a) performance is better because it is not necessary to spawn a separate process for each invocation; b) gateways can be stateless or stateful where CGI forces a gateway to be stateless since a new process is started for each invocation; c) separation of service and presentation logic.
Examples: HP Laboratories' CorbaWeb and DEC's Web Broker.
Examples: ANSAweb, W3Objects, and Xerox PARC's Bayou project.
Examples: Inter-Language Unification (ILU) from Xerox-PARC; Digital Creations ILU Requestor; EC/ACTS DOLMEN project.
Examples: Stanford Digital Library Project.
Advantages: Easy incorporation of small amounts of code into mostly HTML applications. Scripts can validate information on the client-side before passing it to the server, e.g., validate a query to avoid later rejection by the server or check if manditory fields of a CGI form are filled in.
Disadvantages: a) need session control and transactions; b) need event notification; and c) need user authentication.
Examples: The HP CorbaWeb and CorbaScript, Netscape's Visual JavaScript, Sun Labs Tcl/Tk Project, and Web*.
Disadvantages: These approaches are hand-tailored solutions duplicating common functionality. 1) When using Java sockets, a Java application or applet invoking distributed objects must manage its own communication, e.g., data formats, marshalling and unmarshalling. In effect, the CORBA ORB communication paradigm must be implemented on top of the built-in socket layer. Furthermore, access is restricted for security reasons. For example, Netscape Navigator permits applets to open socket connections only to the host that served them. 2) Native methods cannot be verified by the JVM since they are implemented in another programming language. Since the low-level bytecode checks are bypassed, this presents a security hole. 3) RPCs are not object-oriented. Therefore one must design a protocol to encode the transmission of method invocations and responses. In effect, an ORB must be implemented on top of the RPC layer. However, RPC does not support polymorphism or inheritance. When a Java client invokes a Java object via RPC, server-sided overload resolution is not possible since Java does not provide a way to invoke a method from a string representation of the method's name. 4) Java only provides node-level security, but network security mechanisms are being proposed, such as digital signatures for verifying that code comes from a trusted source.
Examples: WebLogic's jdbcKona/T3uses sockets for communication between a Java client and a Java application which in turn accesses one of several relational databases. Java wrappers around RPCs are also used to access relational databases. The communication mechanism for remote method invocation and responses is the network message system with the interpreters at each end marshalling and unmarshalling the messages. Nagaratnam and Srinivasan have implemented a distributed Java prototype calledRemote Objects. By extending the language with the new keyword remotenew, an object can be created on a remote machine. Japan's Electrotechnical laboratory (ETL) has implemented a Java-based ORB called HORB. The Java Remote Method Invocation (RMI) provides a Java-to-Java ORB framework.
Disadvantages: Using a gateway is not as unified an approach as using the a CORBA ORB, for CORBA naming or trading services cannot be used to find services and Java applets cannot benefit from CORBA security and licensing services.
Examples: SunSoft's Java Object Environment (Joe/NEO), Iona's OrbixWeb for Java, Visigenic/Inprise's VisiBroker for Java, APM's Jade (deprecated), and Netscape's Caffeine. Both Visigenic/Inprise's VisiBrokerand Sun's NEO's CORBA 2.0 ORBs are Java-based and support the mapping of IDL to Java.
Java can be used to implement COM objects callable from languages such as Visual C++, Visual Basic, and VisualJ++. All Java classes are automatically exposed as COM objects. Basically this entails writing the COM class in Java, generating COM class wrappers using a special tool, and modifying the Java code to implement the interfaces defined in the COM class wrappers. When the COM object is called, say from Visual C++, the Java bytecode is executed by the Java VM.
Disadvantages: This is not a total solution. At this point, COM is not platform-independent, but available primarily on Windows platforms. However, DCOM (which is based on COM) is being ported to Unix platforms, such as Sun's Solaris. Also, it is non-trivial to use COM services from Java to access ActiveX services, and currently there are no wizards to automate the process. However, a future release of Visual J++ will provide a new class library with the functionality of the COM library API and ease integration with ActiveX services. However, there is a much simpler means of accessing ActiveX services from Java, namely, to use the Java Beans API and the Java Beans/ActiveX bridge.
While not useful by itself to build distributed object applications for the Web, DCE is a good choice as an infrastructure for supporting distributed applications. The DCE RPC is useful within the CORBA 2.0 and OLE/DCOM. The CORBA 2.0 specification permits ORBs to optionally support alternative interoperability protocols, known as Environment-Specific Inter-ORB Protocols (ESIOPs) in addition to the IIOP. CORBA can use the DCE Common Inter-ORB Protocol (DCE CIOP), which is based on DCE RPC, as an environment-specific protocol to provide interoperability. DCOM is a generic protocol layered on the DCE RPC -- DCE RPC is ActiveX's communications protocol, its only underlying method invocation mechanismf.
Advantages: 1) Instead of competing with CORBA, DCE complements it. ORB and RPC method invocation are two similar mechanisms but different because RPCs are not object-oriented. With RPC you can only invoke a specific routine while with an ORB the response may be different because of polymorphism. Note that DCE is actually used in some CORBA implementations to implement method invocation. 2) The Web currently only offers the secure sockets layer (SSL) and secure HTTP (S-HTTP) appropriate for a limited number of applications. DCE provides network security in the form of user authentication, data protection (encryption), and authorization (resource access control).
Examples: The DCE-WEB Project conducted as part of an Advanced Technology Offering (ATO) by the OSF Research Institute (the WanD (Web and DCE) Server handles both standard HTTP-over-TCP and the DCE Web's RPC-based protocol); Gradient's NetCrusader; and HP's OODCE, a C++ application framework and IDL++ compiler that creates an object-oriented programming environment that supports access to DCE capabilities. The recent OSF Jade (Java and DCE ) Project enables Java client applets to use DCE security services to access remote resources.
There are some interworking products, e.g., HP's CORBA Connect, a component of HP ORB Plus that enables bi-directional messaging between CORBA objects and OLE Automation, COM and OCX objects.
Interface definitions are specified in Microsoft IDL (MIDL).
The problem with this approach is that the technologies are not integrated seamlessly to form a network computing environment, but instead form a pool from which to mix and match when developing a distributed application. While the approaches provide a service-based architecture that accommodates cooperating distributed applications and network services, the underlying enabling technologies are loosely coupled. Part of the reason for this is there are two competing computing technologies, namely, CORBA/IIOP and OLE/DCOM/ActiveX. Vendors of all-encompassing network computing environments want their product to handle components from both camps as well as native legacy applications. Until one approach prevails or they merge, this trend of providing APIs and bridges for interoperability will continue.
Examples: Netscape ONE, Oracle's Network Computing Architecture, and IBM's Open Blueprint.
Examples: JavaBeans, Netscape ONE, ActiveX, OpenDoc.
Using CORBA/IIOP, developers can define standard network interfaces for their applications using a cross-platform, cross-language, distributed object model. The ability to encapsulate existing legacy applications and data and make them accessible via network interfaces provides a migration path for enterprises from leveraging existing corporate applications to building next generation network-based applications.
Neither CORBA nor DCOM alone is complete solution for network programming, i.e., for building enterprise-level distributed application. Both just provide the plumbing and a communication mechanism for a collection of cooperating objects and ORBs running across a heterogeneous network of processors and OSes. Real applications also need services like naming, event notification, transactions, concurrency control, and life-cycle control. For CORBA environments, some CORBAservices are provided in an ORB implementation. For DCOM many of these services are being developed (see DCOM: A Business Overview).
Which component object model suits application developers best remains to be seen. Which framework will prevail is not yet predictable.
DCOM and CORBA are two major incompatible standards for distributed objects whose interoperability is necessary if development tools are to support seamless system integration. Strategies for interoperability are:
IBM's JavaBeans Migration Assistant for ActiveX tool converts ActiveX controls to a JavaBeans component. The tool analyzes an ActiveX control's properties and creates a Java container that takes on the features of the ActiveX control and implements the component functions.
In recent interoperability developments, JavaSoft is building the equivalent of Microsoft's COM for the next generations of JavaBeans, while Microsoft is extending COM and porting the DCOM communication mechanism to Java. Microsoft's extensions to COM consist of message-queuing technology to enable asynchronous communication among networked objects, garbage collection to alleviate resource-leaking problems, persistence, distributed debugging, and DCOM rewritten in Java so COM objects running in Windows can interact with Java applets. JavaSoft's extensions to Java Beans consist of an aggregation/delegation model for composition, separate design and run-time support for JavaBeans, a drag-and-drop system for visually manipulating JavaBeans, a composite GUI that embeds a user interface in a JavaBeans component, persistence, and data-typing and registry capabilities so a Bean can determine if other Beans are installed on a Windows platform.
One overarching problem is the lack of standards and the diversity of approaches. Objects enable Web applications to be built out of common APIs and reusable components, and rely on common object services. Unfortunately, there is no standard object model and we will have to contend with interoperability mechanisms for years to come (see Prevalent Directions above). Common standards are also lacking in other areas, e.g., at the transport protocol level and access to remote objects. Competing purposed and proprietary standards from OMG, IETF, W3C, Open Group, Microsoft, Netscape, and others need to converge; otherwise, developers will have to contend with interoperability bridges. The OMG approach of merging the best of submitted RFPs into a single specification seems like a viable strategy, but probably will not happen given the different business models of the commercial players.
The key areas that need to be addressed by researchers are:
There are numerous ongoing QoS research and standardization activities. The OBJS survey paper on QoS discusses QoS research efforts and RSVP, the emerging standard for QoS negotiation over IP. The OMG Green Paper provides a unified approach to QoS across the OMA, CORBA, and CORBA services. ISO/IEC DIS 13236 discusses QoS frameworks, ISO/IEC DTR 13243 is a guide to QoS methods and mechanisms, and ISO/IEC 7N1192 is a working document on QoS in Open Distributed Processing (ODP).
For a complete list of extensions currently under consideration and their descriptions, see here. The list includes
One key research area is providing security against malicious agents (who need access to local resources or can carry a virus) and malicious hosts (who can alter an agents code and state or read private information).
The OMG has an RFP for a Data Interchange Facility and Mobile Agent Facility RFP. "In order to implement mobile agents, three key features need to be supported by ORB: launching and loading of agents on what is traditionally thought of as the client side of the ORB, time asynchronism, and ORB notifying senders and receivers of arrival of packets intended for them. The mobile agent facility proposes these changes." Revised submissions are due June 2, 1997. A joint OMG submission from IBM, Crystalize, GMD FOCUS, and General Magic, Mobile Agent Facility Specification, was submitted April 21, 1997 (Draft 5) and is supported by the Open Group. The 1996 Joint W3C/OMG Workshop Distributed Objects and Mobile Code contains a collection of papers on the topic.
Significant current projects and mobile object/agent technology developments are:
HTTP 1.2 supposedly will contain functionality that didn't make it into HTTP 1.1 and address issues like demographic data, features, version management and search facilities.
Most of the ideas in HTTP-NG are embodied in Simon Spero's specification. W3C is implementing a HTTP-NG proxy server using the Xerox ILU system to investigate feasibility of object technology, and allow for direct comparison with HP's implementation.
The IETF Internet-Draft PEP: an Extension Mechanism for HTTP accommodates extension of HTTP clients and servers by software components.
JavaSoft's Java Cryptography Architecture (JCA) is a framework or accessing and developing cryptographic functionality for Java. Baltimore Technology's J/Crypto is a native Java cryptographic class library that provides encryption and code-signing facilities and is compliant with JCA. Systemics ' Cryptix has cryptographic extensions for Java 1.1 and Perl.
CORBA IIOP cannot communicate directly across a firewall. To overcome this, HTTP tunneling is used, i.e., IIOP packets are converted to HTTP packets which the firewall recognizes and directs. Mechanisms are needed to enable transparent IIOP communication across firewalls.
The W3C Digital Signature Initiative is addressing the use of digital signature, identity certificate, packing list, and content label technologies to help users decide what code and data to trust on the Web.
A recent NSA/OMG Security Workshop addressed CORBA security, requirements for secure ORBs, the CORBAsecurity service, CORBA security architectures, and alternative models for securing CORBA environments (namely, use of firewalls and SSL).
More advanced activities are being pursued by the W3C to address open research issues, and make the Web more robust, responsive, and scalable. Some of the key technologies involved include automated, transparent selection of the closest available replica of a service, distributed replication and error recovery, multicast based replication, and cooperative caches, integrating client pull and server push functionalities.
The Active Client is the set of technologies that enables developers to deliver "least common denominator" components or applications that run across multiple operating systems (Windows, Mac, and UNIX) and multiple browsers. The Active Client provides a programming model for client-side computing using HTML 3.2 and Dynamic HTML, scripting via Visual Basic Scripting Edition (VBScript) and JScript, and Java or ActiveX components.
The Active Server is the set of technologies that enables developers to easily build and deploy component-based server applications. It includes the services needed to make component- and Web-based applications run over the network. The Active Server technologies include the distributed component object model (DCOM), Active Server Pages (ASP), Microsoft Transaction Server, message queues, Windows NT Server (directory and security services), Microsoft SQL server, OLE DB, ODBC, and Microsoft Internet Information Server (IIS) 3.0.
ActiveX is a set of technologies that provides cross-platform, component interoperability in a local or networked environment, regardless of the language in which they were created. It enables client- and server-side components to communicate and interact with one another regardless of whether the component is local or remote. ActiveX includes the component object model (COM) to enable communication between client components as well as DCOM to integrate components across the network. Components that run on either the client or server can be developed using the ActiveX SDK, Visual J++, Visual Basic and C++, or Visual Basic Control Creation Edition.
IIS 3.0 is an information delivery and network applications platform that includes a Web server, component-based application development environment (Active Server Pages), integrated full-text searching (Index Server), multimedia streaming (NewShow), and site management extensions (FrontPage 97 Server Extensions). ASPs let one combine HTML, scripts, and reusable ActiveX server components into a Web-based application. Active Server Pages includes native support for both JScript and VBScript, and ActiveX scripting plug-ins for REXX, PERL, and Python, and other CGI-based languages. Additional built-in functionality includes Web access to enterprise databases, application state management components, and a Java VM.
ANSAweb, part of the ANSA Workprogramme, consists of 2 project phases. Phase 1 provides object wrappers for Common Gateway Interface (CGI) services using OMG IDL. This technology demonstrator has been available for public release since June 1995. The code includes an IDL to CGI stub compiler (SC-CGI).
Phase 2 's uses CORBA IIOP as an alternative protocol to HTTP, and object wrapping for integrating Web services and third party services (or legacy applications) as CORBA services using OMG IDL. The code is available in the form of the ANSAweb Distribution Kit.
ANSAWeb provides a strategy for interoperability between the Web and CORBA by HTTP-IIOP gateways -- the I2H gateway converts IIOP requests to HTTP, and H2I converts HTTP requests to IIOP. The H2I gateway allows WWW clients to access CORBA services; the I2H gateway allows CORBA clients to access Web resources. The pair of gateways together behave like an HTTP proxy to the client and server. An IDL mapping of HTTP represents HTTP operations as methods and headers as parameters. An IDL compiler generates the client stubs and server skeletons for the gateways. H2I is both a gateway to IIOP and a full HTTP proxy so a client can access resources from a server that does not have an I2H gateway. A locator service decides when to use IIOP or HTTP. It the locator can find an interface reference to a I2H server-side gateway, IIOP is used; otherwise, the H2I gateway passes the request via HTTP. The interface between H2I and the locator is in IDL provides implementation flexibility.
Arabica is an internal name for a collection of technologies providing tools for deploying corporate information systems through the World Wide Web. Arabica includes a set of Java Beans components for:
VisualAge for Java is an incremental application development environment that enables developers to visually build Java applets and provides visual partitioning tools, enabling users to connect to existing enterprise server data, transactions and applications. The CBToolkit, part of the Component Broker, incorporates VisualAge for C++ and VisualAge for Java, and can generate corresponding Java, C++, and ActiveX** client components. The Component Broker also contains CBConnector which performs workload balancing, operational monitoring, activity logging, troubleshooting and other management functions across distributed networks from a centralized point of control. CBConnector and CBToolkit are full implementations of OMG's CORBA, COS, and IIOP, and provide the infrastructure for developing, deploying, monitoring and administering component-based applications across networks.
Component Broker provides an infrastructure base for IBM's Commerical Shareable Frameworks initiative, a.k.a. project San Fransicso, whose goal is to build a series of reuseable 100% pure Java application business frameworks designed to reduce the complexity, expense, and time-to-market for Independent Software Vendors (ISVs) to build customized multi-platform business applications. The intent is that the shareable frameworks would provide 40% of a typical working application within the supported domains while ISVs would develop the remaining 60% of the application business processes and services on top of the frameworks.
Caffeine is a complete Java implementation of the CORBA specification, i.e., it is a Java ORB. Its distinguishing feature is that a developer need not learn IDL – IDL is generated from the Java code. Java is used both as an interface definition language and an implementation language. Caffeine includes: 1) a Java2IIOP code generator that produces IIOP-compliant stubs and skeletons from Java interface classes; 2) a Java2IDL preprocessor that produces CORBA IDL from Java code; and 3) a URL-based CORBA naming service. Caffeine is layered on top of VisiBroker for Java and the VisiBroker's Naming Service.
A Java interface is declared to be remote by extending it from the class CORBA.Object which is part of the ORB runtime. The IIOP stubs and skeletons are generated, using Java2IIOP, from the bytecode output by the Java compiler. The resultant IIOP stubs and skeletons are identical to the ones that would be generated by the idl2java compiler.
To make Java objects accessible from other CORBA/IIOP clients written in different languages, they must be registered with the CORBA Interface Repository. This requires CORBA IDL files. The IDL files are generated by Java2IDL which parses the Java code looking for remote interfaces. Finally, the IDL files are loaded into the IR using VisiBroker's utility, IDL2ir.
With Caffeine one can use a variety of naming services: Visigenic/Inprise's SmartAgents, a CORBA COS Naming Service, and a URL-based naming service. The URL Name Service is based on the Resolver Interface which lets a URL be bound to a CORBA object reference and the object reference bound to a URL be obtained. Server objects register themselves with the Resolver, i.e., associate themselves with a URL. Client objects invoke the bind method of a server object via the proxy stub passing the URL; the object reference is returned.
Netscape, in conjunction with Sun and IBM, are developing the Java Foundation Classes (JFC), a comprehensive set of tools for defining the look and feel of Java applications. JFC is the combination of Netscape's Internet Foundation Classes (IFC) and Sun's AWT. JFCs are each built as a JavaBeans component. JFC will be in the next release of JDK.
The CORBA Desktop is a tool-set which allows CORBA objects to be invoked from WWW browsers. An HTML-based GUI is generated for a service from its IDL interface. The HTML form invokes a script via CGI which invokes a generic CORBA client. Using DII, the CORBA client invokes the CORBA service. The limitations of the approach are slowness (due to communication and computation overhead) and the lack of type safety (due to the CGI)
CORBA Desktop is part of the Distributed System's Desktop in which arbitrary services can be invoked in a distributed system without prior knowledge of their existence and their interface specifications.
CORBAnet is an illustration vehicle sponsored by the OMG and developed and maintained by the Australian research organization Distributed Systems Technology Centre (DSTC) to both demonstrate interoperability between ORBs from various vendors using the Internet Inter-ORB Protocol (IIOP) and the potential use of CORBA over the WWW. CORBAnet links together the hardware, operating software, object request brokers, and associated products from key CORBA vendors. CORBAnet also serves as a testbed for CORBAservices and CORBAfacilities.
To access CORBAnet hyperlink to http://corbanet.dstc.edu.au. The CORBAnet application is a meeting booking system that allows users to book a room and staff for a meeting.
The CorbaWeb environment is a generic gateway between HTTP servers and CORBA objects which makes it possible for Web clients to navigate through CORBA object links using dynamically generated URLs for each object. CorbaWeb receives the user's actions through a Web Server CGI program and translates them into scripts for the CorbaScript component which invokes a CORBA/application object, and returns a HTML document containing the requested results.
A browser invokes CorbaWeb with HTML forms exactly as it would for a CGI application. The HTTP server passes certain requests to a CORBA client which runs as a module within the Web server. The CORBA client interacts with CORBA gateways which in turn interact with IDL wrappers of data sources. Installing a new gateway object is a matter of starting it from the command line; it registers itself with the CORBA name server, and becomes visible to the CORBA client and thereby accessible to the Web server. Server side includes embed ORB invocations into an HTML document. The message to CORBA is encoded in a URL (e.g., http://www.someBank.com/orb/customers/teller references a service called "teller"). The CORBA client invokes the gateway's invoke() operation on the URL encoded data, similar to the CORBA DII and Dynamic Skeleton specifications, which decodes the URL and invokes the object wrapper which implements a service. If the decoded data includes a tag identifying the originator of the request, any output from the object wrapper is encoded as HTML by the gateway and returns it to the CORBA client which passes it back to the browser. In this scheme, there is a separation of service and presentation logic in that the object wrapper delivers the service and the gateway deals with presentation issues (decoding input and rendering output as HTML).
HORB is a Java ORB that is not compatible with CORBA. It supports communication only between Java objects. Remote method invocation follows the standard ORB paradigm: a client stub routine (proxy for the server object) transmits the invocation via the ORB to a skeleton routine on the server. HORB uses its own on-the-wire format for Java objects, but supports multiple inter-object communication protocols via the Inter-Object Communication Interface (IOCI). Client stubs and server skeletons are generated directly from the Java source; there is no separate IDL. The HORB compiler is a preprocessor that generates Java source and calls the standard Java compiler to compile it. The HORB application language is Java without any extensions. The HORB client runtime is a set of Java classes; the HORB server runtime is a Java stand-alone application. Performance analysis shows that HORB is 2-3 times faster than Java RMI.
The InterLanguage Unification (ILU) System, through its Interface Specification Language (ISL) or the OMG Interface Definition Language (IDL), permits object-oriented interfaces between units of program structure, called modules, to be defined and documented. An interface specifies object types, other types, constants, exported methods, and exceptions that another module would use to communicate with it. ILU tools produce stubs for particular programming languages from the interface descriptions. These stubs can bind to, call, and be called from other stubs generated from the same interface description. To create a program, stubs are linked with application modules, ILU runtime support for the target language, and the ILU kernel library. Modules can be part of the same memory image or different memory images on different machines. A particular module might be part of several different memory images at the same time. ILU does all the translating and communicating necessary to use all these kinds of modules in a single program.
ILU 2.0 supports bindings for many languages used to implement modules, namely, ANSI C, C++, Modula-3, Common Lisp, Python, and Java. It also supports OMG's Internet InterOrb Protocol (IIOP) which allows ILU to communicate with other ORB systems. ILU can be used to build multi-lingual object-oriented libraries, implement distributed systems, and write CORBA services or clients. It is being used in several Digital Library research efforts such as the Stanford Digital Library and in the W3C implementation of the next-generation of HTTP (HTTP-NG).
Jylu is a complete Java implementation of the ILU runtime kernel and Java language binding.
Jade is a CORBA 2.0 IIOP communications engine written entirely in Java. The Jade "ORBlet" can be automatically downloaded into a web browser thereby providing Web users with access to CORBA services via the Internet. Enterprise service providers offer their on-line services to their customers through Web based, downloadable user interfaces implemented as a Java applet. The applet talks to its CORBA-based server using the Jade ORBlet.
JavaBeans is a set of Java component APIs which allows developers to write portable Java applets and applications from reusable components that can interoperate with other Java applets and applications, as well as with other existing document-sharing/component models via bridges, such as HTML-based frameworks (e.g., Netscape Navigator and JavaScript), LiveConnect, OpenDoc, ActiveX/OLE/COM, and CORBA. IBM and Apple are working on bridge technology that would enable OpenDoc and JavaBeans to work together in MacOS, OS/2, UNIX, and NextStep environments. SunSoft's JavaBean's–ActiveX bridge allows JavaBean components to be embedded and run in legacy ActiveX containers. Application-building tools, such as IBM's VisualAge, SunSoft's Java WorkShop, Symantec's Visual Café, and Inprise's JBuilder allow developers to graphically compose Java components and applications.
Beans can interact with several distributed computing approaches. Beans can use Java's Remote Method Invocation (RMI), CORBA IDL interfaces and IIOP, or JDBC and a database protocol for remote object access.
Enterprise JavaBeans extends the JavaBeans component model to provide a object-oriented transactional environment to build scalable business applications for manufacturing, financial, inventory management, shipping and payroll, and data processing as reusable server components. The draft specification for Enterprise JavaBeans will be available in summer 1997. Enterprise JavaBeans is part of the Java Platform for the Enterprise.
Server-side entities (directories, files etc.) are defined as resources, objects with methods that define behavior and attributes that capture state. Resource objects are a way of extending the server's functionality, and they replace CGI. All defined attributes must to be registered with an AttributeRegistry. An example of a resource is HTTPResources which has overloadable methods to handle the different kinds of HTTP requests (get, put etc.) and a set of attributes to define content-type, content-encoding, the MIME type of the resource etc. Other typical kinds of resources include FileResources, DirectoryResources, CgiResources, etc. New resources are defined in the typical OO manner by subclassing from the one of the appropriate pre-existing resource classes.
Resources can be created by either directly defining the resource object, or by wrapping an existing file system entity (file/directory) into a Jigsaw resource. For the latter to be done automatically, Jigsaw maintains a mapping between the Resource type and the underlying file name as part of the resource factory. One can also programatically create resources corresponding to entities in the filesystem without using the auto-wrapping capability. The programmatic approach is more versatile, e.g., it can allow many-to-many relationships between resources and file system entities, allow a resource name to be independent of the location of the file it is mapped to, etc.
Each running server has an associated resource factory. The resource factory allows the association of existing files and directories in the file system with resource types. It also allows resources to dynamically create/manipulate other resources. For example, a DirectoryResource can dynamically call the resource factory to create FileResource objects on-demand in response to HTTP get requests.
Comparing resources to CGI:
The Web Server project is part of the JTF-ATD reference architecture for command and control (C2). Many DARPA military projects have adopted this architecture or are extending it for use in domains such as modeling and simulation. In the architecture, various military task force commander domain-oriented collections of applications called "anchor desks" (e.g., planning, logistics, weather, others) depend on an infrastructure of services described in IDL and implemented in C++. Collections of services (called servers) provide capabilities for maintaining communications in a bandwidth-limited environment, access to heterogeneous data sources, web management, map creation, display and manipulation, plan management, situation assessment, etc. A C2 schema (several thousand object classes) is described in IDL and represents the description of shared command and control entities.
The JTF-ATD project is using Iona Orbix and GOTS (government off-the-shelf) CORBA product, CORBUS, developed by MITRE. Both are being integrated and others may be considered later. A dedicated Iona representative in their Boston office is supporting the project as problems are encountered as this is one of the largest Orbix development projects currently in progress.
The JTF-ATD Web Server project has defined a number of structured web types for plans, situations, maps, and models, but arbitrary webs can be constructed on-the-fly. The Web Server is actually a set of IDL and C++ libraries that are compiled into other servers and applications which inherit data structures and methods for creating, accessing and managing webs. Webs represent arbitrary graphs consisting of specialized node and link components which can be named, typed and navigated bi-directionally (from any node/web to any other node/web connected by a link). The Web Server does not have any knowledge of the internal contents of nodes as it is the responsibility of the servers and applications to extend the general data structures and methods contained in the Web Server for capabilities such as display, evaluation or manipulation of contents. Web Server webs and nodes are not WWW objects directly, but can be published in HTML or other representations that can be accessed by WWW browsers through the Web Server WWW Gateway. Military requirements for the Web Server include security, robustness, reliability, and replication of webs and their constituent collections of nodes and links in a bandwidth-adaptive manner. Webs and nodes are versionable to help provide consistency among different views of information and what-iffing. Monitors can be set on any specified nodes and webs to detect specific kinds of changes and triggers start particular actions based on the changes detected. There is a web editing tool (the Webber) which can operate on the specialized JTF-ATD webs or WWW webs, using a point-and-click GUI for establishing and editing links between any nodes and webs to form larger webs. The JTF-ATD project is using CORBA 1.2 services and implementing others as needed until these are addressed by CORBA 2.0 (or later) compliant products. JTF-ATD developers found it necessary to divide the collection of object class definitions into broad, high-level classes defined in IDL, and more specific, fine-grained classes defined in C++ due to IDL compiler limitations in the Sun Solaris and HP/UX environments at around 2000 classes.
While the webs which the Web Server manages are not directly WWW compatible, a bidirectional gateway between the JTF-ATD and WWW environments has been implemented to allow conversion of webs in either direction. Version 1.0 was recently released within DARPA and DoD and access to the prototype software and documentation can be requested by contacting Lee Erman at Teknowledge (lerman@teknowledge.com, (415) 424-0500 x 422).
Joe is primarily a client-side Java ORB that enables the networking of Java client/server applications for the Internet and Intranet. Joe links client Java applets with NEO server objects via NEO's CORBA 2.0 ORB. Joe is automatically downloaded along with the Java applets into a desktop Web browser unless it is permanently installed on the client machine. Joe establishes and manages connections between local Java objects and remote CORBA objects using IIOP. Joe also includes an IDL-to-Java compiler that generates associated Java classes from interface definitions of CORBA objects, and supports remote callback so Java applets can receive asynchronous event notification from remote objects and so Internet users can access secured remote services behind firewalls. Joe is bundled with NEO, Sun's CORBA-based networked object environment for Solaris. NEO contains development tools, system administration tools, and transparent networking to create, modify, customize and maintain applications offered as shared services (business objects). NEO also supports ActiveX/OLE/COM interoperability and access to legacy data stored in different types of databases.
Joe is based on Sun's Spring-Java
IDL system.
Netscape ONE (Open Network Environment) is a framework for building interoperable Internet applications that uses OMG's CORBA/IIOP as the basis for its distributed object model. By integrating Visigenic/Inprise's VisiBroker, a Java-based, CORBA/IIOP-compliant ORB, into its client and server software products, client and server objects can interconnect and communicate as if they were part of the same application. Using CORBA interfaces, IIOP allows enterprises to access legacy applications as well as build new network-centric applications.
To aid developers in building Web-based distributed applications, Netscape ONE also includes an IIOP-compliant infrastructure that transparently supports distributed method invocation for Java classes, including Netscape's IIOP-compliant Internet Foundation Classes (IF), a common set of Java classes, components, and APIs, and JavaScript. It also supports HTML, Java, communication and collaboration protocols (HTTP, NINTH, SM TP, I MAP4, POP3), and a broad set of standard, scalable security services (SSL 3.0 and X.509v3). (For a complete list with brief descriptions of key Netscape ONE technologies, see here.) Figure 1 depicts the Netscape ONE application architecture.
Figure 1: Netscape ONE Application Architecture
(taken from Netscape ONE whitepaper)
A typical Netscape ONE application consists of a client component and one or more server components that interact with the client through a set of common interfaces. Within the Web page container, the client component, Netscape ONE supports three different component execution environments: Java, JavaScript, and native-code components (plug-ins). Java and JavaScript components are platform-independent and can run on either the client or server side. Client and server plug-ins are accessed through platform-independent APIs, namely, the Client Plug-in API and the Server Plug-in API, respectively. The latter can be used to gain access to the major databases. LiveConnect provides a common object and messaging model allowing the three kinds of components to seamlessly interact and transparently access Netscape ONE services; they are treated as member objects of the containing Web page. LiveConnect is built on top of Netscape's Java Runtime Interface, which maps platform-specific object models to the LiveConnect object model. This makes it possible for any Java applet to use native methods. IIOP provides a distributed messaging system through which Netscape ONE applications can interact with other network-centric programs and any CORBA 2.0-compliant enterprise application, such as business objects, EDI, and transaction services. Any network-centric application can be make available as a service using IIOP. The IFC provides Netscape ONE components with a common set of platform-independent objects, APIs, and services required to build and deploy network-centric applications. It consists of controls to build GUIs, frameworks for concurrent, object persistence, and resource localization, and services for messaging, security, and networking.
There are nearly 60 development tools developers can use to develop Netscape ONE applications. The tools fall into three categories. First is Core Component Development Tools used to develop Java applets, plug-ins, CGI scripts, and multimedia elements such as graphics, sounds, animations, and visualizations. Second is Application Building and Integration Tools used to build web pages and web sites using HTML and JavaScript, as well as connect with databases and legacy systems. Third is Web Site Deployment and Management Tools for managing assets and links, and measuring site performance and usage.
Oracle's multi-tiered Network Computing Architecture™ (cf. whitepaper and FAQs) provides a unifying framework that combines client/server, Web/Internet, and distributed object computing technologies into a common computing model based on the open and de facto standards CORBA 2.0 (which include IIOP for object interoperability and IDL for language-neutral interfaces) and HTTP/HTML (which includes TCP/IP). In addition, Java is used to provide programmability, portability and extensibility and ActiveX/COM clients are supported through open COM/CORBA interoperability specifications. NCA allows component-based, network-centric applications to be developed and deployed, and for client devices, mainframes, Web servers, database servers, legacy systems, Internet and Intranets, and distributed object software to work together.
The key architectural components of the NCA (see Figure 2) are:
Figure 2: Network Computing Architecture
(taken from Oracle's NCA whitepaper)
Cartridges are containers for objects or software components that plug into the client (e.g., browser), application server, or backend database server to provide extensible functionality through open, standards-based interfaces. Cartridges enable existing Client/Server and legacy applications to run in Web environments. They can be written in Visual Basic, PL/SQL, C/C++, JavaScript or Java with an IDL mapping. Cartridges have access to numerous cartridge services, including CORBA services, as well as clients and servers via the ICX software bus.
The Universal Application Server (see Figure 3) includes a Web Request Broker for managing HTTP connectivity and a Connectivity Broker for managing multiple protocol connectivity to other services such as gateways to legacy messaging and transactions services and gateways to X.400 (email) and X.500 (directory services). The Web Request Broker provides the services of the ORB to Web cartridges which enable users to maintain a constant connection between a client, application server and database server. It supports dynamic load balancing of processes. The Connectivity Broker handles existing client/server and special purpose mechanisms.
Figure 3: Universal Application Server
(taken from Oracle's NCA whitepaper)
The Universal Server (see Figure 4) has an embedded IIOP protocol enabling it to host CORBA objects as well as enable data cartridges to talk to other cartridges across distributed architectures.
Figure 4: Universal Server
(taken from Oracle's NCA whitepaper)
A COM/CORBA bridging mechanism will enable ActiveX/COM clients to access other CORBA/Java cartridges through IIOP. Through ICX, ActiveX/COM clients will also be able to access ORB services provided by the Universal Application Server. In addition, NCA will provide the ability for a Java applet running within a COM application to communicate with an ActiveX control.
The NCA will support Java integration into CORBA/IIOP through a joint CORBA RFP with Sun Microsystems.
Oracle's Project Apollo is a business-to-consumer Internet merchant server built on top the NCA and plugs into the Web Request Broker as an application cartridge.
Open Blueprint is IBM's architectural framework for heterogeneous, distributed, network computing. The Open Blueprint structure provides support for the development, execution, and management of distributed, network applications. It supports HyperText Transfer Protocol (HTTP), Web Browser, Java, DCE, CORBA and CORBA services as well as expanded security, directory and network service functions. It also supports collaboration, intelligent agents and their management, enhanced systems management, internationalization of software and mobile computing functions.
The Open Blueprint structure (see Figure 5) views a system as part of a distributed network and the network as if it were a single system, i.e., everything is viewed as a single system image. As seen in the figure, there are 6 sets of component services: Network Services, Distributed System Services, Applicaton Enabling Services, Systems Management, Local Operating System Services, and Development tools. The building blocks in the figure contain multiple product-independent components implemented by various products on different system platforms. The Open Blueprint structure does not describe packaging of the implementations, but provides software principles and guidelines, defines the desired functions, and specifies important boundaries, interfaces, and technical attributes. Components can be combined to form infrastructure building blocks that can support different computing styles, such as two-tier, three tier, and N-tier client/server or network computing, and support for specific technologies and products.
Figure 5: Open Blueprint Structure
(taken from IBM's Whatis
Webpage)
A network of systems function as a unit connected by a communications network. Services on each system manage resources cooperatively across the network. All services are accessible by all applications from each platform even though all services are not on all platforms. Each node in the network is viewed as following the Open Blueprint structure.
The Distributed System Services consist of Communication Services, Object Management Services, and Distribution Services. The Communication Services supports 4 communication modesl: X/Open's Common Programming Interface for Communications (CPI-C), RPC, Messaging and Queuing, and HTTP. The Object Management Services include the Distributed SOM ORB, and the Life Cycle, Externalization, and Collections basic object services. The ORB is an implementation of OMG's CORBA and supports objects written in C++, SmallTalk, and Java. The Distribution Services enable a single system view of the network.
The Application/Workgroup Services supports compound documents and intelligent agents. The key compound document technology is OpenDoc. Intelligent agents are composed from the 5 sub-components of the Intelligent Agent resource manager: adapters, engines, knowledge used by the engines, libraries that provide knowledge persistent across agent activations, and tools for user interaction. The Application/Workgroup Services also includes the Java Virtual Machine that provides a platform independent execution environment for Java programs.
Iona has two ORB products. The C++ ORB, called Orbix, runs on over 20 OSes including UNIX, Windows 95/NT, MAC, OpenVMS, and MVS. These ORBs supports both IIOP and the proprietary Orbix protocol. Orbix is fully compliant with the CORBA 2.0 specification. The Java ORB, called OrbixWeb, is a lightweight client-side implementation of Orbix.
The Orbix architecture supports CORBA/COM integration. Orbix Desktop for Windows is the integration vehicle. COM-based distributed Windows applications can transparently access and distribute CORBA services while CORBA services can transparently access COM objects on Windows. Four integration models are supported: COM client - CORBA server, CORBA client - COM server, client and server in COM, and client and server in CORBA. An Orbix Wizard generates the proper code in each case for the developer.
Orbix server objects may be written in C++ or Java. The OrbixWeb IDL compiler will be fully compatible with the IDL-to-Java mapping when it becomes a standard.
ORB Plus is a fully threaded, scaleable implementation of OMG's CORBA/IIOP 2.0. It includes CORBA Connect, Enterprise Wizards, and the new services Trader Service, Transaction Service, and Security APIs. ORB Plus supports full two-way COM/CORBA interoperability via CORBA Connect. CORBA Connect provides real-time transparent conversion between the OLE, COM and CORBA object systems. It is is fully compliant with the OMG's COM-CORBA Interworking Specification. The package also include a JIT compiler and GUI object browser. Enterprise Wizards for Microsoft Developer Studio and Visual C++ assists developers creating C++ applications using ActiveX clients and COSS1 method invocations. It consists of the Server Wizard which generates server skeletons based on IDL files and user input, and the Insertion Wizards generates code to modify environment variables, and access the Naming Service, LifeCylce Service, and Events Service.
Future releases will include CORBA Components for developing applications with web browser front-ends. The HP CorbaWeb component allows the use of simple HTML forms programming to access CORBA servers; it includes a customized version of the Apache HTTP server. The Java ORB is a fully CORBA 2.0 compliant ORB implementation in Java for developing distributed Internet applications.
SOM extends CORBA with a Metaclass Framework that allows components to be dynamically created from existing components. It also allows components to be customized by inserting system behavior into binary object classes. This permits an object factory to combine a component's binaries with extended binaries that provide support for security, transactions, and concurrency.In addition, an object can inherit from a before-after metaclass, so each method invocation on an object can be preceded by a before method, and the end of execution of each method can be followed by a call to an after method. This is useful for pre/post processing, acquiring/releasing locks, logging information, or calling a security or licensing server.
Microsoft's DCOM is nearly the same thing as DSOM. They both allow objects to be created that other programs and objects can operate on in a binary-standard manner. Both Microsoft and IBM use these object facilities to write OS controls. Developers can use the same controls and easily modify their behavior.
The project also uses agent technology for managing multiple payment mechanisms and for information finding (collaborative filtering and distributed gathering). An adaptive agent learns to browse the Internet on behalf of the user based on user feedback on the usefulness of previously retrieved pages.
WebTk is an HTML Authoring Tool (editor/browser) written in Tcl and Tk using an Tcl/Tk HTML library making it easy for Tcl applications to be Web-aware. Sun Labs is adding microscripting support with Tcl so the pages can contain mixtures of HTML and Tcl/TK scripts. These scripts can be executed on the server using CGI to fill in variable parts of the page or on the client using the Netscape plug-in when the page is displayed.
Tcl Browser Plug-in for Netscape Navigator that runs Tcl/Tk applets.
Tcl/Tk documents referencing Safe-Tcl and presentation foils on the Tcl/Tk Project.
See the Scripting whitepaper.
The TeleMed system is built on Orbix's implementation of OMG's CORBA. It makes liberal use of inheritance so using OLE/COM that does not support inheritance would be difficult. The Orbix ORB has been integrated with ObjectStore , a commercial object oriented database from Object Design, to maintain persistence of the TeleMed objects (i.e., patient records). These objects are kept in distributed object repositories. CORBA 2.0 is used to represent and access repository objects. The interface to a repository is published in CORBA IDL and it can be mapped to programming language bindings suitable for individual clients.
Future work include the use of components and features of OpenDoc to implement Telemed's GUI and Graphic Patient Record.
Visual JavaScript is a visual development tool that enables enterprise developers to build dynamic Java-based applications that are platform independent and run across the Intranet and Internet. Using the point-and-click user interface, developers drag and drop prebuilt software components from the Component Palette onto Web pages. Components can be HTML form elements, JavaScript components, and/or JavaBeans components. Using the Inspector and Connection Builder features, developers can customize the application behavior of these components by visually setting properties and making connections between them. The JavaScript debugger is used to check completed applications. Components can be built using Symantec Visual Café for Java, Inprise's JBuilder, or Netscape's Component Developers Toolkit and added to the Component Palette.
Visual JavaScript enables an application to leverage the services of the Netscape SuiteSpot family of server software and CORBA services accessible via the Internet InterORB Protocol (IIOP) using the Visigenic/Inprise ORB built into the Netscape browser. SuiteSpot services include Netscape LiveWire database connectivity services from Netscape Enterprise Server, messaging services from Netscape Messaging Server, and directory services such as executing Lightweight Directory Access Protocol (LDAP) directory queries from Netscape Directory Server.
Visigenic has two versions of their CORBA 2.0 ORB: VisiBroker for Java (formerly PostModern's BlackWidow) and VisiBroker for C++. VisiBroker includes a IDL-to-Java compiler and a IDL-to-C++ compiler and an ORB runtime. VisiBroker is an agent-based architecture. Consequently VisiBroker offers object replication, fault tolerance, object migration, and load balancing. VisiBroker for Java also includes a secure bridge for accessing servers behind firewalls, is multi-threaded so multiple object requests can be handled by a single process, and uses IIOP as it only communication mechanism.
Visigenic/Inprise's VisiBridge is a software bridge that enables communication between COM/DCOM objects and CORBA objects. Applications built with ActiveX controls, Visual Basic applications or OLE-enabled applications can interoperate with CORBA-based server systems. The bridge software turns CORBA IDL interfaces into ActiveX controls. The resulting ActiveX Control objects, which contain CORBA client stubs representing the CORBA objects, are then embedded in client-side applications. Runtime client software passes requests from ActiveX controls to CORBA objects via IIOP.
The VisiBroker Gatekeeper enables an application object outside the enterprise firewall to access objects running on machines behind the firewall. The Gatekeeper supports HTTP tunneling, i.e., IIOP messages are encapsulated in HTTP so they can be passed through firewalls.
VisiBroker fully supports the fault-tolerant CORBA Naming Service for C++ and Java. Multiple naming services running in the same network can locate each other and automatically partition the namespace among themselves. This allows objects on different servers to be replicated and the load balanced. If a server goes down, VisiBroker automatically re-routes client calls to a replica. VisiBroker also supports a URL-based naming service. When a client requests an object services using a URL, the CORBA object reference is extracted from the file specified by the URL and used to bind to that object.
VisiBroker also fully supports the CORBA Event Service for C++ and Java. Using a supplier-consumer models, supplier objects can notify any number of consumer objects via an event channel the occurrence of a subscribed event.
A Java-to-IIOP translator utility can infer the IDL object inter-faces and automatically create the object stubs and skeletons. Java developers can use CORBA without having to learn IDL.
The VisiBroker IDL compiler will be fully compliant with the CORBA binding for Java when it becomes available from OMG.
VisiBroker has been incorporated into Netscape's Communicator browser. This enables Netscape ONE applications to access CORBA services and IIOP-compliant enterprise applications.
Web* defines a model to access CORBA services by a WWW browser. Web* is a server-side generic CGI script that accesses a set of layout pages, one at a time, which are HTML documents with embedded Tcl scripts. Web* extracts the HTML and sends it to the client, and interprets all the Tcl scripts and sends the results to the client. The Tcl scripts are written in TclDII, an extension of the Tcl language, which allows the dynamic invocation of CORBA services using DII and the Orbix ORB. Web* also retains client state from each WWW interaction thereby creating the illusion the client is in engaged in session-based transactions. The state information is captured as a collection of Tcl variables, which are transmitted to the clients as embedded hyperlinks in generated layout pages.
DEC uses its implementation of CORBA, ObjectBroker, to provide WWW users direct access to transactional information. All transactions go through the Web Broker, a common access point between the Web and DEC's internal application network. Running under HTTPD as a "cgi-bin" program, the Web Broker translates user's data provided in an HTML form to a generic ObjectBroker object. Using the completed object, ObjectBroker invokes the remote method to service the user's request. On the application server, the Object Wrapper Layer extracts the parameters from the passed object and formats it correctly for the Application Wrapper layer which invokes the application. The method's results are returned in a similar reverse pattern. The Web Broker merges the method's results returned by the Object Wrapper Layer with a Meta-HTML and outputs it to the user.
The ObjectBroker Desktop Connection (DTC) makes corporate business applications and services accessible to Window applications. With DTC, ActiveX applications can access ObjectBroker’s CORBA servers anywhere on the network or intranet.
In the W3Objects model, standard Web resources (HTML documents, GIF images, PostScript files, audio files, and the like) are transformed from file-based resources into objects called W3Objects. That is, into encapsulated resources possessing internal state and well-defined behaviors. The motivating notion is that the current Web can be viewed as an object-based system with a single class of object – all objects are accessed via the HTTP daemon. By changing to an object-oriented paradigm, specialized access can be achieved through the use of inheritance. W3Objects are responsible for managing their own security, persistence, and concurrency control. These common capabilities are made available to derived application classes from system base classes. The W3Object model provides a flexible and extensible way of building Web applications with Web resources encapsulated as objects with well-defined interfaces. Inter-object communication (peer-to-peer) is used though out W3Objects to support functionality such as referential integrity and caching.
A W3Objects server supports multiple protocols by which client objects can access server objects. When using HTTP, the URL binds to the server object and the permitted object operations are defined by the HTTP protocol. Or, the RPC protocol can be used to pass operation invocations to a client-stub generated from a description of the server object interface. W3Objects uses C++ as the interface definition language, although CORBA IDL and ILU ISL can be used.
W3Objects can also be accessed though a gateway, implemented as a plug-in module for an extensible Web server, such as Apache. URLs beginning with /w3o/ are passed by the server to the gateway; the remainder of the URL identifies the requested service and its parameters. Using a Name Server, the appropriate HTTP method is invoked on the requested service.
A HTTP servers talks to a WebObject (WO) application via a single generic WOAdaptor which is a CGI script. The WOAdaptor mediates between the HTTP server and the application. The application to be invoked is obtained from the URL to the WOAdaptor. For example, in the HelloWorld URL - "http://localhost/cgi-bin/WebObjects/Examples/HelloWorld", the part up to "WebObjects" is the URL for the WOAdaptor. The WOAdaptor uses the rest of the URL to find the application, and if necessary invoke it. WO is object model independent. It can interoperate with OLE-based applications and communicate with CORBA 2.0 objects.
An application is a HTTP event loop. An applications consists of multiple components, each of which generates a one page object (dynamic HTML content) of the application dialogue. Components consist of a HTML template, a script declarations file and a script file:
WO has a notion of sessions, and applications can consist of multiple sessions. Data can persist between sessions either by being in Webscript "session" variables (like C++ static data members) or by being stored on the component page. One can do rudimentary load balancing in WO. WOadaptor reads configuration files before launching applications. These configuration files can have machine preferences for application launches.
WebObjects Pro layers on WebObjects, and talks to OLE/COM and CORBA objects on the backend. WebObjects Enterprise layers on the other two, and connects the Web to databases and legacy mainframes. No backend ORB integration is referenced. Netscape and NeXT have an intranet alliance where WebObjects serves as the application development environment, talking to SuiteSpot (server side) and Navigator Gold (Client side).
D. Chappel. Understanding ActiveX and OLE: A Guide for Developers and Managers, Microsoft Press 1996, ISBN 1-57231-216-5.
R. Orfali, D. Harkey, and J. Edwards. The Essential Distributed Objects Survival Guide, Wiley (1996), ISBN 0471-12993-3.
R. Orfali and D. Harkey. Client/Server Programming with Java and CORBA, Wiley (1997), ISBN 0471-16351-1.
R. Orfali, D. Harkey and J. Edwards. Instant CORBA, Wiley (1997), ISBN 0-471-18333-4.
G. Pfister. In Search of Clusters: The Coming Battle in Lowly Parallel Computing, Prentice Hall PTR (1995), ISBN 0-13-437625-0.
G. Almási. A. Suvaiala, I. Muslea, C. Cascaval,
T. David, and V. Jagannathan, Web* - A Technology to Make Information
Available on the Web,
http://webstar.cerc.wvu.edu/webice.ps
(depricated)
Apple, The WebObject's Developer's Guide,
http://developer.apple.com/techpubs/enterprise/WebObjects/DevGuide/DevGuideTOC.html
M. Baentsch, L. Baum, G. Molter,
S. Rothkugel, and P.Sturm, Enhancing the Web's Infrastructure: From
Caching to Replication, IEEE Internet Computing, 1,2 (March-April 1997),
18-27.
http://www.computer.org/internet/9703/toc.htm
A. Beitz, R. Iannella, A. Vogel, and Z. Yang, Integrating WWW and Middleware, http://www.dstc.edu.au/AU/staff/andreas-vogel/papers/ausweb95/ausweb95.html
K. Brockschmidt, What OLE Is Really About,
(Microsoft whitepaper)
http://www.microsoft.com/oledev/olecom/aboutole.htm
T. J. Brando, Comparing DCE and CORBA,
http://www.mitre.org/research/domis/reports/DCEvCORBA.html
D. Chappell, DCE and Objects,
http://www.chappellassoc.com/DCEobj.htm
(deprecated)
P. E. Chung, Y. Huang,
S. Yajnik, D. Liang, J. C. Shih, C.-Y. Wang, and Y. M. Wang,
"DCOM and CORBA Side by Side, Step By Step, and
Layer by Layer" (Sept. 1997).
http://akpublic.research.att.com/~ymwang/papers/HTML/DCOMnCORBA/S.html
J. Dale, A Mobile Agent
Architecture to Support Distributed Resource Information Management,
Ph.D Thesis (January 1997).
http://www.mmrg.ecs.soton.ac.uk/publications/archive/dale1997a/
http://www.mmrg.ecs.soton.ac.uk/publications/archive/dale1997b/
(IEEE Internet Computing paper with David De Roure)
M. Dolgicer and P. Fischer, DCOM, ActiveX and
Corba Must Live Together, Application Development Trends (April 1997).
http://www.adtmag.com/pub/apr97/fe403.shtml
G. Eddon and H. Eddon, Understanding the Java/COM
Integration Model, Microsoft Interactive Developer (April 1997), 57-68.
http://www.microsoft.com/mind/0497/javacom.htm
S. Fowler, Issues on Integrating Objects on
the Web,
http://www.cs.wvu.edu/~fowler/exam1.html
E. Hastings and D.Kumar, Providing Customers Information Using the WEB and CORBA: Integrating Transactions, Objects, and the Web, http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/hastings/hastings.html
HotWired article, Steve Jobs: The Next Insanely
Great Thing [Web+Objects],
http://www.wired.com/wired/4.02/features/jobs.html
IBM, Overview of SOM, AIXpert (August 95),
http://www.developer.ibm.com:8080/library/aixpert/aug95/aixpert_aug95_somover.html
IBM, Introduction to SOMobjects,
http://www.objectwatch.com/issue3.htm
IBM, Open Blueprint Technical Overview,
http://www.software.ibm.com/openblue/id1b1/cover.htm
D. Ingham, M. Little, St. Caughey, S. Shrivastava,
W3Objects:
Bringing Object-Oriented Technology to the Web
http://www.w3.org/Conferences/WWW4/Papers2/141/
D. Ingham, W3Objects: A Distributed Object-Oriented
Web Server (position paper),
Object-oriented Web Servers and Data Modeling
Workshop, Sixth International World Wide Web Conference, Santa Clara, CA
(April 1997).
http://www.pencom.com/metamagic/workshop97/papers/ingham.html
IBM, Introduction to the Open Blueprint: A
Guide to Distributed Computing, 3rd Edition (December 1996).
http://www.software.ibm.com/openblue/id1a1/cover.htm
IBM, Open Blueprint Technical Overview,
3rd Edition (December 1996).
http://www.software.ibm.com/openblue/id1b1/cover.htm
Iona, OrbixWeb Programming Guide V2.0,
http://www.iona.com/support/docs/orbixweb/progguide.pdf.zip
Iona, OrbixWeb Reference Guide V2.0,
http://www.iona.com/support/docs/orbixweb/progref.pdf.zip
B. Janssen and M. Spreitzer, ILU Reference
Manual,
ftp://ftp.parc.xerox.com/pub/ilu/2.0/20a8-manual-html/manual_1.html
JavaSoft whitepaper, JavaBeans: A Component
Architecture for Java,
http://java.sun.com/beans/resources.html#whitepapers
JavaSoft, JavaBeans 1.0 API Specification,
http://splash.javasoft.com/beans/spec.html
J. R. Kiniry and K. Mani Chandy, Leveraging
the World Wide Web for the Worldwide Component Network,
http://www.infospheres.caltech.edu/papers/oopsla96.html
D. Larner, Migrating the Web Toward Distributed
Objects, World Wide Web Journal, 1,4 (Fall 1996),
http://www.w3j.com/4/s3.larner.html
F. Manola, D. Georgakopoulos, S. Heiler, B. Hurwitz, G. Mitchell, and F. Nayeri, "Supporting Cooperation in Enterprise-Scale Distributed Object Systems," In Papazoglou and Schlageter (eds.), Cooperative Information Systems: Current Trends & Directions, Academic Press (1997).
P. Merle, C. Gransart, J. Geib, CorbaWeb: A
Generic Object Navigator,
http://corbaweb.lifl.fr/papers/96_WWW5/paper/Overview.html
P. Merle, C. Gransart, J. Geib, CorbaWeb: A
WWW and CORBA Worlds Integration,
http://corbaweb.lifl.fr/papers/96_COOTS.ps.gz,
Microsoft whitepaper, WhatOLE is Really About,
http://www.microsoft.com/oledev/olecom/aboutole.htm
Microsoft paper, The Component Object Model:
Technical Overview,
http://www.microsoft.com/oledev/olecom/Com_modl.htm
Netscape whitepaper,
The
Netscape ONE Development Environment Vision And Product Roadmap,
http://home.netscape.com/comprod/one/white_paper.html
NeXt whitepaper, Bridging Mainframe to Web
with WebObjects,
http://www.next.com/WebObjects/Mainframe_Brief.html
(deprecated)
OMG paper, Comparing ActiveX and CORBA/IIOP,
http://www.omg.org/news/activex.htm
Oracle whitepaper,
Network
Computing Architecture,
http://www.oracle.com/nca/html/
A. Paepcke, S. S. Cousins, H. Garcia-Molina, S.
Hassan, S. Ketchpel, M. Röscheisen, and T. Winograd, Towards Interoperability
in Digital Libraries: Overview and Selected Highlights of the Stanford
Digital Librrary Project, IEEE Computer (May 1996).
http://www.computer.org/computer/co1996/r5toc.htm
J. Pasquale, Towards Internet Computing,
ACM Computing Surveys 28(4es) (December 1996),
http://www.acm.org/pubs/citations/journals/surveys/1996-28-4es/a215-pasquale/
(members only)
O. Rees, N. Edwards, M. Madsen, M. Beasley, and
A. McClenaghan,, A Web of Distributed Objects,
http://www.ansa.co.uk/ANSA/ISF/wdistobj/Overview.html
R. Resnick, Bringing Distributed Objects to the WWW, http://www.interlog.com/~resnick/javacorb.html
B. Schimpf, Securing Web Access with DCE,
http://www.eng.uci.edu/~peilei/schimpf.html
M. Shoffner, JavaBeans vs. ActiveX,
http://www.javaworld.com/javaworld/jw-02-1997/jw-02-activex-beans.html
(Part
1)
M. Hughes, JavaBeans and ActiveX go Head to
Head,
http://www.javaworld.com/javaworld/jw-03-1997/jw-03-avb-tech.html
(Part 2)
H. Satoshi, HORB: Distributed Execution of Java
Programs,
http://www.infosys.tuwien.ac.at/Research/Corba/archive/related/horb_wwca97.ps.gz
S. Vinoski, CORBA: Integrating Diverse Applications
Within Distributed Heterogeneous Environments, to appear in IEEE Communications
Magazine, Vol. 14, No.2, February 1997,
http://www.cs.wustl.edu/~schmidt/vinoski.ps.gz
Visigenic/Inprise, Distributed Object Computing
in the Internet Age (whitepaper),
http://www.inprise.com/visibroker/papers/distributed/wp.html
W3C, Jigsaw: An object oriented server (whitepaper),
http://www.w3.org/Jigsaw/User/Introduction/wp.html
J. Weiss, A. Johnson, J. Kiniry.
Distributed
Computing: Java, CORBA,and DCE, Open Software Foundation Research Institute,
(provides a good comparison of the three technologies)
http://www.osf.org/mall/web/SW-java/corba.htm
(Open Group Members only)
TU Vienna,
Java
Resources
http://www.infosys.tuwien.ac.at/java/
© Copyright 1996, 1997, 1998 Object Services and Consulting, Inc. Permission is granted to copy this document provided this copyright statement is retained in all copies. Disclaimer: OBJS does not warrant the accuracy or completeness of the information on this page.
Status: this report contains a daunting amount of material assembled first by Craig Thompson, then by Gil Hansen. The report was never finished but was useful to get some handle on the broad range of technical approaches that exist in the area of Web and object integration.
Last Modified: August 16, 2000 by sjf. Send comments to thompson@objs.com
Back to Internet Tool Survey - Back to OBJS homepage