2012 International Conference on Innovations in Information Technology (IIT)
The application of service-orientation principles within service-oriented software engineering methods: a survey and comparison framework Bashar Alani Department of Computer Science Sultan QaboosUniversity Muscat, Oman
[email protected]
Youcef Baghdadi Department of Computer Science Sultan QaboosUniversity Muscat, Oman
[email protected] SOSE requires services to be designed with respect to SO principles since these principles provide guidance during service derivation process and assurance that the resulting services will feature the corresponding service characteristics [3]. In other words, the identification, development of services in compliance with SO principles is crucial to ensure services reusability and flexibility so that it can be part of different solutions in the context of SOA.
Abstract— Service-oriented software engineering (SOSE) is a software engineering approach for building service-oriented solutions by utilizing service-oriented computing paradigm constructs and concepts. Different methods exist to develop service-oriented software. However, no standardized set of service-oriented principles has been defined yet. This paper surveys current principles and provides a comparison framework to identify which are most considered by different SOSE methods at various stages of solution life cycle.
Both academic and industrial communities have developed many methods. However due to the lack of common understanding of what constitutes a service [4], the methods vary significantly from one another. One of the key differences concerning the compliance to SO principles is validating created services against different subsets of SO principles due to the lack of a standardized set of SO principles. Another difference is the development phase (i.e. identification, design, etc.) at which certain principle is considered.
Keywords: service-oriented software engineering; Serviceorientation principles; Survey, Comparison Framework
I.
INTRODUCTION
Service-orientation (SO) is a new paradigm for the design of enterprise architectures, which spreads substantially in the last couple of years. SO is comprised of a specific set of principles [5].
Different researchers have proposed several SO principles. Some principles fall under different names due to lack of standardization; we try in this paper to provide taxonomy of these principles. In addition, a comparison framework is provided to show the extent to which SO principles are considered among various methods and at which phase. In addition, we compare the lifecycle coverage of these methods.
SOSE methods often provide guidance on multiple development activities; SOSE has two main phases: the first phase is service development for reuse, and the second phase is engineering service-oriented solutions by reusing services as building blocks [11] with respect to Service-Oriented Architecture (SOA). Service-Oriented Architecture (SOA) [1] is an architectural style that defines the way services used as fundamental components to form a service-oriented solution. In general, SOSE method addresses the development of services in terms of two tasks [11]:
The rest of this paper is organized as follows: Section 2 describes the selection of the comparison criteria including: taxonomy of developed services based on their specified functionality, taxonomy of SO principles and the evaluation of tradeoff among them, the lifecycle coverage of SOSE methods as well as SOA delivery strategy. In addition, the SOSE methods selected for comparison are overviewed. Section 3 presents the comparison framework and the evaluation of the selected SOSE methods. Section 4 presents some related work in comparing SOSE methods. Finally, a conclusion section introduces further development is provided.
• Service identification: is concerned with identifying candidate services that are logically coherent, independent, and reusable • Service realization: is concerned with defining service contracts as well as service implementation, testing, and deployment. The created services can then be composed to provide serviceoriented solutions. In this paper, we consider the first phase of SOSE, since SO principles are mainly concerned with service development.
978-1-4673-1101-4/12/$31.00 ©2012 IEEE
294
II.
•
SELECTION OF COMPARISON CRITERIA AND SAMPLE METHODS
First, in this section, we present a set of comparison criteria and sample approaches to be compared: A. Comparison Criteria The criteria we selected are: •
Identified services: Services constitute the building blocks of service-oriented solutions; however, what constitutes a service varies between different SOSE methods. Several researchers attempted to provide classification of services [1, 4, 10, 17]. According to Kohlborn two main categories of services can be explicitly identified and realized within the context of SOA these are i) software services: which represent encapsulated business logic and services that encapsulate application logic and ii) business services: represent high level business functional units (like departments and teams). In this paper, we consider software services since business services are not considered as an outcome of service development tasks within SOSE methods. In general software services can be defined by their specified functionality, these include:
SOA delivery strategy: Three common strategies in delivering SOA are possible, depending on the amount of front-end analysis of the business domain and the treatment of existing legacy systems [1]. The top-down strategy is closely tied to an organizations’ existing business logic, from which required services are identified and implemented using web services or other technologies. The bottom-up strategy is the opposite in that it focuses on existing legacy systems, and services are identified and developed on an as-needed basis. The meet-in-the middle (agile) strategy incorporates serviceoriented design principles into business analysis environments while integrating services technologies into technical environments [1]. In our analysis we use [T] to denote top down strategy and [B] for bottom up strategy and [M] for meet in the middle.
• Lifecycle coverage: This criterion has been used by Kohlborn et. al. [4] to show the extent to which service lifecycle activities are described within the context of SOSE method. In our analysis, a scale [0, +, ++] with the following semantics: 0 stands for methods that focus on service identification and analysis only, while + represents methods with a service analysis and design focus, and ++ finally symbols a service-oriented software engineering methodology that include an analysis phases as well as other development phases such as implementation, testing, etc. • Service Orientation Principles: Although Service orientation principles focus more on service realization, a subset of these principles could be applied while performing service analysis phase, this enables the detection of analysis flaws whose revision may result in a more qualified service candidates. In our analysis, we use a scale [0, +, ++] with the following semantics: 0 stands for a service orientation principle which has not been considered neither explicitly nor implicitly, whereas + represents a service orientation principle that is implicitly described by the SOSE method identification approach, and ++ for a principle that is explicitly described. Additional scale [I, D, R] is used as well to indicate the phase at which the SO is considered. The symbol [I] stands for service identification and analysis phase, whereas the symbol [D] stands for service design phase, and [R] for service realization. The following combinations for a SO principle are considered {{I0, I+, I++}, {D0, D+, D++}, {R0, R+, R++}} where a service can either be implicitly, explicitly or not considered at a certain phase. In addition the symbol {-} for a principle that is out of the scope of the service identification method lifecycle. We classify the SO into following categories:
o Infrastructure layer: is the service-oriented abstraction of an organization’s supporting distributed computing infrastructure: Communication services (CS): expose message transfer capabilities such as message-routing. Utility services (US): expose auxiliary support to other services such as service-discovery, diagnosis and management. Meta-services [20] are considered type of utility services. o Capability layer: is the service-oriented abstraction of an organization’s business logic and resources: Task/Activity services (TS): expose action centric business logic elements. Process services (PS): compose and orchestrate other application layer services to implement business process. Data/Entity services (DS): A service that represents CRUD operations on data/business centric entities/data. Utility services (AS): expose the functionality of an application (including migrated, reengineered legacy systems, some COTS). Hybrid services (HS): Services that contain both application and business logic functionalities (including wrapped legacy systems, and some COTS).
o Principles that can be applied during analysis phase and may also be used at subsequent phases, these include:
External services (ES): a service offered by an external party.
Service autonomy (P1): Autonomy refers to the ability of a service to control underlying runtime
295
[7]. Services identified should have granularity level relevant to the consumer [CBD]. At analysis phase some types of services are preferred to contain functionality as large as possible (e.g. business process services), While others can be determined to contain as small functionality as possible (e.g Data services which include entity services).
execution environment minimizing the unpredictable external influences [1]. Service autonomy is a primary consideration when deciding how set an explicit boundary for an application logic to be divided into services and which operations should be grouped together within a service context to avoid redundancy [3]. Two types of autonomy can be considered [1]: i) pure autonomy where the underlying logic is under complete control and ownership of the service and ii) service-level autonomy: service boundaries are distinct from each other, but the service may share underlying resources.
Service entity convergence (P7): the extent to which a service focuses on processing specific business entities [12]. By considering business entity in addition to activity flows during analysis, it is possible to avoid redundant operations in different services thus, increased optimization.
Service reusability (P2): Reusability means creating the service useful for more than one single purpose, thus identifying service beyond the immediate requirements [7]. Applying this principle at analysis phase increase the possibility of being able to accommodate future requirements with less development effort. When designing for potential reuse the service can be part of multiple complex services.
o Principles that can be applied during design phase and may also be used at subsequent phases, these include: Service state management and state design (P8): Services manage their state information and try to minimize consumption of their resource by deferring the management of state information when required [1], depending on the execution context of the service and the number of consumers at any given time. The longer they hold state information the longer the service is unavailable to other services. A service design may consider different levels of statelessness, depending on the frequency of state deferral and the quantity of state data being deferred [3]. These levels are usually specific to each service capability, which can be determined at design phase.
Standardized definition of service contract (P3): According to Erl “service contract establishes the terms of engagement, providing technical constraints and requirements as well as any semantic information the service owner wishes to make public”. Service contracts comply with the standardized definitions of the contract content types and represent mutual agreements between service provider and service consumers. This principle can be started at analysis phase to identify services and the initial specification of their operations and at later phases of development, the operations can be designed and detailed according to specific business requirements.
Service Discoverability (P9): refers to the design of a service so that it becomes as discoverable as possible, regardless of whether a discoverability product or extension actually exists in its surrounding implementation environment [3]. Service discoverability supports avoiding unintentional creation of redundant services/logic at design phase.
Service cohesion (P4): Service cohesion refers to the degree of the strength of functional relevance of activities carried out by a service to realize a business process [7]. When applied during analysis the operations within a service should be grouped in relation to certain task determined by the business requirements.
Service normalization (P10): Services are decomposed and/or consolidated to a level of normal form to minimize redundancy [18]. Services can be de-normalized for specific purposes, such as performance optimization, access, and aggregation.
Service coupling (P5): Service coupling indicates the extent to which a service is interrelated with other services, in other words it refers to the degree of interdependence between two services [7]. It is important that services in the SOA solution maintain a relationship that minimizes dependencies. Coupling between services [3] can initially be determined at analysis phase and detailed at later development steps.
o Principles that can be fully applied during service realization phase and may also be used at subsequent phases (for instance testing, maintenance), this principle can be realized by implementing services using web services technology, these include: Service abstraction (P11): the information published in a service contract is limited to what is required to utilize the service effectively [1].
Service granularity (P6): refers to the scope of functionality that individual services implement
296
Processing details are hidden from and irrelevant to all service requestor.
•
The service oriented analysis and design method documented in Thomas Erl’s book [1] considers explicitly eight SO principles applied at various stages of development two at service identification phase namely service autonomy, reusability. In addition, three SO principles at service design phase the rest are natively supported when implementing services with web service technologies. In addition the trade-offs between the contradicting principles are also considered.
•
IBM Service Oriented Analysis and Design (SOAD) [1] is a method based on modeling disciplines such as objectoriented analysis and design (OOAD), enterprise architecture (EA) frameworks, and BPM. Service granularity is considered at service identification phase in addition to some service identification design considerations such as domain composition, direct and indirect business compositions and service categorization and aggregation.
•
Business-driven service modeling approach [8] applied in finance domain, description of certain SO principles such service loose coupling is provided without explicitly showing how to consider them during service development.
•
Zhang et al. [13] propose a reengineering approach to construct web services from legacy code. The approach covers service development aspect of SOSE method. SO principles are considered implicitly during the process provided.
•
Klose et al. [9] provide a SOSE method which covers service identification phase of SOSE lifecycle. SO principles names are derived from the stages they are applied in the context of a framework. We relate them to four of the earlier described SO principles namely Service autonomy, loose coupling, granularity, standardization. The method also considers tradeoffs between these principle and their effect developed services performance.
•
Kim et al. [14] provide a SOSE method which utilizes use cases to define and identify services. SO principles are considered implicitly during this phase of SOSE. Another method [15] provided by the same authors based on formal methods cover service identification phase of SOSE service development describe SO principles implicitly as well.
Service composability (P12): Services are effective composition participants as well as effective composition containers, regardless of the size and complexity of the composition [3]. This is a core principle of SOA. Service standardization (interoperability) (P13): is the ability of software on different systems to communicate by sharing data and functionality [1]. Service endpoints are vendor neutral. Service location transparency (P14): Location transparency is an ability of a SOA infrastructure that enables service consumers and service providers to operate independently of their locations [19]. Since the discovery of the location takes place at run-time, a service consumer can consume a service without knowing where the physical location of the provider. •
Evaluation of tradeoffs among SO principles: Service identification and development complexity not only comes from multiple features of services we need to consider, but also a tradeoff that needs to be achieved since the features are mutually exclusive[12]. SO principles affect each other when more activities are partitioned to a service. For instance, it is possible for the service to define a coarser interface that hides interaction details but if it too coarse, it may affect reusability [16]. In our analysis we give ++ for an approach that specifically considers tradeoffs between SO principles, + for implicitly considering them, and 0 for not considering them at all.
B.
Sample methods The aim of this work is to evaluate the extent to what SO principles are applied at service development phases within the context of a SOSE method or in the context of a service identification method rather than gaining insight into the state of the art. To support our aim, we selected a collection of prominent SOSE methods to compare based on the criteria presented in Section 2. This representative sample includes academic work [7], as well as approaches developed by the largest providers of packaged business applications such as IBM [6]. We ensured that the types of services identified to be included due to the variety of inputs [10] to identification phase within SOSE requirement. Another requirement that the sample included different SOA delivery strategies including top-down (T), bottom-up (B) approaches and meet in the middle (M). The following is brief description of methods chosen for comparison: •
III.
COMPARISON FRAMEWORK
Table 1 provides a comparison of selected approaches based on the selected criteria. Several approaches provide an implicit explanation of how to achieve these characteristics, some approaches does not cover the entire set of principles neither implicitly nor explicitly. Nearly all SOSE methods considers the principles of cohesion and coupling during analysis phase but not all of them considered reusability explicitly or implicitly despite that granularity may or may not affect the reusability of a service. Most of SOSE methods choose web services as the best choice for realizing identified services since they naturally conform to the SO principles at the service realization phase. In addition, No SOSE methods describe explicitly how to validate SO principles against all identified service types. Most SOSE method leaves it up to the
The Web services development life-cycle methodology [7] consists of eight phases that cover the entire service development life cycle, ranging from planning to deploying, monitoring and managing Service-Oriented Software. Three SO design principles considered explicitly at service design phase namely service cohesion, service coupling and service granularity.
297
[6]
practitioners to decide how to compromise between different conflicting SO principles.
[7]
IV.
RELATED WORK [8]
Certain approaches address all SOA lifecycle phases [6, 7], while other approaches are concerned specifically with early SOA phases, such as service identification or service design [8, 9]. Moreover, approaches may follow different strategies [10] and criteria when deducting services from process models: it can be a systematic way to represent a meaningful business processes or by formulating general guidelines for identifying services. Most SOSE methods lack description of how SO principles can be used to identify service candidates that can successfully be part of a SOA.
[9]
[10] [11]
SO principles have been identified by several authors under different names due to the lack of standardization.
[12]
Several comparisons [11, 4] have been presented to provide guidelines of which service identification approach is more suitable for a certain contexts and requirements, these comparisons have been incorporated with this paper to present a more consistent view of existing approaches.
[13]
V.
[14]
[15]
CONCLUSION AND FUTURE WORK
Most approaches incorporate a set of service orientation principles, during service identification and analysis. However a smaller percentage of them explicitly describe how to achieve this. No standardized set of SO principles has been agreed upon. Some service orientation principles can conflict with each other, it up to the context and the business requirement to decide which principle is more preferred. Not all service orientation-principles can be fully applied at analysis phase. Some may only partially be applied while other can only be applied at later stages. Since these relationships affect each other, any future developed method requires explicitly describing how service orientation principles can be applied.
[16] [17]
[18]
[19]
[20]
Future work involves investigating the effect of applying design patterns that embody best practices on service development, which conforms to service orientation principles. A methodology focuses on the steps required and the input/output of each step. Principles guide us and enable us to check we are making sound decisions to achieve our design goals. REFERENCES [1] [2]
[3] [4]
[5]
T. Erl, Service-Oriented Architecture: Concepts, Technology & Design, Boston: Prentice Hall International, 2005. K. Klose, R. Knackstedt and D. Beverungen, “Identification of Services - A Stakeholder-based Approach to SOA Development and its Application in the Area of Production Planning”, ECIS'07, pp. 18021814, 2007. T. Erl, SOA: Principles of Service Design. Boston: Prentice Hall International, 2007. T. Kohlborn, A. Korthaus, T. Chan and M. Rosemann, “Identification and Analysis of Business and Software Services; A Consolidated Approach”, In IEEE Transactions on Services Computing, pp. 50-64, 2009. S. Inaganti and G.K. Behara, “Service Identification: BPM and SOA Handshake”, BPTrends, vol. 3, pp. 1-12, 2007.
298
O. Zimmermann, P. Krogdahl, C. Gee, “Elements of service- oriented analysis and design” , IBM developerWorks Web services zone, 2004. M. P. Papazoglou and W. J. Heuvel, “Service-oriented design and development methodology”. , Int. Journal of Web Engineering and. Technology (UWET) 2(4), pp. 412–442, 2006. F. Kohlmann and R. Alt, “Business-driven service modeling – a methodological approach from the finance industry”, Int. Working Conference on Business Process and Services Computing, 2007. K. Klose, R. Knackstedt, and D. Beverungen, “Identification of services - a stakeholderbased approach to SOA development and its application in the area of production planning”. ECIS, University of St. Gallen, pp. 1802–1814, 2007. Q. Gu, and P. Lago, “Service identification methods: a systematic literature review”, ServiceWave, pp. 37-50, 2010. Q. Gu, and P. Lago, “Guiding the selection of software-oriented software engineering methodologies”, Service-Oriented Computing and Applications, Vol. 5, No. 4, pp.2 03-223, 2011. M. Qian, N. Zhou, Y. Zhu, and H. Wang, “Evaluating Service Identification with Design Metrics on Business Process Decomposition” IEEE International Conference on Services Computing, 2009. Z. Zhang, R. Liu, and H. Yang, “Service Identification and Packaging in Service Oriented Reengineering”, in Proc. 17th Int’l Conf. Software Eng. and Knowledge Eng. (SEKE ’05), pp. 620-625, 2005. Y. Kim and K.G. Doh, “The service modeling process based on use case refactoring”, Abramowicz, W. (ed.) BIS. LNCS, vol. 4439, pp. 108–120, 2007. Y. Kim and K.G. Doh, “Formal identification of right-grained services for service-oriented modeling”, Vossen, G., Long, D.D.E., Yu, J.X. (eds.)WISE. LNCS, vol. 5802, pp. 261–273, 2009. M. Bell, Service-Oriented Modeling: Service analysis design and architecture, :Wiley, 2008. S. Cohen, “Ontology and Taxonomy of Services in a Service-Oriented Architecture” The Architecture Journal, vol. 11, 2007, pp. 30-35. Microsoft press. T. Shan, “Building a Service-Oriented eBanking Platform” , First IEEE International Conference on Services Computing (SCC'04), pp.237-244, 2004. X. Pan: “A Method to Implement Location Transparency in a Web Service Environment”, InterSymp-2010, Foc. Symp: Advances in Adaptive Planning Capabilities; Baden-Baden, Germany, Aug. 2010. R. Schmidt: “Meta-Services as Third Dimension of Service-Oriented Enterprise Architecture”, Enterprise Distributed Object Computing Conference Workshops (EDOCW), 14th IEEE International pp.157– 164, 2010.
299
