Source Code Components Architectural Characterization - Term Paper Example

Source Code Components Architectural Characterization Client Code Accessing a Component As the concept of reusability has now grass roots in the field of Software Development, so while developing a new component (class), the developer has to think over two major areas. How can that component be accessed by client components, whether the clients components or of the same platform or different compared to that of server Component (new component). After being developed and implemented into the project, where the new component is being accessed by many other client components, what issues would arise if there is a need to make some changes in the code of the new component. In Java, from the basic level, the component is being built in two ways. 1. A type (interface) is being developed without implementation and its implementation is generated at runtime by calling method of class as illustrated by the following example: This example is illustrating the environment of In-process application where the called component is going to be processed within the memory space of the caller/client application. In this example, the interface “My” contains two abstract methods, which needs to be implemented in order to have “My” type object at runtime. The implementation of “My” type is returned at runtime by a static method of class “A”. Now both these types, i.e. “My” and “A” are packaged in the form of a jar-file and can be reused in any java based program easily provided that the proper description about the features (methods, instance variables) are provided to the developer of the new java based program, where he wants to incorporate these existing types. Now based on these existing types, where the client program knows the method signatures of interface “My” and the method signatures of class “A”, the client program is developed and implemented in the desired business area. Now after a period of time if: the change is required in the business logic/coding of the method implementation present in the anonymous class within the scope of A.generateMy( ) method, then only class “A” needs to be compiled again, then repackaged in jar-file to be used by the client java program. There is no need to recompile the client java program. The client java program will keep on enjoying the changes of the implemented methods of “My” interface. the change is required in the signature of the methods of interface “My”, or if the there is requirement to increase the number of methods, then every thing is going to be edited and recompiled, i.e. interface “My”, class “A” and the client program. 2. A type (interface) is being developed without implementation and its implementation is being done at design time by creating a subclass of the interface, which is going to implement every abstract method of the interface. Compared to the previous example, in this example the client java program can create the instance of the implementation class directly. Again the interface “My” and class “A” are going to be packaged in jar-file and integrated with the client java program. Any changes in the coding of the implemented methods would only require the class “A” to be recompiled only, while any changes in the signature of the methods of interface “My” or the increase in the number of methods in the interface “My” would force to change the implementation class “A” and calling syntax in the caller program and after that every thing is going to be recompiled including the client program. The above example is again a sample of In-process application architecture. The above component can be enhanced to suit the needs for distributed application i.e. Out-process architecture, where the component executes in a separate memory space apart from the client java program. For out of process components, java has given various technologies to suits ones needs. The technologies are: RMI – Remote Method Invocation CORBA – Common Object Request Broker Architecture EJB – Enterprise Java Beans JAX - RPC – Java API for XML based Remote Procedural Call RMI Remote method Invocation is one of the cornerstones of Enterprise Java Beans and is an extremely handy way to make distributed java applications. The idea is simple: instead of invoking a method on another java object running in the same java virtual machine, we invoke a method in a Java object in another JVM on the same computer or a different one. The RMI architecture is based on one important principle: the definition of behavior and the implementation of that behavior are separate concepts. RMI allows the code that defines the behavior and the code that implements the behavior to remain separate and to run on separate JVMs. The idea here is that RMI creates an object called a stub that implements the Remote interface and runs in the client’s JVM. When the client invokes remote method, the stub’s implementation of the method transmits the method invocation over to the server’s JVM where another special object called a skeleton interprets the request and invokes the correct method. When the server’s method returns a value or throws an exception, the skeleton packages the resulting information and sends it back to the stub. The stub then returns the information to the client. The stub and the skeleton communicate using a protocol called the java remote method protocol (JRMP). Actually, JRMP is just one of the protocols the stub and server can use. They might also use a protocol called IIOP (Internet Inter-ORB Protocol), which is a protocol from another remote method invocation architecture called CORBA (Common Object Request Broker Architecture). The RMI implementation is essentially built from three abstraction layers. The first is the Stub and Skeleton layer, which lies just beneath the view of the developer. This layer intercepts method calls made by the client to the interface reference variable and redirects these calls to a remote RMI service. The next layer is the Remote Reference Layer. This layer understands how to interpret and manage references made from clients to the remote service objects. In JDK 1.1, this layer connects clients to remote service objects that are running and exported on a server. The connection is a one-to-one (unicast) link. In the Java 2 SDK, this layer was enhanced to support the activation of dormant remote service objects via Remote Object Activation. The transport layer is based on TCP/IP connections between machines in a network. It provides basic connectivity, as well as some firewall penetration strategies. For better understanding, following example illustrates and RMI system. The first step is to define an interface “Calc” which declares all the remote features offered by the service. Secondly, the implementation “CalcImpl” of the interface. This class uses “UniCastRemoteObject” to link into the RMI system. After compiling both the interface and implementation, the related stub and skeleton classes are generated by using the RMI compiler “rmic”. This compiler runs on the implementation class. Now for hosting the “CalcImpl” instance, an application should have to be created which when executed, would create the “CalcImpl” instance and bind it to the RMI Registry with the name “CalcServ”. After this activate the RMI System by executing “rmiregistry” tool and then compile the “CalcServ” application and execute it. Hence the “CalcImpl” object would be hosted in the RMI system waiting for the client’s call. This client application, by using JNDI api lookup for the “CalcServ”. Thus the client receives the remote reference. Through this reference the client invokes the method of local stub class which is responsible for marshalling the method call over the network to the skeleton class, which un marshals the method call and invoke the method of the server object. After that the return value would be marshalled by the skeleton class and unmarshalled at the client side by the stub class. For successful invocation of the remote method of the remote object, RMI passes parameters and returns values between JVMs. For primitive value RMI passes it by value between JVMs. For object RMI again passes the whole object over the network rather than only the reference. For this RMI uses a the technology of serialization. CORBA Although CORBA and RMI are generally considered competing technologies, in the Java realm, they actually work together nicely, thanks to a special blend of CORBA and RMI called RMI-IIOP. One of the deficiencies of Java RMI is that it is Java-specific. We cannot use RMI to invoke methods on a C++ program. This is why CORBA comes into the picture. CORBA also uses the stub and skeleton concept. The CORBA objects represent business objects, our application tends to look a lot like an EJB application. Language independence is made possible via the construction of interfaces to objects using the Interface Description Language (IDL). IDL allows all CORBA objects to be described in the same manner; the only requirement is a “bridge” between the native language (C/C++, COBOL, Java) and IDL. CORBA objects communicate with each other using an Object Request Broker (ORB) as an intermediary, and can communicate over many popular networking protocols (such as TCP/IP or IPX/SPX). ORBs from different vendors communicate over TCP/IP using the Internet Inter-Orb Protocol (IIOP), which is part of the CORBA 2.0 standard. Currently, third-party ORBs are available for the more popular programming languages (including C++, Smalltalk, Java, and Ada95). As other languages grow in popularity, CORBA vendors undoubtedly will release ORBs for those languages, as well. The most important piece of the Object Management Architecture is the ORB. The ORB is the only portion of CORBA that must be present in order to build a CORBA-compliant application. As an example if a java client wants to a C++ method, then firstly an interface should have to be defined using IDL. This interface would then be compiled by using both java/IDL compiler and C++/IDL compiler. The compiler is going to generate language based stub and skeleton code. The C++ object is then registered on C++ compliant ORB and the java client would then access it by passing calls through the java compliant ORB. EJB EJB (Enterprise Java Beans) architecture, also provides a java based distributed architecture. The concept is explained by the help of the following example. In this example, all of these types are packaged in jar-file and is deployed on an EJB Server like J2EE 1.4, which is also called as EJB container. The client java program, which might be running on a different machine on the network, must have only the compiled form of “MyHome” and “MyRemote” interfaces, in order to know how to communicate with the component “A”. Now the client program can not itself instantiate the objects of “MyHome” and “MyRemote” interfaces as there is no implementation at the client side. Now under such circumstances, the client program by using JNDI (java naming and directory interface) services, connects to the EJB container and claims for the implementation of “MyHome” interface by calling InitialContext.lookup( ) method. The EJB container on the other hand creates the implementation object of the “MyHome” interface and serializes it over the network towards the client. The client on the other hand then calls the create( ) method of the “MyHome” interface, which knows how to generate the implementation object of “MyRemote” interface. At this point of time it should be remembered that the methods with in the object of “MyRemote” does not have the actual coding of class “A” methods, rather they just have network link to invoke the methods of class “A” on the EJB Container. Now when the client program, calls any method of “MyRemote” object, subsequently a message is passed over the network to the same method of the bean object of class “A”, which executes with in the memory area of EJB container and then returns the value over the network back to the method of the “MyRemote” object, which in turns return it to the client program. Now if a change is required in the coding of methods of class “A” then only class “A” is going to recompiled and repackaged with the interfaces to be deployed on the server. The client program and the client’s copy of “MyHome” and “MyRemote” interfaces should not have to be changed. But if the change were required in the method signature of class “A” then changes would be done on every end. JAX – RPC XML based RPC is incorporated for accessing web-services. The web service, which is a component hosted on a J2EE compliant web server is able to respond to the client request over the network by using SOAP (Simple Object Access Protocol) messages. The remote procedural call is represented by an XML-based protocol, such as SOAP. In addition to defining envelope structure and encoding rules, the SOAP specification defines a convention for representing remote procedure calls and responses. An XML-based RPC server application can define, describe, and export a Web service as an RPC-based service. WSDL (Web Service Description Language) specifies an XML format for describing a service as a set of endpoints operating on messages. With the JAX-RPC API, developers can implement clients and services described by WSDL. There are three different modes of JAX - RPC services: Synchronous Request-Response: The client invokes a remote procedure and blocks until it receives a return or an exception. One-Way RPC: The client invokes a remote procedure but it does not block or wait until it receives a return. The runtime system for the JAX-RPC client may throw an exception. Non-Blocking RPC Invocation: The client invokes a remote procedure and continues processing in the same thread without waiting for a return. Later, the client processes the remote method return by blocking for the receive or polling for the return. Bibliography Mark Wutka (2001), Using Java 2 Enterprise Edition, Que. Read More