Understand the architecture of the system, the company service bus scene and solution, Part 1
Work role in business service bus
Level: Junior July 2004
This article determines a set of minimum functions to meet the basic needs of the Enterprise Service Bus (ESB) and the service-oriented architecture, SOA. By determining these minimum features, you can determine what existing techniques to implement ESB supporting SOA. By considering how the needs of the particular situation determine the need for additional functions, you can choose the implementation technology that best suits this situation.
Introduction The latest IT integration is the use of Web service technology to implement service-oriented architecture (SOA), many excellent articles tell the benefits and related practices of this technology (see Resources). Recently, the concept of Enterprise Service Bus (ESB) is expressed as a key component of the SOA infrastructure (see Resources). However, it is necessary to clarify that the ESB is a product, technology, standard, or something else. In particular, can I build ESB? If so, how to build it?
This article describes the ESB as a set of infrastructure functions that are implemented by middleware technology and support SOA. ESB supports services, messages, as well as event-based interactions, and has appropriate service level and manageability. To achieve this, you need to concentrate on multiple functions and classified. However, all the features that the ESB can transmit values can be used.
This article determines a set of minimum functions that meet the basic needs of the ESB and SOA principles. By determining these minimum features, you can determine what existing techniques to implement ESB supporting SOA. By considering how the needs of the particular situation determine the need for additional functions, you can choose the implementation technology that best suits this situation.
In the next article, I will define a set of ESB scenarios in SOA to define the common starting point for ESB or SOA implementation. The solution model provides a guide to selecting appropriate implementation technology.
With the development and maturity of the ESB solution, the features they need are constantly developing. Similarly, the availability and functionality of visible ESB products are also becoming more and more perfect. Therefore, in the last article of this series, I will consider the development route of SOA and ESB to guide the initial application of ESB functions and technology, and explain how to select a step-by-step approach.
ESB works in SOA although I don't plan to discuss SOA definitions (see Resources), it is useful to summarize that most of the principles applicable to SOA descriptions are useful:
Use explicitly unrelated interfaces to define services. Using emphasized position transparency and interoperability communication protocols. Package the definition of service for reusable service functions.
Figure 1 illustrates these principles. Note that although Web service technology is very compliant with these principles, it is not the only technology that meets these principles.
Figure 1: Principle of SOA
In order to implement SOA, applications, and infrastructure must support SOA principles. Enabling the SOA application involves creating a service interface, the service interface can also be used indirectly by using the adapter for existing or new features. From the most basic level, enabling this infrastructure involves planning functions to route service requests and pass to the correct service provider. However, the infrastructure supports the implementation of the original service implementation by another service to replace the original service implementation without affecting the client. This not only needs to specify a service interface according to the SOA principle, but also requires the infrastructure to allow client code to call services in a way independent of the service location and communication protocols. Such a service route and an alternative are part of many of the ESB. ESB supports these service interactions and provides integrated communication, messaging, and event infrastructure to support these features. Therefore, it combines the main enterprise integration patterns that are currently using into an entity. ESB provides SOA to provide an infrastructure that needs to be consistent with companies to provide appropriate service level and manageability, as well as operations in the heterogeneous environment.
The remainder of this article will discuss the role of ESB in SOA, including which provide functions other than basic routes and transmissions, as described in the following ESB function model section.
The ESB structure ESB is sometimes described as a distributed infrastructure that forms comparisons with other solutions, such as message proxy technology, generally described as a central radiation (Hub-and-spoke). However, this is not a real difference. Two different issues are being studied: the distribution of centralized and infrastructure. ESB and central radiation (HUB-and-spoke) solutions centrally control configuration, such as routes, service names, etc. of service interactions. Similarly, these two solutions may be deployed in a simple centralized infrastructure or to deploy more complex distributed methods. Figure 2 shows this.
There is no doubt that different technologies have different constraints on the physical deployment model they support - some may be suitable for very widely distributed to support integration in a large geographic range, while others may be more suitable for Deploy in local clusters to support high availability and scalability. Making physical distribution requirements with the functionality of the candidate technology is an important aspect of the ESB design. Another ability is also very important, which is to expand the initial deployment in incremental way to reflect the changing demand, integrate additional system or extended infrastructure.
Figure 2: Concentration control of distributed ESB infrastructure
I should also be positioned between the ESB and other components in the SOA infrastructure, especially relationships with Service Directory, Business Service Choreography, and Business-To-Business (B2B) Gateway. Since the above SOA principles have no strict requirements for these components, we can treat them as an optional component. Figure 3 shows SOA illustrates the relationship between these components.
Figure 3: ESB role in SOA
ESB needs some form of service route directory to routing service requests. However, SOA may have a separate business service directory, and its most basic form may be a design-time service directory for reuse of services throughout the organization's entire development activity. Web Services Place a UDDI directory in the role of the business service directory and service route directory, thus making dynamic discovery and calling services. Such a directory can be considered part of the ESB; however, the service directory may be separated from ESB before such a solution becomes common.
The role of Business Service Choreographer is to combine business processes through a number of business services; therefore, it will call the service via the ESB, and then disclose the business process to other services available to the client again via ESB. However, the role of Business Service Choreographer in ordering business processes and services determines that this business workflow technology is a technique that is separated from infrastructure technology ESB. Finally, the role of the B2B Gateway component is to make two or more organizations that are available to each other in a controlled and safe way. This helps to see other components connected to the ESB, but they are not part of the ESB. Although some gateway technologies can provide features suitable for implementing B2B Gateway components and ESB, the use of the B2B Gateway component is to separate it from ESB. In fact, this use may require additional functions (such as partnership management), which is not part of the ESB and is not necessarily supported by ESB technology.
ESB Function Model Table 1 summarizes and classify some of the ESB functions determined in existing literature (see Resources). Although there are some features that are very basic, other functions (such as automation functions or intelligent features) represent important steps to the on-demand operation environment. It is important to realize that most scenarios only need some of the features in some categories. The minimum function required for ESB implementation will be discussed in the ESB implementation section of the lowest function of SOA.
Table 1: ESB functionality defined in existing literature
Communication service interaction
Routing addressing communication technology, protocols, and standards (such as IBM? WebSphere? MQ, HTTP, and HTTPS) publish / subscribe response / request fire-and-forget, event synchronization, and asynchronous messaging
Service interface definition (for example, Web Services Description Language, WSDL) supports replacement services to communicate and integrate the service messaging model (such as SOAP or Enterprise Application Integration (EAI) Middleware Model) Service Directory And find integrated service quality
Database Services Aggregate Legacy System and Application Adapter EAI Middleware Connective Service Mapping Protocol Converting Application Server Environment (such as J2EE and .NET) service calling language interface (such as Java and C / C / C #)
Transaction (Atomic Transactions, Compensation, Web Service (WS-Transaction)) Various determined delivery examples (such as WS-ReliableMessaging, or support for EAI middleware) security service level
Authentication Authorized unrecognizable confidential security standards (such as Kerberos and Web Service Security (WS-SECURITY))
Permanent throughput availability Other persistent assessment methods for contract or agreements Message processing management and autonomous
Coded logic based on content logical messages and data conversion validity intermediary object identifies mapping data compression
Service preset and registration record, measurement and monitoring of integration self-monitoring and self-control modeling infrastructure intelligence
Object Modeling Universal Business Object Modeling Data Format Library B2B Integrated Public and Private Model Development and Deployment Tool
Business rules policy driver, especially for service level, service functionality, such as Web Service Policy (WS-Policy) mode identification
Many of the features above can be implemented using proprietary technology, or by utilizing open standard implementation. However, using different techniques to implement ESB may make them significantly different, while these features are significantly different, while ESB functions and supported open standards will vary. For these reasons, plus some of the relevant standards that have recently developed and currently promoting ESBs, many key decisions that implement ESB involve the trade-off between mature proprietary technology and immature open standards. In this series of articles, we don't intend to discuss each of the features above. Instead, we will focus on the driving strategy between the different methods of adopting or implementing the ESB. Especially in the next part, we will discuss what the ESB is made by the minimum function required to support SOA.
ESB implementation supporting the lowest function of SOA If only part of the previously determined features are related to most SOA scenes, we may ask: What is the result of the minimum function required to implement the ESB? To this end, consider the principle of the most universally identified ESB definition:
ESB is a logical architecture component that provides an integrated infrastructure that maintains the principle of SOA. The SOA principle requires the use of unrelated interfaces, emphasizes location transparency and interoperability communication protocols, relative coarse particle size and service definitions of encapsulation. ESB can be implemented as a distributed heterogeneous infrastructure. ESB provides methods of managing service infrastructure and functions that operate in a distributed heterogeneous environment.
Table 2 shows the lowest ESB function defined according to these principles
Table 2: The lowest ESB function
Communication integration
Provides location transparency routing and addressing service control services addressing and naming management capabilities at least one form of message transfer model (eg, request / response, publish / subscription, etc.) support at least one of the widely used transmission protocol
Support services provide a variety of integration methods, such as Java 2 connector, web service, asynchronous communication, adapter, etc. Service interactively interact with a unrelated service messaging and interface model, it should put application code from routing services and The transfer protocol is separated and the implementation of alternative services is allowed.
Note that these minimum features do not need to use special techniques, such as EAI middleware, web services, J2EE or XML. The use of these technologies is very close and very compliant, but it doesn't have to be mandated to use them. Instead, the lowest function can be implemented almost simply using SOAP / HTTP and WSDL (of course not all cases):
URL addressing and existing HTTP and DNS infrastructure provide a "bus" "with routing service and location transparency. SOAP / HTTP Support Request-Response (Request-response) communication specification. The HTTP transport protocol is widely used. SOAP and WSDL are open, unrelated to service communication and connection models.
However, these SOAP / HTTP and WSDL basic applications are just integration of point-to-point, and cannot implement key features of some ESBs:
There is currently no management capabilities for controlling service addressing and naming. The service name is controlled separately through each adapter, and the service routing is dispersed between the address of the service client, the HTTP infrastructure, and the service name assigned to the adapter. Although this method relies on the implementation details, it often does not make the replacement of the service to be simple; service requester code (may also be generated by development tools) typically bind to specific services through specific address specific protocols. Provider implementation. If you want to use another service implementation to replace the original service implementation, you need to modify the application code and re-deploy these code.
Of course, there are often other functions in many or even most situations, and this need becomes more common. In particular, whether it is still now, the following demand types may result in more complex advanced technologies: service quality and service level features. Advanced SOA Concepts, such as service arrangements, directory, conversion, and more. Operating environmental requirements on demand, such as management and autonomous functions, and infrastructure intelligence. A plurality of networks, multiple protocols, and the true sense of multiple domains have different ownerships.
Impact of security issues affecting ESB I don't want to directly propose security needs, but they are very important to choose ESB implementation technology. For example, if the service request does not need to provide authentication or authorization, the choice of technology can be very wide. More likely, if some security levels are needed, what form of security is acceptable is very important. E.g:
Whether to accept security in the communication infrastructure, for example, whether the security socket layer (SSL) is verified with each other between the EAI middleware server, or is it in using the HTTPS protocol? Can you accept a separate point-to-point security between the participating systems, or whether end-to-to-end mode is required? For example, is it necessary to pass the client identity to the final provider of the service to the service implementation by a middleware system similar to the agent? Can I accept security in the application layer, for example, is the client code to perform basic HTTP authentication with the user ID and password, or whether this information can be passed to the service as an application data? Do you need to comply with industry safety standards, such as Kerberos or WS-Security?
Although all of this is possible, the development direction of the industry is a standard security (such as a web service security (WS-Security) feature that the infrastructure and middleware support. However, in contrast, these safety standards are also presented recently, and their product support is still developing, rather than have been determined, especially for their interoperability. Therefore, any ESB architecture requires as early as possible to identify security requirements in order to include them in order to select implementation technology.
Conclusion In this article, I discussed most of the general SOA principles and their association with Web service technology. Based on these principles, I propose an infrastructure component that provides routing functions so that the service can interact with each other while supporting the use of another service implementation to replace the original service implementation. These functions are implemented by ESB.
ESB provides a distributed infrastructure while maintaining centralized control, and therefore require some form of service route directory, and it may also require a business service directory. Business Service Choreographer calls services from the ESB and then discloses these processes as new services via ESB.
Many features of ESB include providing:
Communication Service Interactive Integration Quality Service Security Service Level Message Process Management and Autonomous Service Modeling Infrastructure Intelligence In these different functions, I determined the minimum function required to establish ESB, including communication, integration, and service interactions.
In this series of next section, I will discuss some common scenarios, as well as solution patterns related to these scenes, pointing out the most common problems affecting these scenes.
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 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 . About the author Rick Robinson is an IT architect of IBM, and he joined the company in March 1997 as a developer. He is a member of the Architecture Services Group of Emea WebSphere Lab Services. He started paying attention to it when the 1999 WebSphere software platform was first published. Rick is more concerned about technology instead of the industry, but in the past three years, he spent a lot of time and financial fields working together. Rick is a trusted IT architecture design professionals in IBM. Before joining IBM, the Rick was pursuing PhD of Physical.
