XML RPC Server Handling!

, ,
1

Any information on the following is greatly appreciated:

  1. Could XML RPC Server be setup to save/serve session cookies from/to HTTPS web services? A user installation on Unix think performance might be affected because session cookies are not handled efficiently!

  2. The handling on IN/OUT mapping of fields seems to be tricky, especially when using numeric fields in the mix and using groups versus level 1 fields. In order to avoid malformed document response in the Natural client, “AD” attributes had to be used on the CALLNAT. Does anyone know the exact behavior of the XMLRPC Server for handling OUT parameters? Is this a bug in the XMLRPC Server where the RPC format/data buffers are not built completely for the response, when restricting the IN/OUT parameters and not making everything InOut???

TIA
EM

2

Regarding 1): The HTTP/HTTPS handling is done completely by the Java Runtime of the JVM (using the classes from the java.net package). HTTP details like session cookies or keep alive is transparent to the XML RPC Server. I can’t see why using session cookies should improve performance.

Regarding 2): It might be a good idea to contact support with all relevant information. Looks like your IDL definition and your Natural client program are not in sync.

3

Hi Rolf,

  1. The Web Service being used already using session cookies and requiring a certificate. The user thinks session cookies are not handled efficiently which sounds to me like they are not being saved on XMLRPC Server side. Since the XMLRPC Server is running on Unix OS, is their a way to make a cookie folder definition visible/permissible with the startup of the JVM/XMLRPCServer? There isn’t such a folder defined on this Unix image as you would see when using a browser/Windows! I believe one way to circumvent this is to use the new Java API. However, since the JVM is handling this as you mentioned, does the JVM cache the cookie or something has to be set to force it to cache the cookie?

  2. I’ve seen this happening on a couple of scenrios and where the IDL was certainly matching client program parms. I will try to reproduce it and contact
    support with details.

Thank you very much,
Emad

4

Hi Emad,

You need to be aware that cookies are not part of the HTTP specification. They are just ordinary HTTP headers used by both a web server and a web browser. I assume that the JVM does not handle cookies because that should be done by the calling application. The XML RPC Server does not know about cookies. Calls handled by the XML RPC Server are typically stateless without having a session. I think it would be very dangerous if the XML RPC Server would analyze cookies and would try to assign them to RPC client requests.

5

pardon my confusion…cookies are saved on the client side, not the server side. Clients can choose to not save cookies. You don’t specify a folder on the server side - it is up to the client browser to decide where the cookies are stored. The effieciency or not is up to the browser.

So why is the customer asking the XML RPC Server to store the cookies?

6

Hi Doug,

The XMLRPCServer is acting as a client to the WebService - No Browser is being used at all. The WebService seems to utilize cookie to reduce the time for autenticating client’s certificate, I think! The client/XMLRPCServer has just one certificate, which is used for all “Natural client users” calling the WebService. Natural client programs are both batch and online. Therefore, in case of batch, significant time could be saved if session cookie stays alive!

Emad

7

For batch, you might want to experiment with having the Natural programs use conversational mode - it reduces the overhead a bit. From the Natural programs, use the OPEN CONVERSATION statement, listing the “subprograms” that are to be called via RPC, and the CLOSE CONVERSATION once the batch processing is completed.

With EXS, using conversations reduced elapsed times by a bit more than 5% for batch usage from mainframe to Java RPC. Your mileage may vary :slight_smile:

8

Hi Emad,

The XML RPC Server is a HTTP client, but it is not a browser. As already mentioned cookies are not part of the HTTP spec, they are a technology used by web browsers and web servers. I would be very reluctant to have cookie processing in the XML RPC Server.

If the user wants to use a different HTTP client processing (with cookies) they should look at the new Java API for the XML RPC Server which has been introduced with EntireX 7.2.1.50.
See the documentation for details. This API allows the user e.g. to implement a customized HTTPS processing.