《面向服务架构的企业整合本科毕业论文.doc》由会员分享，可在线阅读，更多相关《面向服务架构的企业整合本科毕业论文.doc（16页珍藏版）》请在金锄头文库上搜索。
1、本科毕业设计外文文献及译文文献、资料题目： Service-Oriented ArchitectureA Field Guide to integratingXML and Web Services文献、资料来源：著作文献、资料发表（出版）日期：2004.10.22院 （部）： 专 业： 班 级： 姓 名： 学 号： 指导教师： 翻译日期： 外文文献：Service-oriented architectures for enterprise integrationWith the broad acceptance and popularity of XML and Web services a
2、s a EAI as a strategic remodeling of business infrastructure platform, and structure, its 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 architectu
3、res, 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.
4、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 tr
5、ansport 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, its not of much consequence anymore. XML Perhaps both clai
6、ms 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 architecturesThe process-oriented nature of EAI s
7、olutions 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 typ
8、es 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
9、 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
10、 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 manage
11、d 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 we
12、ll 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
13、 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
14、 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
15、 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
16、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
