A Generalized Distributed Delegate Object Model for ...

Arab J Sci Eng DOI 10.1007/s13369-016-2057-y

RESEARCH ARTICLE - COMPUTER ENGINEERING AND COMPUTER SCIENCE

A Generalized Distributed Delegate Object Model for E-com and M-com Applications N. Shenbagavadivu1 · I. Bremnavas2 · B. Lakshmi3

Received: 21 August 2015 / Accepted: 20 January 2016 © King Fahd University of Petroleum & Minerals 2016

Abstract There is a growing trend toward the usage of mobile computing for several applications, and it is important that the mobile systems are given adequate support at both system level and communication level. The main aim of the proposed distributed delegate object model is to reduce the round trip time (RTT) of huge number of transaction request in E-Com and M-Com applications. Delegate object is a shared object which acts as a place holder for all valuable mobile business information and updates business-related information to the customer automatically. In conventional model, all transaction requests are forwarded to the server directly, whereas in the proposed model, all the transaction requests are handled by delegate object itself which acts as a middleware component thereby reducing the RTT. The proposed model is simulated and tested in thin client and thick client test bed. The result shows improvement in RTT for both thin client and thick client environments. Keywords Delegate object · Mobile business · Mobile computing · Round trip time

B

I. Bremnavas [email protected] N. Shenbagavadivu [email protected]

1

Department of Computer Applications, Anna University – BIT Campus, Trichy, Tamilnadu, India

2

Department of Computer Engineering and Networks, College of CS and IS, Jazan University, Jazan, Kingdom of Saudi Arabia

3

Department of Computer Applications, Jayaram Engineering College, Trichy, India

1 Introduction The growing popularity of electronic business and use of Internet technology increases the demand for extended distributed application environment. In the present scenario, the concepts of e-commerce/m-commerce applications such as electronic funds transfer, supply chain management, mobile money transfer etc., are widespread among large- and medium-scale organizations. These applications are working in a highly distributed and heterogeneous environment. For example, the client/user can access the business data which may cause security problems and also the updated information cannot be retrieved in proper time because the updation of data is performed in server side [7]. To improve the availability and effective data retrieval of information for different types of business clients, we need a generalized distributed model using delegate object. Generally electronic business and mobile business applications always provide up to date information to their customers. This process requires constant querying of database by the application layer. It carries a lot of performance overhead caused by frequent request sent to the database. If the application component identifies a change, the change is thereby retrieved and updated to clients. The general distributed architecture uses an asynchronous pattern such as event based performance and time-consuming tasks. It notifies the changes in database to application layer which reduces constant polling that consumes time and processing power. Most of the electronic business data are held using a delegate object. The delegate object is accessed by a set of services which reduces the number of queries to the database as the delegate object acts as a place holder for data. In the proposed model, the shared object acts as a place holder for all valuable business data that can be shared by various distributed applications for reliable and synchronous

123

Arab J Sci Eng

data transmission which improves security and content availability.

2 Related Work Ceglar and Calder [1] has introduced the concept of a shared object collaborative framework and explained how the concept can be incorporated in an existing object-oriented toolkit. The collaborative systems were simplified, through the elimination of redundant structures and reduction of object instance. Calder et al. [2] has created a distributed environment which implemented the notion of shared object, distributed shared objects and introduced active shared mobile objects. This simulated a distributed shared memory with security, good performance, reliability and transparency. Green and Miller [3] has discussed the design and implementation of multi-tier portal architecture for thin and thick client model. The multi-tier portal architecture is required to provide a scalable and flexible architecture for a beginner to survive in the complicated business environment. Janakiram et al. [4] has developed a new model namely the surrogate object model to handle the asymmetry problem in distributed mobile systems. This model defines an architecture that allows mobile devices to participate seamlessly in computing and communication environment. It also connects the mobile device and its support environment namely the surrogate object in the static network to act on behalf of each mobile device. The surrogate object can remain active and maintain information regarding current state. It also plays an active role on behalf of the device. The surrogate object model elegantly solves a whole set of problems in distributed mobile systems such as: location management, mobile data access in client-server systems, disconnected operations, etc. It also provides an ideal placeholder for host-specific information, thus enabling the application- or host-specific constraints to be enforced. This model efficiently solves various set of problems in distributed mobile systems. This distributed model is a base model of the proposed work. Kang et al. [5] has proposed a framework to keep all mobile application changes updated in location maps stored in a distributed database server. The framework is equipped with updating mechanism consisting of an update manager on the server side. It is also responsible to upload and distribute Scalar Vector Graph (SVG) map object and updates to mobile application subscribers. On the mobile application side, an update handler will replace SVG map objects with the latest one. This is suitable for application that requires frequent updates especially, if new maps are added to the collection or database. The literature survey as detailed above in distributed and mobile application environment, indicates that frequent data retrieval from a remote database in a distributed mobile appli-

123

Fig. 1 Structure of the delegate object

cation. It requires a higher transaction time. However, our proposed model is an extension of surrogate model in which the delegate object is utilized exclusively for business transaction services. In surrogate object model, the surrogate itself acts as a placeholder for each mobile host. It also maintains the information regarding the current state of the device to resolve instability problem in wireless networks. The methodology in our proposed delegate model is to assign a delegate to each business transactions which act as a business component for maintaining business-related information and reduces the round trip time (RTT). Finally, surrogate object connects the mobile device and its support environment, whereas the delegate object acts as middleware to connect business client with server in distributed environment.

3 Structure of the Delegate Object The delegate object contains attribute new data which carries the latest information extracted from business database. The attribute old data holds previous value from new data which is needed for comparison. Date attribute is used to notify the updation time. The attribute flag is controlled by data retrieval service and data updation service to hold the status of e-business data. The structure of the delegate object is shown in Fig. 1. The getInstance() method is a static method which returns an instance of the delegate object. The set and get method ensures updation and retrieval of attribute values. The update() method helps to check whether an information update was completed or not and it also updates flag value. The isupdate() method returns current status of flag attribute. 3.1 Proposed Distributed Model In the proposed distributed model, the shared object is used for reliable and synchronous data communication which improves the secured content availability in valuable business data shared by various distributed applications. The shared

Arab J Sci Eng

Fig. 2 Generalized distributed architecture model

object is named as delegate object. The delegate object is responsible for notification of client’s nearby events, such as insertion of new data or modification of existing data. When new data is updated, either by inserting new record or modifying an existing record, the database is well informed about the event and gives necessary information to corresponding delegate object by triggering of a function. The updated information is automatically transferred to client through a delegate object. The delegate objects are managed by middleware applications. The proposed model maintains the consistency of the business information through trigger services. Any change or updation performed in business database is automatically triggered by trigger services for necessary updation in corresponding delegate object to ensure consistency. In generalized distributed architecture various business services are handled by delegate object. The data retrieval service forwards client’s request to a container. The container obtains an appropriate delegate object’s reference by using middleware application such as message oriented middleware, object request brokers and enterprise service bus. The data updation service transfers data to respective delegate object from business database whenever data is updated. The response content is clearly separated from presentation layer when the client is a web browser or a mobile device. The Fig. 2 shows the generalized distributed architecture model using delegate object. The model in Fig. 2 reduces data access time as the client request is handled by middleware application using delegate object. Otherwise the middleware application communicates to corresponding database and the updated information is transferred to client. It also ensures the integrity of the data between delegate object and database. The trigger service is used to achieve data integrity by transferring past value and updated value to delegate object. The trigger service also checks the constrains of data like maximum limit, range of values and authentication to ensure data integrity. The model

is tested using test beds for both thick and thin client environment. Thus, the performance of this model is evaluated against thin client and thick client architecture in distributed environment.

4 Thick Client Model Using Delegate Object Most e-business applications are required to perform fast and reliable, while delivering dynamic, personalized content necessary to achieve business goals. When business logic resides on client side, it reduces processing load on application server or database thereby improving scalability and load balancing. Today of e-business applications are m-business applications (mobile) which run on limited resources. Therefore, business logic and presentation logic are implemented as a web component. This web component acts as a manager to manage and communicate with delegate object. The test bed model is shown in Fig. 3. In this model, the delegate object is deployed in web container. When the client sends a request to handler, it takes the responsibility of providing the requested service. The updated service information is held in delegate object. The web component for data retrieval retrieves data from delegate object and sends back a response to handler. The end client may be a browser or a mobile device, and the result is generated according to client type. The handler customizes and processes the data received from web component according to the type of client. Any changes or updation made in the database is monitored, and triggered service is invoked. The delegate object is then updated by t data updation service. 4.1 Communication Model for Thick Client Architecture In this model, the client uses web browser or mobile application to send a request for accessing a particular business service. To access a service from the server, the client can

123

Arab J Sci Eng

Fig. 3 Test bed for thick client model using delegate object

register himself with the server just by invoking the registration procedure. The server obtains the necessary information from registered client and sends a list of available e-business services in response. The client selects a service from the available list and invokes the same. The client request is then passed through a custom pipeline which contains a collection of web components. The data retrieval component processes the request and finds a reference for an appropriate delegate object associated with the requested service. The service provider, which is called data update web component, transfers all newly updated data to their respective delegate object from business database through a trigger service. The trigger service notifies any change in business data and updates this change in delegate object. The important features of this model are reduced the data access time and synchronized the data transfer between database and the client through web components. The delegate object can also be modified and accessed any number of times by the web components. The data retrieval web component obtains the data from the delegate object and transfers the response to handler. 4.2 Implementation Details of the Delegate Objects in a Thick Client Model The generalized thick client model is implemented in Java. The web components are Java servlet programs. The e-business and m-business data are maintained in Oracle database. The data updation is carried out using SQL statements. The following database trigger shown in Fig. 4 is fired when a modification is performed in the database. The calljava() function invokes another static function send() written in Java. As the function is static, it can be involved without creating a reference to an instance of class object in which it is defined. The class file is loaded into Oracle using Load Java utility. On loading the

123

Fig. 4 Trigger service

file, two new tables are created automatically in database. The table JAVA$CLASS$MD5$TABLE is used to store the reference of class files that are added, and the table CREATE$JAVA$LOB$TABLE is used to store class files itself [6]. The new data, old data and the updated time are handled by static function. This function establishes a link to service provider (web component for data update) using URL and URLConnection classes. The service provider gets the instance of corresponding delegate object using getInstance() method and updates the new and old data using set methods in DelegateObject class. It also modifies the flag attribute value as ‘true’ using update() method.

5 Thin Client Model Using Delegate Object The thin client model follows three-tier architecture. The three tiers are client tier, middle tier and data source tier. The client tier has client, handler and web component for

Arab J Sci Eng

Fig. 5 Test bed for thin client model using delegate object

data retrieval. The middle tier has a delegate object and web services. The data source tier has a trigger service and data base. The test bed model is shown in Fig. 5. Web services are most popular paradigm for distributed computing. By adopting service oriented architectures (SOA) using web service technology, enterprises can flexibly solve enterprise-wide and cross-enterprise integration challenges. There is always a focussed, ever changing business challenges and opportunities exists in web services. In the previous model, delegate object is managed by client web component. This object management logic is separated and implemented as a web service by making the client as loosely coupled with data services and delegate object. The web services allow the delegate object to reside in any container and permit the client to access the object without knowing the location. The client is kept unaware of any change in location or migration of the object thereby making the client to be loosely coupled. 5.1 Communication Model for Thin Client Architecture The thin client model differs from thick client model in the management of delegate object since the logic is implemented as a separate service from the web component and deployed on a remote middle tier. The web component forwards the request to the middle tier. The middle tier or the application layer contains the delegate object and a web service to manage the delegate object. A delegate object is created for each business need, and a separate web service implements the logic for all business function. To process the request, the data retrieval component invokes the corresponding web service using Web Service Definition Language (WSDL) which acts as an interface. The web service gets the instance of the appropriate delegate object associated with the requested service. The communication with the data tier is implemented in a similar like thick client model. The updated information from the delegate object is retrieved by the web service. The web service also manages the data handled by the delegate object.

The web service responds to the presentation layer. Initially the web container lookup the Universal Description, Discovery and Integration (UDDI) registry to obtain the right service from WSDL. This WSDL is then used by web component to communicate with the web service. 5.2 Implementation Details of the Delegate Objects in a Thin Client Model The generalized thin client model is implemented in Java. The web components are Java servlet programs. The distributed environment is implemented using service oriented architecture. The e-business and m-business environments are heterogeneous across various operating systems, applications and applications infrastructure service oriented architecture with its loosely coupled nature allows enterprise to plug in new service or upgrade existing services in regular fashion to address the new business requirements. Implementation procedure for server tier and client tier is similar to thick client model which is discussed earlier in Sect 4.2. The only difference is the service provider (web component for data update and data retrieval) which is responsible for managing the delegate object in thick client model. In thin client model, the service provider invokes a web service using web service and an interface. The middle tier component is implemented as a web service. Web services are implemented using Java API for XML-based RPC (JAX-RPC). Web component communicates with web service using Simple Object Access Protocol (SOAP) messages. The web service implementation part accepts the request from the web component. It gets the instance of the corresponding delegate object and watches the flag attribute using getInstance() method and isUpdate() method. If the flag value is ‘true’, then it retrieves the newly updated information using get method() in delegate object class. Once the data are retrieved the flag is reset back to ‘false’ using isUpdate() method. The retrieved information (response content) is transferred to the handler for formatting. The formatting is based on the client device

123

Arab J Sci Eng

Fig. 6 Performance of RTT–thick client model

because the client may be a web browser or a mobile device. The formatted response is transferred to the client.

6 Performance Analysis Round trip time (RTT) is used as a performance metric to evaluate the implemented distributed e-business and m-business system. The major factor that influences the performance of the delegate object model is RTT when RTT measures the time needed from the point when the client initiates a request to the point to the client receives the response. 6.1 Experimental Configuration in Thick Client Model Two testing applications are developed to analyze the performance of e-business system. These two tests are: Test A Performance analysis of thick client model without delegate object. Test B Performance analysis of thick client model with delegate object. In Test A, client requests are processed by web component. The web component in turn communicates with database and retrieves the updated value and returns to the client. The new data or updated data is to be retrieved each time so the web component sends a new request to database. The web component or the client is unaware of the changes happened in the database. Therefore, this model uses a polling pattern to place a request to the database at frequent time intervals. The RTT is measured for all client requests. In Test B, the performance is evaluated for thick client architecture using a delegate object. The delegate object and handling functions are deployed in web server. Whenever the client request is initiated, the corresponding delegate object

123

Table 1 Average round trip time in milli seconds for thick client model Distributed model

Average RTT in milli seconds

Distributed model with delegate object

19.43182

Distributed model without delegate object

36.59091

is accepted and it processes the request by forwarding the response to the client. The RTT is measured for all client requests. In both models, the initial RTT time is higher as the web component establishes a connection with database. The further queries are implemented asynchronously thereby reducing the RTT value. In the above two cases, the RTT is measured in terms of milli seconds for a specific e-business and m-business applications and plotted as a graph in Fig. 6. The average RTT is evaluated in terms of milli seconds which is shown in Table 1. By comparing the RTT computed for both the models, it is determined that using delegate object model’s average RTT time is lesser than the model without using delegate object. 6.2 Experimental Configuration of Thin Client Model Two testing applications are developed to analyze the performance of delegate object in m-business application system. These two tests are: Test A: Performance analysis of thin client (mobile client) model without delegate object. Test B: Performance analysis of thin client model with delegate object In Test A, client request is processed by data retrieval web component. The data retrieval web component invokes a related web service. The web service communicates with

Arab J Sci Eng

Fig. 7 Performance analysis using RTT–thin client model

database and retrieves the updated value and returns to the client. Each time a new data or updated data is to be retrieved so the web component has to send a new request to the database. In this case, the web component is unaware of the changes made in the database. Therefore, this model uses a polling pattern to place a request to the database at frequent time intervals. The RTT is measured for all the client requests. In Test B, the performance is evaluated for thin client architecture using a delegate object. The web component forwards the request to middle tier. The middle tier or the application layer contains a delegate object and a web service to manage the delegate object. A delegate object is created for each business need and a separate web service is implemented for the logic of business function. To process the request, the data retrieval component invokes corresponding web service. The web service gets the instance of the appropriate delegate object that is associated with the requested service. The updated information from the delegate object is retrieved by the web service. The web service also manages the data held by the delegate object. The RTT measured in milli seconds for both Test A and Test B. The values are plotted as a graph which is shown in Fig. 7. The average RTT is evaluated in milli seconds which is shown in Table 2. By comparing the RTT computed for both the models it is determined that using delegate object

Table 2 Average round trip time in milli seconds for thin client model Distributed model

Average RTT in milli seconds

Distributed model with delegate object

25.97727

Distributed model without delegate object

47.65909

model’s average RTT time is less than the model without using delegate object. 6.3 Results and Findings The major factor that analyze the performance of the delegate object model is RTT. The average RTT of thick client and thin client model is analyzed. It is determined that using delegate object model’s average RTT time is less compared to the model without using delegate object. The proposed delegate object model is considered as one of the best possible alternatives for e-business and m- business environment since it follows asynchronous communication patterns.

7 Conclusion and Future Work In this paper, we introduced the distributed delegate object model to enhance the information retrieval in e-business and m-business applications. The delegate object model has an effect on the performance of m-business transaction by reducing the network overhead for huge number of transaction requests. This is tested on thick client and thin client architecture, and their performance evaluation is carried out with respect to RTT between the request and response. In both cases, the choice of delegate object is made. The results and findings depict that in either of the models using delegate object provides a better performance compared in terms of RTT. The web services also ensure the location transparency of the delegate object. The developed distributed models can be tested with large scale e-business and m-business environment in real time for portability across different service providers and heterogeneous network scenario. In future, the proposed work can be extended in heterogeneous distributed mobile environment.

123

Arab J Sci Eng

References 1. Ceglar, A.; Calder, P.: A new approach to collaborative frameworks using shared objects. In: Proceedings of the 24th Australasian Computer Science Conference, 2001, ACM International Conference, Vol. 11, No. 10, pp. 3–10 (2001) 2. Lopes, D.; Hammoudi, S.; Abdelouahab, Z.: ESOW: parallel/distributed programming on the web. IEEE Int. Workshop Database Expert Syst. Appl. 9(4), 291–312 (1996) 3. Green, M.L.; Miller, S.D.: Multitier portal, architecture for thin- and thick-client neutron scattering experiment support. Int. Workshop Grid Comput. Environ. (2007) 4. Janakiram, D.; Mohamed, M.A.M.; Vijay Srinivas, A.; Chakraborty, M.: Surrogate object model: paradigm for distributed mobile system. In: ACM International Conference on Information Systems Technology and its Applications, pp. 124–138 (2005)

123

5. Kang, H.K.; Li, K.J.; Kim, M.S.: A framework for dynamic updates of map data in mobile devices. Int. J. Web Eng. Technol. 3(2), 176– 195 (2007) 6. Sujatha, S.; Krishnan, A.; Ramachandran, V.: An enhanced and secure messaging architecture for a distributed e-business environment. Int. J. Electron. Bus. 7(3), 287–300 (2009) 7. Shenbagavadivu, N.; Usha Savithri, S.: Enhanced information security in distributed mobile system based on delegate object model. In: Elsevier Procedia Engineering of International Conference on Communication Technology and System Design 2011, pp. 774–781 (2012)