Service oriented modeling and architecture

This article discusses the highlights of service-oriented modeling and architecture; the key activities that you need for the analysis and design required to build a Service-Oriented Architecture (SOA). The author stresses the importance of addressing the techniques required for the identification, specification and realization of services, their flows and composition, as well as the enterprisescale components needed to realize and ensure the quality of services required of a SOA.

There has been a lot of buzz and hype — some factual, some not so well-founded — surrounding the opportunities presented by Service-oriented Architectures (SOA) and its implementation as Web services. Analysts have predicted, pundits have professed, professors have lectured, companies have scurried to sell what they had, as SOA products — often missing the point that SOA is not a product. Itís about bridging the gap between business and IT through a set of businessaligned IT services using a set of design principles, patterns, and techniques. ZDNet recently said, “Gartner predicts that by 2008, more than 60 percent of enterprises will use SOA as a “guiding principle” when creating mission-critical applications and processes.” A huge demand exists for the development and implementation of SOAs. So if SOA is not just about the products and standards that help realize it, for example through Web services, then what additional elements do you need to realize a SOA? Service-oriented modeling requires additional activities and artifacts that are not found in traditional object-oriented analysis and design (OOAD). The article ìElements of Service-oriented Analysis and Design” describes an initial set of reasons why you need more than OOAD. It also describes how business process management or enterprise architecture (EA) and OOAD are inadequate means of conducting analysis and design. Also, in the IBM Redbook entitled ìPatterns: Service-Oriented Architecture and Web Services”, I illustrate the major activities of this service-oriented modeling approach. 2 29 January 2005 From
However, additional important considerations exist that you need to take into account. For one thing, current OOAD methods do not address the three key elements of a SOA: services, flows, and components realizing services. You also need to be able to explicitly address the techniques and processes required for the identification, specification and realization of services, their flows and composition, as well as the enterprise-scale components needed to realize and ensure the quality of services required. Second, a paradigm shift needs to occur, in order to appreciate the distinct requirements of the two key roles in a SOA: the service provider and service consumer. Third, applications assumed to be built for one enterprise or line of business must now aspire to be used in a supply chain and be exposed to business partners who might compose, combine, and encapsulate them into new applications. This is the notion of the service ecosystem or service value-net. This is a slight step up from just “distributed objects”. Itís about the value created through the network effect: for example, when parties leverage a combination of with Googleís search services and combine them with eBay services to build their own hybrid solutions. Or when a travel agency reaches deep into an airline reservation system and coordinates it with a rental car agency and hotel chain, updating their records and sending the itinerary to your electronic organizer. Whatever the application, you need much more than just good tools and standards to successfully create a SOA. You need some prescriptive steps to support your SOA life cycle; techniques for the analysis, design, and realization of services, flows, and components. Therefore, for anyone interested in enterprise application development, itís crucial to understand the detailed steps involved in service-oriented modeling and architecture.
Before I describe these steps in detail, letís first understand what you are aiming to produce: what is a SOA, and what does it look like? After defining the notion and concepts behind a SOA, Iíll describe the layers of a SOA and how you need to record key architectural decisions about each of those layers that help you in building a blueprint for the SOA that is right for your project, line of business, enterprise-wide effort, or value-chain that you are trying to integrate and come up with a set of services, flows, and components that implement the SOA. Service-Oriented Architecture: A conceptual model This concept is based on an architectural style that defines an interaction model between three primary parties: the service provider, who publishes a service description and provides the implementation for the service, a service consumer, who can either use the uniform resource identifier (URI) for the service description directly or can find the service description in a service registry and bind and invoke the service. The service broker provides and maintains the service registry, although nowadays public registries are not in vogue.

Free download research paper