adapters & the j2ee connector architecture it 490

Adapters & the J2EE Connector ArchitectureIT 490

Stan Senesy

IT Program

NJIT

J2EE Connector Architecture

• Adapters– Deal with the implications and details of underlying

applications, databases, ect.– Usually coded based upon an existing standard (XML,

etc)– Adapters are best purchased as opposed to coded

due to their complexity

J2EE Connector Architecture

• Adapters– Adapters server as the layer between the integration

server and the target application. They may function as an API that allow the common access to a number of differing products

– As adapters have evolved, they’ve become smaller and smarter, with more application logic placed into the adapter

J2EE Connector Architecture

• Adapters– Adapters fall into 2 categories:

• Thin

• Thick

• Figures 10.2 & 10.3

– Additionally, they provide 2 forms of behavior:• Static

• Dynamic

J2EE Connector Architecture

• Adapters– Adapters may be oriented at either the information or

service oriented levels– Information oriented serves to simply obtain

information from the source and move it to the integration server

– Service oriented adapters expose application functions so that they may be abstracted into composite applications

J2EE Connector Architecture

• Interface Types– Application interfaces provide various levels based on

their type, which include:• Static data

• Dynamic data

• Function return data

• Function return service

• Function return abstraction

J2EE Connector Architecture

• Static Data– The application interface returns simple information in

a static format that is not intended to be changed– This interface type works best with information

oriented adapters

J2EE Connector Architecture

• Dynamic Data– These interfaces provide access to a broader source

of data than static. A good example is through a database

– Dynamic data adapters work best with information oriented adapters and may allow the data to be changed

J2EE Connector Architecture

• Function Return Data– Provide access to many internal application functions

but only return responses to those functions– Since it serves to make these functions available to

other functions, it serves in both the information and service realms

J2EE Connector Architecture

• Function Return Service– Abstracts a static service to the integration server or

composite application– Can be bound to appear as a local function– Works primarily with service interfaces

J2EE Connector Architecture

• Function Return Abstraction– Allows the capacity to not only gain local access to a

remote service or function but also to alter the function to meet the needs of a new application

– Works with service based interfacing

J2EE Connector Architecture

• JCA defines a standard architecture that provides interoperability between integration servers

• While Java based, JCA may be adapted to serve in other environments as well

• JCA consists of a set of elements and services including:– System-level contracts and services– Common Client Interface (CCI)– Packaging and deployment interfaces

J2EE Connector Architecture

• System-level Contracts and Services– These are the interfaces between J2EE and the

enterprise integration system– They are implemented in the application server and

resource adapter– The might comprise a mix of vendors– Figure 10.7

J2EE Connector Architecture

• CCI– Defines the properties of a client API– Allows non-managed applications to utilize a JCA

resource adapter

J2EE Connector Architecture

• Packaging and Deployment Interfaces– Allow resource adapters to plug in to J2EE

applications

• JCA environments may be either managed or unmanaged

Application Integration Standards

• Extensible Markup Language (XML)– Robust human readable data exchange standard– Provides exchange for both semantics as well as

content– Allows predefined packaged applications a common

medium to integrate information– A major strength of XML is it’s simplicity. Large pieces

of information may be incorporated into a single XML document

Application Integration Standards

• XML– The Document Type Definition (DTD) determines the

structure of a XML document (syntax)– A parser reads the DTD and compares it to the

incoming data to parse for proper format (metadata)– Message-based standard– Figures 11.2 & 11.3

Application Integration Standards

• XML– What it adds:

• Foundation standard to build on

• Facilitates data transformation

• Growing support

– What it doesn’t add:• Not a substitute for middleware

• Text based format

• Application must support exporting data to XML

Application Integration Standards

• Electronic Business XML (ebXML)– Built on top of XML

• Adds the capacity for:– Process abstraction– Semantics– Notation– Security– And much more…

– A standard designed for electronic commerce– More of a set of guidelines than an actual integration

product– Figure 12.1

Application Integration Standards

• Business Process Execution Language for Web Services (BPEL4WS)– A standard based on combining together local and web services– Supports process as well as data integration– Supports a common standard from process engine to process

engine, rather than just an approach to how to do things– Has the potential to become a language-based standard for

process integration– Service-based standard– Figure 13.1

Application Integration Standards

• Uniform Council Code Net (UCCnet) and RosettaNet– Standards for supply chain integration– Both fall into the category of process-based standards– UCCnet uses a standard DTD structure to define the

valid blocks of a XML document into 3 layers:• Transport

– How to get the message from A to B

• Command– Function and operation

• Data/Document– Information the command acts on

Application Integration Standards

• UCCnet and RosettaNet– A set of standard processes that allow companies to

agree upon the processing of a standard business transaction

– Divided into the Partner Interface Processes (PIPs) and common dictionaries

– Figures 14.2 & 14.3

Application Integration Standards

• Web Service Standards– Simple Object Access Protocol (SOAP)

• Defines an XML based message format that web service-enabled applications can use to communicate and interoperate

• Works similarly to RPC, as adapted for use in CORBA or DCOM

• A major player in the .NET integration framework

Application Integration Standards

• Web Service Description Language (WDSL)– Allows discovery of function and technical information

about web services– Consists of a number of elements:

• Type definitions

• Message definitions

• Operation definitions

• Port type definitions

• Binding definitions

• Service definitions

Application Integration Standards

• Universal Description, Discovery and Integration (UDDI)– A standard for cataloging and publishing WSDL descriptions of

web services that are available over the Internet– Consists of the following components:

• White pages– Address, contact information

• Yellow pages– Industrial categorizations

• Green pages– Technical information about exposed services

– Figure 15.3