Metodologia soa gy ansijo Aexa6pp 2010 45 pagcs Chapter 4 A Methodology for Service Modeling and Design w hen the programming model shifted from the traditional procedural model to that of object-orientation, a major paradigm shift occurred in the world of IT development. The focus was on encapsulating the state and behavior of entities and calling that encapsulation a class. Instances of a class were called objects, which occupied some space in the memory. Object orientation (00) brought in concepts ofinheritance, encapsulation, and polymorphism that could bea lied to define relationships between classes.
WIt PACE 1 oras programming world, ve! , sorne patterns that c be ao to solve similar types the deconstruction o se of 00 in the ts started noticing ge of 00 principles ns depicted class entities, together with their interrelationships using the basic concepts of 00, to provide a solution to the problem. The seminal work in this field was done by the Gang of Four authors in the book called Design Patterns: Elements of Reusable Object-Oriented Software. (See the «References» section. Whereas in 00 the first-class constructs were objects and classes, the next- generation methodology for building software applications was alled component-based development (CBD). In CBD,
The internal implementation of a component may use multiple classes that collectively provide the implementation of the external specification. The classes could use one or more design patterns, thereby leveraging the advantages of 00 principles. In SOA, the main emphasis is on the dentification of the right services followed by their specification and realization. Although some might argue that object-oriented analysis and design (OOAD) techniques can be used as a good starting point for services, its main emphasis is on microlevel abstractions.
Services, on the other hand, are business-aligned entities and therefore are at a much higher level of abstraction than are objects and components. 57 58 A Methodology for Semce Modeling and Design The main first-class constructs in an SOA are serv’ices, service components, and process flows. For the sake of brevity, we refer to process flows as just flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.
Service-oriented modeling and design is a discipline that provides prescriptive guidance about how to effectively design an SOA using services, service components, and flows. Rational Software, now a part of IBM, has provided an extension to Rational Unified Process (RUP) called RUP-SOMA (See the «References» section), which is built on a service- sis and design technique developed bv IBM called S Modeling and Modeling and Architecture (SOMA). The rest of this chapter takes you through the SOMA technique and explains how it helps in the identification, specification, and realization of services, service components, and flows. . 1 An SOA Reference Architecture When defining a service-oriented solution, it makes sense to keep a reference architecture in context—an architecture that establishes the building blocks of SOA: services, service components, and flows that collectively support enterprise business processes and the business goals. The reference architecture provides characteristics and definitions for each ‘ayer nd the relatlonships between them and assists in the placement of the architectural building blocks onto each layer.
This ayering facilitates the creation of architectural blueprints in SOA and helps in reusability of solutions and assets within an industry and potentially across industry verticals. Figure 4-1 shows a sample logical SOA reference architecture. Service consumer AU. I Channel 823 Integration layer (Enterprise Service Bus) Consumers layer Business process layer Composition; choreography; business state machines Information architecture layer (metadata and business intelligence) QoS layer (security, management, and monitoring nfrastructure semices) Governance laver layers and four vertical layers.
The horizontal layers follow the basic principle of a layered architecture model in which 59 architecture building blocks (ABB) from layers above can access ABBs from layers below, whereas layers below may not access Agas from layers above. The vertical layers usually contain Agas that are cross-cutting in nature, which implies that they may be applicable to and used by ABBs in one or more of the horizontal layers. This can also be called a partial layered archltecture because any layer above does not need to strictly interact with lements from its immediate Iower layer.
For example, a specific access channel can directly access a semice rather than needing to go through a business process. The access constraints, however, are dictated by the architectural Style, guidelines, and principles that apply to a given SOA solution. This View ofthe SOA reference architecture is independent of any specific technology implementation, and hence is a logical view. Instantes of this logical architecture can be developed for a specific platform and technology.
Following are definitions of each of the layers: • Layer 1 : Operational systems—This layer includes the operational ystems that exist in the current IT environment of the enterprise, supporting business activities. Operational systems include all custom applications, packaged applications, legacy systems, transaction-processing systems, and the various databases. • Layer 2: Service component layer—Components in this layer conform to the contracts defined by services in the services layer.
A service component may realize one or more services. A service component provides services layer. A service component may realize one or more services. A seruice component provides an implementation façade that aggregates functionality from multiple, possible isparate, operatlonal systems while hiding the integration and access complexities from the service that is exposed to the consumer. The consumer thus is oblivious of the semice component, which encapsulates the implementation complexities.
The advantage of this façade component comes from the flexibility of changing operational systems without affecting the service definition. The service component provides an enforcement point for service realization to ensure quality of service (QoS) and compliance to service level agreements. • Layer 3: Semces layer—This layer include all the services defined in he enterprise service portfolio. The definition of each service, which constitutes both its syntactic and semantic information, is defined in this layer.
Whereas the syntactic information is essentially around the operations on each service, the input and output messages, and the definition of the semice faults, the semantic information is around the service policies, service management decisions, seruice access requirements, and so on. The services are defined in such a way that they are accessible to and invocable by channels and consumers independent of implementation and the transport protocol. The critical Step is the dentification of the services using the various techniques that can be employed for the same.
The methodology that we focus on in this chapter addresses such identification techniques. • Cayer 4: Business process layer—3usiness processes depict how the business runs. A business process is an IT s OF Business process layer—gusiness processes depict how the business runs. A business process is an IT representation of the various activities coordinated and collaborated in an enterprise to perform a speclfic high-level business function. This layer represents the processes as an orchestration or a composition f loosely coupled services—leveraging the services represented in the services layer.
The layer is also responsible for the entire lifecycle management of the processes along with 60 their orchestration, and choreography. The data and information flow between steps within each process is also represented in this layer. Processes represented in this layer are the connection medium between business requirements and their manifestation as IT-level solutions using ABBs from other horizontal and vertical layers in the architecture stack. Users, channels, and B2B partner systems in the consumer layer uses the business processes in his layer as one of the ways to invoke application functionality. ?? Layer 5: Consumer layer—This layer depicts the various channels through which the IT functions are delivered. The channels can be in the form of different user types (for example, external and internal consumers who access application functionality through access mechanisms like B2B systems, portals, rich clients, and other forms). The goal of this layer is to standardize on the access protocol and data format to enable the quick creation of front ends to the business processes and services exposed from the layers below.
Some such standards have emerged in the form of portlets, service compone e (SCA) com 6 OF standards have emerged in the form of portlets, service component architecture (SCA) components, and Web Services for Remote Portlets (WSRP). The adherence to standard mechanisms for developing the presentation layer components for the business processes and services helps in providing template solutions in the form of standard architecture patterns, which helps the developer community to adopt common front•end patterns for service consumption. ?? Cayer 6: Integration layer —This layer provides the capability for service consumers to ocate service providers and initiate service invocations. Through the three basic capabilities of mediation, routing, and data and protocol transformation, this layer helps foster a service ecosystem wherein services can communicate with each other while being a part of a business process. The key nonfunctional requirements such as security, latency, and quality of service between adjacent layers in the reference architecture are implemented by the architecture building blocks in this layer.
The functions of this layer are typically and increasingly being collectively defined as the enterprise service bus (ESB). An ESB is a collection of architecture patterns that uses open standards and protocols to implement the three basic capabilities ofthis layer and provide a ‘ayer of indirection between the service consumers and the service provider by exposing the services only through the ESB. ESB products usually add some specialized features to provide differentiated capabilities in the marketplace.
The integration capabilities are most commonly used by ABBs residing between Layer 2 through Cayer 5. As an example, in Layer 5 there can be many consumers accessing e Layer 2 through Cayer 5. As an example, in Layer 5 there can be any consumers accessing enterprise services through diferent channel types. Each channel type can use different protocols— HTML WMI_ (for mobile users), and Voice XML (for IVR users), to name a few.
Each of these protocols and message formats may be passed through an Extensible Stylesheet Language Transformations (XSLT) engine befare the actual service is invoked. This XSLT transform is usually an ESB-provided feature. The beauty of the ESB-based integration layer is that any feature or function that can be exposed in a manner that follows open standards and protocols for access can be plugged into the ESB so hat it is enabled to take part in a servicebased ecosystem. Figure 4-2 depicts a logical View of the ESB. 1 Business Services Interaction Process Information Security ESB Registry Business Services Partner Business App Access Figure 4-2 Logical View of an ESB in the integration layer As Figure 4-2 suggests, the ESB provides capabilities for sewice consumers and providers to connect to each other, for services to be discovered using the registry, for services to be managed and for secure invocations, and provides application programming interfaces ( e the development of semice connectivity. ?? Laye —This layer focuses on he building of the first-class SOA constructs adds some inherent challenges that are nontrivial to address. The challenges arise while trying to comply with the essential tenets of SOA: abstraction, open standards and protocols, distributed computing, heterogeneous computing infrastructures, federated service ecosystem, and so on- Adherence to these compliance requirements often makes the implementation of the NFRs that much more complicated. This layer provides the infrastructure capabilities to realize the NFRs.
It captures the data elements that provide the information around noncompliance to NFRs at each of the horizontal layers. Standard NFRs that it monitors for noncompliance is security, availability, scalability, and reliability. • Layer 8: Informatlon architecture layer—Thls layer ensures a proper representation of the data and information that is required in an SOA The data architecture and the information architecture representation (along with its key considerations and guidelines for its design and usage) at each specific horizontal layer are the responsibilities of this layer.
Industry models (for example, ACORD, IAA, JXDD) and their usage to define the information architecture, along with business protocols used to xchange business Management IT Management Services Development Semices 62 A Methodology for Semice Des ‘gn layer—This layer ensures the proper management ofthe entire lifecycle of the services. It is responsible for prioritizing which high-value services should be implemented, for each of the layers in the architecture, and for providing a rationalization based on how the sem•ice satisfies a business or IT goal of the enterprise.
Enforcing both design-time and runtime policies that the services should implement and conform to is one of the key responsibilities of this layer. Essentially, this layer rovides a framework that efficiently oversees the design and implementation of services so that they comply with the various business and IT regulatory policies and requrements. Chapter 3, «SOA Governance,» discusses SOA governance and the responsibilities of a governance councll in detail.
Those responsibilities all feature in this layer of the reference architecture. It is worth noting that one ofthe primary reasons for the SOA solution stack representation is that it helps to communicate, to the business and IT stakeholders, the evolution and realization of the enterprises SOA vision and roadmap hrough iterative implementation. Communicating with the stakeholders is key to ensure that the business commitment is pervasive across the various phases of an SOA initiative.
The methodology that we discuss in this chapter WII help in identifying, specifying, and realizing the first-class constructs of an SOA and their placement in the various layers of the architecture stack. This logical View of the SOA reference architecture is also known as the SOA solution stack or just the solution stack. Therefore, the terms SOA reference architecture, SOA solution stack, and solution stack all refer to the s