A Method for Service Oriented Design - Semantic Scholar

2nd EUROPEAN COMPUTING CONFERENCE (ECC’08) Malta, September 11-13, 2008

A Method for Service Oriented Design SEDIGHEH MOOSAVI Faculty of Graduate Studies Islamic Azad University South of Tehran Branch IRAN

MIR ALI SEYYEDI Faculty of Graduate Studies Islamic Azad University South of Tehran Branch IRAN

NASROLLAH MOGHADAM Dept of Computer Science Tarbiat Modares University Faculty of Engineering IRAN

Abstract : Development methodology based on service has critical role in description, establishment, refining and adaptation (verification) of highly volatile business processes. However, there has not been a suitable and consolidated method for the development of high quality service oriented business applications .This article tries to present a method for service-oriented design. We use techniques and current issues in SOA¹ in consolidated form and propose a method for service oriented design. The focus of this paper is on design process. Key-Words: SOA , Layering , Service Type , Process , Variation , Composition , Granularity. discussed design phase in full and have presented techniques only in some of current issues in SOA . The presented method in this paper begins with review of analysis phase layering and helps collaboration process of services by adding more specialized layers. Then variable needs are analyzed and variable points are identified. These points may change later or new points are defined. Based on different services we are facing in design phases, we map services for separate defined layers. Functional area of services, processing needs of services, combination of services and service orchestration for achieving business process objectives are identified . Process service layer, which is a control layer, is defined by identification of business regulations, exceptions and conditions. Using granularity subject, we review services in previous phase and study methods for each services with consideration given to functional area and production output. We define the need for multi granular methods, if necessary, in order to provide security. In this phase, we design the composite services. Generic model, Collaboration Diagram, and sequence Diagram will be the output of this phase. In final stage, using BPMN - as opposed to UML which is based on object , BPMN has process modeling capabilities - we can perform process modeling and obtain executable code by using tool’s features.

1 Introduction SOA provides a set of principles, theories and techniques for effectively organizing business processes ,information and assets in an enterprise. These processes can be expanded in support of strategic planning and profitability levels needed in a competitive business environment[15]. Many enterprises in their initial application of SOA assumed that they could use existing components as web service and determined that this is practical only by creating wrappers and leaving the underlying component untouched. As a result, installation of a thin SOAP/WSDL/UDDI layer over the existing software application or components that make web services possible was widely used in the software industry. There has not been a suitable procedure for constructing commercial strength enterprise applications[9;16;17] . Although, the nature of components make them suitable for using in web services, but it is not true in most cases. Redesigning and reinstalling the components in the right way for providing web services require new extra efforts . For this purpose, we need a servicebased development methodology . Thomas Erl described different design services and design requirements for any type of service[1]. Dijkman and Dumas presented a super model in design based on services from different points of view[7]. Christian Emig used a process language like BPMN for automatic mapping an model in an execution language[5]. Soo Ho Chang presented a method for modeling variation[6]. Oliver Thomas showed how one could utilize process model for designing and realization of service oriented architecture[10]. Existing methods have not

2 Service Oriented Architecture and Design Principles

1. Service Oriented Architecture ISSN:1790-5109

364

ISBN: 978-960-474-002-4

2nd EUROPEAN COMPUTING CONFERENCE (ECC’08) Malta, September 11-13, 2008

•

A successful implementation of SOA requires paying attention to concepts and implementation strategies that formulate main characteristics and features of SOA . Upon a successful implementation of SOA, the enterprise gain benefit by reducing development time, utilizing flexible and responsive application structure , and allowing dynamic connectivity of application logics between business partners. A complete implementation of SOA is not only related to deployment and orchestration of services but also reflects the possibility of using services towards integration of distinct applications and creation of complex application. The roots of service orientation come from “problem differentiation” taken from software engineering concept [1;3]. Service orientation is introduced as an approach for implementation of problem differentiation. There is no official collection of service orientation principles. There are only a series of principles that are related to service orientation more than others are and we discussed them here : • Services are reusable = service reusability • Services share a formal contract = service contract • Services are loosely coupled = service loose coupling • Services are composable = service Composability

Services are autonomous = service autonomy • Services abstract underlying logic = service abstraction • Services are stateless = service statelessness • Services are discoverable = service discoverability

3 Service Oriented Design Method In this section, using techniques and current issues applicable to principles of service oriented design , we will propose a consolidated method to meet our expectations in support of highly volatile business. The proposed method includes following steps and activities (Figure 1):

3.1 Step 1 - Review of SOA System Layering Considering layering strategy, we select an approach in this step. The selected approach is in support of business process and service orientation objectives. This step includes following activities:

Fig.1: Service Oriented Deign phase activities

2 ISSN:1790-5109

365

ISBN: 978-960-474-002-4

2nd EUROPEAN COMPUTING CONFERENCE (ECC’08) Malta, September 11-13, 2008

Activity 1: A Review of Layering Strategy Layering is based on a number of characteristics and features. For example layering based on responsibility and reusability. It is clear that each layering strategy is suitable if it is related to its own modeling.

logic when application service is responsible for presentation of technology and application logic. Business services are responsible for providing explanations for business logic by using service orientation and lead organization’s business models towards web services area.

Responsibility-based Strategy : For example there are 3 identifiable fields in responsibility-based strategy, namely, presentation logic, business logic, and data access logic. Each layer has components that operate in the field of its responsibility. In this strategy, components held under control of layers and this will affect design model. It also affects deployment model when we need to demonstrate physical distribution of responsibilities.

Orchestration Service Layer : Orchestration service layer entails the highest level of abstraction, which reduces the need for other services for operation management and assurance that provision of service operation follows a given order. Activity 3: Introducing More Specialized Layers Along with already defined general layers, we can mention more specialized layers specific for reducing system complexity as well as increasing system efficiency and security as follows:

Reuse-based Strategy : Reuse-based strategy is applicable in organizations that have reusability objectives. Reusability of components will be obvious and components are grouped in layers based on this characteristic.

Data Layer An important feature of SOA is its ability to access to the enterprise data, which strengthen business processes [8].A separate data layer reduces the architectural complexity required to provide access to enterprise data . It also allows organizations to create and leverage services. Delivery of data layer leads to increased opportunities for reusability and reduces system cost for long-term operation. We achieve loose coupling with definition of data layer. Physical data can be organized without affecting application.

Multi-dimensional Strategy : We benefit from two previously mentioned strategies. We define separate layers based on identification of responsibilities. Business logic is divided into new layers depending on reusability. For this purpose, we need to separate business logic from application logic. Separation of business logic, in general, assists reusability. Output: Strategy Determination

Service Access Layer Common service access layer makes uniform access to all basic functions possible as opposed to projectspecific view. Establishing such a layer is an interesting idea because it provides access to all basic functions for all projects[2]. We also have the possibility to add special values to this layer like support of distributed processing and the capability to hide their complexity from projects. Considering requirements of different projects, we recommend that design and use of access layer should take specific objectives of the project into consideration.

Activity 2: Review of Analysis Phase Layering We review layering for service oriented architecture, in this section. System layers are presented in such a way that business-logic of services fall in a separate layer to achieve system agility. Further more, controlling rules for composition of services act as an independent layer. Existence of each layer will be the cause for abstraction of a section of our method. The following layers have been identified in analysis phase: Application Layer : Application layer creates a base that defines technology-specific functionality and its objective is to provide reusable functions related to data processing in a new or inherited application environment. We can mention utility service and wrapper service as typical examples of application services modeling.

Collaborative Layer Demand for collaborative, efficient, flexible and user-friendly services is received with more urgency in business field. Enterprises should deal dynamically with collaboration and cooperation with participants as well as any form of competition [4]. Taking requirements of collaborative services into consideration, we propose layering for SOA based on these requirements. Collaborative services can be categorized as follows:

Business Service Layer : Business service layer exclusively provides services that contain business

ISSN:1790-5109

366

ISBN: 978-960-474-002-4

2nd EUROPEAN COMPUTING CONFERENCE (ECC’08) Malta, September 11-13, 2008

¾ Shared resources ¾ Personal communications and interactions ¾ Organization management As each user interacts with other users through user interface by collaborative services, service logic should have certain functions including locking mechanism, presentation control, user presence management, organization management, communication means for a successful concurrent multi-user interaction. Considering required functions for creating collaboration and cooperation, and this fact that a service may be a part of an orchestration of other services or be an application containing main components for calling other services, we propose: ¾ Basic interactive functions identified should be transferred to SOA as services. ¾ Place these services in an independent layer called collaborative service layer to be available to all developers . An interactive application can be developed based on these services and other selected services (Figure 2).

for variability modeling and adaptable design for each type of service variability. The outcome is considerable increase in reusability of services. Activity 1: Identification of Different Variations Variation is identified by analysis of service requirements and specially business processes as well as basic services. Using variability information obtained from business processes and basic services, we introduce four types of service variability (Figure 3). Workflow: It is possible that in workflow, some basic services are not requested for some certain users and it is possible that a part of service sequence is performed in a different way for other users. Composition: In this case, based on needs of user, different service interfaces can be combined from implementation point of view and we call this variation in composition. Interface: In this case, a requested interface by a business process is a variant point and the interface provided by the candidate service is alterations of a variable point. Logic: A service component contains actions in support of basic services’ functional. A service component shall make different logics related to requested services possible. This is called variation in logic.

Fig.2 : Definition of Collaborative Layer Step Output: Layer Model

3.2 Step 2 - Variation Analysis Services are not created only for already defined users, but because of many un-known users, services are obliged to adapt to many users and concepts. Considering existing investigations and experiences, it is believed that product-line engineering (PLE) has high potential for variability modeling of services and developing high adaptable service components[6] .In this section, we introduced four types of variations that occur in services. The main objective is to provide a method

ISSN:1790-5109

Fig.3 : Types of Variant points Activity 2: Variation Models

367

ISBN: 978-960-474-002-4

2nd EUROPEAN COMPUTING CONFERENCE (ECC’08) Malta, September 11-13, 2008

produce variation. For example activities and parameters variation , transfer variation, error handling variation, and endpoint variation. Output: Variable points grouping in services and parameterization of services.

Variability modeling is an essential prerequisite for establishing adaptable services. Variations should be identified in order to define adaptable services. Services variation can be categorized in two groups, namely business processes and interfaces. KobrA is a solution for SOE based on component[12;13]. This solution uses UML stereotypes for analysis and design model in order to define variation. COVAMOF is also a solution in support of modeling for relationships and dependencies[14]. There are different representations of variation such as decision model, feature model, UML stereotypes, etc. Output: Selection of Variation Model

3.3 Step3 Identification

Phase

Services

Grouping of different services is the prerequisite for having an effective design. There are four main services introduced here along which we introduce other required services as well [2]. Some services can be defined in certain system conditions such as existence of legacy system.

Activity 3: Variability modeling and Grouping We need to move from business process models towards feature models. These feature models are widely used in software product line architecture . Related features are put into feature groups. Members select their desired features from these feature groups [18;19]. Services are used in several systems based on variable functions. Services need variation analyze in order to be used in SPL. We model variant requirements, using definition of variable points in activity diagram. For this purpose, we use the branches and guards constructs along with UML stereotypes that indicate the location of variability (variation points) and the variant behavior to be inserted at those variation points. Output: Feature Model and Variant Points in Activity Diagram

Activity 1: Determination of Services Based on service model, we can determine the final services for design phase by applying SOA design principles and complete coding activities of services in layering model described in step one. The outcome will be the final services from the design phase along with the determination of composite services and service orchestration : Basic Service: These are basic services for SOA. They maintain no conversational session state and are considered stateless. They are divided into datacentric or logic-centric services. Intermediary Service: These services are stateless and act as a bridge for technological incompatibility and/or design gaps in architecture. Intermediary services are grouped in four categories: technology gateways, adapters, façades, and functionalityadding services .

Activity 4: Variant Points Mapping We first use analysis method described for a single system. Then, identified variant points are analyzed in business process models. We first have to decide if these variant points are modeled as part of one service or as part of several services. If variant points are small, candidate service is modeled by applying variant points in service activities and parameters. However, if variant points are plenty in business process model, a solution with higher management capability is to logically group related features in separate services. When all variant points are grouped in one service, the solution is service parameterization. Parameterization can be applied to service activities, parameters and messages. When we group related featured in separate services, we can obtain variation by discovering and binding to different services. These services are based on features they provide us. In parameter-based design, we can apply parameterization to service aspects in order to

ISSN:1790-5109

Design

Process-centric Service: Process based services encapsulate business processes knowledge of an organization. For this purpose, process logic should carefully be separated from business logic and dialog control logic. Process based services are suitable tools for this accomplishment. This option is a prerequisite for an efficient business processes management. Public Enterprise Services: These services are offered by an enterprise to each user or business partner. Because users of public enterprise services are usually unknown and there is a weak relationship between user and provider, therefore, public enterprise services have certain requirements including security and decoupling of the business partners. Output: Service Model

368

ISBN: 978-960-474-002-4

2nd EUROPEAN COMPUTING CONFERENCE (ECC’08) Malta, September 11-13, 2008

Services are not bound to be either coarse or fine grained; they can be coarse, fine or multi grained. It is also possible to create fine-grained façade services that have access to coarse-grained services. It is better to create fine grained basic services because developers have more flexibility during deployment [9;11] .

Activity 2: Position of Control Services Controlling services such as access service, interaction service, partner service and information service are introduced based on their operation type, in addition to the above categories. The need for definition of controlling services is determined, when we review system requirements. These services operate in support of non-functional system requirements and QOS.

Activity 2: Multi-granular Methods of Services Granularity at service method level is as important as granularity at service level. For example, there are different ways to display information about an account :

Step Output: General composition diagram is formed and by using identified dependencies in activity diagram, services are mapped in layering model and position of services are determined from processing needs point of view.

¾ A method for account number and another method for sending address information. ¾ A method that returns both account and address information. ¾ A method that returns requested items (Figure 4). Passing parameter to direct service in the direction of what information to be returned .This solution is more complicated for developers to implement and users will see an interface, which is more difficult to understand and use. To solve this problem, a proxy service can package the complexities in a form of a wrapper and provide a simpler interface to users. The advantage of this technique is that the service supports any granularity such that providing a specific granularity level to users is based on their degree of understanding.

3.4 Step 4 - Review Granularity Granularity can be used in two ways: First, it is applied to the scope of the domain the entire service implements. Second, it is applied to the scope of the domain that each method within the interface implements [11]. A suitable granularity level for service and its methods is relatively large grained. This step includes the following activities: Activity 1: Granularity Technique of Services and Multi-granularity Since services will be used in different manners and this is not predictable at the time of design, it is not necessary to make absolute decision about service granularity.

Figure 4: Method that Returns Requested Items

ISSN:1790-5109

369

ISBN: 978-960-474-002-4

2nd EUROPEAN COMPUTING CONFERENCE (ECC’08) Malta, September 11-13, 2008

Service capability that supports multi-granular methods and returns suitable data is effective in reduction of network traffic. Extra network traffic is for receiving data because of existing excessive unnecessary data and/or too many requests. Granularity is a complicated issue at the time of service design and it is important to understand different options and implement the most appropriate interface.

Business Process Design Activities Based on Service: Interactions: We first define message exchange requirements for process service based on a logical view of workflow logic system created during service modeling step as well as process service candidate and existing service designs. This information is utilized in forming a base for designing all possible interaction scenarios between process and partner services.

Step Output: Collaboration diagram is formed at the conclusion of this step. We use sequence diagram for composite services.

Process Service Design: We proceed to define a service after understanding the requirements for message exchange. This allows a more simple design and generation of the executable BPEL process respectively. Step Output: Process Modeling

3.5 Step 5 - Process Modeling A software application has strong relationships with the business processes that support it. We propose that business processes to be modeled by a tool that automatically maps in an execution language to be executed by a process engine. BPMN is used as a process programming language and BPMN description can be mapped in business process execution languages [1; 5 ;10]. In the design phase, the business logic is mapped to components (e.g., a business process control and a number of use case controls) of the application architecture .Manual mapping of business logic into components shall result major shortcomings such as:

Design Output: We will have a collection of models at the end of design process . The following diagram shows the design output models and their relationships (figure 5).

4 Review of Proposed Method with Design Principles and Service Orientation The proposed method has used isolation of service layers and service categorization for establishing centralized control. It is also based on design principles and adapting long-term strategies in order to help in fulfilling business processes objectives and to support highly volatile processes .Utilizing this method can improve operation speed and prevent duplications and repetitions (Table 1) .

Inefficiency: Many aspects of the model described in analysis step can directly be transferred automatically into the architecture. Inconsistency: A change in model at analysis or design level can result in incompatibility if the change is not manually propagated. Inflexibility: The system is not designed to react flexibly to process changes. Review Criteria

Proposed Method

Isolation of Service Layers

Analysis Service Layers are supported and more specialized layers are proposed

Service Oriented Principles

Is directly Supported

Business Goal Meeting

Business Goal Meeting

Service Taxonomy

Adapting Service Taxonomy

Prediction of Long-term Strategies

√

Prediction of Short-term √ Applicable Strategies Prediction of Variations √ Table 1: Criteria and Proposed Method

ISSN:1790-5109

370

ISBN: 978-960-474-002-4

2nd EUROPEAN COMPUTING CONFERENCE (ECC’08) Malta, September 11-13, 2008

Fig. 5 : Models and Relationships

5 Conclusion

References : [1] Erl , T. : Service-Oriented Architecture: Concepts, Technology, and Design. August 04, 2005. [2] Krafzig, D., Banke, K. and Slama, D.: Enterprise SOA: Service-Oriented Architecture Best Practices. Prentice Hall PTR, 2004. [3] Endrei M., et al. Patterns: Service-oriented Architecture and Web Services, Redbook, SG246303- 00, April 2004 . [4] Jørstad, I. , Dustdar, S., Do, V.T. : A ServiceOriented Architecture Framework for Collaborative Services. Enabling Technologies: Infrastructure for Collaborative Enterprise, 2005. 14th IEEE International Workshops on Publication Date: 13-15 June 2005 , pp.121-125. [5] Emig, C. Weisser, J. Abeck, S.: Development of SOA-based Software Systems - An Evolutionary Programming Approach . Date: February 25 2006 . International Conference on Telecommunications and International Conference on Internet and Web Applications and Services IEEE .

In this article, a method for design process based on software engineering principles was proposed in details and with related principles. This method provides a simple and clear view of design principles, which are applicable in general to different areas of business. Layering based on separation of responsibility and reusability was applied in this proposed method and feature model was created by educing variable items out of a system. Composite services and service orchestration were identified after definition of design phase services and mapping them using layering model. Applying granularity to service method is an approach to support security principles. We finally used process-modeling tool for process service modeling. Extension of this method for a suitable testing method, development of software engineering tools for the proposed design method, adaptation of existing methodologies such as MDA and/or RUP for the proposed design method can be defined as future works.

ISSN:1790-5109

371

ISBN: 978-960-474-002-4

2nd EUROPEAN COMPUTING CONFERENCE (ECC’08) Malta, September 11-13, 2008

Proceedings 10th IEEE Symposium and Workshops on Engineering of Computer-Based Systems (ECBS'03), Huntsville Alabama, USA, April 7-11, 2003. IEEE Computer Society, 2003. [19] Streitferdt, D., Riebisch, M., Philippow, I. : Formal Details of Relations in Feature Models. In: Proceedings 10th IEEE Symposium and Workshops on Engineering of Computer-Based Systems (ECBS'03), Huntsville Alabama, USA, April 7-11, 2003. IEEE Computer Society Press, 2003. S. 297304 .

[6] Chang, S.H. and Kim , S.D. : A Variability Modeling Method for Adaptable Services in Service-Oriented Computing. In the proceedings of the 11th International Conference on Software Product Line, Volume , Issue , 10-14 Sept. 2007 Page(s):261 – 268 . [7] Dijkman , R.M. and Dumas, M. : Serviceoriented Design: A Multi-viewpoint Approach. International Journal of Cooperative Information Systems 13(4) , 2004, pp. 337-378. [8] Vandersluis, K . , “The Benefits of a Data Abstraction Layer for SOA ,” Published: June 16, 2008 SOA Magazine Issue XIX . [9] Papazoglou, M.P. and van den Heuvel, W.J. “Service-Oriented Design and Development Methodology,” Int'l J. Web Eng. and Technology, vol. 2, no. 4, 2006, pp. 412–442. [10] Thomas, O., Leyking, K., Dreifus , F. , “Using Process Models for the Design of Service-Oriented Architectures: Methodology and E-Commerce Case Study, ” In the proceedings of the 41st IEEE Hawaii International Conference on System Sciences, 2008 . [11] Service-Oriented Architecture ,Sun Microsystems, Jini Network Technology,chapter 2. [12] Matinlassi, M. , “Comparison of software product line architecture design methods: COPA, FAST, FORM, KobrA and QADA ,”In the proceedings of the 29th International Conference on Software Engineering, IEEE Computer Society, Washington Brussels Tokyo, Scotland, UK, May 26th - 28th 2004. pp. 127 - 136. [13] Atkinson, C., et al., Component-based Product Line .Engineering with UML, Addison Wesley, 2001. [14] Sinnema, M., et al., “COVAMOF: A Framework for Modeling Variability in Software Product Families,” In the proceedings of the Third Software Product Line Conference (SPLC 2004), Lecture Notes on Computer Science 3154, Boston, MA, USA, August 2004. [15] Papazoglou , M.P. and Georgakapoulos, G. : Introduction to the Special Issue about ServiceOriented Computing, CACM, October 2003, 46(10): 24-29. [16] Papazoglou, M.P. : Principles and Foundations of Web Services: A holistic view, Addison-Wesley, to appear: 2006. [17] Brown , A . , et. al., “SOA Development Using the IBM Rational Software Development Platform: A Practical Guide”, Rational Software, September 2005. [18] Pashov, I., Riebisch, M.: Using Feature Modeling for Program Comprehension and Software Architecture Recovery. In: Amendment to

ISSN:1790-5109

372

ISBN: 978-960-474-002-4