There a large number of packaged solutions available in the market
which promise a complete and scalable solution to the problem of Enterprise
Application Integration (EAI) of existing legacy systems and Enterprise
Information Systems (EISs) with e-business applications.
I will be examining, for you, one of the tools, which seems to substantiate
such claims to a relatively larger extent than the rest i.e. Java.
Or to be more specific, the Java2 Enterprise Edition (J2EE), the connector
Architecture which, seems to be ideal for coming up with scalable, secure,
and transactional resource adapters for a wide range of EISs providing
options for ERP integration. E-business applications are moving to open
and standards-based technologies. A growing number of Web applications
package vendors are going for the J2EE specification as a result of
an industry partnership and open community process led by Sun Microsystems.
Whether this will lead to the chaos of another open source-like community
or a monopoly, only time will tell, but the fact is that standards are
evolving.
So now that we know what to use, let's have a look at how to use it.
J2EE applications require a J2EE-compliant application server, such
as IBM's WebSphere, BEA Systems' WebLogic, or IPlanet from the Sun/Netscape
Alliance. The application servers come with an HTTP server, a database,
and deployment tools. Because the servers comply with J2EE, they also
provide support for additional services, including naming and access,
resource pooling, transactions, and security. Because developers do
not have to bother with low-level service details, it is easy to develop
multi-tiered, distributed, scalable Java applications. J2EE services
also help in customizing applications at deployment. The typical architecture
for such a solution can be broken up into:
- The data level
Comprising of the legacy system and the database
- The Business level
A middle tier really comprising of maybe (depending on the ERP system)
CORBA interfaces, the JDBC connectors and the EJB that provide a platform
for the final level
- The front end or presentation level
The actual interface for the user which can take the form of servlets
and JSPs for HTTP, Java applications or applets or even Corba clients
Some ideas on actual development
The next few lines may sound like a load of Greek to those of you who
think Java stands for those relics on wheels but there are three approaches
to development with J2EE connectors.
- The application component could rely on an EAI framework for transactional
access to SAP and an RDBMS or
- The application component accesses a CICS transaction by programming
directly to the CCI, the adapter provided or
- The application component uses a J2EE connector specification-compliant
JDBC driver to write JDBC SQL statements against an RDBMS. Of these,
the second, developing directly with CCI can be the most complex.
The connector architecture specification is the result of a joint effort
of representatives from BEA, Fujitsu, IBM, Inline, Inprise, IPlanet,
Motorola, Oracle, SAP, Sun, Sybase, Tibco, and Unisys. A strong industry
representation in the development of this specification suggests that
a variety of application-development tools and EAI frameworks will soon
become available.
IBM's VisualAge for Java includes an EAI framework called Common Connector
Framework (CCF), which will form IBM's implementation of the J2EE Connector
Architecture specification. VisualAge for Java provides a CCF-based
tool called Enterprise Access Builder (EAB) that assists in developing
record definitions and ultimately exposing an EIS function in the form
of a JavaBean. The EAB can also be used to develop EJB-based access
to various EISs. In short, the architecture, although just out, holds
great promise for those interested in a dependable, economical, future-proof
EAI solution.
Services
