Understanding the architecture of the architecture of the company, the enterprise service bus scene and solution, Part 2
Drive architecture ESB scene and problem
Level: Intermediate July 2004
In the second part of this series of Enterprise Service Bus, ESB, the author describes and analyzes some common scenarios for implementing ESB and other service-oriented architectural (SOA) solutions.
Article 1 of this series describes the basic concepts and work characters of the Enterprise Service Bus (ESB). This paper focuses on the scenes and problems of ESB development as supported as a service-oriented architecture (SOA). Your organization's SOA and ESB may need to be applied to one or more scenarios.
The ESB scenario and the ESB scenario in SOA describes the starting point of many SOA and ESB implementations. Each scene points out the problem of driving architecture and design decisions, and these decisions affect solution mode (will be described in Part 3 of this series). In the issue of driving the ESB architecture and design decision, you can read detailed descriptions on these issues. These solution patterns represent the basic use of service technology, to a simple ESB implementation, and then the development process of complex SOA architecture.
The purpose of these ESB scenarios is not to show all the needs of SOA or ESB. For example, although a scenario (such as the basic integration of two systems) may seem good matching specific current needs, this demand may develop into more complex demand over time (such as supporting one or Multiple applications achieve a wider range of connectivity scenarios. In addition, there may be many cases of separate demand for SOA or ESB infrastructure, in line with simple scenes, but they are concentrated together. complex.
We need to make a choice between the three needs and definition of future needs and definitions of the three people's consistent solutions to achieve a very clear demand. It may be more suitable as generally relatively complex scenarios (such as implementing SOA infrastructure supported by high service quality and Web service standard). In addition, individual situations can be regarded individually as simple scenes, but the last obtained solution will develop into a generic architecture.
Several parts of the ESB scenario in SOA describes the features of these scenes:
Basic integration of two systems supports one or more applications to achieve a wider range of connectivity support legacy systems implement a broader connection support Enterprise application integration (EAI) architecture implementation of a broader connection between organization or The controlled integration of the system enables process automation to enable process automation to implement SOA infrastructure supported by high service quality and Web service standards.
Basic integration of two systems
Scene companies need to provide integration between two systems implemented with different technologies such as J2EE, .NET, CICS, etc.. Web service SOAP standards or messaging middleware may be a candidate integration technology. An important issue in this scene is whether there is a need to integrate other systems in the future. Using an extensible solution with an extensible solution can be supported in the future needs; however, you must maintain balance between additional work to construct a solution to a simple problem to solve the problem. The most relevant question related solution mode (see next article) 1, 3, 4, 6, 10, 13
Use the wrapper or adapter to achieve basic integration - see the basic adapter. Or, you want to expand in the future, there are two options:
Add a control service gateway. Or achieve a complex infrastructure - such as Web Services Compliant Broker or Eai Infrastructure for SOA.
Support one or more applications to achieve wider connectivity
Scene existing packaged or custom development applications (such as Customer Relationship Management, CRM), Enterprise Resource Planning, ERP, etc.) may be used by J2EE platforms or other application server environments Implemented, the available functions provided are exceeded by the application itself. The value of these functions in the form of service is that both interoperability between applications, and access to new channels or clients. The use of interoperable or open standard communications and service protocols seem to be the best way to develop in the future. The most relevant question-related solution mode (see next article) 1, 2, 3, 4, 6, 8, 9, 10, 11, 12, 13, 14 using a wrapper or adapter to achieve basic integration - See the basic adapter. Add a control service gateway. Or achieve a complex infrastructure - such as Web Services Compliant Broker or Eai Infrastructure for SOA. If you need a process choreography, you will implement Service Choreographer or Full SOA Infrastructure.
Support legacy system to achieve wider connectivity
Scenario has a large investment in legacy techniques such as CICS, IMS, etc. to support them to provide them with core business transactions and data access applications. Its important value is to provide interoperability or open standards, as well as service-based access to these matters (eg, inquiry account balance transactions, create orders, schedules, or delivery tracking, query inventory levels, etc.). The most relevant problem related solution mode (see next article) 1, 2, 3, 4, 7, 8, 9, 10, 11, 13, 14
Use the wrapper or adapter to achieve basic integration - see the basic adapter. Or, you want to expand in the future, there are two options:
Add a control service gateway. Or achieve a complex infrastructure - such as Web Services Compliant Broker or Eai Infrastructure for SOA.
Support Enterprise Application Integration (EAI) infrastructure achieves a wider range of connectivity
Scene requires an existing EAI infrastructure (such as IBM WebSphere Business Integration) to perform access based on interoperable protocols or open standards. Although the Open Interoperability Level can be provided in some scenarios based on the XML business data and open service interfaces, such as HTTP or WebSphere MQs), if appropriate interoperability levels are available in some scenarios, but if you have customized or specialized It is not acceptable to extensions, and WSDL and SOAP Web standards may be needed. The most relevant question related solution mode (see next article) 3, 4, 5, 8, 9, 11, 13, 14
Use open data format and Eai Infrastructure for SOA to extend the EAI infrastructure. Add a control service gateway. Or add an open standard support to the infrastructure with Web Services Compliant Broker.
Realize the controlled integration of services or systems between organizations
Scene organizations want their customers, suppliers, or other partners to directly integrate features provided by one or more applications, legacy systems, and the like. The focus of control is to provide access from external parties to these applications. Because the organization cannot directly control the technology used by its partners, it is best to use open standards. This scenario can be applied between the dispersed tissue, or between the various units of large distributed tissues. The most relevant question related solution model (see next article) 1, 2, 3, 4, 6, 8, 9, 10, 11, 13, 14
Add a service gateway. Or if you need more complex functions, you will implement Web Services Compliant Broker. Automation of process by arranging services
Scene (Note: This scene can be seen as the development of a more wide connection scene to support one or more applications. It does not be treated as an ESB scenario, because the service module is usually implemented from ESB, as this series The first article said. However, the reason why I am here is because this scene often drives the demand for ESB and service arranging components.) Existing packaged (for example, customer relationship management (Customer Relationship Management , CRM), Enterprise Resource Planning, ERP, etc.) or custom development applications may be implemented in the J2EE platform or other application service environment, which provides the available features that are over the application itself. These functions can be disclosed as a service using interoperable or open communication and service protocols so that applications can interact. These interactions can be combined at certain levels to form a business process. These processes should be explicitly modeled using appropriate modeling and process implementation techniques (possibly complied with appropriate open standards). The most relevant problem-related solution mode (see next article) 1, 2, 3, 4, 6, 10, 11, 12, 13, 14
If the direct connection of the service is possible, it implements Service Choreographer. Full SOA Infrastructure is implemented if more complex integration or control is required.
SOA infrastructure with high service quality and Web service standards
Scene This scene is made up of the previous. It represents the need for universal internal or external access provided by multiple applications, legacy systems, and the like. There is a need for a variety of security, aggregation, conversion, routing, and service proofability. IT organizations are increasing in response to supported business, so that more common and more flexible integrations can be performed between business systems. The most relevant question related solution mode (see next article) all
Implement Full SOA INFRASTRUCTURE.
Problems drive ESB architecture and design decisions In order to determine suitable solution patterns and implementations for ESB, you need detailed analysis of specific ESB functional requirements. The following problem is intended to help perform this process, while the previous part points out specific issues related to each scene.
Does existing features and their data interfaces match the services you want to provide? Can you modify or aggregate applications?
If it is not possible, the conversion or aggregation function needs to be provided by an adapter or an ESB architecture, or has to be completed by the service client. Can the service open in the form of some general business data models? If it can, do the system that implements these services already supports this model? Or can you do this?
If the service is not possible, the conversion or aggregate function needs to be provided by an adapter or an ESB architecture. Do you need an open standard? Or whether appropriate interoperability can be achieved by EAI middleware? Which open standards are suitable if you need an open standard?
While using an open standard is a way to achieve interoperability, the proprietary EAI middleware also has a high degree of interoperability and often matures much. In addition, many organizations have a wide range of existing infrastructure, in some scenarios, they may make the open standards a few more effects. In scenarios that require open standards, Web services may be the most obvious choices in these situations. However, you can also apply Java Messaging Service (JMS), JDBC, basic XML, or some other techniques (such as EDI or industry-universal XML format. In practice, it cannot always assume that different implementations of the same criteria have interoperability Sex, especially for standards that have recently appeared or just raised. For web services, Web Services Interoperability Organization releases the basic summary of interoperability using SOAP and WSDL, other more advanced standards (for example Overview of Web Service Security (WS-Security), WS-Transaction, etc. will then be released. The use of open standards has not been guaranteed before the product is fully, stable and widely supported. And may not always promote interoperability. Do you need to support basic communication protocols and standards (such as WebSphere MQ, SOAP, WSDL) or require more advanced features (such as web service security (WS-Security), web service transactions (WS-Transaction, etc.) Support for more complex standards will be more stringent to implement technology choices, and may mean use still unripe techniques. When considering changes the existing infrastructure used When message formats and protocols (including open standards) are required to make these changes throughout the existing infrastructure? Or will you apply new message formats and protocols soon? If you are using or consider using EAI technology, Does this technology have their own internal formats? Or can it handle open standards as internal formats?
Any application of open standards is driven by the demand for extended access, so they are more important than the availability of existing infrastructure than internally used. This will bring restrictions on the use of specific formats, techniques, or standards internally. Is the system or open standard (such as SOAP, JMS or XML) required for system-disclosed systems (such as SOAP, JMS or XML)?
If not supported, the ESB infrastructure or adapter will need to convert between the desired open standard and service provider supported by the format. Can I directly support (eg, CICS SOAP support) legacy system availability by using updated XML-based technologies Do you need a separate adapter? Does the legacy platform support XML processing? If supported, can this processing flexibly use the platform function?
If the desired SOAP or XML function is not available because of any of this, you need to use in the adapter (such as S J2C Connector Architecture Adaptors, integrated layer, or ESB infrastructure), integrated layer or ESB infrastructure. Appropriate conversion function. If the EAI technology is available, do it use the appropriate function or interface granularity to achieve the service as a message flow? Which connectivity protocols (such as JAVA, SOAP, WebSphere MQ, and Java Remote Method Invocation)? If the existing message flow does not provide the required service, additional processes need to perform conversion. If EAI technology does not directly support the required criteria, you need to add a gateway component. What protective measures should be provided to the service provider system from the service client channel to workload buffer, safety, login and other forms?
This buffering is usually one role of the ESB infrastructure and defines what it needs. If a specific service provider system (such as Legacy Transactional Systems) requires additional protection, you can use a dedicated integrated layer. How much should I achieve? What is the implementation should be consistent in these services? How to implement consistency (may be on multiple platforms and multiple applications)?
If you only need very little service, a simple point-to-point integration model may be more suitable. However, if you need more services or after a while, add a control point (such as provided by ESB), it becomes more and more. Service interaction is included inside the organization, or some interaction outside the organization?
This is often a case different from the ESB infrastructure implemented in a single organization, as the need for security and service routes may differ from external available services. Do you need service arranging? Whether service arranging is involved in short-Lived or long-lived (in a slogable) process, or both? Do they include artificial activities?
In the case where these requirements constitute business functions, the arrangement should be implemented in the service choreographs separated from the ESB. Regarding the need to support long-term state processes or to support manual activities will restrict the choice of technology. What kind of service-level demand should the infrastructure (for example, service response time, throughput, availability, etc.)? How do you need to expand it over time?
Some candidate ESB implementations are relatively new and may only be tested only on a limited service level. Similarly, since the relevant open standard is not the recent development, it is rising, so supports their support in more established products and technologies is also new. In the foreseeable future, key architectural decisions will focus on the balance of specific open standard advantages, and support these open standards for the emerging or mature product technology for service level needs. Developing these real-time decisions requires some standards and supports their products that are relatively mature (e.g., XML, SOAP, etc.), some (WS-Security), more, and some (such as web service transactions) ) Is rising. The trade-offs between the standards and the verified service-class feature often drive a mixing method that combines the ESB and the SOA architecture to accommodate standards, proprietary or custom technology. Do you need a point-to-point security model (for example, whether the ESB can be approved to the service request, or you need to pass the requester's identity or other credentials to service provider)? Do you need to use an application or legacy security system to integrate service security models? If the point-to-point security is acceptable, many existing solutions (such as SSL, J2EE security, adapter security models, etc. accessed) can be applied. If you need end-to-end security, the Web service security standard is possible to provide all relevant systems to support it. In other words, you can use a client model with the client message head, or transmit security information like application data.
Ending the text identifies the most common scenes in some ESB implementations, as well as issues that directly affect the corresponding solutions. Although there is no complete cover of all hidden issues, these are most often encountered.
We outline the common scenes of the SOA architecture that achieves the support of high quality services and Web service standards from two systems. And describe fourteen different issues that need to pay attention to:
Existing Data Interface Business Data Model Open Standards Support for Basic or Advanced Communication Protocols Conversion to Data Transfer Formats through the existing system The new technology public existing service The existing EAI technology needs to protect the existing EAI technology needs Provide how much service and need consistency, interior and interoperability between service arranging requirements for service-oriented requirements for service-oriented requirements for service-oriented requirements for service - to-end (end-) Use of to-end) security model
Understanding these basic scenarios and issues have a strong foundation for your development possible solutions. In Part 3 of this series, I will discuss the practical solutions mentioned in this article. as follows:
Basic Adapter Services Gateway Web Services Compliant Broker Service Choreographer's EAI architecture complete SOA architecture
Finally, I will discuss the organization to consider how to develop their architecture when using controlled and incremental ways. Some issues that will also guide you to develop your own ESB route.
Acknowledgments If the author did not discuss with the following person, there would be no such thing as this article, and everyone has contributed great ideas and ideas for this article: Beth Hutchison, Rachel Reinitz, Olaf Zimmerman, Helen Wylie, Kyle Brown, Mark Colan, Jonathan Adams, Paul Fremantle, Keith Jones, Paul Verschueren, Daniel Sturman, Scott Cosby, Dave Clarke, Ben Mann, Louisa Gillies, Eric Herness, Bill Hassell, Guru Vasudeva, Kareem Yusuf, Ken Wilson, Mark Endrei, Norbert Bieberstein CHRIS NOTT, ALAN HOPKINS and Yaroslav Dunchych. Reference
To learn more about the enterprise service bus, see "Understanding the architectural architecture of the architecture of the company, the company service bus scene and the solution, Part 1" (developerWorks, December 2003). To understand how Web service technology provides the necessary basis for the implementation of service-oriented architecture, please read the Web Service-Oriented Architecture - The Best Solution to Business Integration of Annrai Otoole - The Best Solution To Business Integration. In the CBDI Forum, please refer to Lawrence Wilkes. SOA - Save Our assets (requires subscription). Patterns: Service-Oriented Architecture and Web Services Red Book, SG24-6303-00, April 2004, author endrei M. et al. Read "Migrate to the Service-Oriented Architecture, Part 1" (DevelWorks, December 2003) and "Migrate to Service-oriented Architecture, Part 2" (DeveloperWorks, December 2003). Access to LooselyCoupled.com to get a list of Enterprise Service Bus (Enterprise Service Bus). The article Gartner, which is originally defined in Enterprise Service Bus, needs to be subscribed, but you can also find their sites, the title of this article is Predicts 2003: Enterprise Service Buses Emerge, released on December 9, 2002, author ROY W. SCHULTE. Study the IBM Patterns for E-Business website. Access IBM's on-demand Business (On Demand Business) for more information on the on-demand operating environment. The information used herein is from Forthcoming Red Books Patterns: Implementing An SOA Using An Enterprise Service Bus, SG24-6346-00, draft, author Martin Keen et al. Find other SOA and Web services technology resources in the SOA and Web Services technology area of DeveloperWorks. Buy discount books about a wide variety of technical topics at the Developer Bookstore. Interested in testing IBM products with powerful driving force under conditions that do not pay high-speed startup or get short-term assessment licenses? DeveloperWorks Subscribe to provide WebSphere, DB2, Lotus, Rational, and Tivoli products (including Eclipse-based WebSphere Studio IDE) low cost, 12 months, single-user licenses for you to develop, test, assess, and demonstrate your app .
