|By Dave Chappell||
|August 31, 2004 12:00 AM EDT||
The past several years have seen some significant technology trends, such as service-oriented architecture (SOA), enterprise application integration (EAI), business-to-business (B2B), and Web services. These technologies have attempted to address the challenges of improving the results and increasing the value of integrated business processes, and have garnered the widespread attention of IT leaders, vendors, and industry analysts. The enterprise service bus (ESB) draws the best traits from these and other technology trends to form a new architecture for integration. The ESB concept is a new approach to integration that can provide the underpinnings for a loosely coupled integration network that can scale beyond the limits of a hub-and-spoke EAI broker.
An ESB is a highly distributed, event-driven, enterprise SOA that is geared toward integration. It is a standards-based integration platform that combines messaging, Web services, data transformation, and intelligent routing to reliably connect and coordinate the interaction of significant numbers of diverse applications across extended enterprises with transactional integrity. An extended enterprise represents an organization and its business partners, which are separated by both business boundaries and physical boundaries. In an extended enterprise, even the applications that are under the control of a single corporation may be separated by geographic dispersion, corporate firewalls, and interdepartmental security policies.
An ESB is designed to be pervasive, meaning that it is capable of spanning the extended enterprise. But an ESB is also pervasive in the sense that it is capable of being used as a general-purpose integration environment that is suitable for any project, no matter how large or how small.
The SOA of the ESB
An ESB is the implementation backbone for a loosely coupled, event-driven SOA that enables a highly distributed universe of named routing destinations across a multi-protocol message bus.
An SOA provides an integration architect with a broad abstract view of applications and integration components to be dealt with as high-level services. Service components in an ESB expose coarse-grained, message-driven interfaces for the purpose of sharing data between applications, both synchronously and asynchronously. In an ESB, applications and event-driven services are connected through the bus as abstract endpoints. These abstract endpoints are tied together in a loosely coupled SOA, which allows them to operate independently from one another. An integration architect uses an ESB to tie together assemblies of abstract endpoints that form composite business processes, or process flows (see Figure 1).
What the endpoints actually represent can be very diverse. For example, an endpoint may represent a discrete operation, like a specialized service for calculating sales tax. The underlying implementation of the endpoint could represent a local binding to an application adaptor, or a callout to an external Web service. The applications and services can be physically located anywhere that is accessible by the bus.
In an ESB, data is passed between endpoints using messages. The coordination of the message passing is done using an ESB concept known as itinerary-based routing. A message itinerary is metadata that gets carried with a message that provides a list of forwarding addresses. The itinerary is a set of instructions telling the ESB invocation framework which endpoints the message needs to be delivered to as it travels from endpoint to endpoint across the bus. Itineraries contribute to the distributed nature of the ESB architecture by eliminating the dependency on a centralized routing engine, which could potentially be a single point of failure. They are intended for relatively finite microflows of messages. Simple branching and merging of routing paths can be achieved through integration patterns that take advantage of specialized splitter and aggregator services. More sophisticated process orchestrations are also possible using specialized orchestration engines that can be layered onto the bus as additional services.
Configuration, Not Coding
The mantra of the ESB is "configuration rather than coding." In an ESB, abstract endpoints, which are accessible through application adapters, message queues, Web services invocations, and a variety of other protocols, are configured through a tool interface rather than coded into applications. It's not that there's anything wrong with writing code, but there's plenty of code to be written elsewhere that doesn't have to do with hard-wiring interdependencies between applications and services.
With its distributed deployment infrastructure, an ESB can efficiently provide central configuration, deployment, and management of services that are distributed across the extended enterprise. Artifacts that affect the behavior of an integration service, such as an XSLT stylesheet that can be used by a data transformation service, are also configurable in an ESB.
The ESB Service Container
The highly distributed nature, and the ESB mantra of "configuration rather than coding" is largely due to traits of the ESB service container. A service container is the physical manifestation of the abstract endpoint, and provides the implementation of the service interface. A service container is a remote process that can host software components.
A service container is simple and lightweight, but it can have many discrete functions. As shown in Figure 2, service containers take on different roles as they are deployed across an ESB.
In its simplest form, a service container is an operating system process that can be managed by the ESB's invocation and management framework. A service container provides a number of facilities for the service implementation such as event dispatch, thread management, security (encryption, authentication, and access control), and QoS via reliable message delivery. Unlike its distant cousins, the J2EE application server container and the EAI broker, the ESB service container allows the selective deployment of integration functionality exactly when and where you need it, and nothing more than what you need.
A service container can host a single service, or can combine multiple services in a single container environment (see Figure 3).
An ESB service is also scalable in a fashion that is independent of all other ESB services. A service container may manage multiple instances of a service within a container. Several containers may also be distributed across multiple machines for the purposes of scaling up to handle increased message volume (see Figure 4).
The ESB Service Interface
The ESB container provides the message flow in and out of a service. It also handles a number of facilities, such as service life cycle and itinerary management. As shown in Figure 5, the container manages an entry endpoint and an exit endpoint, which are used by the container to dispatch a message to and from the service.
Messages are received by the service from a configurable entry endpoint. Upon completion of its task, the service implementation simply places its output message in the exit endpoint to be carried to its next destination. The next destination may be a reply to the original sender of the message, or more often may be sent along to the next leg of its journey using a forwarding address. The output message may be the same message that it received. The service may modify the message before sending it to the exit endpoint. Or, in the service may create a completely new message to serve as a "response" to the incoming message and send the new message in the exit endpoint.
What is placed in the exit endpoint depends on the context of the situation and the message being processed. In the case of a content-based routing (CBR) service, the message content will be unchanged, with new forwarding addresses set in the message header.
In more sophisticated cases, one input message can transform into many outputs, each with its own routing information. For example, a splitter service can receive a purchase order document, split it into multiple output messages, and send out the purchase order and its individual line items as separate messages to an inventory or order fulfillment service. The service implementation in this case does not have to be written using traditional coding practices; it can be implemented as a specialized transformation service that applies an XSLT stylesheet to the purchase order document to produce the multiple outputs.
Process Tracking and Error Handling
In addition to a normal exit endpoint to handle the outgoing flow of a message, additional destinations are available to the service for auditing the message and for reporting errors. The tracking endpoint can be utilized to monitor the progression of a message as it travels through a business process. Tracking can be handled at both the individual service level and the business-process level. From the service implementation's point of view, it simply places data into the tracking endpoint or fault endpoint, and the surrounding ESB invocation and management framework takes care of the tracking and error reporting. This approach provides a separation between the implementation of the service and the details the surrounding fault handling. The implementer of a service need only be concerned that it has a place to put such information, whether it is information concerning the successful processing of good data, or the reporting of errors and bad data.
One of the many benefits of using itinerary-based routing to coordinate the interactions between discrete integration services is the ease with which integration patterns can be created and reused to solve common integration challenges. A message itinerary can be a powerful and flexible tool for intercepting the path of a message and performing operations on it, thus adding value to the integration environment. Through configuration and management tools, additional processing steps can be inserted into a business process definition as event-driven services into an XML processing pipeline. The following describes two of the common integration patterns in use today: the "VETO" pattern, and a variation known as the "VETRO" pattern.
The VETO Pattern
VETO is a common integration pattern that stands for Validate, Enrich, Transform, Operate (see Figure 6). The VETO pattern and its variations can ensure that consistent, validated data will be routed throughout the ESB.
The "Validate" step is usually the first part of any ESB process and can be accomplished in a number of ways. It's important that if possible, this step happen independently; this removes the burden of validation from all of the downstream service implementations and promotes reuse. Building validation directly into the first service of a process makes it difficult to insert an additional service in front of it without requiring that the new service also provide its own validation.
An example of validation is to simply verify that an incoming message contains a well-formed XML document and conforms to a particular schema or WSDL document that describes the message. This requires that the service always have available the up-to-date XML schema for a particular message type. The schema and WSDL can be kept in the directory service and managed remotely by the management infrastructure of the ESB. A service may also have scripting associated with it, which can be made available to the service as a configuration parameter
If the target data is not in XML format, or if there is no schema or WSDL available, then a custom service can be used to validate the incoming message.
The "Enrich" step involves adding additional data to a message to make it more meaningful and useful to a target service or application. The Enrich service could be implemented to invoke another service to look up additional data, or it could access a database to get what it needs.
The "Transform" step converts the message to a target format. This often involves converting the data structure to an internal canonical format, or converting from the canonical format to the target format of the "Operate" step. The target system may have its own built-in validation rules requiring that the transformation step modify the incoming data in order to prevent the target system from rejecting the message. In this sense, the transformation step is also providing pre-validation protection in a separate service that can be separately managed. While this may mean redundant logic in the short term, it provides more flexibility in the long term, because it allows the "Operate" step to focus on business logic.
The "Operate" step is the invocation of the target service or an interaction with the target application. If the target operation is an enterprise application that requires its own data format, then the previous transformation step converts the message to the target format required by the application.
Variations: The VETRO Pattern
The VETO pattern has many variations. One such variation is the VETRO pattern, which includes a "Route" step such as a content-based router service (Figure 7).
In some cases the validate, enrich, and transform steps can be accomplished in one service implementation. For example, a CBR service may use a script-based validation directly in the service itself, rather than using a separate service. This may provide some convenience, particularly if the context of validation can't easily be applied to other uses. However, keeping them as separate services further promotes loose coupling and service reuse, and allows the validation to be separately defined and managed. Through the flexibility of configuration and deployment, that choice can be revisited over time without affecting all of the application endpoints that use the pattern. The stages of the VETO pattern can be implemented as separate services that can be configured, reused, and independently swapped out for alternate implementations.
The VETO concept is profoundly simple, yet is at the heart of what an integration architect does regularly with an ESB. An ESB provides an event-driven SOA for applications in an integration fabric. Regardless of the process routing and orchestration method being used - whether itineraries or the more sophisticated process modeling using an orchestration service - it is the use of integration patterns such as VETO and its variations that provide the overall value and flexibility to the integration fabric.
I hope that this brief introduction to the ESB and its use of integration patterns has provided you with insight into the internal workings of the ESB, and given you a sense of how an integration architect can use event-driven components as services to construct reusable integration patterns in an enterprise SOA. The VETO pattern is one of many being used in ESB-based integrations.
I encourage you to learn more about the ESB as a technology concept, for it is already rapidly changing the way integration is being done across a variety of industries. So get reading, and get on the bus!
The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering Cloud Expo and @ThingsExpo will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at Cloud Expo. Product announcements during our show provide your company with the most reach through our targeted audiences.
Oct. 23, 2016 12:30 PM EDT Reads: 4,484
When we talk about the impact of BYOD and BYOA and the Internet of Things, we often focus on the impact on data center architectures. That's because there will be an increasing need for authentication, for access control, for security, for application delivery as the number of potential endpoints (clients, devices, things) increases. That means scale in the data center. What we gloss over, what we skip, is that before any of these "things" ever makes a request to access an application it had to...
Oct. 23, 2016 12:15 PM EDT Reads: 13,644
Virgil consists of an open-source encryption library, which implements Cryptographic Message Syntax (CMS) and Elliptic Curve Integrated Encryption Scheme (ECIES) (including RSA schema), a Key Management API, and a cloud-based Key Management Service (Virgil Keys). The Virgil Keys Service consists of a public key service and a private key escrow service.
Oct. 23, 2016 09:45 AM EDT Reads: 1,020
Apache Hadoop is a key technology for gaining business insights from your Big Data, but the penetration into enterprises is shockingly low. In fact, Apache Hadoop and Big Data proponents recognize that this technology has not yet achieved its game-changing business potential. In his session at 19th Cloud Expo, John Mertic, director of program management for ODPi at The Linux Foundation, will explain why this is, how we can work together as an open data community to increase adoption, and the i...
Oct. 23, 2016 09:45 AM EDT Reads: 1,882
What do dependency resolution, situational awareness, and superheroes have in common? Meet Chris Corriere, a DevOps/Software Engineer at Autotrader, speaking on creative ways to maximize usage of all of the above. Mark Miller, Community Advocate and senior storyteller at Sonatype, caught up with Chris to learn more about what his team is up to.
Oct. 23, 2016 09:30 AM EDT Reads: 1,483
All clouds are not equal. To succeed in a DevOps context, organizations should plan to develop/deploy apps across a choice of on-premise and public clouds simultaneously depending on the business needs. This is where the concept of the Lean Cloud comes in - resting on the idea that you often need to relocate your app modules over their life cycles for both innovation and operational efficiency in the cloud. In his session at @DevOpsSummit at19th Cloud Expo, Valentin (Val) Bercovici, CTO of So...
Oct. 23, 2016 09:30 AM EDT Reads: 2,122
Monitoring of Docker environments is challenging. Why? Because each container typically runs a single process, has its own environment, utilizes virtual networks, or has various methods of managing storage. Traditional monitoring solutions take metrics from each server and applications they run. These servers and applications running on them are typically very static, with very long uptimes. Docker deployments are different: a set of containers may run many applications, all sharing the resource...
Oct. 23, 2016 09:00 AM EDT Reads: 3,492
SYS-CON Events announced today that eCube Systems, the leading provider of modern development tools and best practices for Continuous Integration on OpenVMS, will exhibit at SYS-CON's @DevOpsSummit at Cloud Expo New York, which will take place on June 7-9, 2016, at the Javits Center in New York City, NY. eCube Systems offers a family of middleware products and development tools that maximize return on technology investment by leveraging existing technical equity to meet evolving business needs. ...
Oct. 23, 2016 09:00 AM EDT Reads: 4,457
DevOps is a term that comes full of controversy. A lot of people are on the bandwagon, while others are waiting for the term to jump the shark, and eventually go back to business as usual. Regardless of where you are along the specturm of loving or hating the term DevOps, one thing is certain. More and more people are using it to describe a system administrator who uses scripts, or tools like, Chef, Puppet or Ansible, in order to provision infrastructure. There is also usually an expectation of...
Oct. 23, 2016 08:45 AM EDT Reads: 1,579
JetBlue Airways uses virtual environments to reduce software development costs, centralize performance testing, and create a climate for continuous integration and real-time monitoring of mobile applications. The next BriefingsDirect Voice of the Customer performance engineering case study discussion examines how JetBlue Airways in New York uses virtual environments to reduce software development costs, centralize performance testing, and create a climate for continuous integration and real-tim...
Oct. 23, 2016 08:30 AM EDT Reads: 1,254
The general concepts of DevOps have played a central role advancing the modern software delivery industry. With the library of DevOps best practices, tips and guides expanding quickly, it can be difficult to track down the best and most accurate resources and information. In order to help the software development community, and to further our own learning, we reached out to leading industry analysts and asked them about an increasingly popular tenet of a DevOps transformation: collaboration.
Oct. 23, 2016 08:15 AM EDT Reads: 1,282
At its core DevOps is all about collaboration. The lines of communication must be opened and it takes some effort to ensure that they stay that way. It’s easy to pay lip service to trends and talk about implementing new methodologies, but without action, real benefits cannot be realized. Success requires planning, advocates empowered to effect change, and, of course, the right tooling. To bring about a cultural shift it’s important to share challenges. In simple terms, ensuring that everyone k...
Oct. 23, 2016 08:00 AM EDT Reads: 12,481
In case you haven’t heard, the new hotness in app architectures is serverless. Mainly restricted to cloud environments (Amazon Lambda, Google Cloud Functions, Microsoft Azure Functions) the general concept is that you don’t have to worry about anything but the small snippets of code (functions) you write to do something when something happens. That’s an event-driven model, by the way, that should be very familiar to anyone who has taken advantage of a programmable proxy to do app or API routing ...
Oct. 23, 2016 08:00 AM EDT Reads: 1,239
DevOps is speeding towards the IT world like a freight train and the hype around it is deafening. There is no reason to be afraid of this change as it is the natural reaction to the agile movement that revolutionized development just a few years ago. By definition, DevOps is the natural alignment of IT performance to business profitability. The relevance of this has yet to be quantified but it has been suggested that the route to the CEO’s chair will come from the IT leaders that successfully ma...
Oct. 23, 2016 06:15 AM EDT Reads: 16,387
SYS-CON Events announced today that SoftNet Solutions will exhibit at the 19th International Cloud Expo, which will take place on November 1–3, 2016, at the Santa Clara Convention Center in Santa Clara, CA. SoftNet Solutions specializes in Enterprise Solutions for Hadoop and Big Data. It offers customers the most open, robust, and value-conscious portfolio of solutions, services, and tools for the shortest route to success with Big Data. The unique differentiator is the ability to architect and ...
Oct. 23, 2016 06:00 AM EDT Reads: 713
DevOps is being widely accepted (if not fully adopted) as essential in enterprise IT. But as Enterprise DevOps gains maturity, expands scope, and increases velocity, the need for data-driven decisions across teams becomes more acute. DevOps teams in any modern business must wrangle the ‘digital exhaust’ from the delivery toolchain, "pervasive" and "cognitive" computing, APIs and services, mobile devices and applications, the Internet of Things, and now even blockchain. In this power panel at @...
Oct. 23, 2016 05:15 AM EDT Reads: 1,845
@DevOpsSummit has been named the ‘Top DevOps Influencer' by iTrend. iTrend processes millions of conversations, tweets, interactions, news articles, press releases, blog posts - and extract meaning form them and analyzes mobile and desktop software platforms used to communicate, various metadata (such as geo location), and automation tools. In overall placement, @DevOpsSummit ranked as the number one ‘DevOps Influencer' followed by @CloudExpo at third, and @MicroservicesE at 24th.
Oct. 23, 2016 04:00 AM EDT Reads: 3,952
As software becomes more and more complex, we, as software developers, have been splitting up our code into smaller and smaller components. This is also true for the environment in which we run our code: going from bare metal, to VMs to the modern-day Cloud Native world of containers, schedulers and microservices. While we have figured out how to run containerized applications in the cloud using schedulers, we've yet to come up with a good solution to bridge the gap between getting your conta...
Oct. 23, 2016 03:30 AM EDT Reads: 1,454
Without lifecycle traceability and visibility across the tool chain, stakeholders from Planning-to-Ops have limited insight and answers to who, what, when, why and how across the DevOps lifecycle. This impacts the ability to deliver high quality software at the needed velocity to drive positive business outcomes. In his session at @DevOpsSummit 19th Cloud Expo, Eric Robertson, General Manager at CollabNet, will show how customers are able to achieve a level of transparency that enables everyon...
Oct. 23, 2016 03:00 AM EDT Reads: 1,275
DevOps theory promotes a culture of continuous improvement built on collaboration, empowerment, systems thinking, and feedback loops. But how do you collaborate effectively across the traditional silos? How can you make decisions without system-wide visibility? How can you see the whole system when it is spread across teams and locations? How do you close feedback loops across teams and activities delivering complex multi-tier, cloud, container, serverless, and/or API-based services?
Oct. 23, 2016 02:15 AM EDT Reads: 1,019