上周举行了IBM的第二届IMPACT SOA会议，与会者超过6000人。在早间的会议中，IBM高管重申这一观点：SOA所带来的主要创新是业务/IT的一致性。他们给出了一个以业务过程为中心的视图，其中SOA是使企业变得灵活的触发器。同时，他们还介绍了IBM的Smart SOA视图，它是一组以大量客户SOA部署经验为基础的SOA原则/成熟度模型。会议期间，IBM也请求从业者贡献他们关于SOA的想法。贡献者可通过在线的思想共享站点——SOA JAM给出他们的想法，该活动已于上周4结束。本文对几次在线访谈、第一天和第二天的早间会议，以及新闻发布会进行了总结。

IBM软件集团副总裁 Steve Mills解释了问题的根源以及SOA是如何改变业务的：

随着互联网运动于94年拉开序幕，我们解决了全球范围内人与应用、人与他人互联的问题。随之出现的是一组关于开放架构的概念，人们在超过3千万个Web服务器之间穿行……按你的方式去调用服务把事情完成。大约在2004年左右，SOA开始复苏。但是我们已经做了很长时间的集成。东西是新的，而且我认为事情是：业务相关的，而非技术相关的。调整业务和IT，把它们结合起来，在业务过程和业务流程环境下使用IT作为一种转换技术，围绕IT中的投资驱动价值显著地增长……SOA是一种强大的思想，而且是一种利用业务灵活性来节约长期成本、可在短期内实现的架构。

我们已经在垂直方向完成了自动化（整个20世纪，我们都在为企业垂直的生产部门使用打包的/自行开发的应用，通过人工来连接系统），对于21世纪的方式来说，在其中应用是过程的一个内容来源。允许运行时动态部署服务。

这种“SOA激活了端到端业务过程”的观点是围绕会议进行的主题。IBM将其视为企业执行模式的转变——不是通过点对点或无集成的方式让各个业务部门管理自己的IT系统，而是让他们将应用暴露成可供更广泛的企业过程（它们常常通过ESB组装而成）使用的资源。同时，寻求将跨部门业务过程的多个相似实现替换成整个公司都必须使用的一个服务的途径。这种围绕统一服务——它们受IT中心控制——进行的部门合并，IBM称之为“梳理企业”。

IBM还把许多商业公司客户邀请到讲台上，就如何实现新的跨各种异构IT系统的业务关键过程，讲述类似的案例。一个算不上完全“任务关键型”但是很切题的例子是在Harley Davidson（译注：世界著名的哈雷摩托品牌）实现的一个系统。它实现了一个骑车旅行自助系统，它能让你规划一次横跨美国的旅行，预定旅馆，获得GPS位置，预购为长途跋涉做准备的Harley Davidson齿轮，搜索和增加汽油站停靠点等等。Harley CIO Jim Haney解释说

SOA不是在谈技术。它讲的是你如何把那些令你头大的各个碎片装配在一起。它还涉及如何定义一个创造良好顾客体验的过程。

Jim以旅行地图应用为例对传统应用设计方法和新的SOA风格设计方法进行了比较。传统方法——他们会创建一个地图应用，“聚焦单一事务”——地图。客户想要的其他服务，如旅馆预定、搜索沿途有趣的事件/站点，会留给其他IT系统或单独的应用。

但是使用SOA风格思维模式，他们使用“客户透镜”而不是“IT透镜”进行观察，关注“规划一次摩托驾驶”，而不是事务个体。Jim解释说：

这需要文化的改变：不要只关注系统和应用。从开始到结束，客户是如何完成一个过程的？由按系统和应用去思考，转换到按客户完成一个过程所需做的事去思考。

InfoQ对SOA市场副总裁Sandy Carter进行了采访，她谈到IBM的Smart SOA视图/成熟度模型，并就这个范围内他们所看到的企业发表了意见：

根据Sandy的说法：

• 61%的公司尚在基础层面，在特定部门或业务部门实现SOA
• 30%的处于‘扩展的端到端’，其中已实现了跨部门的过程。Sandy给出了一个IBM自己的例子：“IBM内部有19条不同的供应链。当你将企业梳理后，只有一条供应链是所有人都参与的。”Sandy也提到了一个欧洲政府，它有不同的办事处，都分别实现了他们自己的护照处理程序。这个政府实现了一个护照处理服务，并让所有办事处都使用那个服务。
• 处于转换阶段的公司不到8%，在这个阶段，由于能按不断变化的市场需求快速改变现有的运行过程，因此已经获得了真正的灵活性。Sandy给出了一家英国保险公司的例子，他们一直在寻求改变他们的商业模型：不是让你按每月固定价格缴费，他们想让你按每天的驾驶和驾驶距离缴费。IBM开发副总裁 Craig Hayman称之为“现有运转中的企业过程策略变化的热部署”，它是IBM的BPM套件的特性之一。
• 3%公司能适应业务动态变化。这个模式中的企业可以配置事件处理和关联策略，可在运行时动态修改现有过程。

不少IBM高管提到IBM今年的重点是事件+策略这一最后区域。在Impact上，IBM展示了一款名为WebSphere Business Events的新产品，它可以让业务所有人定义模式和过滤器，结果会激活一个新过程。

另一个有趣的客户案例是Health Care services公司，它是全美第4大健康计划公司。他们的许多业务子集都是由拥有不同IT系统的各个组织完成的，它们是：资格（eligibility）、保险查询（benefit inquiry）、申请状态（claim status）等。在向SOA转变的过程中，他们构建了企业范围内的资格服务。现在系统中的10个不同应用使用一个资格服务。公司的Austin Waldron解释说：

转变并不容易，这些应用的所有人曾经自己做任何事情……转变把一部分IT内容从单个应用中移走，放入到一个集中化的架构组中……治理要确保组织的所有不同部分认同这种面向服务方法，使用它代替他们自己去做是个非常大的转变。

从各个部门到IT中心的服务转变被许多IBM的高管称为“梳理企业”。这里，你利用单个应用中不同角落的各种‘能力’，你必须确保对于整个端到端过程有相同的健壮性。Steve Mills称这为“过程集成”，解释它“给环境带来了很多压力，需要补偿、修正和回滚等特性”。Steve认为这正是IBM与业内其它公司的区别所在。

在两天的会议中，IBM还介绍了5个SOA最佳实践，它是对超过6000家客户部署和250个案例研究的经验总结：

1. 从一开始就联结业务和IT。首先确定业务愿景，然后看IT如何支持它。
2. 开发一个服务于未来愿景的架构。不仅仅是满足一个过程或一个LOB，而是可以经历时间考验的东西。
3. 技巧、文化、治理。
4. 伸缩性和过程集成——你计划如何应对峰值？
5. 如何保持端到端的运营可视化？

随着越来越多的部门被卷入到SOA来，分析师称SOA的开销在2008年将加倍。今年的IBM Impact也庆祝了Websphere的10周年、IBM MQ的15周年和CIC的40周年。

                                                                   廖伟池
                                                                  2008-07-21

通过服务发现，得到可能成为服务的候选者列表。在服务规约阶段，规范性地描述服务各个方面的属性，形成作为业务和IT互动的服务契约。在服务实现阶段，进行服务、组件和服务组装的实现。

在进行面向服务的分析和设计时，服务发现阶段提取服务有三种方法：自顶向下、自底向上和中间汇聚。


                                                                                                                                   黄剑雄
                                                                                                                                      2008-07-12

An introduction to SOA

Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application's business logic or individual functions are modularized and presented as services for consumer/client applications. What's key to these services is their loosely coupled nature; i.e., the service interface is independent of the implementation. Application developers or system integrators can build applications by composing one or more services without knowing the services' underlying implementations. For example, a service can be implemented either in .Net or J2EE, and the application consuming the service can be on a different platform or language.

Service-oriented architectures have the following key characteristics:

·         SOA services have self-describing interfaces in platform-independent XML documents. Web Services Description Language (WSDL) is the standard used to describe the services.

·         SOA services communicate with messages formally defined via XML Schema (also called XSD). Communication among consumers and providers or services typically happens in heterogeneous environments, with little or no knowledge about the provider. Messages between services can be viewed as key business documents processed in an enterprise.

·         SOA services are maintained in the enterprise by a registry that acts as a directory listing. Applications can look up the services in the registry and invoke the service. Universal Description, Definition, and Integration (UDDI) is the standard used for service registry.

·         Each SOA service has a quality of service (QoS) associated with it. Some of the key QoS elements are security requirements, such as authentication and authorization, reliable messaging, and policies regarding who can invoke services.

Why SOA?

The reality in IT enterprises is that infrastructure is heterogeneous across operating systems, applications, system software, and application infrastructure. Some existing applications are used to run current business processes, so starting from scratch to build new infrastructure isn't an option. Enterprises should quickly respond to business changes with agility; leverage existing investments in applications and application infrastructure to address newer business requirements; support new channels of interactions with customers, partners, and suppliers; and feature an architecture that supports organic business. SOA with its loosely coupled nature allows enterprises to plug in new services or upgrade existing services in a granular fashion to address the new business requirements, provides the option to make the services consumable across different channels, and exposes the existing enterprise and legacy applications as services, thereby safeguarding existing IT infrastructure investments.

As in Figure 1's example, an enterprise employing SOA could create a supply chain composite application using a set of existing applications that expose the functionality via standard interfaces.

Figure 1. Supply chain application. Click on thumbnail to view full-sized image.

Service architecture

To implement SOA, enterprises need a service architecture, an example of which is shown in Figure 2.

Figure 2. A sample service architecture. Click on thumbnail to view full-sized image.

In Figure 2, several service consumers can invoke services by sending messages. These messages are typically transformed and routed by a service bus to an appropriate service implementation. This service architecture can provide a business rules engine that allows business rules to be incorporated in a service or across services. The service architecture also provides a service management infrastructure that manages services and activities like auditing, billing, and logging. In addition, the architecture offers enterprises the flexibility of having agile business processes, better addresses the regulatory requirements like Sarbanes Oxley (SOX), and changes individual services without affecting other services.

SOA infrastructure

To run and manage SOA applications, enterprises need an SOA infrastructure that is part of the SOA platform. An SOA infrastructure must support all the relevant standards and required runtime containers. A typical SOA infrastructure looks like Figure 3. The following sections discuss the infrastructure's individual pieces.

Figure 3. A typical SOA infrastructure. Click on thumbnail to view full-sized image.

SOAP, WSDL, UDDI

WSDL, UDDI, and SOAP are the fundamental pieces of the SOA infrastructure. WSDL is used to describe the service; UDDI, to register and look up the services; and SOAP, as a transport layer to send messages between service consumer and service provider. While SOAP is the default mechanism for Web services, alternative technologies accomplish other types of bindings for a service. A consumer can search for a service in the UDDI registry, get the WSDL for the service that has the description, and invoke the service using SOAP.

WS-I Basic Profile

WS-I Basic Profile, provided by the Web services Interoperability Organization, is turning into another core piece required for service testing and interoperability. Service providers can use the Basic Profile test suites to test a service's interoperability across different platforms and technologies.

J2EE and .Net

Though the J2EE and .Net platforms are the dominant development platforms for SOA applications, SOA is not by any means limited to these platforms. Platforms such as J2EE not only provide the framework for developers to naturally participate in the SOA, but also, by their inherent nature, bring a mature and proven infrastructure for scalability, reliability, availability, and performance to the SOA world. Newer specifications such as Java API for XML Binding (JAXB), used for mapping XML documents to Java classes, Java API for XML Registry (JAXR), used for interacting with the UDDI registries in a standard manner, and Java API for XML-based Remote Procedure Call (XML-RPC), used for invoking remote services in J2EE 1.4 facilitate the development and deployment of Web services that are portable across standard J2EE containers, while simultaneously interoperating with services across other platforms such as .Net.

Quality of services

Existing mission-critical systems in enterprises address advanced requirements such as security, reliability, and transactions. As enterprises start adopting service architecture as a vehicle for developing and deploying applications, basic Web services specifications like WSDL, SOAP, and UDDI aren't going to fulfill these advanced requirements. As mentioned previously, these requirements are also known as quality of services. Numerous specifications related to QoS are being worked out in standards bodies like the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS). Sections below discuss some of the QoS artifacts and related standards.

Security
The Web Services Security specification addresses message security. This specification focuses on credential exchange, message integrity, and message confidentiality. The attractive thing about this specification is it leverages existing security standards, such as Security Assertion Markup Language (SAML), and allows the usage of these standards to secure Web services messages. Web Services Security is an ongoing OASIS effort.

Reliability
In a typical SOA environment, several documents are exchanged between service consumers and service providers. Delivery of messages with characteristics like once-and-only-once delivery, at-most-once delivery, duplicate message elimination, guaranteed message delivery, and acknowledgment become important in mission-critical systems using service architecture. WS-Reliability and WS-ReliableMessaging are two standards that address the issues of reliable messaging. Both these standards are now part of OASIS.

Policy
Service providers sometimes require service consumers to communicate with certain policies. As an example, a service provider may require a Kerberos security token for accessing the service. These requirements are defined as policy assertions. A policy may consist of multiple assertions. WS-Policy standardizes how policies are to be communicated between service consumers and service providers.

Orchestration
As enterprises embark on service architecture, services can be used to integrate silos of data, applications, and components. Integrating applications means that the process requirements, such as asynchronous communication, parallel processing, data transformation, and compensation, must be standardized. BPEL4WS or WSBPEL (Web Services Business Process Execution Language) is an OASIS specification that addresses service orchestration, where business processes are created using a set of discrete services. WSBPEL is now part of OASIS.

Management
As the number of services and business processes exposed as services grow in the enterprise, a management infrastructure that lets the system administrators manage the services running in a heterogeneous environment becomes important. Web Services for Distributed Management (WSDM) will specify that any service implemented according to WSDM will be manageable by a WSDM-compliant management solution.

Other QoS attributes such as coordination between partners and transactions involving multiple services are being addressed in the WS-Coordination and WS-Transaction specifications, respectively, which are OASIS efforts as well.

SOA is not Web services

There seems to be general confusion about the relationship between SOA and Web services. In an April 2003 Gartner report, Yefim V. Natis makes the distinction as follows: "Web services are about technology specifications, whereas SOA is a software design principle. Notably, Web services' WSDL is an SOA-suitable interface definition standard: this is where Web services and SOA fundamentally connect." Fundamentally, SOA is an architectural pattern, while Web services are services implemented using a set of standards; Web services is one of the ways you can implement SOA. The benefit of implementing SOA with Web services is that you achieve a platform-neutral approach to accessing services and better interoperability as more and more vendors support more and more Web services specifications.

Benefits of SOA

While the SOA concept is fundamentally not new, SOA differs from existing distributed technologies in that most vendors accept it and have an application or platform suite that enables SOA. SOA, with a ubiquitous set of standards, brings better reusability of existing assets or investments in the enterprise and lets you create applications that can be built on top of new and existing applications. SOA enables changes to applications while keeping clients or service consumers isolated from evolutionary changes that happen in the service implementation. SOA enables upgrading individual services or services consumers; it is not necessary to completely rewrite an application or keep an existing system that no longer addresses the new business requirements. Finally, SOA provides enterprises better flexibility in building applications and business processes in an agile manner by leveraging existing application infrastructure to compose new services.