Service Oriented Architecture Design and Development Method René van Donselaar Universiteit Utrecht Notice of Originality I declare that this paper is my own work and that information derived from published or unpublished work of others has been acknowledged in the text and has been explicitly referred to in the list of references. All citations are in the text between quotation marks ( ). I am fully aware that violation of these rules can have severe consequences for my study at Utrecht University. Signed: Date: 3-4-202 Name: René van Donselaar Place: Utrecht
Introduction As application portfolios grow, enterprises have increasing difficulty managing all applications. One of the main issues is that applications are built with the tools that are available at a certain time and therefore the application portfolio will contain applications that are built based on different programming languages and design patterns. Making applications that are built using different programming languages exchange data is a complex and costly task. Tracking the functionalities that are covered by applications is difficult and redundancy occurs by a lack of documentation and integration of applications. Architecture with a higher level of abstraction can help solve these problems. Service Oriented Architecture (SOA) is a form of enterprise architecture based on both internal and external services which communicate via interfaces (Brown et al., 2002). Services are used to provide other applications or interfaces access to functionality that can come from one or more applications. When using services the underlying applications are invisible to the user and can communicate with other services, independent of programming language or platform. This also creates opportunities for interoperability with other enterprises, making it more easy to use each other s services. SOA requires that the services are documented and reused within business units to maximize development efficiency and reduce the complexity of growing application portfolios. For the implementation of SOA, the business has to be adapted to follow the new set of principles. Although the business is an important aspect of successful implementation of SOA, the application design and development also needs to be adapted. Using existing applications and adding new interfaces is not enough, it requires a new development method that is integrated through the whole development process. In this paper we will discuss the Service-Oriented Design and Development Method (SODDM) by Papazoglou and Van den Heuvel (2004). Papazoglou is a Computer Science professor and has specialized in Service Science. Over the years he has published over eighteen articles related to SOA. His most famous work is Service-oriented computing (2003) which has been cited over 400 times. For developing SODDM Papazoglou worked together with Van den Heuvel who is an Information Systems professor. Van den Heuvel is an expert in service systems and business process management. His latest work on SOA is Business policy compliance in service oriented systems
(20) that describes a form of adaptive SOA that can handle the changing business policies within an enterprise. The SODDM method is based on Rational Unified Process, Component-based Development and Business Process Modeling. It bears resemblance to many other agile development methods by using an iterative process with phases. Within the phases we see distinct differences with an agile development method like SCRUM (Schwaber, 2009), which is based on products with a product backlog. SODDM starts with a planning phase; defining the business needs and goals in order to identify services rather than products. This step is crucial for business alignment and for managing the application portfolio. The next phase involves analyzing a business case in order to find possible solutions and alternatives, much like in a PRINCE2 project (Jansen, 2007). The difference is that this phase is also involves specific SOA related analyses, like service coupling; where the goal is to make the business processes as independent as possible. The services in the business process are also analyzed for their cohesion; the services should be highly related to one another. Other phases are: Provisioning, deployment and monitoring. SODDM provides an agile based development method that is geared towards managing services and tight business alignment in order to implement a SOA architecture.
[ Example ] For this example an imaginary airline company referred to as Aircom will be used. First, the planning phase is explained. Aircom has a set of business needs that have to be addressed: Customers should be able to do their own bookings Customers should be able to check for available seats Customers should be able to pay for their booking A business goal is derived from these business needs. Aircom has the goal of servicing their customers with an online booking web application which was derived from the business need of expanding their business to involve e-commerce. The next activity is to look at the current technology landscape in order to define a solution. The technology that is fit for the project is chosen based on what is currently available, the costs of the development and what technology is already used within the company. To find which services need to be created and which have already been incorporated, the current portfolio of services is analyzed in the analysis and design phase. Table - portfolio analysis Service name Booking registration service Booking cancellation service Booking availability request service Customer login service Customer registration service Customer payment service Is implemented Yes Yes Yes No No No Table depicts the portfolio for the bookings business process, which is a combination of the asis situation with the to-be situation. The as-is situation contains all services that the company currently has, while the to-be situation shows all services that need to be created in order to support the new business process. It shows which services the company had already
implemented and those that need to be implemented. Since some services are already available they can be coupled with the new services for web based bookings. By doing this, the SOA principle of reusing existing services within a business process can be addressed. After this a business process realization scenario is chosen, which consists of four major categories: Green field development; which starts with the development of a service and then looks at the possible language for the webinterface. Top-down; when using an already existing interface. Bottom-up; when a new interface is to be created. Meet-in-the-middle; when an already existing interface is being mapped partially onto a new service. The choice for a scenario is based on costs, risks, benefits and return of investment. The service is specified according to three elements, which are structural, behavioral and policy specifications. This specification can be written in XML as is shown in the example below. Here the existing service of booking registration is shown. <porttype name= canreceivea43_porttype > <operation name= BookingRegistrationRequest > <output message= tns:bookingregistrationrequest /> </operation> </porttype> The first specification is the port type, which is used to communicate with the service. An operation is defined with its name, in this care BookingRegistrationRequest. The output
message is in many cases identical to the operation name and is the message that is sent when the operation is triggered. In the specification of services many more attributes are documented, such as the programming style and service policies. The business processes are described and the roles that perform them. After the design is finished the construction will start in the construction and testing phase. The construction will be based on the previously defined planning, analysis and design. The constructed service is tested on its functionalities according to its specification. Strategies for service metering, rating and billing are defined in the provisioning phase. In this example the service could be offered for free and the billing could be incorporated in the actual payment for the booking. The service is now ready to be deployed in the deployment phase. How this is done has to do with the outcome from the process realization analysis. For this example the new service is deployed within the existing IT structure of Aircom, as they are already offering similar services. For the web interface an external party is used. Finally the service enters the execution and monitoring phase. Here who will be responsible for what part of the service is described. For the existing services no changes are made, while for the new services members of the business process are assigned to each service. The service is monitored by looking at aspects of the SLA that can be measured. In this example the time that it takes to get a response from the booking service is measured to see if it is according to the SLA. The up-time of the service can also be measured which is stated in the SLA.
Process Deliverable Diagram After analyzing SODDM a graphic representation of the process and its deliverables was made. It shows all activities one must perform on the left side, ordered from top to bottom. On the right side a connection is made with the deliverables that are produced by each activity. Van de Weerd & Brinkkemper (2006) can be used as reference for reading PDDs.
Plan Analyze business needs BUSINESS GOAL...* PLAN Review current technology TECHNOLOGY LANDSCAPE Conceptualize requirements BUDGET AND SOFTWARE DEVELOPMENT PLAN Analyze costs and benefits Tasks Deliverables Schedule is input for Categorize and decompose business environment BUSINESS AREA DEFINITION...* Business expert Analyze Review business goals and objectives ANALYSIS Identify processes AS-IS PROCESS MODEL TO-BE PROCESS MODEL Scope processes Analyze process realization Business analyst is input for Design Specify business processes Specify services SERVICE DESIGN Address design concerns Construct provides design for SERVICE ORIENTED APPLICATION Test Test dynamics Test functions is input for Test performance Test assembly [else] [passed test] Provision Govern service REVIEW...* PROVISION PLAN Certify service SERVICE CONTRACT...* Rate service BUSINESS CASE...* Define billing strategy BILLING STRATEGY is input for Execute service Monitor Measure SERVICE MONITOR REPORT Report response time throughput availability Figure - SODDM PDD
Activity table All activities that are depicted in the PDD have been included in an activity table. Here each activity is described. The name of the activity is displayed and next to it are the (optional) sub activity names with a short description in the last column. Table 2 - Activity table Activity Plan Analyze Sub activity Description Analyze business Business needs are analyzed in order to define BUSINESS GOALS. needs (Papazoglou & Van den Heuvel, 2004) Review The current technology landscape is being reviewed in order to find current suitable technologies that can be used within the business in a technology TECHNOLOGY LANDSCAPE. (Papazoglou & Van den Heuvel, 2004) Conceptuali ze requiremen ts Analyze costs and benefits Categorize and decompose business environmen t Review business goals and objectives Identify processes Scope processes Analyze process realization The requirements of the new environment are conceptualized and mapped to new or available implementations. (Papazoglou & Van den Heuvel, 2004) A financial analysis of the costs and benefits is performed that produces a BUDGET AND SOFTWARE DEVELOPMENT PLAN. (Papazoglou & Van den Heuvel, 2004) The business expert categorizes and decomposes the business into BUSINESS AREAs based on the functions provided by the business processes. (Papazoglou & Van den Heuvel, 2004) The business analyst reviews business goals and objectives that drive the development of business processes as part of the ANALYSIS. (Papazoglou & Van den Heuvel, 2004) The business analyst identifies current processes are in order to create an AS-IS PROCESS MODEL. (Papazoglou & Van den Heuvel, 2004) The business analyst defines the scope of business processes in order to create TO-BE PROCESS MODEL. (Papazoglou & Van den Heuvel, 2004) The business analyst considers diverse business process realization scenarios. (Papazoglou & Van den Heuvel, 2004)
Design Construct Test Provision Execute service Monitor Address design concerns Specify services Specify business processes Test dynamics Test functions Test performanc e Test assembly Govern service Certify service Rate service Define billing strategy Meaure Report Analyze and solve design concerns such as managing granularity, reuse and composability. (Papazoglou & Van den Heuvel, 2004) Specify the service by structural, behavioral and policy specification. (Papazoglou & Van den Heuvel, 2004) Describe the business process structure, Roles and non-functional business process concerns. (Papazoglou & Van den Heuvel, 2004) The development of the web service and implementation of the web service. (Papazoglou & Van den Heuvel, 2004) Run the implementation and compare its actual to its expected behavior. (Papazoglou & Van den Heuvel, 2004) Test how the system executes functions and if they follow the expected behavior. (Papazoglou & Van den Heuvel, 2004) Monitoring the systems on-line response times and transactions under peak workload conditions. (Papazoglou & Van den Heuvel, 2004) Tests whether all services function properly when assembled into business processes. (Papazoglou & Van den Heuvel, 2004) Align the business strategy with the IT strategy. (Papazoglou & Van den Heuvel, 2004) List all the properties that the application may attain. (Papazoglou & Van den Heuvel, 2004) Create a pricing model that could be used to calculate the charges for the customer. (Papazoglou & Van den Heuvel, 2004) Define a strategy for billing services that way the customer needs to perform his payment. (Papazoglou & Van den Heuvel, 2004) Ensure the new process is carried out by all participants. (Papazoglou & Van den Heuvel, 2004) Measure the service level objectives and performance. (Papazoglou & Van den Heuvel, 2004) Evaluate the service level objectives and performance. (Papazoglou & Van den Heuvel, 2004)
Concept table The concepts that are present in the PDD are listed in Table 3. Each concept is shown by name and explained with a short description. Table 3 Concept table Concept BUSINESS GOAL TECHNOLOGY LANDSCAPE BUSINESS AREA DEFINITION BUDGET AND SOFTWARE DEVELOPMENT PLAN PLANNING ANALYSIS AS-IS PROCESS MODEL TO-BE PROCESS MODEL SERVICE DESIGN SERVICE ORIENTED APPLICATION REVIEW SERVICE CONTRACT BUSINESS CASE BILLING STRATEGY PROVISION PLAN SERVICE MONITOR Description Describes the objectives of the business. (Papazoglou & Van den Heuvel, 2004) Describes the current available technology that can be used. (Papazoglou & Van den Heuvel, 2004) A description of functions served by business processes. (Papazoglou & Van den Heuvel, 2004) Describes the tasks, deliverables and schedule. (Papazoglou & Van den Heuvel, 2004) Consists of BUSINESS GOAL, BUSINESS AREA DEFINITION and BUDGET AND SOFTWARE DEVELOPMENT PLAN (Papazoglou & Van den Heuvel, 2004) Consists of an AS-IS PROCESS MODEL and a TO-BE PROCESS MODEL. (Papazoglou & Van den Heuvel, 2004) Describes the current business processes and services. (Papazoglou & Van den Heuvel, 2004) Describes a desired situation of business processes and services. (Papazoglou & Van den Heuvel, 2004) The design of the service that describes the granularity, reuse, composability, specification and business processes. (Papazoglou & Van den Heuvel, 2004) The tested construction of the service. (Papazoglou & Van den Heuvel, 2004) Internal and external parties look at the quality of the service and report in a review. (Papazoglou & Van den Heuvel, 2004) Can be an SLA, and contains all service certificates. (Papazoglou & Van den Heuvel, 2004) Shows the costs, benefits and resources that are involved with the provision. (Papazoglou & Van den Heuvel, 2004) A description of how the customer should pay for the service. (Papazoglou & Van den Heuvel, 2004) Consists of a BILLING STRATEGY and one or more REVIEWs, SERVICE CONTRACTs and BUSINESS CASEs. (Papazoglou & Van den Heuvel, 2004) Contains the response time, throughput and availability of the service.
REPORT (Papazoglou & Van den Heuvel, 2004) Literature review SODDM was first introduced by Papazoglou and Van den Heuvel (2004) and is based on Rational Unified Process, Component-based Development and Business Process Modeling. Rational Unified Process was introduced by Kruchten (2004) and is based on the best practices in software engineering. SODDM addresses the need for a method to design and develop services within an organization that uses SOA for their enterprise architecture. Brown et al. (2002), describes the process of design and development of web applications in a service-oriented environment. This study only shows the design and development aspects and does not deal with the complexities of the business side and how to translate this into services. Zimmerman et al. (2005) also provided techniques for analyzing and designing SOA development based on UML and Rational Unified Process, but this study is more general and does not describe an entire method for dealing with development. Reijnders et al. (20) has compared many of the service-oriented software development methods, in this study SODDM is also described and compared with other methods like SOMA. SOMA was introduced by Arsanjani (2004) and is an agile method developed and used by IBM for a SOA architecture development. Another method is the WSIM by Lee et al. (2006) which is based on the extending existing development methods for development geared towards SOA. The study also shows that SODDM and SOMA are the most dominant studies on this subject. References Arsanjani, A. (2004). Service-oriented Modeling and Architecture. IBM developerworks. Brown, A., Johnston, S., Kelly, K. (2002). Using Service-Oriented Architecture and Component- Based Development to Build Web Service Applications. Rational Software Corporation. Jansen, P. (2007). Prince2 Compact. Pearson Benelux: Education.
Kruchten, P. (2004). The rational unified process: an introduction. Addison-Wesley Professional. Lee, S., Chan, L., Lee, E. (2006). Web Services Implementation Methodology for SOA Application. Industrial Informatics. Papazoglou, P., Van den Heuvel, W. (2004). Service-Oriented Design and Development Methodology. Int. J. of Web Engineering and Technology (IJWET). Reijnders, G., Khadka, R., Jansen, S. (20). Developing a Legacy to SOA Migration Method. Department of Information and Computing Sciences, Utrecht University, Tech. Rep. UU-CS- 20-008. Schwaber, K. (2009). Agile project management with Scrum. O'Reilly Media. Van de Weerd, I., Brinkkemper, S. (2009). Meta-Modeling for Situational Analysis and Design Methods. Zimmerman, O., Schlimm, N., Waller, G., Pestel, M. (2005). Analysis and design techniques for Service-Oriented Development and Integration. IBM Deutschland.
Appendix Conceptualized requirements (conceptual solution) Requirements Name Description Owner Some requirement A short description Who submitted the requirement Some requirement A short description Who submitted the requirement Some requirement A short description Who submitted the requirement Business solution Name of the solution Textual description Components description Graphical representation of the business solution (use cases) System Performed action UseCase «extends» UseCase5 Performed action UseCase2 Performed action UseCase6 UseCase3 Name of the actor Name of the actor Performed action UseCase4 Name Role Description User template Name of the user (if available) Name of the role within the system Short description of the user
Id Name Description Extends Usecase template Unique usecase id Name of the usecase Short description of the usecase Extends which usecase(s)