Approaches or service design methods reviewed here were chosen using literature research on SOA or service design topic. Choice criteria: its explicit situation in the SOA context. top-down/ bottom-up service design approach - Completeness: A method or approach is complete if it includes the necessary description of the activities, elements and tools; Furthermore, a method should include the components: purpose and scope, constructs, principles of form and function, artifact mutability, testable propositions, justificatory knowledge, principles of implementation, expository instantiation. - Referring to service design the approach or method should specify the identification process. Service identification can be accomplished using the inventory of the legacy systems and business process documentation, i.e. bottom-up or top-down, i.e. modeling or analyzing business processes from scratch. Furthermore, both technical and business content need to be separated during the design. This aspect allows autonomous implementation of the services. Additionally the approach or method needs to consider the given architectural principles. Its transparency and homogeneity need to be preserved during service design and deployment . - Goal reference: The approach needs to be evaluated concerning its reference to service design. Here case studies or application examples are helpful for actual evaluation of method implementation (see also). A SOA- situated approach needs to consider software engineering as well as business engineering in the service design phase. The province of the method (industry or software vendor origins) is important for the evaluation of technology, applicability, dispersion and mutability of the approach. Also, general technology direction for service development and deployment need to be suggested by the approach. - Consistency: Consistency of a method or approach is evaluated according to the temporal and logical dependencies between the suggested process steps, outcomes or roles. Furthermore, parallel activities need to be explicitly synchronized. Activity and process descriptions need to have clear and explicit semantics.
SOAM: top-down/ bottom-up service design, legacy systems analysis; focuses on business requirements and business-oriented business process realization SOAA: includes service design patterns, data models and interfaces,
Process Owner, Business Process Analyst and IT Developer. The process owner is involved into the process operation, business analyst is a member of a (internal) consulting team or a team that is concerned with business process management tools that are used for e.g. for process modeling, and workflow systems. IT developer transforms business requirements into software components. The first two phases are conducted by the process owner and business process analyst. The last two phases are completed by business process analysis and IT developer.
business process models and descriptions. The identified operations need to be mapped to the service model. This model is transformed into a service description including interface definition in a WSDL-file. In the requirements analysis phase business requirements that need to be realized using services are elevated. Here the purpose of the service is defined: whether it is meant to encapsulate a legacy system or to support a business process. Whether it is possible to support a business process in a SOA is evaluated according to the following criteria
Constructs: a meta model, etc Principles of form and function: Blueprint or architecture of the artefact Muatlibility mathod level: designer can foresee changes of the method itself; instance of a method: possible changes in the instantiation of the method are foreseen in the original method design and are described there. Testable propositions: method evaluation concrete Principles implementation: adaptation for a particual situation, introduction of the method into the organisation Exempository Instantiation: realife application of the design method
- Know-how of business process analysis needed - role concpet is enterprise specific - c-level management support for the SOA implementation
ME2011 presentation by Levina
Towards a Method for Service Design ME‘ 2011 Olga Levina Trung Nguyen Thanh, Oliver Holschke, Jannis Rake-Revelant Berlin Institute of Technology
Agenda <ul><li>Overview of the Development of the Design Process </li></ul><ul><li>Principles of Service Design </li></ul><ul><li>Overview of Service Design Approaches </li></ul><ul><li>Developed Service Design Approach </li></ul><ul><li>Discussion and Outlook </li></ul>
References <ul><li>Erl, T., Service-Oriented Architecture: Concepts Technology, and Design. 5 ed., 2005, New Jersey: Prentice Hall PTR. </li></ul><ul><li>Marks, E.A., Bell, M., Service-Oriented Architecture: A Planning and Implementation Guide for Business and Technology. 1 ed. 2006, Hoboken: John Wiley and Sons Inc. </li></ul><ul><li>Krafzig, D., Banke, K., Slama, D., Enterprise SOA: Roads and Best Practices for Service- Oriented Architectures (in German). 1 ed. 2007, Heidelberg: REDLINE GmbH. </li></ul><ul><li>Heutschi, R., Serviceorientierte Architektur 2007, Berlin: Springer. </li></ul><ul><li>Offermann, P., Bub, U. A Method for Information Systems Development According to SOA. in AMCIS 2009. 2009. </li></ul><ul><li>Papazoglu, M., Heuvel, W.-J. van d., Service-Oriented Design and Development Methodology. International Journal of Web Engineering and Technology 2006: p. 412-442. </li></ul>