| home / programming / enterprise / 1 |   [previous] |
|
|
|
Now, if you were paying attention, you would have noticed a key phrase in the previous section: in theory. What an expert will tell you about web services in EAI is that they can deliver enormous benefits, but they cannot automatically replace all existing EAI infrastructure at once. At least, that is the story today. Several important issues have to be resolved first.
Because web services are not a software package, they have no inherent capability to manage the kind of enterprise message traffic required in EAI. EAI demands robust message management, reliability, and auditability. People need to know that their integrated applications are performing as expected. As a result, the consensus is that
EAI packages will be around for a while. However, they will most likely be web service– based, and that makes a big difference.
You will still need an EAI package that can work with an SOA, or equivalent, to manage the interoperation of systems in an SOA. Figure 5.13 shows what this might look like. Each side of the firewall has its own EAI package assuring smooth operation of the SOA. Do you notice anything different about them, though? In the figure, the EAI packages no longer have the “lock and key” symbolism of proprietary packages. That is because in the SOA, the EAI package becomes a piece of web services– based middleware.
For the EAI vendor, this is not great news. Being web services based likely means that they will no longer be able to sell as many add-on modules to interconnect various systems. If everything is web services based, the EAI vendor cannot justify selling a proprietary package. The SOA will almost certainly diminish, though not eliminate, the business of EAI propriety integration platforms and drive a trend where EAI companies will emphasize their “process tools” rather than the underlying integration technology.
Security is another big factor in adopting an SOA for EAI purposes. Impressive as the SOA looks in figure 5.13, it is entirely insecure. Because web services use Internet protocols for messaging, and because Internet messages are designed to go through the firewall, then web services are quite exposed to security breaches. Figure 5.14 illustrates how an unwelcome user could access web services in your SOA. There are some
excellent solutions to this problem, of course, and we address those later in the book. The point to remember is that web services in their natural state are completely open.
Organizational politics is other reason web services are not an instant panacea in EAI. There is a reason why those “islands of integration” appear in most enterprise architectures. Often, they are the result of divergent budgetary pressures or political pull. Whether we like it or not, people in organizations tend to like their “turf ” and want to expand their base of power. When these turf battles extend to IT, which they always do, the result is conflicting sets of priorities and agendas. Opening every system as a service is not going to make the issue of control, management, and budget go away. In fact, web services might compound the problems unless the organization works through the issues in advance.
For example, in our hypothetical company in figure 5.13, how is the accounting department going to react when it finds out that they have to support interoperation with the mainframe, the website, and the vendor’s systems in addition to those it already supports? Who is going to figure out what kinds of information can be accessed by the new users? Who is going to pay for the increased infrastructure required to pay for the new higher message volume? Who is going to pay for and execute the changes in security policy that must accompany an increase in the pool of potential users of a web service? If the accounting department decides to charge a usage fee for access to its web services as a “chargeback,” how is that issue resolved? These are but a few of the kinds of questions that automatically arise when systems are opened up in an SOA.
In sum, while exposing systems as standards-based services will bring powerful benefits, implementation requires a focused, disciplined approach to ensure effective results.
With EAI projects suffering from high costs, long cycle times, and a high rate of failure, the issue of integration has become a major headache for many IT managers. Though such projects are usually started with good intentions and intelligent design, corporate politics and unplanned changes in business process often result in multiple EAI projects locked together in incompatible “islands of integration” that build further barriers to true enterprise integration.
Web services have the potential to reduce the cost, time requirements, and complexity of EAI by enabling systems to interoperate using universally understood web service standards such as SOAP, WSDL, and UDDI. Because they are based on open standards, web services also promise to deliver some degree of vendor neutrality, or lack of dependence on specific vendors. However, security and performance issues, as well as organizational political considerations, mitigate against web services as a “magic bullet” in all EAI situations.
That said, existing EAI packages are likely to endure for many years due to their ability to manage enterprise-level transaction volume and assure performance of integrated systems. It is also highly probable that these EAI packages will migrate to web services standards, a move that will permanently alter their company business models. At that point, EAI companies will primarily compete with web services “enabling” companies who offer the ability to add enterprise-class security and transactional capabilities to an SOA, as well as process tool vendors who offer industry standardcompliant visual process modeling tools.
In the portal realm, web services add flexibility by enabling portal developers to swap out content sources virtually at will. In contrast to traditional portal design, where the developer must write or acquire a separate proprietary interface to each underlying data source that feeds into the portal, with web services the developer can write web service consumer software to invoke underlying applications or data sources.
In the field of software development, web services deliver on the long-sought promise of truly reusable software code. As virtual universal objects, web services enable object-oriented software to utilize any web service–exposed object regardless of the programming language used to create the object. As a result, web services have the potential to reduce or eliminate the costly, challenging process of rewriting software programs to conform to new operating system and hardware standards as companies modernize.
Written by Eric Pulier and Hugh Taylor with forward by Paul Gaffney and reproduced from "Understanding Enterprise SOA" by permission of Manning Publications Co. ISBN 1932394591, copyright 2005. All rights reserved. See http://www.manning.com
| home / programming / enterprise / 1 | [previous] |
Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | Shopping | E-mail Offers | Freelance Jobs 
Created: March 27, 2003
Revised: December 2, 2005
URL: http://webreference.com/programming/enterprise/1
