Adapters & the J2EE Connector Architecture IT 490

1. Adapters & the J2EE Connector ArchitectureIT 490 Stan Senesy IT Program NJIT

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. J2EE Connector Architecture • CCI • Defines the properties of a client API • Allows non-managed applications to utilize a JCA resource adapter

15. J2EE Connector Architecture • Packaging and Deployment Interfaces • Allow resource adapters to plug in to J2EE applications • JCA environments may be either managed or unmanaged

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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