Information Technology Reference
In-Depth Information
accessible application function (service) that may need to integrate with
other applications to fulfill its service contract. The drivers of data synchro-
nization and Web Services are also different. Web Services will generally be
initiated by a user request/event, whereas data synchronization is generally
initiated by state changes in data objects (e.g., customer, item, and order).
An event to which a Web Service reacts could be a user-initiated request
such as a purchase order or an online bill payment. User events can natu-
rally be generated by applications such as an order management application
requiring a customer status check from an accounting system. On the other
hand, a state change in a data object can be an activity like the addition of a
new customer record in the customer service application or an update to the
customer's billing address. These state changes trigger an adapter to add the
new customer record or update the customer record in all other applications
that keep their own copies of customer data.
For the J2EE to .NET application connectivity scenario, a connectivity
service in the form of a resource adapter is required. In this implementa-
tion strategy, Web Services can become the interface between the company
and its customers, partners, and suppliers, whereas the resource adapters
become integration components tying up different ESs inside the company.
This is just one potential implementation pattern in which Web Services
and resource adapters can coexist. Another potential integration pattern in
which Web Services and resource adapters are required to collaborate is in
business process integration. Applications that use business processes will
have to expose required functionality. Obviously, Web Services are ideal for
this purpose. When the applications need to integrate with other EISs to ful-
fill their part in the business process, they will use resource adapters.
9.2.6 ESB Scalability
Scalability is a particularly important issue for any automated business inte-
gration solution. Scalability concerns in the case of ESB translate to how well
the particular ESB implementation has been designed. The use of asynchro-
nous communications, message itineraries, and message and process def-
initions allows different parts of the ESB to operate independently of one
another. This results in a decentralized model providing complete flexibil-
ity in scaling any aspect of the integration network. Such a decentralized
architecture enables independent scalability of individual services as well
as the communications infrastructure itself. For instance, parallel execution
of business operations and itinerary-based routing significantly contribute
to the highly distributed nature of the ESB, as there is no centralized rule
engine to refer back to for each step in the process.
Typical integration broker technologies handle scalability using a central-
ized hub-and-spoke model; that is, they handle changes in load and configu-
ration by increasing broker capacity or by adding brokers in a centralized
location. A centralized rule engine for the routing of messages can quickly
Search WWH ::




Custom Search