The following discussion deals only with planning/deployment on the “server side” using “EntireX/XML RPC Server” (no soap/wsdl related stuff) as intermediary between the Natural clients and the services they want to consume using a remote application gateway.
Facts on the application server side:
Consist of a front end servers (based on Tomcat) that directs input request to several servers doing the actual processing work and also invokes plenty of service providers
Existing client applications used to send requests to the above mentioned front end (the gateway) using HTTP protocol either directly or via java or dot-net proxy code.
One of the existing service providers which existing clients applications consume, are remote Natural programs via EntireX Broker residing on the remote mainframe side.
An Example of URL which represents client applications request to the gateway is: http://?service=<name1>&<app=<name2>&data=&other_params=
design time prep, configuration of XML RPC server & deployment
For each service to be consumed by the Natural client, get or produce the service data definition XSD files (one for input request parameters and the other for reply related parameters, the output).
For each XSD pairs use the ‘IDL Extractor for XML Schema’ to create an .IDL and a .XMM files.
Convey the .IDL & .XMM file pairs to the Natural client side developers.
Deploy the resulted XMM file to an existing (if this is not the first deployment) or new XML RPC server (1’st time deployment)
4.1 Do I have to also establish a “local” broker? - see fact 3 above
4.2 I saw pictures regrading deployment configration like: localhost:1971@RPC/XMLRPCSERVER01/CALLNAT. I understand that localhost:1971 is a broker listener but the exact meaning of each of the server-name parts (separated by "slash’) following the ‘@’ is not clear to me. What should I choose for them assuming that the XML RPC would run on my premise and not on remote mainframe?
4.3 The XSD files contains only data information (as opposed to WSDL which contains detailed service invocation information (URL, methods etc.):
4.3.1 So, how do I convey ‘wsdl - like’ equivalent operational information to the XML RPC server?
4.3.2 When I create the IDL from my XSD file, I deliberately force the IDL to contain two metadata needed for proper HTTP invocation by reflecting them in the Library & Program clauses. How can these two pieces of information can be reflected in the HTTP request that suppose to be emitted from the XML RPC Server? (see name1 & name2 in the above sample URL)
4.3.3 The deployment dialog box from the document indeed shows that I have to fill a URL. But If I want to fill it with the URL of my gateway I must add the above Library & Program names into the URL but I don’t see how. (see ‘name1’ & ‘name2’ in the sample URL above). - Those metadata values are not constant, each IDL contain different Library Program names.
4.4 I have mentioned above that clients of our gateway may use a java or dot-net proxy to access the gateway. So in order to solve the problem of the two metadata pieces hidden in the Library and Program clauses of the IDL, can I use instead a non-Http Url but some jar activation URL syntax that will be call by the XML RPC server with the XML runtime data that Natural clients has sent it?
Assuming the answer to this question is ‘yes you can’ I want the XML RPC server to call my proxy jar instead of posting URL directly to the gateway:
4.4.1 Is there any protocol I have to implement (in my proxy jar) in order to pass data from the XML RPC to the jar proxy executable? Is there any support in the XML RPC proxy to avoid loading this jar file on each request and doing it only once?
4.4.2 Alternatively, can I add my stub to the XML RPC server so that I will be able to control how to invoke my proxy jar file and transfer the XML data, the Library & Program names?
4.4.3 Are there significant disadvantages of using external jar activation in comparison to posting Http request directly to my gateway?
If there is a way for the XML RPC server to call my gateway directly (including passing the Library & Program information for each Natural request), Is there something I have to deploy on my gateway side (remember - its Tomcat)?
If the answer is yes
5.1 What do I have to deploy in the gateway?
5.2 Does it mean that XML RPC server calls must be directed to a specialized servlet that you are providing its source code and I have to complete it by forwarding the call after some processing to my regular servlet?
Whew. Its hard to read and respond to this many questions in one thread.
Generate a Natural client from the IDL using Designer. Convey the generated objects (subprogram, PDA and test program) to the Natural developers.
4.1 No need for a “local” broker. Just use the EntireX Broker already running (I’m assuming yours is on the mainframe based on your comments)
4.2 Replace “localhost:1971” with the address of your EntireX Broker.You will need to obtain the port number from the mainframe systems folks who maintain that EntireX Broker. Host name is the DNS (or IP address) of your mainframe host.
The name following the at-sign (@) is referred to as the “SERVER NAME”. You will also see it identified as a trinity (=“3 parts”) or by its parts CLASS/SERVER/SERVICE. In your example, CLASS=RPC, SERVER=XMLRPCSERVER01, SERVICE=CALLNAT.
The Server Name is the identifier of a given service within the EntireX Broker (which can host many services). Typically, you leave the CLASS=RPC and SERVICE=CALLNAT (historical reasons, but also applicable if using Natural).
Natural really just uses the middle part (SERVICE=XMLRPCSERVER01), but EntireX Broker uses all 3 parts.
You have up to 32 characters to identify any part of the trinity, and it is case sensitive. So, for dealing with mainframe applications, all upper case is usually preferred.
Your XML RPC Server will run on your Windows (or *Nix) box, but it will connect to the EntireX Broker on the mainframe. The EntireX Broker is the switchboard - your Natural clients will also connect to the same EntireX Broker, looking for services that your server is offering, identified by the trinity name.
4.3.2 service, app, data, other_params should be the data elements of your IDL. XML RPC Server only supports level 1 elements for a GET operation as you are describing.
If you use POST to contain the XML document, you have more flexibility and your XSD’s will probably make more sense.
You could create a servlet that accepts a POST XML document and parses that into your HTTP GET request. Your XML RPC Server’s TargetServer name will be your servlet.
Incidentally - putting your XML on the HTTP URL is a weak approach - the URL length is limited by many conventions, URL encoding requirements will make it longer, harder to read and it is much harder to provide secure communication over the URL than to a payload POST document. I understand you are probably just dealing with the hand you’ve been given, but if you have any say, you should object to this request style.
Thank you Douglas.
Indeed the intention is to use HTTP/POST so the HTTP/GET example was just to clarify important parameters that for a given remote service are not changing regardless of the content of the XML payload. see in my post the part of the Get example ‘…?service=<name1>&<app=<name2>’.
Because of this I do not find it usable to specify in the IDL two constants parameters inside the XML payload and therefore I asked whether my idea to express those constants as Library->name1 & Program->name2 is not a better way, assuming that I can post those constants with the relevant XML payload to the remote gateway. Assuming that my idea is feasible, then how can I tell the XML RPC server from where to fetch this (Library & Program) parameters and to send them along with the XML payload in the Http/post request to the remote gateway.
Note: for each different service, this two parameters are changing (hence different Library & Program in the IDL) but for a given service they are constant for each request directed to the same service.
Also, I remember I once saw in the docs (but cannot find it now) the ability to use another invocation protocol “jar://…” which invokes jar file. Can you point me to the right place in the docs.
I haven’t tried this myself, but you might be able to include the service and app in the TargetServer. You’d have to have a TargetServer section for each combination, I think.
This allows you to manipulate the XML data. And you can (actually you have to) implement your own routine to call the external service via HTTP or whatever you want.
Note that you only get the request XML stream as input, there is no access to the library and/or program name.
I wouldn’t imagine that code development staff would be found in “administration” related document.
Anyway, from fast skimming over the document you have pointed to, it looks as if that would solve the problem of massaging/converting the input request payload into the required format that the remote gateway is expected.
Regarding the missing library and/or program name from the XML, my current thing is to “hide” it in the XML as part of namespace declaration in the XSD that is translated to IDL + XMM files. I guess that by having the this kind of “user exit” routine, I can easily retrieve this two missing pieces from the input XML and convert it to the required HTTP call.
If you read Douglas’ first reply, it says the following:
“Your XML RPC Server will run on your Windows (or *Nix) box, but it will connect to the EntireX Broker on the mainframe. The EntireX Broker is the switchboard - your Natural clients will also connect to the same EntireX Broker, looking for services that your server is offering, identified by the trinity name.”
Hi Jacob,
are you really calling an Integration Server flow from Natural using web services? If yes, then this is not the recommended approach. You should use the EntireX Adapter.