|
Wednesday May 8 2002 Web Services and Remote References An Intimidating Task? What are "remote references", and how do they relate to distributed object technology? Are the concepts of a remote object reference still applicable for Web Services technology? This article describes briefly the software architecture concept of remote references, and shows why they are best avoided when using XML Web Services due to the fundamental mismatch between the service oriented middleware approach of Web Services and the object oriented middleware required to support a remote reference architecture. What are "Remote References"? A number of different technologies exist for building distributed client/server applications, but the most common and popular approach today is to use some type of "distributed objects", although this may well be replaced shortly by the "service-oriented" approach of XML Web Services. Distributed Object Technology Distributed object technology allows object-oriented software components running on one machine to be accessed from client programs running on different computers. It also allows calls between processes on the same machine where the "local" and "remote" hosts are actually the same computer. This allows distributed applications to be written without having to worry about the ultimate location of the server process - whether that is on the same computer, the same local network, or half way across the world in the Internet. This is the important concept of "location transparency", which allows such things as testing an application in a development environment with both client and server on the same machine, then for production deployment running each on different bigger machines to maximize throughput of the system. For a distributed object system to work, there are five parts in the total end-to-end communication picture that are common to all different implementations of this technology:
Definition of the term Remote Reference Remote references (or remote object references) are a way for object-oriented software components to interact across process or machine boundaries, but with "location transparency" from the point of view of the client program. Examples of Remote References from Existing Middleware There are several common middleware technologies that use remote references, although sometimes using slightly different phrases to describe the concept. CORBA The CORBA (Common Object Request Broker Architecture) standard from the OMG (Object Management Group, http://www.omg.org/technology/documents/corba_spec_catalog.htm) is based exclusively around remote references - all remote CORBA objects are accessed by an objref (object reference), and the IOR (Interoperable Object Reference) format is a standardized way to represent and store these object references in a serialized binary form defined by the CORBA specifications. It is possible to pass an objref as a parameter on a call to a CORBA object, or return an objref from a call as either a return value or an output parameter. CORBA objrefs can either be transient (the object references become invalid when the server implementation program stops) or permanent (server implementation instances created on demand if necessary), and object references can last longer than lifetime of a particular object. RMI - Java Remote Method Invocation All RMI objects are remote objects, and calls to these use the remote references to these obtained through some form of registry lookup - usually either the RMI Registry process, or a JNDI (Java Naming and Directory Interface) naming context. Normally RMI objects are transient, but the RMI Activation system provides a means for "permanent" remote object references where an instance of the server object implementation is created on demand to service the request if necessary. EJB - Enterprise JavaBeans The Enterprise JavaBeans framework builds on top of the RMI or CORBA distributed object technology by adding the elements of managed object lifecycles, managed transaction semantics, and declarative security policies on top of the basic RPC mechanism. DCOM DCOM is Microsoft's RPC technology for making COM (Component Object Model) objects available across process and machine boundaries. Originally, it provided the basic RPC and object activation and lifecycle facilities of RMI or CORBA, but over time it evolved to also cover the higher-level framework functions of transaction and security management through the combination of DCOM and MTS (Microsoft Transaction Server). .NET Remoting The .NET Framework includes as standard extensive facilities for supporting the making and receiving of remote method calls, including full control of object activation policies, declarative security, and transaction attributes. Microsoft provides extensive technical documentation on the .NET Remoting framework through the MSDN website. For more details, see http://msdn.microsoft.com/ and http://www.msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/hawkremoting.asp. Applying Remote Reference principles to Web Services The concept of remote references can be mapped fairly cleanly into Web Service technology. The data required to represent a remote reference can be encoded into an XML format using the approach of a composite data type with the appropriate fields. A schema definition can be created for this representation, so that a remote object reference can be serialized into a recognizable form on the wire. When the remote reference data arrives on the client, the data can be stored in an appropriate internal storage object created by the middleware library ready for a suitable interface to be applied to make it usable to the client program. There is the obvious question of who creates and controls the schema definition for the remote references, and the possibility that multiple competing formats may exist, up to one per possible implementation language that exists in the works. All of these are concerns for Web Services infrastructure vendors, but are likely to be resolved over time as the technology matures. The XML Protocol working group at W3C (http://www.w3.org/2000/xp/Group/) is looking at the related areas of the Asynchronous Messaging and Event Notification usage patterns, although they are not yet looking at the standardization of remote references specifically at the moment. Remote Object Factory The situation of a Web Service that acts as a "factory" for another service instance is much harder to deal with using general purpose Web Services software. This factory service will attempt to return the remote reference data for the client to construct a client-side proxy for the second service, and then use that newly constructed proxy for further communications. This requires a language capable of dynamically creating local proxy instances, the necessary SOAP libraries for the client-side programming language that can recognize this data as the representation for a remote reference and act accordingly, and finally there needs to be a suitable pre-existing interface to provide a wrapper for the local proxy and make it usable in a strongly typed language such as Java. Client Callback All the previous discussion of the problem of factory objects applies equally to the client callback situation, just obviously in the reverse direction of course. As a simple example, how would a Visual Basic client program create a suitable remote reference to pass to a Java Web Service? Even though a VB.NET program may be able to create a callback reference compatible with .NET Remoting without too much trouble, it is not likely to be in the form that is directly usable with a Java Web Service. Minimizing Problems with Remote References By far the easiest way to minimize problems with remote references is simply not to use them at all! There are very few, if any, scenarios where what we are trying to achieve by using remote references cannot be achieved by other more "service-oriented" mechanisms. For the situation of exposing as a Web Service an existing system that already uses remote references extensively as factory objects (which is a very common approach in mature CORBA systems), it is usually easier to create a simple "façade application" that mirrors the interface of the underlying service, but uses opaque handle values or tokens to ensure all reference objects remain in the same technology domain. Thus we avoid the problem of programming language semantic mismatch or a technology translation gaps. Where the decision is taken that remote references are going to be used by a Web Service then it is better to restrict that service to internal use inside the corporate firewall. It will be extremely hard unless you are a large company such as General Electric to get all your trading partners to change to using the same SOAP library as you have chosen just so they can use that one particular Web Service from your company, but it is considerably easier to adopt an in-house technology standard. Finally, remember that as soon as remote references are used in an application, the problems of "distributed garbage collection" need to be borne in mind so as not to restrict server scalability. When the server has full control of remote object lifecycles, it can take steps to intelligently optimize the number of object instances in existence at any point in time to match the current demand from clients. Conclusion One of the hardest parts of a software architect's job is making decisions about the implementation technology and approach to use to solve a particular business requirement. All the new XML Web Services technology is making many fashionable sounding things possible now that were previously impossible or very hard without this technology. It is still the software architects' responsibility to consider the long-term implications of the decisions they make at the early stages of the technology adoption cycle, and there are a number of problem areas that need very careful decisions. This article is an extract from Web Services Business Strategies and Architectures. Buy the book from Amazon.com Or purchase the extended PDF version of this article from:
Adobe Acrobat format (PDF) - 85K |