We were implemented years ago a SOA system where various clients from different origins and technologies call this SOA system which in turn distributes requests to various “service providers” and return back their replies.
One of the service providers is a remote mainframe’s Natural programs. We actually implements what Rolf has told us in this forum and I quote:
- Using EntireX workbench (running on non mainframe machine) to extract the IDL
- Using EntireX IDL to Java code generator, thus getting java source code
- Compile the java code and create a jar file - the client
- Ensure that the java class path contains the entirex.jar file
- Invoke the method from the client jar file which in turn sends message that suppose to reach the required mainframe Natural program.
- EntireX Broker intercepts the requested message and forwards it to the Natural RPC Server
- The Natural RPC Server invokes the natural subprogram and return the reply to the Broker
- EntireX Broker intercept the reply and hand it over to the client.
The above first 5 steps are done inside out SOA system and it works like charm
Now, the people from the Natural “side” want to send requests to remote service providers that the above home grown SOA system has already access to. I would like to know if there is an easy way to implement similar steps to the above (“Rolf steps”) but from “bottom to top”: The natural programs are the client and their calls should be forwarded (via RPC, Broker) to our SOA system, executed and return the reply back to the Natural client.
I would like to get two kinds of solutions options (if there are more please let me know):
1. Assuming I supply to the Natural people either a generic Java or dot-net clients they can call which in turn, sends to our SOA front-end (Tomcat) a request to be processed. The request is in essence an HTTP request with XML payload. In this case I have to supply the client developer a priori, the structure of the XML to be passed by their call for each kind of service provider they need access to.
or the less preferable option (because the complexity is quite unknown for me):
2. Assuming I can develop a listener (must be in Java) which is called by the EntireX broker originated by calls from natural clients. In this case I also expect, as mentioned in option 1, to read a request object which contains the same “standardized” content like required service name and XML payload.