Available online at ScienceDirect. IERI Procedia 7 (2014 ) Engineering. Objects. Distributed

Transcription

1 Available online at ScienceDirect IERI Procedia 7 (2014 ) International Conference on Applied Computing, Computer Science, and Computer Engineering Analytical comparison of Aspectized Service Oriented Distributed Objects Usha Batra a, Saurabh Mukherjee b, Anuj Ramesh Yadav c and a,c ITM University, Sector 23 A, Gurgaon, , India b Banasthali University, Rajasthan, , India Abstract Distributed Object Computing is a paradigm that allows objects to be distributed across a heterogeneous network and allows each of the components to interoperatee as a unified whole. The evolution of a revolutionary programming paradigm that promises to have a profound effect on the way we interact with computers, people and places is well known as Aspect Oriented Programming. Middleware platforms, such as RMI, CORBA, DCOM, J2EE and.net platform, offer abstractions for the complex distributed environment. Distributed middleware are difficult to build and implement because the distributed frameworks impose a large code overhead due to the specific distributed systems programming conventions. In this paper we implement Aspectss with distributed objects technologies and web services and compare the implementation behavior of distributed systems programming concepts in comparison to the design of web services based distributed middleware framework. The research challenge involves firstly removing crosscutting concerns by modularizing into separate units named Aspects and secondly implementation and comparison of the three major technologies in the field of distributed systems RMI, CORBA and Web Services The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license 2013 The Authors. Published by Elsevier B.V. ( Selection and peer review under responsibility of Information Engineering Research Institute Selection and peer review under responsibility of Information Engineering Research Institute Keywords: Aspect Oriented Programming, Common Object Request Broker Architecture, Remote Method Invocation, Remote Procedure Call, Service Oriented Architecture, Web Service. 1. Introduction Modularity stands the chief principle among many thatt contributed towards the success of OOP. Thus OOP consists of multiple modules; a module is defined as a single independent functional unit. Few code snippets The Authors. Published by Elsevier B.V. This is an open access article under the CC BY-NC-ND license ( Selection and peer review under responsibility of Information Engineering Research Institute doi: /j.ieri

2 72 Usha Batra et al. / IERI Procedia 7 ( 2014 ) cannot be amassed to a single module. Such snippets tend to be scattered across multiple modules defying the definition of a module to be independent, in Aspect Oriented Software Development (AOSD) community such a context is termed as Crosscutting Concerns (CC) [1]. OOP that supports a huge dictionary of functionalities does not have a solution of its own to deal with the named scenario of CC, it is advent that respective programming paradigm was not developed considering the CC problem. Modules such as security management, session tracking, session expiry, logging, tracing and profiling are affected by such a problem. Consequences following the CC context are redundant, unreasonable, update anomaly, inefficient, scattered and tangled code. AOP is a solution to the former problem by allowing a way to cluster such code snippets to a modularized unit called Aspect [2].An aspect is a functional unit that is used for incorporating crosscutting code to a single module [3,4]. AOP is not a replacement to OOP as it does not enhance the functionality prospect of the one given through the later but provides an ideal modularization by eliminating CC in form of Aspects hence the former stands as an extension to the later [2, 3]. Distributed system is a software system that interacts and coordinates between components spread across the network to achieve the desired result. Such interaction between components essentially modules are realized through RPC. RPC is a methodology to invoke remote procedures without hard coding the details of interaction and invocation of the remote procedure is carried out as if the procedure was locally available in the same program. Java version of RPC is called as RMI. RMI supports only native Java invocation for availing programming independent interactions another technology named CORBA is used. For example through CORBA a Java procedure can make a RPC type invocation to a C++ procedure. Another technology highly advertised for developing distributed system is WS based upon SOA. The fetal effect of CC in OOP is also inherited to RMI CORBA and WS. Hence in our approach we present a cleaner modularization through weaving aspects with RMI CORBA and WS [5, 6]. 1. Research Challenges a. Firstly, removing CC by clustering it into a single unit named Aspect. b. Secondly, Implementation and comparison of the three major de facto s in the field of distributed systems RMI, CORBA and WS. The rest of the paper is organized as Section II discusses the implementation techniques for Aspectized CORBA followed by implementation of Aspectized WS in Section III and Section IV gives a tabular comparison of Aspectized Distributed Objects and Aspectized Web Service behavior followed by conclusion in section V. 2. ASPECTIZED CORBA. In our previous research [8], we presented a brief introduction to aspect and Aspectized RMI implementation. So we extend our research through aspectizing CORBA and WS.In CORBA [7, 12] an Interface is written in Interface Definition Language (IDL) this particular interface is compiled to an Object Oriented Language specific code that consists of stub and skeleton that communicate with each other through Object adapter. Object adapter performs binding and polymorphism. It simplifies the task of ORB by assisting an ORB in delivering a client request to an object implementation. Once ORB has the client s request, it locates appropriate object adapter associated to the object and forwards the request to it. Adapter interacts with the object implementation s skeleton, that performs marshalling and invocation of relevant instance method. 2.1 Steps to develop an Aspectized CORBA Implementation with reference to our basis application [7] STEP 1 Create an interface in IDL, In our implementation the interface is it declares three methods estconnection(), getpatientinfo() and shutdown().

3 Usha Batra et al. / IERI Procedia 7 ( 2014 ) STEP 2 Compile the.idl file using a compiler. As our implementation is in java context, Hence we used idlj(idl to java compiler). idlj fall. idl command in console. The command generates a hierarchy of classes named HealthCarePOA, HealthCareOperations, HealthCareHolder, and HealthCareHelper. Specialized roles of these classes will be elaborated further in this section. STEP 3 Defining HealthCareImpl class and HealthCareServer class, the former extends HealthCarePOA and overrides the methods declared in.idl. Whereas the later handles ORB resolving and handling naming context. STEP 4 Defining a logging aspect named LogAspect. STEP 5 Implementing a Client named HealthCareClientt that initializes the HealthCareImpl reference with the registered object through the assistance of HealthCareHelper.narrow( NamingContextExt_reference.resolve_str(name) ). STEP 6 Start the ORB using the command start orbd -ORBInitialPort 1050 ORBInitialHost localhost. STEP 7 Start HealthCareServer class and start HealthCareClient class that will invoke the former class methods. <<Java Class> >> HealthCarePOA <<Java Interface>> _methods:hashtable HealthCareOperations _ids:string[] HealthCarePOA() _invoke(string,inputstream,responsehandler):outputstream _all_interfaces(poa,bytel[]):string[] _this():healthcare _this(orb):healthcare <<Javaa Class>> HealthCareHelper _id:string _typecode:typecode healthcarehelper() insert(any,healthcare):void extract(any):healthcare type():typecode: id():string read(inputstream):healthcare write(outputstream,healthcare): :void narrow(object):healthcare unchecked_narrow(object):healthcare HealthCareImpl orb:orb con:connection ps:preparedstatementt HealthCareImpl setorb(orb):void estconnect():void getpatientinfo():void shutdown():void HealthCareServer HealthCareServer() main(string[]):void getpatientinfo() :void estconnection() ):void shutdown():voidd <<Java Interface>> HealthCare 0..1 HealthCareClient HealthCareClient () main(string[]):void <<Java Class> >> HealthCareHolder HealthCareHolder() HealthCareHolder(HealthCare) _read(inputstream):void _write(outputstream):void _type():typecode <<Java Interface>> Streamable Org.omg.CORBA.portable _read(inputstream):void _write(outputstream):void type():typecode LogAspect LogAspect() publicmethodexecuted():void before():void around():void

4 74 Usha Batra et al. / IERI Procedia 7 ( 2014 ) Fig. 1 Class Diagram of Aspectized CORBA Implementation a) HealthCareOperations It is the interface that contains all the procedures/modules declared in the original.idl interface i.e. java specific declaration of methods estconnection(), getpatientinfo() and shutdown(). b) HealthCare It is the interface that contains the characteristics of HealthCareOperations, and CORBA specific interfaces such as org.omg.corba.object and org.omg.corba.portable.idlentity. c) HealthCareHolder It is used to hold the reference to an object that implements HealthCare Interface This class is used to handle an out or an inout parameter in IDL in Java Syntax. In an IDL, a parameter may be declared to be out if it is an output argument and inout if the parameter contains an input values as well as carries an output values. d) HealthCarePOA Portable Object Adapter (POA) is a type of object adapter that facilitates an object implementation to communicate with different ORB. This Java class is the skeleton, server side proxy combined with portable object adapter. It extends org.omg.portableserver.servant and implements HealthCareOperations, and org.omg.corba.portable.invokhandler as shown in class diagram Fig 1. e) HealthCareStub At the server side two classes must be provided the Servant and the Server. Former class is named HealthCareImpl and later as HealthCareServer. Servant class is the implementation of the IDL interface and hence extends HealthCarePOA and overrides the methods. f) LogAspect It declares a pointcut named publicmethodexcecution() that represents any public method irrespective of return type, method name and parameter list. Defining two advices before() and around() on the same pointcut publicmethodexecution(). before() advice logs in the current executing method through thisjoinpoint.getsignature() and Aspect location that is executed during the method invocation through this keyword. around() advice logs in the amount of time in nanoseconds required by a method to execute. 3. ASPECTIZED WEB SERVICE Web service is based on Service Oriented Architecture (SOA) [8]. The messaging design patterns [9, 10, 11.] allow the interchange of information by exchanging messages between components and applications. In our implementation of web service the server side program is HealthCareWebServiceServer.java and associated aspect along with it named LogAspect.aj, LogAspect is similar to the one discussed in Aspectized CORBA used for aspectizing the logging CC. 3.1 Steps to develop an Aspectized Web Service [8] STEP 1 Create a base class. We have developed a class named HealthCareWebServiceServer along with an aspect LogAspect. Former consists of two methods estconnection(),getpatientinfo() and execute() while the later is similar to the one in CORBA implementation. refer the class diagram shown in Fig 2. STEP 2 Publish this service in Universal Discovery Discription and Integration (UDDI) for this purpose we used Apache Axis 2 as a registry of web service realizing the SOA architecture [8]. The UDDI holds the Web Service Description Language (WSDL) that contains all the vital configuration details, protocol and location of the web service so that such a web service could be invoked by the client.

5 Usha Batra et al. / IERI Procedia 7 ( 2014 ) STEP 3 Once the client receives the WSDL document it can generate server stubs of the web service and then use these stubs to communicate with the web service. STEP 4 Creating the object of the stub class in our implementation context is being HealthCareWebServiceServerStub class and then using the stub methods to invoke the service. HealthCareWebServiceServer health.care con:connection ps:preparedstatement HealthCareWebServiceServer() esconnection():void getpatientinfo():void execute(int):void <<Java Class> >> LogAspect HealthCareWebServiceServerStub HealthCareWebServiceServerStub(ConfigurationContext,String) HealthCareWebServiceServerStub(ConfigurationContext,String,b... HealthCareWebServiceServerStub(ConfigurationContext) HealthCareWebServiceServerStub() HealthCareWebServiceServerStub(String) getpatientinfo(getpatientinfo): void execute(execute):void estconnection(estconnection): :void Client Client() main(string[]):void Execute MY_QNAME:QName locall:int localltracker:boolean LogAspect() publicmethodexecute():void before():void around():void GetPatientInfo GetPatientInfo( () getomelement(qname,qmfactory):omelement serialize(qname,xmlstreamwriter):void serialize(qname,xmlstreamwriter,boolean):void getpullparser(qname):xmlstreamreader << <Java Class>> EstConnectionn EstConnection () getomelement(qname,qmfactory):omelement serialize(qname,xmlstreamwriter):void serialize(qname,xmlstreamwriter,,boolean):void getpullparser(qname):xmlstreamreader Fig. 2 Class Diagram of Web Service and Web Service Client 4. Aspectized Distributed Objects Vs. Aspectized Web Service Aspectized Objects Distributed vs. Web Service Parameters Protocol Service Discovery RMI Java Remote Method Protocol RMI Registry CORBA Internet Inter ORB protocol CORBA Naming Services Web Service Simple Object Accesss Protocol UDDI/WSDL Specification Data Model Communication Java Remote Interface Mathematical Data Model Between Stub- Skeleton Interface Definition Language-IDL Interface Definition Language-IDL Stub Skeleton communicate through object adapter and ORB Web Services Description Language-WSDL Web Services Description Language-WSDL Service Oriented Architecture Based Language Neutral No(Java Specific) Yes(Object Specific) Yes Level Interoperability No Syntactic Interoperability Syntactic and Semantic Fig. 3 comparison of Aspectized Web Service and Distributed Objects

6 76 Usha Batra et al. / IERI Procedia 7 ( 2014 ) Conclusion This paper presented an Aspect Oriented Programming based implementation approach for comparing distributed technologies and web services. It is observed that level of interoperability is best in case of Web Services based distributed communications. The Web Services as middleware support in Services Oriented Architecture provides end to end solution. References [1] Ladded R, AspectJ in Action, 2nd edition. Manning Publications [2] Filman, R.E. & Friedman D.P. Aspect Oriented Programming is Quantification and Obliviousness. Workshop on Advanced Separation of Concerns at OOPSLA [3] Saigal, N.: Modularizing Crosscutting Concerns in Software, nsaigal/papers/nalinsaigal/dissertation.pdf, 2011 [4] Kaur, A., Johari, K.: Identification of Crosscutting Concerns: A Survey. International Journal of Engineering, Science and Technology 1(3), ,2009 [5] Aspect-oriented programming site, [6] Amirat, A.K.: Modularization of crosscutting concerns in requirements engineering. International Arab Journal of Information Technology, Vol.5, No.2, 2008 [7] John Wiley and Sons, The Common Object Request Broker: Architecture and Specification, Revision 2.0, Object Management Group, 1995 [8] Roshen, W.: SOA-Based Enterprise Integration: A Step-by-Step Guide to Services based Application,May 2009 [9] Usha Batra, Saurabh Mukherjee, Enterprise Application Integration (Middleware): Integrating stovepipe applications of varied enterprises in distributed middleware with Service Oriented Architecture, IEEE International Conference on Electronics Computer Technology, 2011 [10] Usha Batra, Saurabh Mukherjee, Software Design Patterns for message driven service oriented integration of stovepipe applications in healthcare enterprise, Recent Researches in Applied Computer and Applied Computational Science, 2011 [11] Usha Batra, Saurabh Mukherjee, Shelly Sachdeva, Pulkit Mehndiratta, Aspect Oriented Programming for Modularization of Concerns for Improving Interoperability in Healthcare Application. Paper published in Springer Verlag LNCS 7813, pp , DNIS [12] Liu Jing Yong, Zhang LiChen, Zhong Yong and Chen Yong. Middleware-based Distributed System Software Process. International Journal of Advanced Science and Technology, Volume 13, 2009.