October 24, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Delving into Service-Oriented Architecture

  • September 17, 2004
  • By Bernhard Borges, Kerrie Holley and Ali Arsanjani
  • Send Email »
  • More Articles »

Service-Oriented Modeling, Analysis, and Design

So far we've spoken about the end result of SOA, architecture with a composite set of business-aligned services. To create SOA, we need to identify, specify, and design services and their choreography from the angles of consumer and provider. The modeling, analysis, and design of services are not quite the same as the world of OO. There are additional activities that need to be done.

Major activities of a service-oriented modeling approach were described in an IBM Redbook. Also, Zimmerman et al. (see References) describe a case for, and context of, service-oriented analysis and design (SOAD). In this section we describe these key-differentiating activities and provide a technique for the modeling, analysis and design of SOA services. Specifically, we examine how the services of an SOA are identified, specified, and realized.

An SOA does not start only from the bottom-up as is often the case with a merely Web services based approach. There are a number of important activities and decisions that influence not just integration architecture but enterprise and application architectures as well. They include the activities from both the consumer and provider views described in Table 1.

Table 1.

Service identification consists of a combination of top-down, bottom-up, and middle-out techniques. In the top-down view, a blueprint of business use cases provides the specification for business services. This top-down process is often referred to as domain decomposition, the decomposition of the business domain into its functional areas and subsystems, including its flow or process decomposition into processes, sub-processes and high-level business use cases. These use cases are often very good candidates for business services exposed at the edge of the enterprise.

In the bottom-up portion of the process, or existing asset analysis, existing systems are analyzed and selected as viable candidates for providing lower-cost solutions to the implementation of underlying service functionality that supports the business process. In this process, we analyze and leverage APIs, transactions, and modules from legacy and packaged applications. In some cases, componentization of the legacy systems is needed to re-modularize the existing assets for supporting service functionality.

The middle-out view consists of goal service analysis to validate and unearth other services not captured by either top-down or bottom-up service identification approaches. It ties services to goals and sub-goals, key performance indicators, and metrics.

Service classification is launched once services have been identified. It is important to start service classification in a service hierarchy, reflecting the composite or fractal nature of services: services can and should be composed of finer-grained components and services. Classification helps determine composition and layering as well as coordinates building of interdependent services base don the hierarchy. Also, it helps alleviate the service proliferation syndrome in which an increasing number of small-grained services get defined, designed, and deployed with very little governance, resulting in major performance, scalability, and management issues. More importantly, service proliferation fails to provide services that are useful to the business, which would allow for the economies of scale to be achieved.

Subsystem analysis takes the subsystems found above during domain decomposition and specifies the interdependencies and flow between the subsystems, and puts the use cases identified during domain decomposition as exposed services on the subsystem interface. The analysis of the subsystem consists of creating object models to represent the internal workings and designs of the containing subsystems that will expose the services and realize them. The design construct of "subsystem" will then be realized as an implementation construct of a large-grained component realizing the services in the following activity.

Component specification is the next major activity; the details of the component that will implement the service(s) are specified: data, rules, services, configurable profile, and variations. Messaging and Events specifications and management definition occur at this step.

Service allocation is the process of assigning services to containers that will realize their published functionality. Structuring of components occurs when we use patterns to construct enterprise components with a combination of mediators, facade, rule objects, and configurable profiles and factories. Service allocation also consists of assigning the services and the components that realize them to the layers in your SOA. Allocation of components and services to layers in the SOA is a key task that will require the documentation and resolution of architectural decisions that relate not only to the application architecture but also to the technical operational architecture designed and used to support the SOA realization at runtime.

Service realization recognizes that the software that realizes a given service must be selected or custom built. Other options that are available include integration, transformation, subscription, and outsourcing of parts of the functionality using Web services. Here you decide which legacy system module will be used to realize a given service and which services will be built from the "ground-up." Other realization decisions for services outside of business functionality include: security, management and monitoring of services.

Conclusions

SOA extends CBD into the realm of ubiquity and pervasive access through extending the reach of callable components by using non-proprietary, interoperable protocols, service descriptions that separate of interface from implementation. SOA will have a more profound impact on software engineering than what we have been accustomed to with object-oriented and component-based development. Executing a sound service-oriented analysis and design technique will be a critical success factor to make this promise a reality as SOA itself has components and layers that need to be defined and designed.

References

  • Endrei, M.; Ang, J.; Arsanjani, A.; Chua, Sook; Comte, Philippe; Krogdahl, Pal; Luo, Min; and Newling, Tony. (2004) Patterns: Service-oriented Architecture and Web Services. IBM Redbook, ISBN 073845317X. www.redbooks.ibm.com/redbooks/SG246303/ wwhelp/wwhimpl/java/html/wwhelp.htm
  • Levi, K.; Arsanjani, A. "A Goal-oriented Approach to Enterprise Component Identification and Specification." Communications of the ACM, Oct 2003.
  • Arsanjani, A. "The Enterprise Component Pattern." Proceedings of Pattern Languages of Programming, 2000.
  • Zimmerman, O.; Korgdahl,P.; and C. Gee, C. "Elements of Service-oriented Analysis and Design", IBM developerworks. June 4, 2004.
  • Keen, Martin; Bishop, Susan; Hopkins, Alan; Milinski, Sven; Nott, Chris; Robinson, Rick; Adams, Jonathan; and Verschueren, Paul. ( 2004) Patterns: Implementing an SOA with the Enterprise Service Bus. IBM Redbook ISBN SG24-6346-00.




Page 3 of 3



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel