Object SharingOn a Windows 2000 (XP etc.) platform, it is possible to ‘share’ the Component Enabler client object (the LINCEnvironment object) among users. This can be achieved by making use of the COM+ features of the platform itself.
Setting up is easy
The LINCEnvironment object can be made into a COM+ object, simply by declaring it as such using the Component Services console from the control panel. A wizard lets you choose the LINCEnvironment object from a list, after which it does the rest. Then, in the properties of the new COM+ object, you can turn on object pooling, and set minimum and maximum values for the pool.
Using it is easy
When creating a LINCEnvironment object in your client, the system will automatically return you one from the pool, rather than creating a new one.
To release the object, you simply need to clear any reference to it by your client. When the system detects that there are no more references to the object, it is automatically returned to the pool, ready for the next client to use.
Is there a catch?
On its own, this technique requires stateless Ispecs, as all users are in essence sharing the one EAE session, transaction number, and so on.
Stateful sessions, however, are possible in combination with Message Queuing.
Message Queuing.To avoid one TCP/IP socket connection per user, EAE Release 3.2 adds a Microsoft Message Queuing (MSMQ) transport.
With message queuing all requests are wrapped as messages and placed on a message queue. The Remote Access Servers (RAS) then read all user requests from the queue, using one (or more) TCP/IP socket(s). The request is then unwrapped, and passed to the EAE system to process.
While one request is being processed by the EAE system, RAS is available to read another message and pass it on to the EAE system. In this way we can achieve a higher throughput with just one connection.
When the EAE host has processed a request, the reply is picked up by RAS and sent back to the user’s reply queue (identified in the original message). RAS is then free to process more requests and replies while the client processes its reply.
If the connection nears saturation, it is possible to start another RAS process and connection to read from the request queue, thus doubling the potential throughput.
There’s more!
In addition to the reduction of TCP/IP socket connections, message queuing has also allowed us to store a ‘state key’ within the message infrastructure. This state key is used by the EAE system to restore the ‘state’ of the session for a particular user, to what it was at the end of the last reply.
Using this, the client can pass the state key with the next request, and know that EAE will restore the state as it was in the previous transaction. This means that items like GLB.WORK will work as it this were a normal terminal session.
Look in the Component Enabler class reference for the new methods that allow your client to get and set the state key.
And even more!
While message queuing can reduce the number of TCP/IP socket connections, in of itself, it still requires one LINCEnvironment object per user. However, in conjunction with object pooling described above, it is simple to share the LINCEnvironment objects amongst the clients, while still maintaining a stateful system.
SubclassingSubclassing is a technique in object-orientated languages, which allows you to expand upon, or change the behavior of the parent object.
What this means to you, is that it is possible to add new functions, or change functions of the LINCEnvironment class to work in the way you want.
This is best explained with an example. Using subclassing, it is simple to change the behavior of the LINCEnvironment object, such that it will automatically connect itself to your EAE host when you create the object. This can simplify your clients significantly. Such functionality would also be very useful where you may wish to make your system available to several parties, but do not wish them to know the details of how to connect.
If you wished all spaces to be replaced with for web access, you could simply write a method to do the substitution for you. This would be of most advantage when using a scripting client, as Java will run much faster as it is in essence, compiled.
Is this a component?
With subclassing, you can also move in the direction of making your EAE system appear as components. For instance, a single method call in your subclass could connect to the system, navigate to a particular Ispec, and then gather data from multiple Ispecs, before returning the data to the client. From the client perspective, it was all achieved with a single invocation of a component. The actual mechanics of the call can be completely hidden from the client programmer.
Why stop at one?Each subclass can be given a different name, and individually registered as a COM (and even COM+) object. This allows you to create a series of components, all of which perform a different function. To the client programmer however, they simply appear as different components.
Pooling As individual components, they can also be pooled individually. As pooled objects, they might only connect once, thus removing the connect and login overhead for subsequent clients.
Note that a subclassed, pooled object communicating via message queuing can be a very efficient (albeit more complex) solution to large numbers of WWW users.
Setting up is easy
The LINCEnvironment object can be made into a COM+ object, simply by declaring it as such using the Component Services console from the control panel. A wizard lets you choose the LINCEnvironment object from a list, after which it does the rest. Then, in the properties of the new COM+ object, you can turn on object pooling, and set minimum and maximum values for the pool.
Using it is easy
When creating a LINCEnvironment object in your client, the system will automatically return you one from the pool, rather than creating a new one.
To release the object, you simply need to clear any reference to it by your client. When the system detects that there are no more references to the object, it is automatically returned to the pool, ready for the next client to use.
Is there a catch?
On its own, this technique requires stateless Ispecs, as all users are in essence sharing the one EAE session, transaction number, and so on.
Stateful sessions, however, are possible in combination with Message Queuing.
Message Queuing.To avoid one TCP/IP socket connection per user, EAE Release 3.2 adds a Microsoft Message Queuing (MSMQ) transport.
With message queuing all requests are wrapped as messages and placed on a message queue. The Remote Access Servers (RAS) then read all user requests from the queue, using one (or more) TCP/IP socket(s). The request is then unwrapped, and passed to the EAE system to process.
While one request is being processed by the EAE system, RAS is available to read another message and pass it on to the EAE system. In this way we can achieve a higher throughput with just one connection.
When the EAE host has processed a request, the reply is picked up by RAS and sent back to the user’s reply queue (identified in the original message). RAS is then free to process more requests and replies while the client processes its reply.
If the connection nears saturation, it is possible to start another RAS process and connection to read from the request queue, thus doubling the potential throughput.
There’s more!
In addition to the reduction of TCP/IP socket connections, message queuing has also allowed us to store a ‘state key’ within the message infrastructure. This state key is used by the EAE system to restore the ‘state’ of the session for a particular user, to what it was at the end of the last reply.
Using this, the client can pass the state key with the next request, and know that EAE will restore the state as it was in the previous transaction. This means that items like GLB.WORK will work as it this were a normal terminal session.
Look in the Component Enabler class reference for the new methods that allow your client to get and set the state key.
And even more!
While message queuing can reduce the number of TCP/IP socket connections, in of itself, it still requires one LINCEnvironment object per user. However, in conjunction with object pooling described above, it is simple to share the LINCEnvironment objects amongst the clients, while still maintaining a stateful system.
SubclassingSubclassing is a technique in object-orientated languages, which allows you to expand upon, or change the behavior of the parent object.
What this means to you, is that it is possible to add new functions, or change functions of the LINCEnvironment class to work in the way you want.
This is best explained with an example. Using subclassing, it is simple to change the behavior of the LINCEnvironment object, such that it will automatically connect itself to your EAE host when you create the object. This can simplify your clients significantly. Such functionality would also be very useful where you may wish to make your system available to several parties, but do not wish them to know the details of how to connect.
If you wished all spaces to be replaced with for web access, you could simply write a method to do the substitution for you. This would be of most advantage when using a scripting client, as Java will run much faster as it is in essence, compiled.
Is this a component?
With subclassing, you can also move in the direction of making your EAE system appear as components. For instance, a single method call in your subclass could connect to the system, navigate to a particular Ispec, and then gather data from multiple Ispecs, before returning the data to the client. From the client perspective, it was all achieved with a single invocation of a component. The actual mechanics of the call can be completely hidden from the client programmer.
Why stop at one?Each subclass can be given a different name, and individually registered as a COM (and even COM+) object. This allows you to create a series of components, all of which perform a different function. To the client programmer however, they simply appear as different components.
Pooling As individual components, they can also be pooled individually. As pooled objects, they might only connect once, thus removing the connect and login overhead for subsequent clients.
Note that a subclassed, pooled object communicating via message queuing can be a very efficient (albeit more complex) solution to large numbers of WWW users.