1. 王林章 软件工程组 南京大学计算机科学与技术系 lzwang@nju.edu.cn http://cs.nju.edu.cn/lzwang Service-Oriented Architecture

2. Why SOA ？ IT 现状  不同种类的操作系统，应用软件，系统软件和应用基 础结构（ application infrastructure ）相互交织  一些现存的应用程序被用来处理当前的业务流程（ business processes ），因此从头建立一个新的基础 环境是不可能的。 面临的问题  业务的不断变化需要企业做出快速的反应  需要复用现有的应用程序和应用基础设施（ application infrastructure ）  为客户，商业伙伴以及供应商提供新的互动渠道

3. The business drivers for a new approach While IT executives have been facing the challenge of  cutting costs  maximizing the utilization of existing technology At the same time they have to  continuously strive to serve customers better  be more competitive  be more responsive to the business’s strategic priorities. There are two underlying themes behind all of these pressures: Heterogeneity and change

4. The business drivers for a new approach Heterogeneity  Most enterprises today contain a range of different systems, applications, and architectures of different ages and technologies.  Integrating products from multiple vendors and across different platforms were almost always a nightmare.  But we also cannot afford to take a single-vendor approach to IT, because application suites and the supporting infrastructure are so inflexible. Change  Globalization and e-business are accelerating the pace of change.  Improvements in technology continue to accelerate, feeding the increased pace of changing customer requirements.

5. The business drivers for a new approach As a result, business organizations are evolving  from the vertical, isolated business divisions of the 1980’s and earlier  to the horizontal business-process-focused structures of the 1980’s and 1990’s  towards the new ecosystem business paradigm. Business services now need to be componentized and distributed. There is a focus on the extended supply chain, enabling customer and partner access to business services.

6. The business drivers for a new approach Questions:  How do I make my IT environment more flexible and responsive to the ever changing business requirements?  How can we make those heterogeneous systems and applications communicate as seamlessly as possible?  How can we achieve the business objective without bankrupting the enterprise? Currently many IT executives and professionals alike believe that now we are getting really close to providing a satisfactory answer with service-oriented architecture.

7. The business drivers for a new approach In order to alleviate the problems of heterogeneity, interoperability and ever changing requirements, such an architecture should provide a platform for building application services with the following characteristics:  Loosely coupled  Location transparent  Protocol independent Based on such a service-oriented architecture, a service consumer does not even have to care about a particular service it is communicating with because the underlying infrastructure, or service “bus”, will make an appropriate choice on behalf of the consumer.  The infrastructure hides as many technicalities as possible from a requestor. Particularly technical specificities from different implementation technologies such as J2EE or.NET should not affect the SOA users.  We should also be able to reconsider and substitute a “better” service implementation if one is available, and with better quality of service characteristics.

8. Object-oriented analysis and design  Larman describes the essence of the object-oriented analysis and design as considering “a problem domain and logical solution from the perspective of objects (things, concepts, or entities)” in Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design.  Jacobson, et al, define these objects as being “characterized by a number of operations and a state that remembers the effects of these operations” in Object-Oriented Software Engineering: A Use Case Driven Approach. In object-oriented analysis, such objects are identified and described in the problem domain, while in object-oriented design, they are transitioned into logical software objects that will ultimately be implemented in a object-oriented programming language.  With object-oriented analysis and design, certain aspects of the object (or group of objects) can be encapsulated to simplify the analysis of complex business scenarios.  Certain characteristics of the object(s) can also be abstracted so that only the important or essential aspects are captured, in order to reduce complexity.

9. Component-based design Component-based design is not a new technology. It is naturally evolved from the object paradigm.  Packaged solution suites can also be encapsulated as such “components”. Once the organization achieves a higher level of architectural maturity based on distinctly separate functional components, the applications that support the business can be partitioned into a set of increasingly larger grained components.  Components can be seen as the mechanism to package, manage and expose services.  They can use a set of technologies in concert: Large- grained enterprise components, that implement business- level use-cases, can be implemented using newer object- oriented software development in combination with legacy systems.

10. Service-oriented design In Component-Based Development for Enterprise Systems, Allen includes the notion of services, describing a component as  “an executable unit of code that provides physical black- box encapsulation of related services. Its service can only be accessed through a consistent, published interface that includes an interaction standard. A component must be capable of being connected to other components (through a communications interface) to a larger group”. A service is generally implemented as a course- grained, discoverable software entity that exists as a single instance and interacts with applications and other services through a loosely coupled, message- based communication model.

11. SOA SOA 的理念最初由全球最具权威的 IT 研究与顾问 咨询公司 Gartner 于 1996 年提出：  “A service-oriented architecture is a style of multitier computing that helps organizations share logic and data among multiple applications and usage modes.” 。

12. SOA OASIS defines SOA as the following:  A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

13. Wikipedia In computing, the term Service-Oriented Architecture (SOA) expresses a perspective of software architecture that defines the use of services to support the requirements of software users. In an SOA environment, resources on a network are made available as independent services that can be accessed without knowledge of their underlying platform implementation 。 SOA

14. 在计算领域，面向服务的体系结构表示这样一种 软件体系结构，它定义使用服务来满足软件用户 的需求。在一个 SOA 环境下，网络上的资源是以 独立可访问的服务存在的，访问这些服务不需要 了解它们的底层平台实现细节。 “ 一种应用程序体系结构，在这种体系结构中， 所有功能都定义为独立的服务，这些服务带有定 义明确的可调用接口，可以以定义好的顺序调用 这些服务来形成业务流程 ” 。

15. SOA 面向服务的体系结构 (SOA) 是一个组件模型，它 将应用程序的不同功能单元 ( 称为服务 ) 通过这些 服务之间定义良好的接口和契约联系起来。接口 是采用中立的方式进行定义的，它应该独立于实 现服务的硬件平台、操作系统和编程语言。这使 得构建在各种各样的系统中的服务可以以一种统 一和通用的方式进行交互。

16. Service-oriented design important service-oriented terminology:  Services: Logical entities, the contracts defined by one or more published interfaces.  Service provider: The software entity that implements a service specification.  Service consumer (or requestor): The software entity that calls a service provider. Traditionally, this is termed a “client”. A service consumer can be an end-user application or another service. –Service locator: A specific kind of service provider that acts as a registry and allows for the lookup of service provider interfaces and service locations. –Service broker: A specific kind of service provider that can pass on service requests to one or more additional service providers.

17. Interface-based design In both component and service development, the design of the interfaces is done such that a software entity implements and exposes a key part of its definition.  Therefore, the notion and concept of “interface” is key to successful design in both component-based and service-oriented systems. The following are some key interface-related definitions:  Interface: Defines a set of public method signatures, logically grouped but providing no implementation. An interface defines a contract between the requestor and provider of a service. Any implementation of an interface must provide all methods.  Published interface: An interface that is uniquely identifiable and made available through a registry for clients to dynamically discover.  Public interface: An interface that is available for clients to use but is not published, thus requiring static knowledge on the part of the client.  Dual interface: Frequently interfaces are developed as pairs such that one interface depends on another; for example, a client must implement an interface to call a requestor because the client interface provides some callback mechanism.

18. Interface-based design The following figure shows the UML definition of a customer relationship management (CRM) service, represented as a UML component, that implements the interfaces AccountManagement, ContactManagement, and SystemsManagement.  Only the first two of these are published interfaces, although the latter is a public interface.  Note that the SystemsManagement interface and ManagementService interface form a dual interface.

19. Layered application architectures Object-oriented technology and languages are great ways to implement components. While components are the best way to implement services, though one has to understand that a good component-based application does not necessarily make an good service-oriented application.  The term “the application edge” reflects the fact that a service is a great way to expose an external view of a system, with internal reuse and composition using traditional component design.

20. A closer look at service-oriented architecture Service-oriented architecture presents an approach for building distributed systems that deliver application functionality as services to either end- user applications or other services. It is comprised of elements that can be categorized into functional and quality of service.

21. A closer look at service-oriented architecture Functional aspects include:  Transport is the mechanism used to move service requests from the service consumer to the service provider, and service responses from the service provider to the service consumer.  Service Communication Protocol is an agreed mechanism that the service provider and the service consumer use to communicate what is being requested and what is being returned.  Service Description is an agreed schema for describing what the service is, how it should be invoked, and what data is required to invoke the service successfully.  Service describes an actual service that is made available for use.  Business Process is a collection of services, invoked in a particular sequence with a particular set of rules, to meet a business requirement. Note that a business process could be considered a service in its own right, which leads to the idea that business processes may be composed of services of different granularities.  The Service Registry is a repository of service and data descriptions which may be used by service providers to publish their services, and service consumers to discover or find available services. The service registry may provide other functions to services that require a centralized repository.

22. A closer look at service-oriented architecture Quality of service aspects include:  Policy is a set of conditions or rules under which a service provider makes the service available to consumers. There are aspects of policy which are functional, and aspects which relate to quality of service; therefore we have the policy function in both functional and quality of service areas.  Security is the set of rules that might be applied to the identification, authorization, and access control of service consumers invoking services.  Transaction is the set of attributes that might be applied to a group of services to deliver a consistent result. For example, if a group of three services are to be used to complete a business function, all must complete or none must complete.  Management is the set of attributes that might be applied to managing the services provided or consumed.

23. SOA collaborations The following figure shows the collaborations in a service-oriented architecture. The collaborations follows the “find, bind and invoke” paradigm.  A service consumer performs dynamic service location by querying the service registry for a service that matches its criteria.  If the service exists, the registry provides the consumer with the interface contract and the endpoint address for the service.

24. SOA collaborations The roles in a service-oriented architecture are:  Service consumer: The service consumer is an application, a software module or another service that requires a service. It initiates the enquiry of the service in the registry, binds to the service over a transport, and executes the service function. The service consumer executes the service according to the interface contract.  Service provider: The service provider is a network- addressable entity that accepts and executes requests from consumers. It publishes its services and interface contract to the service registry so that the service consumer can discover and access the service.  Service registry: A service registry is the enabler for service discovery. It contains a repository of available services and allows for the lookup of service provider interfaces to interested service consumers. Each entity in the service-oriented architecture can play one (or more) of the three roles of service provider, consumer and registry.

25. SOA collaborations The operations in a service-oriented architecture are:  Publish: To be accessible, a service description must be published so that it can be discovered and invoked by a service consumer.  Find: A service requestor locates a service by querying the service registry for a service that meets its criteria.  Bind and invoke: After retrieving the service description, the service consumer proceeds to invoke the service according to the information in the service description. The artifacts in a service-oriented architecture are:  Service: A service that is made available for use through a published interface that allows it to be invoked by the service consumer.  Service description: A service description specifies the way a service consumer will interact with the service provider. It specifies the format of the request and response from the service. This description may specify a set of preconditions, post conditions and/or quality of service (QoS) levels.

26. SOA collaborations In addition to dynamic service discovery and definition of a service interface contract, a service-oriented architecture has the following characteristics:  Services are self-contained and modular.  Services support interoperability.  Services are loosely coupled.  Services are location-transparent.  Services are composite modules, comprised of components. These characteristics are also central to fulfilling the requirements for an e-business on demand™ operational environment. Finally, service-oriented architecture is not a new notion.

27. Services vs. components A service is a coarse-grained processing unit that consumes and produces sets of objects passed-by-value.  It is not the same as an object in programming language terms. Instead, it is perhaps closer to the concept of a business transaction such as a CICS® or IMS™ transaction than to a remote CORBA object. A service consists of a collection of components that work in concert to deliver the business function that the service represents.  Thus, in comparison, components are finer-grained than services.  In addition, while a service maps to a business function, a component typically maps to business entities and the business rules that operate on them. As an example, let us look at the Purchase Order component model for the WS-I Supply Chain Management sample.

28. Services vs. components In a component-based design, components are created to closely match business entities (such as Customer, Purchase Order, Order Item) and encapsulate the behavior that matches the entities’ expected behavior.  Purchase Order component provides functions to obtain information about the list of products ordered and the total amount of the order  Item component provides functions to obtain information about the quantity and price of the product ordered. In a service-oriented design, services are not designed based on business entities. Instead, each service is a holistic unit that manages operations across a set of business entities. –For example, a customer service will respond to any request from any other system or service that needs to access customer information. –The customer service can process a request to update customer information; add, update, delete investment portfolios; and enquire about the customer’s order history. –The customer service owns all the data related to the customers it is managing and is capable of making other service inquiries on behalf of the calling party in order to provide a unified customer service view. –This means a service is a manager object that creates and manages its set components.

29. Service-oriented architecture benefits With a service-oriented architecture, we can realize several benefits to help organizations succeed in the dynamic business landscape of today:  Leverage existing assets.  Easier to integrate and manage complexity.  More responsive and faster time-to-market.  Reduce cost and increase reuse.  Be ready for what lies ahead. Service-oriented architecture is by no means a silver bullet, and migration to SOA is not an easy task. Rather than migrating the whole enterprise to a service-oriented architecture overnight, the recommended approach is to migrate an appropriate subset of business functions as the business need arises or is anticipated.

30. Service-Oriented Architecture Architecture Classification for SOA-Based Applications W.T. Tsai, Chun Fan, Yinong Chen  Arizona State University ， Tempe, AZ 85287  {wtsai, fanchun, yinong}@asu.edu Raymond Paul  Department of Defense, Washington, DC  Raymond.Paul@osd.mil Jen-Yao Chung  IBM T. J. Watson, Research Center  jychung@us.ibm.com

31. Service-Oriented Architecture The architecture of SOA-based applications is different from traditional software architecture where the architecture is mainly static.  The architecture of an SOA-based application is dynamic, i.e., the application may be composed at runtime using existing services. Thus SOA has provided a new direction for software architecture study, where the architecture is determined at runtime and architecture can be dynamically changed at runtime to meet the new software requirements. Thus a target application is built through service discovery and composing instead of traditional process of designing and coding software.

32. Service-Oriented Architecture SOA software has the following characteristics that are different from traditional software: Standard-based Interoperability  SOA emphasizes on stand-based interface, protocols, communication, coordination, workflow, discovery, collaboration, and publishing via standard protocols such as XML, SOAP, WSDL, UDDI, HTTP, CPP, ebXML, ebSOA, BPEL, FERA, and OWL-S.  These standards allow services developed on different platforms can interoperate with each other with the knowledge of service specifications only. Dynamic Composition via Discovery  SOA provides a new way of application development by using services just discovered. Furthermore, the composition and discovery can be carried out at runtime.

33. Service-Oriented Architecture Dynamic Governance and Orchestration  Execution of services needs to be controlled and several mechanisms are available. One is service governance by policy. More specifically, policies can be specified, checked, and enforced during development time and at runtime.  The other is orchestration where process execution will be coordinated by a central controller and it is responsible for scheduling the execution of services that may be distributed across a connectivity network such as ESB (Enterprise Service Bus).

34. Service-Oriented Architecture Architecture of SOA applications, including IBM SOA Foundation architecture, Microsoft’s Whitehorse, SAP’s NetWeaver, OASIS’s FERA and various enterprise SOA applications such as Enterprise SOA and Service-Oriented Enterprise.

35. Application Architecture Issues Due to dynamic nature of SOA, the architecture of SOA-based applications has the following characteristics that are distinct from traditional software architectures:  Dynamic architecture and dynamic re-architecture  Lifecycle management embedded in the operation infrastructure architecture In traditional software design, the architecture can not be changed after its deployment. In SOA, the basic building block is not a component but a service. Services are usually connected to a bus-like communication backbone such as an ESB (Enterprise Service Bus). Communications among the services are controlled by a control center, which is also attached to the communication backbone.

36. Application Architecture Issues This new approach allows new services to be added into the system without stopping the application. Furthermore, a new application can be composed from the existing services by just changing the workflow specification without changing the basic SOA framework.

37. Application Architecture Issues IBM SOA Foundation architecture consists of stages: modeling, assembling, deployment, and management. Furthermore, runtime governance activities are performed to provide guidance and oversight for the target SOA application. The activities in the four stages are performed iteratively.  Modeling: Gather requirements and establish the application model to represent the system using a set of services.  Assembling: The designer can either create required services from scratch or find an existing service from a service broker to develop the application according to the model constructed.  Deployment: The runtime environment is configured to meet the application’s requirements, and the application is deployed into that environment for execution.  Management: After the application is deployed, the services used in the application are provisioned and monitored for information needed to prevent, isolate, diagnose, and fix any problem that might occur during application runtime.

38. SOA Architecture Classification SOA Architecture Classification (SOAC) for SOA-based applications, which is based on four parameters:  The structure of the application. It can be either static or dynamic.  The runtime re-composition capability. If the architecture can support runtime re-composition, services in the applications using this type of architectures can be replaced by some other services to meet changing requirements or to fix runtime failures. Note that it is not necessary to classify an architecture base on dynamic composition as this is already a part of SOA definition.  The fault-tolerance capability. This can be further decomposed into two sub-factors: fault-tolerant control center and fault-tolerant communication backbone.  The system engineering support for SOA applications will be needed as a part of the lifecycle management. Some sample system engineering support includes model-based development, policy specification and enforcement, completeness and consistency checking, model checking, simulation, reliability assessment, automated code generation, monitoring, and data collection.

39. SOA Architecture Classification With these parameters, one can specify the classification of an SOA application using a tuple (Structure, Re-composition, Fault-tolerance, System engineering), where  Structure: an application can have S (for static structure) or D (dynamic structure), but not both;  Re-composition: an application can have R (for with dynamic re- composition capability) or N (for without it), but not both;  Fault-tolerance: an application can have FB (faulttolerant communication backbone), FC (faulttolerant control services), or FN (no faulttolerance);  System engineering support: SOA application architecture has the SOSE supports, it is denoted with SY. On the contrary if an SOA application architecture has no SOSE support, it is denoted with SN.

40. SOA Architecture Classification (S,N,FN,SN) Architecture  Once the application is deployed, it cannot be changed or recomposed. (D,N,FN,SN) Architecture  Services are connected to the shared communication backbone.  These services are loosely coupled such that an individual service does not need to know the details or even the existences of other services.  The dynamic composition as well as orchestration will be managed by Application Composition Manager.  The workflow specification defines the execution sequence of services to deliver the desired functionalities.

41. SOA Architecture Classification (D,R,FN,SN) Architecture  In this way, after the application is deployed, the Data Collection service will keep on monitoring the behaviors of the participating services and collect data at runtime.  The data collected will be continuously analyzed to decide if it is necessary to trigger a reconfiguration.  If a reconfiguration is triggered, the application specification including the workflows and participating services will be dynamically updated according to the reconfiguration policy. (D,R,FC,SN) Architecture  The control center is now more complex as it not only needs to keep track of the status of participating services, but also needs to check itself continuously to ensure the control center can tolerate its own faults.

42. SOA Architecture Classification (D,R,FB/FC,SN) Architecture  In the previous architecture, the control center is fault tolerant, but failures occurred in the communication backbone are not handled.  Since the control center is also built on top of the communication backbone, i.e., it uses the backbone for communication.  In this case, if the backbone fails, the fault-tolerant control center will fail too.  The communication backbone can be a computing platform, such as.NET, or ESB. Microsoft developed a reliable messaging service called Indigo that provides fault-tolerant communications between services.  ESB is essentially a service-oriented middleware that allows services to communicate with each other. (D,R,XX,SY) Architecture  In (D, R, XX, SY), if X and Y are variables, it introduces a family in which different system engineering supports are added to the operation infrastructure.  IBM SOA Foundation architecture includes modeling/specification, verification and validation, assembling, deployment, and management.  Automated tools can help tune the deployment environment and deploy the application into the tuned environment.

43. SOA Architecture Classification Evaluation criteria for the different architectures:  Complexity: The architecture complexity will increase as we move the architecture from the top to the bottom and from the left to the right in the architecture roadmap. Thus (S, N, FN, SN) is the simplest architecture and the (D, R, FB/FC, SY) is the most complex one.  Dependability: If the fault-tolerant mechanisms are implemented properly, the dependability should enhance as we move the architecture from top to bottom and from left to right of the map, because more and more fault-tolerance capabilities areintroduced into the architectures.  Efficiency: As the complexity increases, the efficiency can decrease if additional resources and computation power outperform the benefit. Evaluation is necessary to evaluate the efficiency.  Adaptability: Architecture styles with the recomposition capability have higher adaptability than those without the capability. Thus the adaptability should increase when the architecture moves from the top to the bottom and from the left towards the right of the map. Higher adaptabilityalso indicates the better self-monitoring, selfhealing, and self-governing capabilities.

44. SOA Architecture Classification  Difficulty to implement: The simplest architecture style is the easiest one to use because it doesn’t require many complex techniques.  Cost of Development: The architecture that is the easiest to implement has the lowest development cost.  Cost of Maintenance: As one advances from the top towards the bottom of the SOA application architecture roadmap, one can see that the architecture styles near the bottom have more selfmonitoring, self-governing, and self-healing capabilities. Thus the cost of maintenance will decrease accordingly. On the other hand, the increasing complexity can increase the maintenance cost. Careful evaluation is needed.  System engineering support: SOSE supports are vital to deliver better SOA applications and services, especially at enterprise level. Automated tools shall be adopted to facilitate these supports. Obviously SY > SP > SN.

45. Recent SOA Application Architectures IBM WebSphere  WebSphere Integration Reference Architecture aims at providing a comprehensive set of services to enable business integration in a large diverse enterprise environment.  and WebSphere Integration Reference Architecture, WebSphere architecture is (D, R, FN, SN) according to the SAC, and an SOA application using this architecture can be monitored after deployment.

46. Recent SOA Application Architectures OASIS FERA  FERA (Federated Enterprise Reference Architecture) presents a set of principles and guidelines for the development and deployment of an SOA application with loosely coupled collaboration.  FERA is an (D, N, FN, SN) architecture according to the SAC.

47. Recent SOA Application Architectures Process Embedded SOA Infrastructure  The Process-Embedded Service-Oriented Infrastructure (PESOI) is an approach that integrates development and operation infrastructure into the application developed. This approach

48. SOA 特征 服务功能实体的根本独立性 ; 大量数据低频访问 基于文本的消息传递 使用开放的标准 ; 平台中性，不受平台限制 ; 跨平台 ; 组合性 ; 扩展性 ; 重复使用性 ; 抽象性.

49. 提供服务级别的重用 应用程序通信简单 模块化，面向事件，接口组件化编程 使用户无需关注服务实现细节，服务可以运行于 任意平台，使服务重用最大化 服务开发和维护简单 服务是抽象的、可组合、可发现、松耦合、可重 用、无状态、自主的 SOA 优点

50. 可通过互联网服务器发布，从而突破企业内网的限制，实现与供应 链上下游伙伴业务的紧密结合。通过 SOA 架构，企业可以与其业务 伙伴直接建立新渠道，建立新伙伴的成本得以降低。 与平台无关，减少了业务应用实现的限制。要将企业的业务伙伴整 合到企业的 “ 大 ” 业务系统中，对其业务伙伴具体采用什么技术没有 限制。 具有低耦合性特点，增加和减少业务伙伴对整个业务系统的影响较 低。在企业与各业务伙伴关系不断发生变化的情况下，节省的费用 会越来越多。 具有可按模块分阶段进行实施的优势。可以成功一步再做下一步， 将实施对企业的冲击减少到最小。

51. 管理服务元数据 缺少实际测试 安全分层 互通性 服务粒度 不一定能提高系统灵活性、降低成本和开发时间 SOA 挑战

52. Summary SOA-based applications have dynamic instead of static architecture, and thus they have drastically different characteristics than traditional software architecture.