by Mike P. Papazoglou
Service-oriented computing is not simply about deploying software: it also requires that organizations evaluate their business models and come up with service-oriented design and development techniques and support plans. At INFOLAB/University of Tilburg in the Netherlands we have developed an experimental methodology for service-oriented design and development that applies equally well to Web services and business processes.
Service orientation utilizes services as constructs to support the rapid, low-cost and easy composition of distributed applications. Key to this concept is the service-oriented architecture (SOA), which is a logical way of designing a software system to provide services to either end-user applications or to other services distributed over a network, via published and discoverable interfaces. A well-constructed SOA can empower a business environment with a flexible infrastructure and processing environment by provisioning independent, reusable automated business processes (as services) and providing a robust foundation for leveraging these services.
In their early use of SOA, many researchers and developers think that they can port existing components to act as Web services just by creating wrappers and leaving the underlying component untouched. Since component methodologies focus on the interface, many developers assume that these methodologies apply equally well to SOAs. Thus, the placement of a thin SOAP/WSDL/UDDI veneer on top of existing applications or components that implement the Web services is now widely practised in the software industry. Yet this is in no way sufficient to construct commercial-strength enterprise applications. Unless the nature of the component means it is suitable for use as a Web service " and most are not " it takes serious thought and redesign to properly deliver a component's functionality through a Web service.
While relatively simple Web services may be built with conventional development methodologies, a service-oriented development methodology is of critical importance to specify, construct, refine and customize highly volatile business processes from internally and externally available Web services.
Our service-oriented design and development (SoDD) methodology provides
sufficient principles and guidelines to specify and construct business processes choreographed from a set of internal and external Web services. It takes into ac-count a set of development models (eg top-down, bottom-up and meet-in-the-middle), stresses reliance on reference models, and considers several service realization scenarios, including green-field development, outsourcing, and legacy wrapping in cases where services are assembled out of pre-existing components.
Our service-oriented design and development methodology is based on an iterative and incremental process that comprises one preparatory and eight distinct main phases that concentrate on business processes and may be traversed iteratively. These are planning, service-oriented analysis and design, construction and testing, provisioning, deployment, execution and monitoring.
Service-Oriented Analysis and Design Phases
Service analysis aims at identifying, conceptualizing and rationalizing business processes as a set of interacting Web services. In particular, the analysis phase places an emphasis on identifying and describing the processes and services in a business problem domain, and on discovering potential overlaps and discrepancies between processes under construction and available system resources that are needed to realize singular Web services and business processes. It therefore examines the existing services portfolio at the service provider's side to understand which patterns are in place and which need to be introduced and implemented. Service analysis helps prioritize business processes and services where SOA can contribute to improvements and offer business value potential. It also helps to centre efforts on business domains within an enterprise that can be mapped to core business processes.
The analysis phase reviews the business goals and objectives of an enterprise, since these drive the development of business processes. It helps focus SOA initiatives by creating a high-level process map that identifies business domains and processes of particular interest to an enterprise. Business processes are ranked by criteria related to their value and impact, reuse and high consumption, feasibility and technical viability. From the process map, analysts can identify candidate business services that relate to these processes. Candidate business services are those that have potential value for an organization and can be evaluated on the basis of reuse, business impact, and organizational value.
Designing a service-oriented application requires developers to define related, well-documented interfaces for all conceptual services identified by the analysis phase, prior to constructing them.
The design phase encompasses the steps of singular service specification, business process specification, and policy specification for both singular services and business processes. Service design is based on a twin-track design approach that provides two production lines - one along the logical part and one along the physical part of the SOA - and considers both functional and non-functional service characteristics. The purpose of logical service design is to define singular services and assemble (compose) services out of reusable singular service constellations. This calls for a business process model that forces developers to determine how services combine and interact jointly to produce higher level services. The physical design trajectory focuses on how to design component implementations that provide services at an acceptable level of granularity. Physical design is thus based on techniques for leveraging legacy applications and component-based development.
Mike P. Papazoglou
University of Tilburg, The Netherlands