1 / 28

J2EE Connector Architecture

J2EE Connector Architecture. Outline. Connector Overview Goals J2EE Integration Common Client Interface (CCI) Object Model Example Usage System Contracts Connection Pooling Transactions Security Deployment (.rar files) Future Direction. Connector Goals.

belva
Download Presentation

J2EE Connector Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. J2EE Connector Architecture

  2. Outline • Connector Overview • Goals • J2EE Integration • Common Client Interface (CCI) • Object Model • Example Usage • System Contracts • Connection Pooling • Transactions • Security • Deployment (.rar files) • Future Direction

  3. Connector Goals • Provide standardized interfaces to Enterprise Information Systems (EIS) • Mainframe Transaction Processing (TPs) - CICS, Tuxedo • Enterprise Resource Planning (ERP) - PeopleSoft, SAP • Database Systems - JDBC, LDAP • The Resource Adapter (RA) is a system-level software driver used to connect to an EIS • The resource adapter may be utilized in a managed (application server) or non-managed environment • Primary goal is to smoothly integrate J2EE components and EIS systems • Support general capabilities of J2EE 1.3 application servers • Scalability (typically via Pooling, Lifecycle management, clustering) • Distributed Transactions • Security

  4. Contracts • A resource adapter supports three types of contracts • The Application contract (may support CCI) • A JCA Resource Adapter is not required to support any specific application contract (e.g. future versions of JDBC) • The JCA System contracts • Connection Management • Transaction Management • Security Management • The EIS protocol contract (typically proprietary) • The packaging of the adapter could also be considered a contract • Follows J2EE jar and deployment descriptor pattern

  5. App Server Connection Manager Transaction Manager Security Manager High-Level Connector Architecture Container-Component Contract Application Component Application Contract (may be CCI) JCA Resource Adapter JCA System Contracts EIS-Specific Protocol EIS

  6. Application Contracts • The application contracts apply to user interaction with the Resource Adapter • Whether from a J2EE component or standalone • Ideally, the contracts extend standard interfaces detailed in the Connector Specification • Called the “Common Client Interface” or CCI • Interfaces provide standardization for: • obtaining connections • submitting synchronous requests for record-based data • querying metadata • controlling local transactions • Support for CCI is NOT required • Vendor may provide totally proprietary interfaces

  7. Common Client Interface and JDBC • Like JDBC, CCI deals with record-oriented queries and follows a similar usage pattern

  8. “Spec” classes • CCI includes the ConnectionSpec to pass arbitrary information • An empty interface • Implementation defines properties following JavaBean conventions (get/set) • Standard Properties: UserName, Password • InteractionSpec • connection.getInteraction() takes an InteractionSpec argument • Also a JavaBean with standard properties • FunctionName • ExecutionTimeout • FetchSize • InteractionVerb - synchronous actions • SYNC_SEND • SYNC_SEND_RECEIVE (default) • SYNC_RECEIVE • ResultSetType - java.sql.ResultSet (FORWARD, SCROLL_SENSITIVE) • ResultSetConcurrency - java.sql.ResultSet (READ_ONLY, UPDATABLE) • May be bound in JNDI as a resource environment reference (like JMS Topics) public interface javax.resource.cci.InteractionSpec extends Serializable { public static final int SYNC_SEND = 0; public static final int SYNC_SEND_RECEIVE = 1; public static final int SYNC_RECEIVE = 2; }

  9. Records • An Interaction uses Record objects to qualify invocations and receive data in response

  10. Records (cont’d) • Records may be created through a provided implementation of the RecordFactory interface • The MappedRecord is a Map • The IndexedRecord is a List • Either may contain hierarchical structures of Records • The create() methods of the factory take a recordName as an argument • The factory will utilize this name to reference meta information related to the construction of the record type • The resource adapter may include additional means to create custom records

  11. ResultSet • The CCI ResultSet extends the JDBC ResultSet • Provides similar support for scrolling, type mapping, updatability • It may not support more advanced JDBC types • Blob, Clob, Array, Ref, Distinct, Struct, customized mapping • java.sql.ResultSetMetaData is reused • Query column name, type, etc. • ResultSetInfo provides information on the supported ResultSet functionality • e.g. visibility of updates and inserts

  12. CCI Example - CICS Connector // STANDALONE //create and set values for a managed connection factory for EPI EPIManagedConnectionFactory mcf =new EPIManagedConnectionFactory(); cf.setConnectionURL("tcp://gunner.almaden.ibm.com"); cf.setServerName("SCSCPAA6"); ConnectionFactory cxf=(ConnectionFactory)mcf.createConnectionFactory(); // or J2EE (using Environment Naming Context) InitialContext ctx = new InitialContext(); ConnectionFactory cxf = (ConnectionFactory)ctx.lookup(“java:comp/env/jca/myConnector”); //create a connection object Connection connection =cxf.getConnection(); //create an interaction with CICS to start transaction EPIP Interaction interaction =connection.createInteraction(); May pass ConnectionSpec to define identity, context, etc.

  13. CCI Example - CICS Connector // Implements InteractionSpec EPIInteractionSpec iSpec =new EPIInteractionSpec(); iSpec.setFunctionName("EPIP"); // well-known property iSpec.setAID(AIDKey.enter); // vendor-specific property iSpec.setInteractionVerb(InteractionSpec.SYNC_SEND_RECEIVE); // default // Create a record to store the response from CICS - implements Record // Can create records in this way or through RecordFactory implementations // obtained via ConnectionFactory.getRecordFactory() EPIScreenRecord screen =new EPIScreenRecordImpl(); // execute w/ InteractionSpec, InputRecord, OutputRecord boolean rc =interaction.execute(iSpec,null,screen); //close the interaction and connection interaction.close(); connection.close();

  14. Connection Management • The connection management contract allows the resource adapter to leverage application server support for connection pooling • May manage their own pools in a non-managed environment • Application component (EJB, servlet, client) looks up a Connection Factory in JNDI using the Environment Naming Context (ENC) • Component requests a Connection Handle - possibly passing additional information import javax.resource.cci.ConnectionFactory; import javax.resource.cci.ConnectionFactory; import javax.naming.InitialContext; ... InitialContext ctx = new InitialContext(); ConnectionFactory fcty = (ConnectionFactory)ctx.lookup(“java:comp/env/eis/myEIS”); Connection conn = fcty.getConnection(new MyEISConnectionSpec(data)); Note that this example assumes support of CCI

  15. Connection Management (cont’d) • Multiple connection handles may refer to the same underlying ManagedConnection (physical connection) • The app server will examine its pool of connections and determine a subset which could match the request (<res-sharing-scope>) • The app server calls matchManagedConnection() on the resource adapter with parameters: • Information passed to getConnection() (via a ConnectionSpec if CCI) • Security information for the current principal (javax.security.auth.Subject) • A subset of active connections (based on app server logic) • If none of the candidates match, the app server will request a new connection • Note that over time the app server may associate many different connection handles with a single ManagedConnection (@see associateConnection())

  16. Connection Management Interaction RA must provide for non-managed

  17. Transaction Management Contract • J2EE distinguishes two types of transactions and contracts for each • A transaction controlled external to the resource manager is an XA or JTA transaction • The resource manager may only support one-phase commit of XA transactions • A transaction managed internal to the resource manager is a local transaction • An adapter may support either, both, or neither (<transaction-support>) public interface javax.resource.spi.ManagedConnection { … javax.transaction.xa.XAResource getXAResource() throws ResourceException; javax.resource.spi.LocalTransaction getLocalTransaction() throws ResourceException; ... }

  18. Transaction Management • Many scenarios are problematic if all resource managers do not support XA transactions with 2PC • The same thread of execution (involving one or more app components) may only utilize a single non-XA RA • In general, use of non-XA and XA capable RAs may not be mixed in the same thread of execution • Local transactions may not span container boundaries (J2EE 1.3 spec) • But... higher performance is attained through the use of only local transactions • But how does server know a priori what resource managers will be involved in a transaction ? • Some advantage may be achieved through 1-PC optimization • 2PC “last resource optimization” may be provided by some app servers • Any number of non-transactional resource managers may be mixed with transactional ones

  19. XA Transaction Management • XA transactions are initiated and terminated (commit or rollback) in two basic ways in J2EE • By the container based on deployment descriptor settings • Explicitly by component code (Using JTA UserTransaction) • In neither case are low-level XA interfaces visible to components • Typically, container-managed transactions are used • In this scenario, a transaction context is active at the time the getConnection() call is made (upon entry into the method implementation) • After the app server obtains a ManagedConnection, it gets the XAResource from the connection and enlists it with the transaction manager • The final Connection.close() causes the resource to be delisted • At method completion, the container completes the transaction and the transaction manager utilizes the two-phase commit on all previously enlisted resources

  20. Local Transaction Management • Local transactions may be either container-managed or component-managed • Components manage local transactions using a RA-specific API (typically implementing javax.resource.cci.LocalTransaction) • The LocalTransaction instance is obtained from the connection • contains only start(), commit(), rollback() • In situations of component-managed local transactions the app server is notified of transaction events via the ConnectionEventListener public interface javax.resource.spi.ConnectionEventListener { … void localTransactionStarted(ConnectionEvent event); void localTransactionCommitted(ConnectionEvent event); void localTransactionRolledback(ConnectionEvent event); ... }

  21. Security Contracts • The application component provider has 2 options for EIS sign-on • Container -> Authentication details defined by the deployer • Application -> Passed to getConnection() by component code • Choice is defined in component deployment descriptor <res-auth> element • Adapters often provide default settings in their descriptors • Application-level authentication information is passed directly to the RM • Opaque to the connector architecture • Container-level authentication information is one two types • PasswordCredential • GenericCredential • The type passed to the adapter is defined by its deployment descriptor - <credential-interface>

  22. Container Authentication • JCA utilizes the JAAS APIs to pass authentication information • The app server creates a javax.security.auth.Subject object which contains a single principal and an instance of the correct Credential type • The Subject instance is passed to the ManagedConnectionFactory matchManagedConnection() or createManagedConnection() methods by the app server • The app server determines the contents of the Credential based on: • The principal identification in effect at the time of getConnection() • May be different from the authenticated user (e.g. EJB 2.0 runAs) • <authentication-mechanism-type> element(s) • deployment settings for mapping of principal identifications

  23. Resource Principal Identification • The resource principal identity for the adapter-EIS communication may be established by the deployer in various ways: • Configured Identity (static) • Identity is defined in descriptor • Principal Mapping • Each resource has a mapping of component principal -> resource principal • Caller Impersonation • Resource principal acts on behalf of the caller principal • Principal delegation specific to security mechanism (e.g. Kerberos) • Credentials Mapping • The principal identity remains the same but credentials are mapped to a different authentication domain

  24. Caching Manager • Current JCA architecture includes minimal contracts for a Caching Manager • The caching manager registers interest in transaction events • Similar to the EJB SessionSynchronization interface • beforeCompletion() - just prior to commit() • afterCompletion() - notifies whether transaction committed or rolledback • The caching manager services CCI queries and resyncs with the EIS when appropriate based on the above callbacks • Connector-based JDO implementations are Caching Managers

  25. Packaging and Deployment • Resource adapters are packaged in jar files similar to application components (suffix is .rar) • The Resource Adapter Archive contains all java and native files required to execute • Also contains the RAR deployment descriptor - ra.xml • Each application server typically provides a schema for an additional proprietary deployment descriptor • JNDI bind location • Details of security mapping

  26. Contents of the Deployment Descriptor • Class file identification • <connection-interface> and <connection-impl-class> • <connectionfactory-interface> and <connectionfactory-impl-class> • <managedconnectionfactory-class> • Security Settings • <authentication-mechanism-type>* - BasicPassword, Kerbv5, etc. • <credential-interface> - PasswordCredential or GenericCredential • <reauthentication-support> - Can ManagedConnections change principal ? • <security-permission> - special security permissions (standard “grant” .policy syntax) • use privileged code blocks to exercise • Misc • <license-required> • <config-property> - misc configuration values

  27. Future Direction • Specification • Pluggability of JMS Providers • Thread Management Contract • Needed to allow asynchronous communication with EIS • Finally have the ability to create threads (!?) • CCI support requirement • CCI XML support • Metadata - Query Interactions and Record types available • Submit Interactions as XML • Industry • Entity Bean CMP mapping to EIS ? • Greater variety and ease of use of EIS • Ability of new technologies to integrate with J2EE • JDO ?

  28. Vendors • Insevo • CICS, IMS, JD Edwards, Baan, SAP, Siebel, PeopleSoft • Support CCI and XML-based interface/schema repository • Bi-directional communication • Resource Adapters, Inc • SAP, PeopleSoft, Siebel, Oracle • Also support XML interaction and Bi-directional communication • SolarMetric, PrismTech, FastObjects, Versant • JDO Implementations w/JCA support • Sonic • Can plug RAs into SonicXQ as services

More Related