Java examples for web application

, ,
1

Hi smart people,

We are currently evaluating the use of EntireX with Java and we have a simple ‘best practice’ question. What object can we use to maintain state between pages without having to log in for every call to Broker (i.e. an object we can put in HTTPSession for use in subsequent JSPs)?

Our current sample application keeps a ‘logged in’ Broker object in Session which can then be used to instantiate the ‘wrapper’ (RPCService) objects we want to use, but I’m not sure this is the best solution. What is the SecurityToken and can it be used for this purpose? Are there some good Java coding samples out there, besides the ones included with the workbench?

Thanks for any help you can give us,

Craig

2

Hi Craig,

there is no simple answer to this - it depends on your environment and application:

  • Are you using security ?
    If yes, is the same userid used for all/most calls are do they differ from call to call ?
    Are you calling the same wrapper object or different ones ?
    Is your Broker configured with AUTOLOGON=YES or =NO ?

It also depends where you want to achieve an optimization:

  • Do you want to reduce the number of Broker calls ?
    Do you want to optimize the performance of the Java application ?
    Do you want to reduce the overhead of user authentication ?
    Do you want to reduce the number of client sessions (NUM-CLIENT) in the Broker ?

Maybe you can give us some information about your environment. Then it’s simpler to make a suggestion.

3

Hi Rolf,

Thanks for the reply. I’ll try to fill in the blanks and see if it helps:

Are you using security?

Yes, EntireX security would be used.

If yes, is the same userid used for all/most calls are do they differ from call to call?

Yes, I’m talking about one user’s session.

Are you calling the same wrapper object or different ones?

I would assume that different wrappers would be used depending on the functions the user executes.

Is your Broker configured with AUTOLOGON=YES or =NO?

Currently, it is set to AUTOLOGON=NO, I think. It’s set to the default, and I assume that would be NO.

It also depends where you want to achieve an optimization:

Do you want to reduce the number of Broker calls ?

I’m not sure. We just don’t want to “carry around” the user’s id and password throughout the user’s session. We want to log on once to authenticate and not have to pass the user’s credentials (user id and password) to Broker every single time we call it.

Do you want to optimize the performance of the Java application?

That would be nice.

Do you want to reduce the overhead of user authentication?

I don’t think it’s the overhead we’re concerned with. We just don’t want to constantly be passing the user’s credentials around.

Do you want to reduce the number of client sessions (NUM-CLIENT) in the Broker?

I don’t know, do I? I’m VERY new to this and haven’t looked into optimization strategies.

Does that help clarify things at all?

I guess I’m wondering what my options are, such as keeping a ‘logged on’ broker object in Session, and trying to find coding samples. I just don’t know all the ways available to manage these EntireX objects over the life of a user’s Session. Maybe I’m trying to do something that nobody else does or trying to avoid doing something that everybody else does do. Huh? Anyway, any suggestions would be greatly appreciated.

Thanks!

Craig

4

Hi Craig,

I think you are on the right track if you are going to cache the Broker objects.
Instantiating an object can be done like:

Broker b = new Broker(brokerid, userid);
b.useEntireXSecurity();
b.logon(password);

Save the Broker object in the cache.
To do a call, get a Broker instance out of the cache, and:

MyWrapperObject w = new MyWrapperObject(b, "RPC/SERVER/CALLNAT");
w.setXyz(...); ...
w.method(...);

and then put back b to the cache.

During logon processing a security token is generated and kept in the instance of class Broker. Thus all following calls will 1) not send the password and 2) force no reauthentication.

There is one important issue you need to take care about.

When you instantiate a Broker object and call the logon() method the Broker creates a user session for this client. The attribute file parameter NUM-CLIENT defines the maximum number of clients (independent from the used service). Make sure that NUM-CLIENT is high enough for the cached objects and all other applications using the same Broker kernel.

Normally the user session of this client is terminated by issuing a logoff() call. However, in this case it does not make sense to call logoff() because this would eliminate the advantanges of the caching. So we let the Broker kernel do the logoff automagically once the non-activity timeout for the client (CLIENT-NONACT in the attribute) expires. Then the next usage of the cached Broker object will result in a BrokerException because this user is not longer known (and authenticated) by the Broker kernel. So you need to catch the BrokerException, check for the “Logon required” error and issue a logon again. Here’s a code snippet to do that:

MyWrapperObject w = new MyWrapperObject(b, "RPC/SERVER/CALLNAT");
w.setXyz(...); ...
try {
    w.method(...);
}
catch (BrokerException be) {
    if (be.getErrorClass() == 20 && be.getErrorCode() == 134) {
        b.logon(password);
        w.method(...);
    }
    else {
        throw be;
    }
}
5

Thanks for the reply Rolf. I appreciate the help/tips.

Craig

6

Hi guys, I have a similar situation, I would like my application to login only once(with autologon(password)) to broker, but we also have a web application that logs in all the time, considering we have only 3 jobs running the RPC broker, will the first application hang on to one of the brokers, leaving only two for the web, since the first application holds one login?

7

A login to the EntireX Broker does not connect the user to an RPC Server. The default arrangement for RPC wrapper calls to the server is non-conversational - that is, the application makes one request, gets a reply and the “conversation” is immediately closed by Broker - the server is stateless.

Thus, the same user, logged into one Broker (ETBxxx), can use any number of servers (RPC/srv/CALLNAT), which will be able to service many other users virtually at the same time.

A server can be tied up by one client if you have long running server applications or are using conversations. Conversations provide the possibility of stateful server applications, but they dedicate the server to that client for the duration of the conversation. If this is required, you may need additonal server replicates to manage the load.