Adapters & the J2EE Connector Architecture IT 490
description
Transcript of 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