In CORBA, client and server applications interact over the ORB. Using the ORB, the client conveys a request for a method invocation to the server and the server sends results back to the client along the same path.
We follow a similar procedure to the RMI case where we define an (IDL) interface and implement it on the server side using the functionality of ProxyFactory. Moreover, we use the IDL programming model of the Java 2 Platform, known as Java IDL, consisting of both the Java CORBA ORB and the idlj compiler. The compiler maps the Object Management Group’s (OMG) Interface Definition Language (IDL) to java bindings [22]. The model enables distributed Web-enabled Java applications to transparently invoke operations on remote network services using the industry standard IDL and the HOP protocol [20].
Following the IDL programming model, we define remote interfaces using the IDL, then compile the interfaces using the idlj compiler. The compiler generates the Java version of the interface, as well as the class code files for the stubs and skeletons that enable our applications to hook into the ORB. Applying idlj on the IDL interfaces is similar to invoking the rmic-tool of the RMI system on remote object implementations, as for example, BeanProxyFactoryWrapper in the previous section. Because the services provided by the server are reusable pieces of code, they are generic, implement general behaviour and are independent of applications' specifications. The IDL interfaces, which nominate the services implemented on the server side and passed to clients over the ORB, reflect the genericity of these services by using generic parameters and return types not related to any client application. IDL provides appropriate types, e.g. any, that allow us to express the genericity of the services. An any-type is mapped into Java org.omg.CORBA.Any and an object of such type represents a pair consisting of an omg.org.CORBA.TypeCode and a value. We note that org.omg.CORBA.Any provides operations that allow insertion and extraction of the TypeCode and the value contained in the object.
Figure 16 shows an example of a generic IDL interface in pseudo code, where consecutive, dots denote further functions. The first in-parameter, obj, of type any represents the application object to be attached to the proxy. The proxy, implemented at the server side, provides reusable functionality suitable to customize the behaviour of the object. The second parameter is of type any and is added arbitrarily. The function's return value is also of type any. The module ProxyObjects is mapped into a Java package with the same name where the stubs and skeletons needed for the communication over the ORB are placed.
A Java sample implementation of the IDL interface ProxyFactoryWrapper is shown in Figure 17. The class extends the ProxyFactoryWrapperPOA (line 5) and provides a method for each operation in the interface. An object of type ProxyFactory is used as an aggregate (line 6) and initialized in the constructor (lines 8-10). In the method createProxy( ), the objects' content (values) of the org.omg.CORBA.Any parameters are first extracted as java.lang.Objects (lines 13 and 14).The return object of type org.omg.CORBA.Any is created using the instance of the ORB currently
Figure16
Figure17
associated with the skeleton (line 15). The extracted objects are used as parameters of the method delegated to the aggregate to obtain a proxy object as a return value (line 18). The proxy object is inserted into the return object (line 19) before the latter is returned (line 21). Delegating the call to ProxyFactory is similar to the way we implemented the RMI remote object BeanProxyFactoryWrapper in Figure 14.
The skeleton ProxyFactoryWrapperPOA is generated by the idlj compiler and acquires a name of the form <InterfaceName>POA as part of the IDL/Java mapping specification. All the skeleton classes generated by applying the idlj compiler allow our server application to connect to the ORB runtime system and provide marshalling and un-marshalling routines. There is an alternative to this inheritance implementation style of associating object implementation classes with a skeleton class, called delegation or the Tie-method. With the Tie-method, ProxyFactoryWrapperImpl does not extend ProxyFactoryWrapperPOA but it implements ProxyFactoryWrapperOperations and delegates method invocations to the skeleton class ProxyFactoryWrapperPOATie Generating the required classes to implement the Tie-Method is achieved by using appropriate options when applying the idlj tool.
The POA (Portable Object Adapter) is a component of the ORB structure responsible for looking up and potentially activating the implementation for executing operations'.
Figure 18 shows a typical implementation of the server application class. In the main method,
Figure 18
上一页 [1] [2] [3] [4] [5] [6] [7] [8] [9] 下一页
分布式环境中动态代理的应用外文翻译 第4页下载如图片无法显示或论文不完整，请联系qq752018766
