面向服务架构的企业整合本科毕业论文.doc

本科毕业设计
外文文献及译文

文献、资料题目： Service-Oriented Architecture
—A Field Guide to integrating
XML and Web Services
文献、资料来源：著作
文献、资料发表（出版）日期：2004.10.22
院 （部）：
专 业：
班 级：
姓 名：
学 号：
指导教师：
翻译日期：

外文文献：
Service-oriented architectures for enterprise integration
With the broad acceptance and popularity of XML and Web services as a EAI as a strategic remodeling of business infrastructure platform, and structure, it's hard to say how these respective trends affected each other as they emerged.
XML One could argue that the EAI initiative was rejuvenated with the infusion of enabled technologies and service-oriented architectures, as the introduction of these complementary platforms resulted in an overhaul of EAI architectures. As a result, the quality and sophistication of EAI products has never been better.
On the other hand, the momentum behind the EAI trend could very well have been a and especially to Web services. The increas major contributor to the popularity of XML, and especially to Web services. The increasing need to reduce the costs of integrating disparate environments led to the ubiquitous requirement for a standard data sharing platform, independent of ties to vendors and provided a standard data transport which empowered Web existing technologies. XMLservices with the ability to effectively abstract proprietary platforms in support of utilizing this transport standard to communicate over previously non-standard boundaries. and really, it's not of much consequence anymore.
XML Perhaps both claims are true, and Web services have become key enabling technologies within the world of EAI, and EAI products are being built from the ground up in support of the XML and Web services technology platforms.
1. Service models for enterprise integration architectures
The process-oriented nature of EAI solutions has driven the requirement for service models that can execute and manage various aspects of enterprise business. EAI middleware is typically involved with the creation and hosting of these services; however, it is not uncommon for custom-developed integration solutions to provide these types of services independently. Either way, an understanding of their roles and underlying technologies is vital when designing an enterprise integration architecture. The following XWIF service models are distinctive of senrice-oriented EAI environments.
When coordinating the message exchange pattern involved in the execution of a busi- ness task, it is often necessary to encapsulate the interaction between Web services into a dedicated business process. This provides a central source of business logic that determines the rules, conditions, and exceptions relating to the workflow scenarios that can occur within a solution. A number of business process dialects have emerged; however, the BPEL4WS specifi-cation has received the broadest industry support. It is complemented by the WS- Coordination and WS-Transaction standards to provide a framework for building sophisticated and fully managed business workflows.
A BPEL4WS process service exists as a Web service composed from numer-ous language constructs that can facilitate most traditional workflow requirements. The documeilt representing the BPEL4WS process contains interfaces (or portTypes) WSDL for the process service itself, as well as any additional services involved with the execu- tion of the process.
Unlike regular WSDL documents, however, the service definition for a BPEL4WS processprovides no binding information. It is intentionally implementation-neutral so that the process can remain mobile, reusable, and independent from changes to the technical deployment environment.
WS-Coordination is closely associated with the WS-Transaction specification, which defines two distinct coordination types, both of which are relevant to enterprise integration environments. The first, atomic transactions, enables the management of ACID like transactions. The service model for atomic transaction coordinators is established in Chapter 9; it is the most common type of coordination service used in legacy integration architectures. The second coordination type provides a niodel for long running transactions, and is represented as part of the coordination service model(for business activities)
Business proces sintegration is a typical characteristic of EAI solutions, which is why coordination services for business activities are utilized exclusively for the management of long running business activities.
This service model is generally used in conjunction with process services as a means of handling successand failure conditions related to the execution of the overall process activity .
The WS-Coordination specification provides an assembly of services with predefinedinterfaces that support the management of a coordination context. Specifically, this collection of services provides separate operations for the creation of a context, the registration for a context, and the selection of a protocol.
2.Fundamental enterprise integration architecture components:
EAI solutions centralize inter-application communication and automate new processes with the help of two core components: the broker component and the orchestrntion engine . The frundamental functions enabled by these components establish the basic EAI architecture
To demonstrate how these components function, basic data exchange scenarios are provided in this section. Even though these exainples might seem simplistic, they explain key EAI concepts. Most enterprise integration problems are sollved through the use of these two core components. Incidentally, these two integration scenarios are equally common in B2B environments
The broker component is capable of performing a wide variety of runtime functions, such as:
● sopliisticated data transformations
● merging documents froin different sources
●supplementing received data from one application with additional information from another
The primary function of an integration broker component, however, is to ensure that data received from one source is always in the forinat expected by the destination
The following five-step process demonstrates the retrieval of data by application B, in response to a request from application A (How the request is sent to application B is not relevant to this example.) Figure 10.7 provides an overview of the process steps

Step 1 : retrieve requested data from the source database (Figure 10.8) Application A initiates a request for data that is transmitted to application B. Application B processes this request and retrieves the data

Step2: validate source data using source schema (Figure 10.9) At some point, the retrieved data is validated against a schema representing the data model of the message document that will be used to transport the data outside of the application boundary
This step may occur natively within the database, or it may be executed within application B's logic. The latter case is more likely if the data is retrieved from multiple data sources, in which case a unique schema for this specific representation may exist.

Step 3: broker the data format (Figure 10.10) Finally, here's where our broker component kicks in. It will already have schemas from both applications, as well as a data map that will allow it to transform the retrieved data into the data format required by application A
Also, in this example, it performs a dynamic lookup from an external data source in order to supplement the received data with additional information. The transformation also filters out some uiulecessary data (not shown).

Step 4: validate target data using target schema (Figure 10.11) ,Application A receives and validates the data contained within the response to its original request.

Step 5: insert data into target database (Figure 10.12) Once successfully validated, application A processes and then inserts the data in its database.

3. Web services and enterprise integration architectures：
Integration architectures designed for the enterprise reach beyond cross-application communication concerns. Primarily driven by business process automation, these solutions can be extremely broad in both functional and architectural scopes
Numerous EAI solution vendors have provided sophisticated environments to accommodate ever-changing business processes. The two fundamental integration components explained in the previous section are key players in these environments, because they support the introduction of new business processes by unifying disparate applications to collaborate on a fcinctional level
Most EAI solutions rely on asynchronous messaging-based communication frameworks, and therefore open up the interaction options between the integrated participants. XML, is a natural fit for this framework, and has established itself as its standard data represen tation technology. Web services have also mfiltrated traditional EAI environments, and their support has reached the point where vendors are building pure service-oriented enterprise integration products
This leads us to a common problem with traditional EAI: interoperability between vendor platforms. Toward the end of this section we explore how this very significant issueis being addressed through a contemporary service-oriented EAI model.
4. Hub and spoke：
The most popular of the traditional EAI models, this architecture promotes centralized processing throuh a hub that is provided by proprietary middleware. A centrally located server hosts the integration logic that controls the orchestration and brokering
Through a series of adapters, a wide variety of disparate client applications can participate in data exchange as well as the orcliestration workflow that resides within the hublogic. Once an application is connected to the hub, it may not even nced to bc aware of other applications it ends up indirectly interacting with
Figure 10.21 shows how integrated applications essentially create point-to-point connections with the hub itself. By hiding the solution participants from each other, a level.of "logic autonomy" is established
Facilitated by broker transformation features, orchestration-enabled routing can suport one-to-one, one-to-many, and many-to-many data exchange patterns. This level of flexibility can lead to a variety of creative integration scenarios. The fact that all of the data flows through a central location reduces the potential of redundant data re-entry and processing, and also makes the monitoring of communication much easier
In addition to simplifying a number of administration tasks, this design centralizes the maintenance of the process logic, and even promotes reuse within the application components that implement the centralized orchestration workflow
This model, however, does introduce some risks. As the busiest and most popular part of an integration architecture, the hub environment can become a potential processing hazard. Bottleneck situations are a constant danger, uiiless scalability is carefully planned and designed into the hub infrastructure.
Also, the hub can establish a single point of failure for a very large amount of automation. Imagine twelve different applications working together to support automated processes for five divisions of an organization. Now imagine the one point through which all data must flow going down. Not a pretty picture. Though measures can be taken, such as replicatio and clustering, the cost of putting together a fully scalablc hub-and-spoke environment with full fail-over support may be prohibitive.
It has been theorized that one of the major reasons this model has been so heavily promoted is that it benefits the vendors more than you. Once your enterprise commits to a full-scale EAI solution, it fill create a great number of dependencies on a proprietary technology. The solution will be expensive to purchase, expensive to build upon, and extremely expense to rcpldce. A centralized hub that introduces a vendor-specific product to control all communication between your intcgrated applications will become deeply entrenched in your organization. For better or for worse.

5. Enterprise Service Bus (ESB)：
If you built a pure service-oriented architecture from scratch, you could design it in such a way that you would avoid many of the problems that have plagued proprietary EAI solutions. Your only real challenge would be the time and expense required EAI solutions.Your only real challenge would be the time and expense required to build an enterprise-grade integration architecture driven by an army of standardized Web services.
What if, though, sonleone built a platform supporting such an architecture for you.The underlying technology would still be proprietary ,but would not lock you in. Every component of the solution would exist as a Web service, allowing you to exchange allowing you to exchange or upgrade it as you please. Urn.. . do you deliver?
ESB is a refreshing departure from the proprietary stigma often associated with traditional EAI products. Some yendors have recognized an opportunity to combine the best of both worlds,while liberating product owners from vendor dependencies.
Typical ESB architectures establish an integration platform that acts as a dynamic hosting environment for intelligent service intermediaries. Serliice containers can host a variety of service components Even though the containers may be proprietary, the ser vices they host are not. In addition to supporting interchangeable services,it also allows for the underlying hosting environment to be replaced while preserving the logic already encapsulated by these services.
One of the most significant benefits of this architecture is its ability to transcend the many obstacles of traditional inter -EAI-integration. If two ESB solutions were implemented with different veiidor platforms, the open interface policy of this model would make any disparity in the service hosting environments almost irrelevant.
中文译文：
面向服务架构的企业整合
XML和Web服务将EAI作为一种战略重构的业务基础平台，得到广泛的应用和普及，由于这项技术的出现，很难说XML和Web服务今后的发展趋势会是怎样? XML将EAI技重新植入面向服务架构，使其互补平台全面实现EAI架构，结果证明，EAI产品的质量和复杂度比以往任何时候都要好。
至于另一方面：随着EAI的不断发展，EAI很有可能成为一个特别的Web服务，EAI在XML和Web服务越来越广泛的应用。随着EAI的不断发展，可以使不同的环境在一个标准的数据共享平台运行，并提供一个标准的数据传输的授权网络平台，XML的服务尽可能的去掉自己专用平台，以支持利用这一运输标准比以前的沟通非标准界限好的平台。现在这个已经没有多大的问题了。
在EAI从底层向上层的产品都支持XML和Web服务的技术平台，已经成为XML和Web服务技术的重要平台。
1. 服务模式成为企业集成架构:
这一过程为导向性质的EAI解决方案，推动了需求的服务模式，可以执行和管理各个方面的企业业务。EAI的中间件通常是参与建立和维护这些服务，但是提供这类独立的服务，并非是定制开发集成解决方案。无论哪种方式，它们的作用和技术对企业在设计集成架构都是是非常重要的。以下XWIF服务模式是以服务为导向企业独特的应用集成环境。当协调消息交换模式参与执行商业任务时，通常需要封装他们之间相互作用的网络服务，然后进入一个专门的业务流程。这个业务流程提供了一个集中的业务逻辑来源规则，条件和有关的工作情况，这时将提供一个解决方案。近年来，像这样业务流程的越来越多，但是BPEL4WS的规范得到了最广大的行业支持。BPEL4WS提供一个框架补充了WS-协调和WS-交易标准，并建立了先进的和全面的管理业务流程。
BPEL4WS进程服务是为Web服务的数值组成而存在的，该进程符合最传统的工作流程要求。BPEL4WS的代表进程服务包含文件（或por