Thanks to the wide adoption of Service Oriented Architecture, the JBI specification is becoming more and more popular. With JBI, development of new integration components that can be installed in compliant Enterprise Service Bus (ESB) is possible, to act as bridges between the bus and the old communication technologies. The Jbi4Cics component is an Open Source JBI Binding Component that can be used to connect an ESB with a CICS system. In this article we present this component along with an integration use-case sample developed that shows off the JBI lifecycle.

Lot of ESBs allow plugging in JCA adapters - so how is this different from a service endpoint on the bus using a JCA CICS adapter to communicate with the CTG? Also, for JBI4CICS does the bus communicate with the BC over SOAP according to the generated WSDL?

The difference is this: JCA is a generic interface in which it is not always possible to obtain metadata of the service being called, instead JBI4Cics is specialized on using a JCA adapter for CICS so it can make assumption on the kind of data being transmitted. In particular by analyzing the Cobol Copybook it can infer the metadata of any CICS Service and give them a WSDL representation. So the answer to the second question is yes, any endppoint created with JBI4Cics is defined by a WSDL so messaeges flowing to that endpoint should be compliant with the WSDL definition. The protocol though is not exactly SOAP but is a Normalized Message (basically a wrapped document literal) as defined by the JBI specs.

Sorry, I should have made my question more explicit - so, what would be the advantage of using JBI4Cics over an IBM JCA CICS resource adapter? I would imagine the CICS resource adapter would also support obtaining metadata about the service and allow analyzing the COBOL copybooks.

I can tell you what are the differences, if those are advantages depends on your needs. A JCA adapter is designed to work inside a J2EE container to make resources, often transactional, available to ejbs. So here you have a programming model and it's expected that you code against the JCA API to access your data. JBI binding component instead can be used to make services based on whatever technology available inside an ESB BUS. So in this case there's no programming model you just configure the binding component and you can access the service as an endpoint inside the bus. For example you can have a bpel process calling the service. The main difference here is no programming just configuration. JBI4Cics happens to use the IBM JCA CICS connector behind the scene, but that is an implementation detail. The bottom line is that the comparison is not very fair because a JCA resource adapter and a JBI binding component are two different thing. If you want to make a comparison with ibm products you should look at their ESB (I'm not an expert of IBM product) but you should find that IBM ESB (even if it's not JBI compliant) has a CICS connector, which I guess it's based on IBM JCA CICS resource adapter itself.

Hello, Congratulation for your job on BC components (CICS IMS...) I already ask you this question (may be someone else could propose a solution to our problem). At office we have no mainframe, no CICS, no IMS. Does someone know a way to test your components (with public (open access) CISC or IMS Transaction for example) Thanks Paul

Hi, if you woud like to test the jbi4cics component without a CICS server you have to set the connection type to DUMMY (http://jbi4cics.sourceforge.net/userGuide.html). With DUMMY an echo service is created and the service doesn't connect to host. Regards Amedeo Cannone

If you are interested in just parsing copybooks and data based on said copybooks in Java applications, I have a completely unrelated open source project called cb2java. This tool requires no code generation and is not bound to XML or anything else other than copybooks and Java. Anyone who is willing to contribute or wants to evaluate this tool and provide feedback please do so in the cb2Java forums. I apologize for hijacking this thread.