We are lookin’ for best practices to implement RPC connection
Some questions ?
Is the java a application a fat java client or is the code running in a multi-user WAS server ?
So talk about Unix security. So you think of using EXX security or not ?
Note that the is a standard pooling facility in the broker. See documentation.
It relates to BID field. Example
BID=ETB001:1971?poolsize=100&pooltimeout=6000
Keep connectikon alive. You talk about conversation RPC ?
We had setup in a .NET scenatio, and a multi-tier environement with .NET (no exx code), Windows server with EXX code, Mainframe a pooling mechanism.
This was in an environment with MF RACF security, where each end-user was logging on with his MF userID/password via EXX security and thru which we wanted to setup a pooling in the MS server environment where we had slots to communicate with the broker.
We used EXX token for that and maintained the security tokens that EXX security gave us in the middle tier (NT server). This way setting up a pooling mechanism.
Thsi runs since long in production. I do not know if you need the same kind if mechanism, but in java it should work as well.
The application is a multi-user WAS server.
We use the Unix security to valid access on this WAS server because we would like integrate this web application in our current system (SYGA) so that the users can continue to use the same userid and password in both systems. How EXX security could help us?
When I speak about “keep connection alive” I would like be sure that the following approach is valid: When a user is connected on the web application, the connection to the broker is established immediately and reserved for this user only. During the live of the web session, this user need will have to initiate several RPC conversations for a very short time each time. I would like to be sure doesn’t meet an error message like ‘timeout’ during the life of this web session.
If your application is using a generic or application userid - that is, the user id identifies the web application server, not the web users - then you can pool the Broker connection object.
If you are using a user specific connection, then you probably don’t want to pool the Broker objects, but keep them solely within the user’s session context. Each user should have their own Broker/Service objects and do a logon/logoff to establish and preserve their credentials.
EntireX Security can validate the logon against the Broker’s host operating system security - Unix security, in your case.
In any case, a timeout can happen if the objects are cached within the session, depending on the session timeout value versus the Broker timeout (conversation and client non activity timers). From what you have described, you would probably want the client non activity timer in Broker to be slightly greater than the web application session timeout value. If you are not using conversations (typically the case for web applications), then a small conversation time out value is usually appropriate, around 1 to 5 minutes - use the larger values only if a given call can requires longer time.
An option that reduces the resources required in the Broker is to use shorter timeouts, but add code to the application to handle the timeout errors (the specific error varies depending on the client wrapper) and do a silent re-login if needed. The Java Wrapper API includes this as an option (Broker.autoLogon method).