分布式环境中动态代理的应用外文翻译 第2页
Figure 7. Generic implementation of JavaBeans active properties mechanism.
Using inheritance and aggregation for implementing the MVC pattern require adding event-firing code in all the set methods of all Model classes holding the data. This implies dependency of the GUI implementation on the corresponding JavaBeans classes, stronger coupling and potentially extra costs of testing and maintenance.
Figure 5 shows how a Point object with type IPoint(representing a Model) can be attached to a meta-object of type Bean Proxy, A listener object of an arbitrary type Demo (representing a View) is assigned. The implementation of the binding function createProxy() is shown in Figure 6.
Figur5.Attaching an application object Point object to a BeanProxy.
Figre 6.The class factory BeanProxyFactory.
In addition to InvocationHandler, BeanProxy also implements the interface IPropertyChangeSupport to allow for addition and removal of listeners and to fire a property change event after intercepting the set methods. Intercepting any change of state of a base level object of any type is implemented in Figure 7 as follows. Before invoking the set method on the base-object, the proxy gets the old value of the object’s field. It then invokes the set method, get the new value and fires the event. Any other method is delegated to the base-object. We note that the base level object attached implementation of JavaBeans active properties’ mechanism.
We note that BeanProxyFactory and BeanProxy are implemented independently of base-objects and thus can be used as library classes providing support for implementing GUIs of arbitrary applications. Reflection and polymorphism allow the implementation of generic code. Java’s dynamic proxies mechanism provide means to invoke the reflective code at runtime.
OPEN ARCHITECTURE IN A DISTRIBUTED SYSTEM
The architecture of Figure 4 provides a suitable OO framework to implement code separated from, and independent of, client applications and allows the composition of components with application code at runtime in a natural way. From a distributed system perspective, however, it represents a single application running on a single JVM. The proxy code must be downloaded and installed on the client’s machine(I.e. where the application code runs) to permit the construction of an open architecture and consequently to allow the customization of the default implementation.
In a distributed environment, the code must be accessible by several clients running on different machines, each with its own JVM. In such a case, the link between base and meta-level must be modified in a way which allows several applications at the base level to customize the behaviour of their objects concurrently using meta-objects running on a different machine, The resulting client/server architecture requires the specification of a communication protocol and consequently the application of the technology that allows the implementation of such a protocol. There are several alternatives, the most common of which are the Java Remote Method Protocol (JRMP), better known as the RMI protocol[18], the Internet Inter Object request broker Protocol (IIOP) associated with CORBA[19,20] and the HyperText Transfer Protocol()HTTP) On the Web[21].
Herein, we extend the single JVM open architecture to a client/server architecture with several JVMs running (possibly) on different machines, where one of them represents the server and provides reusable code. To achieve this goal, we first consider RMI protocol and use the corresponding technology(Java’s RMI API) available as part of the Java developing environment since JDK1.1.x. Next, we look at a CORBA implementation using fully functional ORB that is available in every deployment of the Java 2 Platform since JDK1.2.x. Finally, we consider the HTTP protocol and build a Java Servlet implementation using Java ‘s Servlets API available as part of Java 2 Platform, Enterprise Edition. In our discussion of the different implementations, we omit issues related to network security, access control, data encryption or Internet firewalls, which we consider the scope of our research,
The most natural extension of the open architecture of Figure 4 is client/server architecture with several clients at the base level connected to one server application at the meta-level over a (TCP/IP) network(see Figure 8).
Figure 8.A two-level reflective architecture with dynamic proxies as remote objects
Using JRMP as a communication protocol, the communication between clients denoted by App.1,Appp. 2, ..., and App. N, at the base level and the server application at the meta-level, realized on top of the TCP/IP protocol, extends over the tree layers of the RMI architecture. The RMI system provides the client with a stub (a proxy) representing the remote object to which the application object can be bound to customize its behaviour. The remote method call on the stub is forwarded to a RemoteRef object residing in the remote reference layer; this layer defines and supports the invocation semantics of RMI. The connection between the JVM of the client and that of the server is realized at the transport layer with the support of the TCP/IP protocol.
With the IIOP protocol, communication between client and server is realized in a similar fashion. The object reference on the client side, App. 1, App. 2,…,App.n, points to a stub function. The stub uses the ORB to connect to the server machine that runs the server object. After establishing the connection, the stub sends the object reference and parameters to the skeleton code linked to the destination object’s implementation. The skeleton code transforms the call and parameters into the required implementation-specific format and calls the object. Any results or exceptions are returned along the same path over the ORB. The ORB represents the underlying transport layer.
Servlets follow a request/response model in which a client sends an HTTP request message to a server and the server responds by sending back a reply message. Server are normally used to support application processing assigned to a middle tier that acts as a Web server in so called three tier client/server systems, passing and controlling the requests and responses between a lightweight client and a data source. The clients, App.1,App.2,…, and App.n pass their requests to the servlets on the server side utilizing the HTTP protocol and receive, in response, a reference to remote objects.
We note that by distributing the application over several machines and assigning the meta-level its own JVM on which the server process(es) runs, we do not modify the semantics of reflection provided by Java’s dynamic proxies persists. The proxies’ invocation handlers are still interpreted as meta-objects, to which application objects at the base level, distributed over different client processes and memory environments, can be attached to customize their behaviour. Moreover, the causal relationship between base and meta-level remains the same. Distribution adds a new dimension to the existing structure without affecting the other dimension to the existing structure without affecting the other dimension representing the base-meta property of objects. The reification process and its triggering by method calls (events) at the base level remains the same and with RMI, CORBA and Java’s servlets technologies, the details of how this process develops over the network remain hidden from the user. The question we need to address is, what modifications are required in order to attach an application client object to a remote reusable meta-object running on a different machine?
We now address the question of constructing a distributed system of the architecture of Figure 8. The resulting system supports code reuse using the networking technologies available in the Java 2 Platform. We start with the RMI, followed by CORBA and finish with a look at the servlet implementation of our architecture. We deal with each of the networking approaches separately and in each case we consider lients as simple applications that communicate with their respective servers over the corresponding protocol.
With the support of the networking technologies provided by the Java 2 Platform, it is possible to distribute the objects of Figure 8 over different JVMs by further dividing them into client and server objects. Base objects with their interfaces represent client applications, whereas proxies with associated handlers and factories define the server application.
Figure 9.IProxyFactory defines the communication interface between clients and server
RMI-based system
The ProxyFactory or its representative plays the role of interface between client and the customization service provided by the meta-objects. To transform a single application system into a distributed RMI-based system, the following steps are employed.
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] 下一页