arava wrote:
> Hi ,
>
> We have to design an application server which accesses number of subsystems( 4
> -to be precise).
>
> We have a lot of restrictions on the access of the subsystems ...to quote one for
> example though our application server is multithreaded and can cater to a lot of
> concurrent requests but the API's to the subsystems are not multithreaded..They
> Queue up the requests and send them one by one. So there comes the infamous
> performance issue!!!!
>
> So in our application server we spawn 4 threads to the 4 subsystems. So we ensure
> that by concurrently accessing the 4 subsystems we can improve performance...to
> be frank , accessing one by one ....we will loose all our clients who have to
> wait for a day to get their requests processed!!!!!
>
> So, in this scenario, given the restrictions that the EJB spec puts , i do not
> think that this system can be designed using EJB's as spawing your threads etc is
> not allowed.
>
> We are trying to use some J2EE server to improve scalability....but it seems that
> this will not work
>
> DOES EJB FAIL ?????Cant this system be designed using EJB's???
Arava,
Don't worry, you are describing a very common situation, and EJB does not fail.
The bit of the jigsaw you are missing is called a "connector".
A connector is effectively an extension of the application server. It can be
called by EJBs, but is not itself subject to the usual EJB restrictions. There
are off-the-shelf connectors for a number of different subsystems, but you
probably need to design your own.
A connector typically gets initialised by the application server at part of the
preparation for running EJBs in a JVM and is shut down politely by the server
when the JVM is no longer needed for EJBs. A connector typically creates threads
and uses semaphores, etc. It logically "owns" a number of connections to the
target subsystem and suballocates them to EJBs as needed. It also deals with
security on behalf of the EJBs. A connector should not involve itself in the
format or meaning of the data passing back and forth - it should be merely a
pipe. It is a separate job - usually in the domain of AD tools, to provide a
simple-to-use API to the service provided by the subsystem.
A good example of a connector is how EJBs access JDBC.
cheers... Ian
Ian McCallion
Alexis Systems Limited
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
