J2EE Connector Architecture and Enterprise Application Integration [Sharma, Stearns & Ng 2001-12-24].pdf

(4936 KB) Pobierz
425713174 UNPDF
J2EE Connector Architecture and Enterprise Application Integration
Rahul Sharma
Beth Stearns
Tony Ng
Publisher: Addison Wesley
First Edition December 01, 2001
ISBN: 0-201-77580-8, 416 pages
Front Matter
About the Author
The Java(TM) 2 Enterprise Edition (J2EE) platform connector architecture is the key component in
Java’s support for enterprise application integration (EAI) and for linking enterprise information
systems (EISs) with Web services. Because many services are now provided through the Web, it is
essential that business enterprises have an efficient EAI solution. J2EE(TM) Connector Architecture
and Enterprise Application Integration is the definitive guide to showing enterprise organizations
how to incorporate existing enterprise infrastructure and applications, taking them into the
Web-enabled economy of the future.
Written for application component developers who are building Connector architecture applications,
J2EE(TM) Connector Architecture and Enterprise Application Integration explains how to connect
applications not only to one another but also to a multitude of EISs and legacy systems. This book is
also of interest to independent software developers (ISVs) and others who develop resource adapters
for specific EISs. Readers will learn how to link underlying infrastructure products with J2EE
application server and platform technologies.
TEAMFLY PRESENTS
425713174.001.png 425713174.002.png
Table of Content
A
B
C
Foreword
Standards can redefine a marketplace—consider the impact that SQL had in launching the relational database
market. Standards can also create new markets—without HTML, HTTP, and SSL, we would still be waiting for
the World Wide Web. That is why the Java community is so excited about Web Services and the Java™ 2
Enterprise Edition (J2EE™) Connector Architecture: we expect a similarly dramatic impact on application
integration.
By application integration (or simply “integration”), I do not just mean Enterprise Application Integration (EAI),
which I would characterize as Intranet integration, which happens behind the firewall. I am also including
business-to-business application integration (B2BI) wherein the applications from one company directly
interoperate with the applications of a business partner across the Internet or a Virtual Private Network. In fact,
EAI and B2BI are already converging: individual business units increasingly have their own IT infrastructure and
applications. So just as Web technologies are widely used on our Intranets, we can expect XML, Web Services,
and J2EE adapters to become common on our corporate networks. But I would take this one step further. The
majority of new applications today are built to plug into the Web. Going forward, we should demand that both
commercial off-the-shelf applications as well as “home grown” applications be “integration ready” out of the
box—ready to plug into this emerging integration “backplane” of Web Services.
Technology alone is never sufficient to drive this level of change. There also must be a compelling business case.
Today, large companies depend on tens of thousands of applications. Most of these applications operate in silos,
interconnecting only with their close peers. And the trend is toward proliferation. At the same time, the rigors of
competition are forcing our businesses to specialize—to focus on only what they do well. But as we divest and
outsource, we are forced to more closely integrate with our business partners.
Integration “after the fact” is such a pain point that some application vendors are now suggesting that the only
antidote is to purchase every business application from a single supplier so that they are “pre-integrated”—call
this “worst of breed.” For larger businesses such a prospect is absurd. What about the legacy applications and data?
What about the increasing demand for vertically specialized applications? What about the in-house software
essential for competitive differentiation?
So, while integration may well be the biggest source of information technology (IT) pain today, the integration
solutions market nevertheless remains fragmented. Growth is stilted by a lack of standards. Instead of a unifying
architecture, we have numerous small vendors offering highly proprietary technologies:
1. Proprietary protocols— The litmus test for a proprietary protocol is whether the same software stack
has to run on both sides of the network. The Web analogy is compelling—without HTML and HTTP, a
World Wide Web of heterogeneous clients talking to heterogeneous servers would not have happened.
Proprietary protocols simply do not work for the scale of integration we need on the Web. Beware: While
XML is a standard, XML document-passing conventions can still be highly proprietary. That's why the
emerging family of Web Services standards is so essential—SOAP, WSDL, UDDI, ebXML, BTP, and so
on. Without such standards, users will be unable to mix and match integration solutions as they have Web
technologies.
2. Proprietary adapters— Adapters map between new standards (such as Java technology and the J2EE
platform) and legacy technologies (including COBOL/CICS). Even with the emergence of XML and Web
Services, adapters remain essential because very little of today's legacy is going to directly support Web
Services. Adapters solve what could be called the “last mile” problem of integration—how do I get from
my XML/Web Services “backbone” into the legacy? Without a standard model for adapters, it's nearly
impossible to get critical mass. Instead of an enterprise software vendor delivering standard adapters with
its product, adapters are “one-off” by a small integration vendor or the system integrator.
3. Proprietary containers— Protocols and adapters are hosted in containers. Virtually all integration
solutions on the market today depend on proprietary containers. These containers are themselves
proprietary not just because the adapters and protocols are. Consider that little investment protection is
offered for the additional programming required to move data from one integration platform to another:
o Synchronous and asynchronous messaging (for hub-and-spoke as well as peer-to-peer integration
server networks)
o Security (authentication, authorization, privacy, non-repudiation)
o Transactions, compensating actions, and guaranteed delivery
o Message (data dependent) routing, load balancing, and failover
o Rules management, workflow, and multi-vendor collaboration
o Naming/directory (LDAP, UDDI)
o Transformation
o Repository and content management
I

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin