|
Site home page Get alerts when Linktionary is updated Book updates and addendums
Get info about the Encyclopedia of Networking and Telecommunicatons, 3rd edition (2001)
Download the electronic version of the Encyclopedia of Networking, 2nd edition (1996). It's free! Contribute to this site Electronic licensing info
|
Distributed Object Computing Related Entries Web Links New/Updated Information Note: Many topics at this site are reduced versions of the text in "The Encyclopedia of Networking and Telecommunications." Search results will not be as extensive as a search of the book's CD-ROM. As discussed under the topic "Object Technologies," objects are encapsulated procedures and/or data, a building block of reusable code that can be combined with other objects to create programs or add functionality to existing programs. Programmers generally work with objects. A component is a self-contained coded module that provides some service to other components in an object-oriented environment. You can think of a component as a mini-application. You've no doubt downloaded components such as sound and video players that enhanced the functionality of your Web browser. Think of Web browsers as containers that run components. Distributed object computing is about building applications in a modular way with components. Components are typically designed for distribution across networks for use on multivendor, multiplatform computing systems. Because components are meant for distribution, standard interfaces and communication methods are important. An interesting paper written by Simon Phipps of IBM (see the link on the related entries page) provides insight into how the Web and component technology fit together:
XML has become a critical part of component technologies because it allows for the exchange of structured information among any type of systems. XML creates a framework for documents in which data has meaning as defined by tags. Any system or application that understands XML tags can access data in XML documents. The distributed object/XML relationship is discussed further in the next section. In an enterprise environment, components developed for in-house use may reside on multiple servers in multiple departments. Some objects are used throughout the organization and may be the core components of an application. Other components may add special functionality or exist temporarily on user systems. The component approach lets network administrators and develops quickly update components as needed, without changing the whole system. If multiple companies are involved in business-to-business relationships over private networks (or the Internet), object technologies can be used to integrate business processes. All that is necessary is a standard object interface that lets each company access common data or objects. Some of the advantages of component technology are listed next. While component technology may be used to build custom in-house applications, such as accounting systems, Web browsers and browser add-ins provide the most immediate example of component technology.
Component models provide the basis for inter-service communications and component integration. Web sites can offer sophisticated services for users by performing interactive tasks that involve calls by one server to multiple other servers. These multitiered environments allow tasks to be broken up into different services that run on different computers. Services such as application logic, information retrieval, transaction monitoring, data presentation, and management may run on different computers that communicate with one another to provide end users with a seamless application interface. Distributed Component Architectures A standard component model and inter-component communication architecture are critical in furthering the use of component technology on the open Web. The most common component models are CORBA, EJB (Enterprise Java Beans), and Microsoft COM, as discussed shortly. Distributing applications over networks leads to some interesting problems. In a stand-alone system, components run as a unit in the memory space of the same computer. If a problem occurs, the components can easily communicate that problem with one another. But if components are running on different computers, they need a way to communicate the results of their work or problems that have occurred. An ORB (object request broker) handles the plumbing that allows objects to communicate over a network. You can think of the ORB as a sort of software bus, or backbone, that provides a common interface through which many different kinds of objects can communicate in a peer- to-peer scheme. One such ORB is CORBA (Common Object Request Broker Architecture). CORBA is cross-platform and allows components written for different operating systems and environments to work together. An object makes a request and sends it to the ORB. The ORB then locates the requested object or an object that can provide services, and establishes communication between the client and server. The receiving object then responds to the request and returns a response to the ORB, which formats and forwards the response to the requester. In this model, objects simply specify a task to perform. The location of the object that can satisfy the request is not important. The end user sees applications as being seamless, even though services and data may be coming from many places on the network. The ORB process is similar to a remote procedure call with the added benefit that the ORB itself is capable of locating other objects that can service requests. Actually, an ORB is an alternative to RPCs (remote procedure calls) and message-oriented middleware. To run sophisticated applications and transactions over networks, there is a need to register components and coordinate their activities so that critical transactions can take place. For example, if data is being written to multiple databases at different locations, a transaction monitor is needed to make sure that all those writes take place. Otherwise, they must all be rolled back. Microsoft Transaction Server is an example. It coordinates the interaction of components and ensures that transactions are implemented safely. Because it provides these features in an object-based environment, it is essentially a transaction-based object request broker. See "Transaction Processing" for more information. The most important object models are described here:
DCOM is the most common of the technologies at this point, mainly because of existing support, developer knowledge, and the pervasiveness of Windows clients. CORBA has better multivendor, multiplatform support and is best for heterogeneous environments. CORBA was originally designed for tightly controlled enterprise network environments and well-managed inter-company connections. Both DCOM and CORBA are considered enterprise application development technologies, although both have been extended to work over the Internet. But they are considered too complex for most Web applications. EJB has gained the widespread support of Web developers. It is implemented in application servers from IBM, BEA Systems, and iPlanet (the Sun and Netscape Alliance). The CORBA 3.0 specification defines CORBA Beans, which combines features of CORBA and EJB with additional support for XML. Microsoft's SOAP is important because it represents a move from the traditional remote procedure call method for exchanging information among objects to a message-passing scheme that uses XML. Microsoft now believes that messaging model best for the Web, as opposed to connection-oriented models such as RPC (remote procedure call) and Java's RMI (remote method invocation). By allowing objects to interact via XML, data interoperability is enhanced. SOAP carries XML messages across the Web via HTTP, which is pretty much a bottom line for interoperability. The Object Management Group that managed CORBA standards has been working with OASIS (Organization for the Advancement of Structured Information Standards) to define how XML can be used to support CORBA services. EJB uses XML to provide information about Bean's interfaces, data types, and structure. Copyright (c) 2001 Tom Sheldon and Big Sur Multimedia.
|
