axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Doug Davis" <>
Subject Re: Architecture consideration
Date Thu, 12 Apr 2001 11:10:06 GMT
In order to do this you would need a new AxisServlet (one that called
the AxisEngineEJB) and of course an AxisEngineEJB.  In order to
not duplicate code the AxisEngineEJB could then call the other
AxisEngine and everything should work just fine.  Seems like a fine
approach if using EJBs is what you want/need to do.  Do you think there
are some architectural changes to the core Axis code needed to
support this?

"Yuhichi Nakamura" <> on 04/12/2001 04:56:03 AM

Please respond to

Subject:  Architecture consideration

Food for thoughts:

So far, we have assumed a "single" AxisEngine architecure.
(I prefere the term "AxisEngine" than "AxisServer."
As I mentioned in the security thread, having multiple engines could
be a good idea.  What prevents multiple engine approach?
In the current codebase, multiple engines can be generated when
multiple instances of AxisServlet are generated.  Am I right?

many:1 relationship between AxisServlet and AxisEngine.
An AxisServlet is associated to an AxisEngine.  An AxisEngine
might be associated by multiple AxisServlet's.  This
indicates that AxisServlet does not perform routing.

In addtion to AxisServlet, we should want to provide
other transport listners such as SMTP, JMS, FTP, etc.
Furthermore, some AxisEngine instance might be shared by
these listners.  In that case, AxisEngine should be
put in a different JVM, and accessed by others remotely.
I prefer to provide AxisEngine EJB, and access it via RMI/IIOP.
This allows us to use J2EE security model (role-based

I believe that the above ideas are just an extension (hopefully natural)
of our current thoughts.  Any comments?

I think J2EE is the next big thing, so I want to consider how Axis
fits into J2EE.

Best regards,

Yuhichi Nakamura
IBM Tokyo Research Laboratory
Tel: +81-462-73-4668

View raw message