MAINFRAME > Administrator > IMS

Bringing IMS and SOA Together With IMS Connect

New requirements for IMS Connect functionality could make implementing an SOA environment with IMS easier and more flexible.

New requirements for IMS Connect functionality could make implementing an SOA environment with IMS easier and more flexible.

IBM* IMS*, the high-performance application server from IBM for the System z* platform, is part of the IBM effort to help businesses adopt a service oriented architecture (SOA).

A key feature of IMS in TCP/IP-based SOA environments is the integrated IMS Connect function. With it, IMS can provide information as a service to application programs running in distributed TCP/IP environments.

IMS Connect Client Flow

IMS Connect, which runs in a separate z/OS* address space from IMS, provides a TCP/IP gateway for IMS.

Application programs access IMS through IMS Connect using either the IMS Transaction Manager (TM) Resource Adapter (formerly IMS Connector for Java*) delivered with IBM WebSphere* Application Server, the IMS SOAP Gateway, which is available free online (www. ibm.com), or a user-written—or roll-your-own—IMS Connect client. These IMS Connect clients use TCP/IP sockets to communicate with IMS Connect and, ultimately, IMS.

The basic flow between a client and IMS Connect is shown in Figure 1:

  1. The client establishes a TCP/IP socket with IMS Connect using an IP address and port number.
  2. The client sends a transaction, a command or a request to retrieve queued output to IMS Connect.
  3. IMS Connect passes the incoming request to IMS by using the services of the z/OS cross-coupling facility (XCF).
  4. The IMS Open Transaction Manager (OTMA) component of IMS receives the request
  5. IMS processes the request
  6. The IMS OTMA component returns the response to IMS Connect.
  7. 7. IMS Connect returns the response to the client.

IMS Connect Client Configuration

IMS Connect clients can connect to IMS Connect through any of the TCP/IP addresses and ports associated with the TCP/IP stack.

IMS Connect supports two types of TCP/IP sockets: transaction sockets and persistent sockets. If a client sends one request to IMS at a time, the client should use transaction sockets, which remain open for one interaction with IMS. If a client sends multiple, frequent requests to IMS, persistent sockets are a better choice because they handle many requests over the same socket and minimize the overhead of establishing a socket. Persistent sockets are ideal when using SSL; the overhead of the SSL handshake is incurred only when the socket is opened.

The z/OS Communications Server sysplex distributor or the z/OS shareport option can be used to distribute client connections among multiple instances of IMS Connect. If an IMS Connect client uses persistent sockets, the effectiveness of the workload distribution is reduced, because the client’s workload can’t be redistributed while the same socket connection persists. Also, if an instance of IMS Connect terminates, client sessions on persistent sockets temporarily terminate also.

IMS Connect supports two IMS commit modes: commit-then-send (CM0) or send-then-commit (CM1). When CM0 is specified, IMS commits changes to IMS databases before returning a response to IMS Connect. When CM1 is specified, IMS sends the response to the client before committing changes to the IMS databases.

Specifying CM1 can impact IMS processing because while an IMS application program waits for the response to be sent before committing its changes, it can’t process new requests and can delay other IMS application programs trying to access the same data. If the client specifies an IMS synchronization level that requires either a positive (ACK) or negative (NAK) acknowledgement from the client for each response, the impact on processing can be even greater.

Specifying CM0 has a minimal impact on IMS processing. As soon as the changes are committed, database locks are released and other applications can access the data. As soon as the response is placed on the output queue, the IMS application program is free to process new requests.

Clients can retrieve CM0 responses on the output queue immediately or at a later time. When the client retrieves the response, it can send an ACK and IMS removes the response from the queue or it can send a NAK and IMS leaves the response on the queue for later retrieval.

Ben Johnson is an IBM information developer. He has been writing about IMS since 2003, focusing on both IMS database administration and IMS communications and connections, with a particular interest in OTMA and IMS Connect. He can be contacted at bpj@us.ibm.com.

Dave Cameron is a senior software engineer for IMS development. He can be contacted at daveac@ca.ibm.com.

Jack Yuan is a senior software engineer for IMS development. He can be contacted at jackyuan@us.ibm.com


comments powered by Disqus

Advertisement

Advertisement

2017 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Bringing IMS and SOA Together With IMS Connect

New requirements for IMS Connect functionality could make implementing an SOA environment with IMS easier and more flexible.

Celebrating 40 Successful Years

IMS version 10 supports synchronous and asynchronous callout

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters