International Conference on Advances in Engineering and Technology, (ICAET-2011), May 27-28, 2011

SERWO: A Novel Design Approach to Build Reusable Services

G. Shanmugasundaram and Dr.V. Prasanna Venketesan
Abstract---Reusability is one of the most prominent service principles that can reduce cost of solution ownership. Designing a service which can be reused in the future requires accurately predicting the future needs. The reusable service has to support the quality of services i.e. the services should possess the quality attributes such as Interoperability, Reliability, Availability, Usability, Security and Performance, Scalability, Extensibility and Adaptability. The objective of this paper is to explore the design level challenging issues in developing the reusable services and propose a Service Workshop (SERWO) Tool which helps in designing the reusable services. The proposed tool is used to transform or change the existing service which does not possess reusability into reusable service. This SERWO Tool would use pattern(s) for developing reusable service. To demonstrate the applicability and usefulness of the SERWO, we perform a case study on Flight Reservation System. Keywords---Reusability, Service Reusability and Reusability Tool, Service Quality, Service Design I. INTRODUCTION services into a reusable one and a case study to evaluate the framework. Section four states the conclusion and future work. II. SERVICE REUSABILITY AND ITS ISSUES

OFTWARE architectures are the foundation for designing, communicating, and constructing complex software systems [3]. A service-oriented architecture (SOA) is a software architectural pattern, in which recurring software architecture reused in a variety of applications, thereby allowing coarse grained software reuse at the architectural level. It is the evolutionary step in helping IT organizations meets demands for faster application development, lower IT costs, and greater adaptability to changing business requirements. An SOA is not just a system built as a set of services. Most definitions of an SOA would agree that an SOA defines application functionality as a set of shared, reusable services [1]. The fundamental reason to take services as reusable components is that services may provide shorter cognitive distances. Cognitive distance is defined by the amount of intellectual effort that must be expended by software developers in order to take a software system from one stage of development to another [2]. In SOA, a service must be described, specified, implemented, registered, published and finally applied. The rest of the paper is organized as follows. Section two discusses about the Service reusability and its issues. Section three elaborates the proposed system for transferring the
G. Shanmugasundaram, Department of Banking Technology, Pondicherry University, Puducherry, India. Email: sundar_gss2004@yahoo.com Dr.V. Prasanna Venketesan, Department of Banking Technology, Pondicherry University, Puducherry, India. Email: prasanna_v@yahoo.com

Software reuse has been the subject of extensive research in the context of object-oriented programming and component technology based development. The primary mechanism for achieving reuse in object-oriented programming is (class) inheritance [4]. Inheritance creates strong dependencies (i.e. coupling) among application objects and for that reason is generally not used in distributed environments. The mechanism for maximizing reuse of service components in the context of highly distributed (domain-wide) service-oriented applications has not been fully tacit at present. We define service reuse as the ability to participate in multiple service assemblies (compositions). Given this perspective, services must be composable to achieve good levels of reuse. For example, a well-designed credit score service can be reused in a large number of loan and insurance applications, and therefore is highly reusable. A. Issues in developing reusable Services The following subsections address various issues in transforming the ordinary service into reusable one. 1) Issues on Services with Standard Interface - The interface created in existing services does not follow any standards and do not have high-level interfaces. Services which can provide high-level interfaces are more reusable because they provide an interface with high level of granularity masks specialized or implemented for specific methods. 2) Problem in Process Separation - Services have the combination of the both process logic and business logic. There is no separation between the process and business logics. The existing service without the process separation leads to many difficulties that can affect service performance also. Separating out the process logic from the business logic means that business services should not have embedded process logic that ties it to a specific process. Process separation is an architectural strategy for creating reusable services. 3) Difficulties in Stateful Service - Services have to define whether its a stateful or stateless one. Stateful services require more memory to store the temporary data about the requests resulting in performance degradation, and difficulty in processing requests. However stateful services are still permitted in SOAs [8].

ISBN 978-1-4507-6433-9 2011 Published by the Coimbatore Institute of Information Technology

International Conference on Advances in Engineering and Technology, (ICAET-2011), May 27-28, 2011 A stateless service is where temporary data about previous requests is not maintained on the server. Instead the temporary data is stored on the clients resources and it is passed back to the server in every message. This means that the same server does not have to process successive requests from the same client to ensure correct operation. This improves scalability and load balancing because clients can be independently routed to, at each message. Stateless service increase stability and subsequently reusability. 4) Improper Message Exchange Patterns - The existing services cannot handle the multiple message exchange patterns. Without these feature the business services cant be used for wider range of processing situations. The message exchange patterns are not clearly described in the services interface description. Multiple message exchange patterns support a variety of invocations and can be more easily reused. 5) Services without variability support - A service which does not provide variability in design will not support the future functionality changes. Its necessary to update the services with new feature to meet the changing market/business needs. Designing for variability is a critical issue in service design. Different techniques for modelling variability can be applied, such as software product line approaches and variation point models [9], [5], [10]. Single design supporting future functionality or multiple applications paves way for developing reusability in services. III. PROPOSED SYSTEM FOR REUSABLE SERVICES Message Pattern Miner - It maintains the repository for the messaging pattern that can be used for routing the messages. It helps in an efficient way to exchange the message which in turn improves service reusability Variability Advisor - The variability advisor would make the services to withstand the changing needs of the market. In the proposed framework the phases Interface Analyzer and State Resolver are explained in detail with implemented results. A. Process involved in Various Phases 1. Interface Analyzer - The interface analyzer checks the services (the given input) for standard interface which would achieve reusability. If the Interface is not a well defined one then the interface analyzer would generate a solution based on the rules to standardize it thereby maximize the cohesion and minimize the coupling. 2. State Resolver - The state resolver will check the services for defining the states i.e. stateless or stateful. It can maintain state diagram for achieving the reusability. If the service is not a stateless the state resolver would change the service to be stateless one. The state resolver is used to resolve the states i.e. Stateful or stateless. It is pre-eminent that a service maintains the state in shared database, rather than in a server object achieve reusability. This provides access to databases for retrieving the states and offers service to customer. B. Flight Reservation System A Case Study Flight reservation system has been considered as a case study for detailed implementation of reusable services, in which flight booking service without the reusable nature is given as input to the system. It is assumed that a flight booking is for a single flight segment, i.e. a direct flight between the origin and destination location, and that only one airline is involved [11]. Figure 2 illustrates function hierarchy that results from progressive function decomposition and produces elementary leaf functions (shaded on the diagram). Table I contains the corresponding descriptions of elementary business functions.

To overcome the above said issues in designing reusable services, we propose a tool which can be used to build the reusable services. The proposed framework is a SERvice WOrkshop (SERWO) which analyses the issues and provides solution by building the reusable services.

Fig. 1 SERWO- A Framework for Reusable Service

The framework consists the five different blocks each having its own functionality. They are Interface Analyser - It checks the input (services) for high level and well defined interface to achieve reusability and provides the solution based on the rules. Process Separator- It separates business and process logics in a service. State Resolver - Given service is checked for defining the states i.e. stateless or stateful. If the service is not a stateless the state resolver will change the service to be stateless one.

Fig. 2 Flight Booking Business Function Hierarchies

ISBN 978-1-4507-6433-9 2011 Published by the Coimbatore Institute of Information Technology

International Conference on Advances in Engineering and Technology, (ICAET-2011), May 27-28, 2011
TABLE I FLIGHT BOOKING ELEMENTARY BUSINESS FUNCTIONS Business Function Flight (Availability) Enquiry Description The travel agent requests a list of flights for a pair of origin and destination cities on a given departure date. The airline responds with a collection of flights (i.e. zero or more flights). The response includes flight number, departure airport, departure time, arrival date, arrival time, and arrival airport for each flight. The travel agent requests seat availability for a particular flight specifying the flight number, departure airport, arrival airport, departure date, and cabin type (e.g. economy). The airline responds with the quantity of seats available. The travel agent requests pricing information specifying the flight number, departure airport, arrival airport, departure date, and cabin type. The airline responds with the pricing information that includes the base fare and base fare code. The travel agents request a traveler seating preference (e.g. an aisle seat). The airline responds with a seat number. The travel agent requests a traveler meal preference (e.g. Vegetarian). The airline responds with special meal confirmation.

service interface for its high level functionality. For checking two general rules have been framed for the above case: Both input and output parameters should be minimal Output parameter would be functionally dependent on input parameter set. Based on the rules the interface would be refined for flight booking service. Rules for identifying the Dependency between operations
FD1: OriginLocation, DestinationLocation, DepartureDate Flight Number FD2: Flight Number DepartureAirport, DepartureTime, ArrivalAirport, Arrival Time FD3: Flight Number, DepartureDate ArrivalDate FD4: FlightNumber, DepartureDate, CabinTypeQuantity FD5: FlightNumber, DepartureDate, CabinType FareBasisCode, BaseFare

Seat (Availability) Enquiry

Price Enquiry

Seating Request

Special Meal Request

TABLE III CANDIDATE BOOKING FOR FLIGHT BOOKING SERVICE Service Operations FlightEnquiry Method type: state-view Input Parameters Output Parameters FlightNumber DepartureAirport DepartureTime ArrivalAirport ArrivalDate ArrivalTime Quantity, FareBasisCode BaseFare

The above five rules are framed for identifying the dependency between the operations. After identification of the dependency the business functions are split into elementary functions. The output of the interface analyzer is shown in the table III.
TABLE III
OUTPUT OF I NTERFACE

ANALYZER Output Parameters FlightNumber

Service Operations FlightEnquiry

Input Parameters OriginLocation DestinationLocation DepartureDate

OriginLocation DestinationLocation DepartureDate

Schedule Enquiry FlightNumber

Seat & Price Enquiry Method type: state-view

FlightNumber DepartureAirport ArrivalAirport DepartureDate CabinType FlightNumber DepartureAirport DepartureDate TravelerName CabinType Booking Reference ID SeatPreference Booking ReferenceID MealPreference

DepartureAirport DepartureTime ArrivalAirport ArrivalTime ArrivalDate

Arrival Enquiry

FlightNumber DepartureDate FlightNumber DepartureDate CabinType FlightNumber DepartureDate CabinType FlightNumber DepartureDate CabinType TravelverName BookingReferenceID SeatPreference BookingReferenceID MealPreference

Book Flight Method type: state-change

Seat Enquiry Booking Reference ID Price Enquiry SeatNumber BookFlight MealType Seating request Meal Request

Qunatity

FareBasisCode BaseFare

Seating Request Method type: state-change Meal Request Method type: state-change

BookingReferenceID

SeatNumber SpecialMealType

The case study has been analysed with help of the two phases (i.e. interface analyzer and state resolver) of SERWO. The Output of the two phases is shown in table III and IV respectively. C. Interface Analyzer Phase The flight booking service has been given as input to the framework. The first phase interface analyzer would check the

D. State Resolver Phase In this phase the state chart are used to describe how the operations can transfer the parameters. By using the state charts the state dependencies as well as independency of the operations are identified. After identifying the stateful

ISBN 978-1-4507-6433-9 2011 Published by the Coimbatore Institute of Information Technology

International Conference on Advances in Engineering and Technology, (ICAET-2011), May 27-28, 2011 operations are changed into stateless operations either by passing the information along with request or using the shared database. The state chart consists of two methods entry and exit. The output of the first operations can be given as input of the next operations. It helps to identify the state dependency between the operations. The output of the state resolver phase is shown in Table IV.
TABLE IV
OUTPUT OF STATE RESOLVER

Service Operations FlightEnquiry

Entry OriginLocation DestinationLocation DepartureDate

Exit FlightNumber

Fig. 4 Reuse graph for State Resolver phase

Our proposed framework provides better percentage of reuse for the case used. IV. CONCLUSION AND FUTURE WORK

Seat Enquiry

FlightNumber

DepartureAirport, DepartureTime ArrivalAirport, ArrivalTime Arrival Date

Price Enquiry Book Flight

Flight Number, Departure Date FlightNumber DepartureDate CabinType FlightNumber DepartureDate CabinType

Quantity FareBasisCode BaseFare

Seating Request

E. Reuse comparison using Graphs After applying framework the services Operations are simplified into more sub operations thereby achieving more reusability. Fig. 3 depicts the reuse graph for the flight reservation service before and after using Interface analyzer on the framework.

A service as a reusable unit is more appropriate for software reuse, because the logic of a service is separated as per the business and process logic. The SOA paradigm has the potential to offer significant benefits to software systems development, maintenance, and reuse. Thus SERWO can be used for building reusable services by addressing the issues related to reusability is shown with help of a case study. Applying proven software design principles will ensure that organizations will achieve higher levels of service reuse and better return on investment in the long term. Future work focuses on implementation of next three phases of the framework. SERWO on complete implementation ensures high reusability. REFERENCES
[1] Sun Solutions and Services for Adopting a Service Oriented Architecture white paper June 2007. [2] Krueger, C. W., Software Reuse, ACM Computing Survey, vol. 24, no. 2, June 1992, pp. 131-183. [3] Software Architectural Reuse Issues in Service-Oriented Architectures Proceedings of the 41st Hawaii International Conference on System sciences 2008. [4] Haibin Zhu Building Reusable Components with Service-Oriented Architectures, Senior Member, IEEE. [5] H. Gomaa and M. Saleh, "Software Product Line Engineering for Web Services and UML," in 3rdACS/IEEE International Conference on Computer Systems and Applications, Cairo, Egypt, 2005. [6] D. v. Thanh and I. Jrstad, "A Service-Oriented Architecture Framework for Mobile Services," in Advanced Industrial Conferenceontelecommunications/Service Assurance with Partial and Intermittent Resources Conference/ELearning on Telecommunications Workshop, Lisbon, Portugal, 2005. [7] M. E. Dunn and J. C. Knight, Automating the Detection of Reusable Parts in Existing Software," in 15thinternational conference on Software ngineering, Baltimore, Maryland, 1993, pp. 381 - 390. [8] D. J. N. Artus, "SOA realization: Service design principles." vol. 2006: IBM Developer Works, 2006. [9] Carnegie-Mellon, the Software Engineering Institute (SEI), "Feature Oriented Domain Analysis." vol.2006. [10] L. Webber and H. Gomaa, "Modeling Variability with Variation Point Model," in 7th International Conference on Software Reuse, Austin, Texas, 2002, pp.109-122. [11] Feuerlicht, G., 2005, Design of Service Interfaces for e-Business Applications using DataNormalization Techniques, Journal of Information Systems and e-Business Management, Springer-Verlag GmbH, 26 July 2005, pages 1-14.

100 90 80

Reuse Percentage

70 60 50 40 30 20 10 0

No. of Service Operations

Fig. 3 Reuse graph for Interface Analyzer phase

After applying framework the independent services operations are more which demonstrates the increase in service reusability. Fig. 4 illustrates the reuse graph for the flight reservation service before and after using State Resolver on the framework. The graph has been obtained using the formula mentioned below. Average reuse = Total Number of independent Service Operations/Number of Service Operations

ISBN 978-1-4507-6433-9 2011 Published by the Coimbatore Institute of Information Technology