A Systematic SOA-based Architecture Process

A Systematic SOA-based Architecture Process José Jorge Lima Dias Júnior1, Eduardo Santana de Almeida3, Silvio Romero de Lemos Meira2,3 DATAPREV – Technology and Information Company of Social Security1 Federal University of Pernambuco2 C.E.S.A.R. - Recife Center for Advanced Studies and Systems3 [email protected], [email protected], [email protected] Abstract During recent years, the notion of software architecture has emerged as the appropriate level for dealing with software quality. This sub-discipline of the software engineering has a several foundations that characterize a set of aspects in the architecture processes, such as views-oriented description, quality attributes orientation and architecture evaluation. Service-Oriented Architecture (SOA) emerged as a type of software architecture to build systems through the composition of services. On the one hand, the traditional architecture processes do not comprise some SOA features. On the other hand, the available SOA approaches do not fulfill all the software architecture foundations. In this sense, this paper proposes a systematic SOA-based architecture process that complains the main software architecture foundations and SOA features in order to guide the architects in the construction of a software architecture description. Keywords: Architecture Process, SOA, Software Architecture.

1. Introduction Software Architecture has attracted a great attention from researchers and practitioners since the last decade. The increasing size, complexity, and demand for quality software systems are some of the drivers that have increased interest in this sub-discipline of software engineering [7]. As any activity of software engineering, it is useful to follow a defined process in order to guide the architect through the definition of the application architecture [14]. A complete architecture process can include three main activities [14], [15]: define the architecture requirements; design the architecture; and evaluate the architecture. Moreover, the architecture documentation is part of the architecture design. However, it is common to find these activities separated in different methods in the literature. For example, some methods [2], [20], [25] focus on the architecture design activities and other methods [18], [19] focus on the architecture evaluation. The first one is concerned with the creation of software architecture, and the second one aims at analyzing a software architecture in order to identify potential risks and verify if the quality requirements have been addressed in the architecture.

An architecture design method aids the architects to design a software architecture description, considering styles that can be used and different views for several goals, addressing different quality attributes. Nevertheless, architecture design methods that were developed in different domains naturally exhibit domain characteristics and emphasize different goals [15]. Therefore, none of these methods [2], [20], [25] alone is comprehensive enough to cover the design of software architectures for systems with different sizes on various domains [21]. Currently, a special type of software architecture is being widely explored by academy and industry: Service-Oriented Architecture (SOA). A basis of the SOA is the concept of service as a functional representation of a real world business activity meaningful to the end-user and encapsulated in a software solution [26]. In the enterprise context, SOA allows the organizations, which have a highly fragmented application infrastructure under management of different business areas, integrate these applications in the service level [10]. On the one hand, the traditional architecture processes do not comprise these SOA features. On the other hand, the available SOA approaches [1], [11], [12], [17], [23] do not fulfill all the software architecture foundations, such as quality attributes orientation, views-oriented description and architecture evaluation. In this sense, this paper proposes a new process to create an SOA-based architecture description. For this purpose, the main activities in the software architecture processes and the main features found in the SOA approach were elicited. Furthermore, an initial evaluation was performed in order to assess the proposed process, in which the difficulties of its use, the guidance that it provides to the architects and the completeness of the architecture description created were analyzed. The remainder of this paper is organized as follows: Section 2 discusses the foundations of the proposed process. Section 3 presents a new SOA-based architecture process. Section 4 presents the evaluation performed to assess the proposed process. Section 5 discusses related work. Finally, Section 6 presents some concluding remarks.

2. Process Foundations A software development process can be understood as the set of activities needed to transform the user’s

requirements into a software system. The way it is done can change from process to process. In this sense, all types of processes are based on some foundations. In this section, the foundations used to elaborate the process are presented. Quality Attribute Oriented. Quality attribute requirements must be considered early in the life cycle, and the software architecture must be designed so that their quality attributes are met [3]. Hence, the process supplies a specific activity to elicit these requirements in order to address them through different views. Views-oriented Description. Software architecture is a complex entity that cannot be described in a simple onedimensional fashion [4]. A view is a “representation of a whole system from the perspective of a related set of concerns”, and a viewpoint is a “specification of the conventions for constructing and using a view” [16]. Thus, the process proposes viewpoints to represent different concerns of the SOA. Architecture Evaluation. Since software architecture plays a significant role in archiving system wide quality attributes, it is very important to evaluate a system’s architecture with regard to desired quality requirements [8]. In this sense, the process proposes a specific activity for evaluating the SOA in order to verify if the architectural decisions are addressing the quality attributes. However, an existent method is suggested in this activity. Business process oriented. Services provide a better way to expose discrete business functions and therefore a good way to develop applications that support business processes [6]. In this context, the process considers and analyzes the enterprise business processes in order to identify the services of the SOA. Design by contract. An important aspect of the SOA is that it separates the service’s implementation from its interface. To successfully use a service, both the consumer and provider need to understand the contract — what the implementation agrees to do for the consumer [22]. Thus, the process enables the definition of the service contract. Service-orientation principles. The service-orientation principles are considered in the service interface definition and other design activities in order to maintain the SOA foundations. Multiple development teams. One of the main benefits of using a SOA is that it allows a high degree of modularity. This feature permits that the services can be implemented for different teams [17]. Hence, a SOA-based process must be organized in order to enable the division of work in multiple teams to implement the services.

3. The Process Along this section, how the foundations were attended by the proposed process will be explained. The roles involved in the process were divided in two groups: • Enterprise business team: Roles of people who have an overall view of the enterprise. This group is divided in

two roles: Enterprise manager and SOA architect. The first one is the person who knows the enterprise business as a whole and manages the integration of business area teams. The second one is a specialist that knows about SOA concepts and technologies. • Business area team: Internal or external people of the enterprise that are interested on providing or consuming some service. This group can be divided in two subgroups: Service development team and Business specialist team. The first one has the roles related to services development, i.e., the team that will design and implement individual services. The second one has the roles of business specialists of some business area. Development teams in a SOA-based enterprise project can be decoupled due to high degree of modularity by using a SOA. Thus, each team is responsible for implementing a specific list of services. These teams must focus on the agreement of service contracts [18]. In order to fulfill the foundation of having multiple development teams, the proposed process is composed by two phases: SOA Definition and Service Design. The first one has activities related to the architecture definition of the SOA-based enterprise system. The second one aims at designing the services identified in the SOA Definition phase. In this case, each service is designed by the team responsible for providing the service. Figure 1 shows the two phases of the process, in which the Enterprise business team participates in the activities of the SOA Definition phase along with all Business specialist teams (A, B and C), and in the next phase of Service Design, in which each service development team is responsible for designing its own services.

Figure 1. Phases of the proposed process.

This paper focuses on the SOA Definition phase. For this reason, this paper aims at detailing only this phase. In the Service Design phase, a traditional architecture process to design the individual services can be used. The SOA Definition phase is composed by three activities. Briefly, the three activities are the following: • SOA Analysis: The services are identified as well as the consumers and providers. Besides, the quality attributes of the SOA and of the specific services are also identified. • SOA Design: The service contracts are specified and it is decided if these services will be reused or developed. Moreover, the views are created in order to address the quality attributes of the SOA and of the services, and the SOA documentation is produced.

• SOA Evaluation: The architecture is evaluated in order to verify if it is capable of fulfilling required quality attributes and to identify any potential risks. The proposed process defines sub-activities for the first two activities and it uses an existent evaluation method for the third one. These activities will be seen in details in the next subsections.

3.1 SOA Analysis Activity This activity has the objective to identify the services and the respective consumers and providers as well as the quality attributes for each service and for the SOA as a whole. The next subsections discuss the sub-activities of the SOA Analysis activity. 3.1.1 Identify Service Interfaces This is one of the most important concerns in serviceoriented design. This sub-activity aims at uncovering the services that will compose the SOA. For this purpose, this work proposes the Service Identification Workshop (SIW). The SIW provides an opportunity to join the areas to provide input about their needs and expectations with respect to services that are of particular concern to them. Hence, business specialist team and enterprise business team will achieve meetings in order to identify the service interfaces. Figure 2 shows the steps of SIW.

Figure 2. Steps of SIW.

Firstly, the SIW must be planned. For this purpose, the SOA architect analyzes the business areas, studying the macro characteristics of each one. In this sense, he can analyze documents available about the business area, existent systems, and new systems such as business process models, requirements and use cases. Next, the workshop can be started with the SIW introduction. In this step, the SOA architect explains the motivation for the SIW and describes each step of the technique for the participants. Moreover, the stimulus to use SOA for the enterprise must be presented, showing the benefits of this architecture solution. After that, each business specialist team must present its business area, showing the main business processes, responsibilities, functionalities of existent and new systems, and so on. Besides, each team must take clear about its business drivers for using services of another business area. The next step is Create Business Process Model. The idea of this step is to create new business

processes or remodel the existent ones of each business area in order to represent them in the most granular representation of processing steps. This idea is the same found in the Erl’s approach [11] in which it aims at taking the business process and breaking it down into a series of granular process steps in order to identify the services based on them. In addition, these business processes must represent the points of integration among the business areas identified in the prior step. Since the business process models have been created or refined, the services can be identified. This step is also conducted by the SOA architect that along with the business specialist teams will decide what business activities identified in previous step will be considered software services. After consolidation of the services identified, the SOA architect must present them to all the SIW participants in order to validate the results. 3.1.2 Categorize Service Interfaces Services have different uses and purposes [26]. Hence, services can be classified through their operational characteristics with different granularity levels [24]. Moreover, to categorize the services according to their purpose, increase the potentiality of reuse [11]. Currently, diverse service taxonomies are found in the literature [11], [12], [17], [24]. The SOA architect must choose some taxonomy and categorize the services identified in the previous sub-activity. This choice of the taxonomy depends on how the architect intends to organize the services. In this sense, the categorization of the services will influence the organization of the SOA layers in the SOA Design activity. In this work, the taxonomy presented by Papazoglou [24] was used. It uses three categories as following: • Business Services: They automate a generic business task with significance to the business process. • Technical Services: They are coarse-grained services that provide the technical infrastructure enabling the development, delivery, maintenance and provisioning of business processes. • Utility Services: They are fine-grained services that provide value to business services across the organization, for example, services implementing calculations, algorithms, directory management services, etc. The output of this sub-activity is the service interfaces categorized in accordance with this taxonomy. 3.1.3 Apply Service-Orientation Principles It is important that principles be applied to the services interfaces so that they have characteristics inherent to the service-oriented approach. There is no official set of service-orientation principles. Diverse principles related to service-orientation approach are found in the literature. Papazoglou and Heuvel [23] and, Feuerlicht and Lozina [13] list three principles: service coupling, service cohesion and service granularity. The service coupling can be seen as the degree of interdependence among two business processes. Hence, the objective is to minimize coupling, i.e., to make business

processes as independent as possible by not having any knowledge of or relying on any other business processes. Cohesion refers to the level of interrelationships among the elements of a software module. High level of service cohesion increases application stability as cohesion limits the impact of changes to a small number of services. Service granularity refers to the scope of functionality exposed by a service. Services may exhibit different levels of granularity. From the perspective of service-oriented design, it is preferable to create higher-level, coarse-grained interfaces that implement a complete business process. The output of this sub-activity is the interfaces refined.

verify if they already exist. In this case, the available services can be reused and the non-existent services will be developed. The providers for these services can be found in the internal or external area of the enterprise. Furthermore, it is necessary to decide how the services will be acquired (leasing, buying, and so on). The output of this sub-activity is a table containing a set of services identified and the information if they will be reused or developed. In case of the service to be reused, additional information of the provider must be described, such as reputation, support, business model, target market, and so on [10].

3.1.4 Identify Quality Attributes After uncovering the service interfaces and their respective consumers and providers, it is necessary to identify the quality attributes for each service identified as well as for the SOA as a whole. Quality attributes could be missing from the requirements document, and even if addressed adequately, they are often vaguely understood and weakly articulated [3]. For this goal, an adaptation of Quality Attribute Workshop (QAW) [3] is used. QAWs were elaborated by SEI (Software Engineering Institute) and provide a method for identifying a system’s architecture critical quality attributes. For this purpose, QAW generates, prioritizes and refines quality attribute scenarios before the software architecture is completed The output of this sub-activity is the scenarios and a table with the quality attributes prioritized of each service and of the SOA as a whole. This prioritization is important since there are tradeoffs among the quality attributes. For example, if the system requires security then the performance is decreased.

3.2.3 Address Quality Attributes Since the services and quality attributes were identified in the SOA Analysis activity, they must be addressed through different views. In this sense, for each identified service and for SOA as a whole, several views will be applied to represent these different concerns. This paper proposes a set of viewpoints to represent the architecture decisions of the SOA. However, these viewpoints are not a closed list, and other viewpoints can be used according to demand of the SOA architect. Layer Viewpoint. The tiers provide a conceptual structure at the enterprise level that organizes the services [18]. The objective of this viewpoint is to represent the layers of the architecture. Integration Viewpoint. This viewpoint describes how the services will be integrated. The two significant options for a primary integration pattern are direct point-to-point and hub-and-spoke [5]. Security Viewpoint. Security can be achieved on different levels in the SOA approach, such as transport layer and message levels. Hence, the security view should represent the solution using one of these levels. Interaction Viewpoint. The implementation alternatives impact important quality attributes of the system, such as interoperability and modifiability [5]. This view must represent how the consumer and the provider will be interacted. Physical Viewpoint. Issues about interoperability, security and reliability can be decided, since it aims at capturing the distribution of the applications and services that compose the SOA as well as the transport and message protocol used in the communication among them. Registry Viewpoint. This viewpoint aims at addressing how the services will be published, found and executed. The decision about the architecture of service discovery will be represented in this viewpoint. Publisher Viewpoint. The services can be registered under diverse technologies such as UDDI, ebXML, P2P network, and so on. In this sense, this viewpoint must represent how the service will be published by the provider in order to turn it available to the consumers. Consumer Viewpoint. This viewpoint must represent the following issues: how the consumer can find a service;

3.2 SOA Design Activity In this activity, the solution of the problem will be elaborated, specifying the service contracts, applying different viewpoints for the quality attributes identified and producing the architecture documentation. This activity was also subdivided in sub-activities. 3.2.1 Specify Service Contracts Since the service interfaces with their respective potential consumers and providers are known, it is necessary to define the contract among them. A service contract contains the terms agreed by the service provider and service consumer for the supplying of the service. In summary, the service contract must contain the following information: service interface, service messages structure, pre- and post conditions, quality attributes, potential consumers, provider and SLA. This service contract can be specified with a simple document or a formal description such as WSDL specification. 3.2.2 Reuse Existent Services The idea of this sub-activity is to search the services identified with their respective quality attributes in order to

how the consumer acquires the service; and how the consumer can bind the service (dynamically or statically). Technical Process Viewpoint. This viewpoint must represent the technical business processes that are part of the SOA, i.e., the business processes in the perspective of the services identified. These views are useful when it is necessary to map the technical business process into Business Process Modeling Language such as BPEL. None of these viewpoints are mandatory. In this sense, the SOA architect must decide, according to the project, what viewpoints to use. 3.2.4 Produce SOA Documentation After all activities have been realized, it is necessary to create the architecture documentation. This document is the main output of the architecture design activity, because it will document the artifacts produced. All information that is necessary for the service development teams must be documented, since this documentation serves as a guide to them. Dias [9] presents the complete SOA documentation template.

3.3 SOA Evaluation Activity Many architecture-centric analysis methods have been created in the few past years. Due to this variety of methods, an initial orientation is necessary. In this sense, the Architecture Trade-off Analysis Method (ATAM) [8] — developed by the SEI — is used as the basis for defining the activities for an architecture evaluation. For this purpose, SEI also produced a technical report about SOA evaluation [5] aiming at offering practical information to assist the evaluation of a system that uses the SOA approach. This evaluation method was chosen because, beyond being a mature method, it is scenario-based and it can reuse the scenarios created in the QAW. In spite of this activity being considered important, it is not mandatory to be performed. Moreover, other methods can be used in order to evaluate the architecture.

4. The Evaluation The goal of the experiment was to analyze the proposed process for the purpose of evaluating it with respect to the difficulties of its use, the guidance that it provides to the architects and the completeness of the architecture description created from the point of view of the practitioners in the context of software architecture. The experiment was run as an off-line project by professionals of a software development company. This company develops information systems for a government department that has five different areas that are responsible for some strategic business and have its own information system that helps to perform their business processes. Hence, this project is composed of five sub-projects running alongside that need to be integrated. Each sub-project has the objective to create an information system and each one has its own development team, with its project manager, software architect, business analyst, developers, and so on.

In this sense, the project of this experiment is a real problem of a SOA-based scenario with different development teams. The experiment had the following results: Difficulties in the SOA Analysis activity. The subactivity Apply Service-Orientation Principles presented the most difficulty. Only one subject did not have problems to execute this sub-activity. It is important to highlight that the lack of experience of the subjects with SOA may have influenced this result. For example, the subjects considered difficult to perform this sub-activity because it does not specify the “step-by-step” to be executed. However, an expert SOA architect, having familiarity with these principles, would not have the same difficulty. The experiment suggested that the SOA Analysis activity is difficult to be performed. However, it is necessary to highlight that this value for the null hypothesis was defined without any previous data, since it was the first time that this aspect was analyzed. Nevertheless, the next time that the experiment is performed this value can be refined based on this experience, resulting in a more calibrated metric. Difficulties in the SOA Design activity. The main difficulty mentioned was to elaborate the views. Some factors can have influenced this result. First, the profile of the subjects, that had difficulty in this sub-activity, did not have experience in the software architecture position. Other factor can be related to the lack of experience in Web Services of some subjects. The experiment suggested that the SOA Design activity is difficult to be performed. However, in the same way as in the SOA Analysis activity, this value for the null hypothesis was defined without any previous data. Guidance for creation of the architecture description. In spite of all the subjects suggesting that it is necessary to have guidelines for the sub-activities, they agreed that the sub-activities defined by the process guides the architect, since the process directs what must be produced in each stage of the process in the creation of the SOA description. Completeness of the architecture description. Seven of eight quality attributes required were addressed by the architecture description. Only the quality attribute Testability was not addressed. In this sense, the creation of a Test Viewpoint was suggested in which it would contain information about how the services can be tested. The experiment has evidenced that the process is useful in SOA context in order to guide the architect in the design of an architecture description. However, the experiment also shows that the process needs to be improved. Besides, other evaluations in other contexts must be performed to verify if the process can be applied on them.

5. Related Work In this section, five known SOA approaches [1], [11], [12], [17], [23] were analyzed according to defined foundations elicited in the previous sections. These approaches aim at supporting the full SOA lifecycle, including planning, analysis and design,

construction, testing, deployment, and governance activities, while others limit their scope to a subset of these phases, such as analysis and design [23]. For example, the Papazoglou’s [23] covers all the development lifecycle and the Jones’s approach [17] covers only initial planning. On the other hand, Erl’s approach [11] covers only analysis and design activities and the SOAF [12] and SOMA [1], beyond analysis and design, covers the construction of the services. However, none of these approaches focus on the architecture activities, since they are not in accordance with some software architecture foundations. In spite of all these approaches to consider the quality attribute aspects, none of them attend entirely and explicitly the view-oriented description and architecture evaluation requirements. Regarding design by contract and service-orientation principles requirements, only the Jones’s approach does not cover them. All the other approaches have some way to identify and to address the service contracts, and apply service-orientation principles. On the other hand, all of these approaches are focused in the business processes.

[5] Bianco, P., Kotermanski, R. and Merson, P. Evaluating a Service-

6. Concluding Remarks

[14] Gorton, I. Essential Software Architecture. Springer-Verlag Berlin

A new SOA-based architecture process was proposed in this paper. It comprises the main important foundations of the software architecture and service-oriented areas such as service identification; quality attributes identification; service categorization; service contract specification; service reuse; SOA documentation; and SOA evaluation. Moreover, an experimental study was performed in order to evaluate the proposed process. It was verified that the process needs to be improved, mainly in respect to guidelines to perform the sub-activities. As a future work, a case study will be applied in practice to validate and refine the proposed process in a real project.

Acknowledgments This work was partially supported by the National Institute of Science and Technology for Software Engineering (INES1), funded by CNPq and FACEPE, grants 573964/2008-4 and APQ-1037-1.03/08 and Brazilian Agency (CNPq process number 475743/2007-5).

References [1] Arsanjani, A. Service-Oriented Modelling and Architecture

Oriented Architecture. SEI Technical Report, CMU/SEI-2007-TR015, September, 2007.

[6] Brown, A., Johnston, S., Kelly, K. Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications. Rational Software Corporation, 2002.

[7] Clements et al. Documenting Software Architecture: Views and Beyond. Addison Wesley, 2002.

[8] Clements et al. Evaluating Software Architectures: Methods and Case Studies, Boston, MA: Addison-Wesley, 2002.

[9] Dias, J. J. A Software Architecture Process for SOA-based Enterprise Applications. MS.c dissertation, Federal University of Pernambuco, Recife, Brazil, August, 2008.

[10] Dias, J. J.; et al. A XML-based Quality Model for Web Services Certification, In the 9th Int. Conf. on Enterprise Information Systems (ICEIS), Madeira, Portugal, 2007.

[11] Erl, T. Service-Oriented Architecture: Concepts, Technology, and Design. Prentice Hall, 2005.

[12] Erradi, A., Anand, S., Kulkarni, N. N. SOAF: An Architectural Framework for Service Definition and Realization, IEEE International Conference on Services Computing, 2006, 51-158.

[13] Feuerlicht, G. and Lozina, J. Understanding Service Reusability, In the Proceedings of the 15th International Conference Systems Integration. Prague, Czech Republic, 2007, 144-150. Heidelberg, 2006.

[15] Hofmeister, C., et al. A general model of software architecture design derived from five industrial approaches. The Journal of System and Software, 2007, 106-126.

[16] ISO/IEC 42010. Systems and software engineering - Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE Std 1471-2000. 1st. edition, 2007.

[17] Jones, S., Mike, M. A methodology for service architectures, OASIS Draft, http://www.oasis-open.org/, 2005.

[18] Kazman, R., Abowd, G., Bass, L. and Clements, P. Scenario-Based Analysis of Software Architecture, IEEE Software, Nov, 1996.

[19] Kazman, R., Mark, R. and Clements, P. ATAM: Method for Architecture Evaluation, Technical Report. CMU/SEI-2000-TR004. Pittsburgh, 2000.

[20] Kruchten, P. The 4+1 View Model of Architecture. IEEE Software, vol. 12, no. 6, 1995, 45–50.

[21] Matinlassi, M. and Kalaoja, J. Requirements for Service Architecture Modeling. In Workshop of Software Modeling Engineering of UML. Dresden, Germany, 2002.

[22] Meyer, B. Object-Oriented Software Construction, 2nd edition, Prentice Hall, 1997.

[23] Papazoglou, M. P. and Heuvel, W. Service-oriented design and development methodology. Int. J. Web Techonology, Vol. 2 No. 4, 2006, pp. 412-442.

Engineering

and

(SOMA), IBM developer-Works, http://www.ibm.com/developerworks/webservices/library/ws-soadesign1, 2004.

[24] Papazoglou, M. P. What’s in a Service?. 1st European Conf. on

[2] Bachman, F., Bass, L. Introduction to the Attribute Driven Design

Industrial Applications. In: Proc. of 17th International Conf. on Soft. Eng. (ICSE). ACM Press, 1995, 196-207.

Method. IEEE Software,2001.

[3] Barbacci, M. R., Ellison, R., Lattanze, A, J., Stafford, J. A., Weinstock, C. B., & Wood, W. G. Quality Attribute Workshops, 3rd. Edition. Pittsburgh, PA: SEI, Carnegie Mellon University, 2003.

[4] Bass, L., Clements, P., Kazman, R. Software Architecture in Practice, Reading, Mass.: Addison-Wesley, 2003.

1

http://www.ines.org.br

Software Architecture. Proc. in Springer. Madrid, Spain, 2007.

[25] Soni, D., Nord, R., Hofmeister, C. Software Architecture in

[26] Zimmermann, O., Krogdahl, P., Gee, C. Elements of ServiceOriented Analysis and Design, Available at: http://www128.ibm.com/developerworks/webservices/library/ws-soad1/, 2004.