You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Gonzalo A. Diethelm" <go...@aditiva.com> on 2002/06/25 19:43:15 UTC
Avalon 5 and integration
Disclaimer: newbie talking, wishful thinking mode on.
If this has been brought up before, my apologies. One of the things
I would like to see in Avalon 5 (4.5, x+1, whatever) is documented
patterns for integration with other component models (I'm using the
word component in a loose sense here). For example, we are using
EJBs in other projects, and I think it would be great to have a
documented way of approaching these scenarios:
* Components are implemented as Avalon components, EJBs are shallow
bridges to them.
* Components are implemented as EJBs, Avalon components serve as
interfaces to the components from the non-EJB world (is this doable
at all?).
* Hybrid mode: some components are EJBs, some are Avalonized.
The EJB model is just an example here, it would be nice to have well
documented patterns for doing this integration with Servlets, CORBA,
COM, etc. I don't know all of these very well, so it may be that it
is simply not possible to have this degree of integration, but I
think it would be very good to have documented patterns for Servlets
and EJBs at least.
Best regards, and thanks for a solid architecture.
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon 5 and integration
Posted by Berin Loritsch <bl...@apache.org>.
> From: Berin Loritsch [mailto:bloritsch@apache.org]
>
> > From: Gonzalo A. Diethelm [mailto:gonzalo.diethelm@aditiva.com]
> >
> > Disclaimer: newbie talking, wishful thinking mode on.
> >
> > If this has been brought up before, my apologies. One of the
> > things I would like to see in Avalon 5 (4.5, x+1, whatever)
> > is documented patterns for integration with other component
> > models (I'm using the word component in a loose sense here).
> > For example, we are using EJBs in other projects, and I think
> > it would be great to have a documented way of approaching
> > these scenarios:
>
> Please, no alarms about Avalon 5.
Sorry, I thought this was posted to the users list....
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon 5 and integration
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> > If this has been brought up before, my apologies. One of the
> > things I would like to see in Avalon 5 (4.5, x+1, whatever)
> > is documented patterns for integration with other component
> > models (I'm using the word component in a loose sense here).
> > For example, we are using EJBs in other projects, and I think
> > it would be great to have a documented way of approaching
> > these scenarios:
>
> Please, no alarms about Avalon 5.
??? Don't know what you mean by that...
> Now, as to you request for documentation, that can be satisfied
> while we are still in A4.
Ok, although I did say "(4.5, x+1, whatever)".
> There are several approaches we can take. There are several component
> models that Avalon can work with (or within). These include:
>
> * EJBs
> * CORBA
> * Servlets
> * Role Your Own
>
> For something like a servlet architecture, the best approach is
> embedding
> an Avalon container within the servlet. There are two ways you can do
> it. For the simple case where you have one servlet servicing all your
> requests, you have that contain the embedded Avalon container and make
> your calls to that. For a more distributed case, you would bind the
> container to JNDI and have all servlets access it. (Use a special
> purpose
> servlet that exists just to bind the Avalon container).
>
> To use a hybrid environment, where some components are EJBs or CORBA
> components and some are Avalon components, you would have to apply the
> same trick for the distributed servlets. Bind the Avalon container to
> JNDI and access it from all the other components. Unfortunately there
> is no portable way to do that. You can't use EJBs to bind the container
> either because their environment is too constrained (no access to the
> filesystem, no write access to JNDI, etc.).
>
> To use Avalon as your façade to the external EJB/CORBA components you
> *must* use the ServiceManager interface because it returns an Object
> instead of artificially forcing you to implement Component.
>
> For the Role Your Own components, it is your architecture so you have
> to decide.
>
> Hopefully this will get you pointed in the right direction. If there
> is anyone willing to donate some detailed instructions on how to best
> implement this, the Avalon team would be more than happy to post those
> instructions on the web.
This is good info, hopefully someone who knows how to do it will
take the time and make it the beginnings of documentation for the
use cases I enumerated.
Thanks,
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Avalon 5 and integration
Posted by Berin Loritsch <bl...@apache.org>.
> From: Gonzalo A. Diethelm [mailto:gonzalo.diethelm@aditiva.com]
>
> Disclaimer: newbie talking, wishful thinking mode on.
>
> If this has been brought up before, my apologies. One of the
> things I would like to see in Avalon 5 (4.5, x+1, whatever)
> is documented patterns for integration with other component
> models (I'm using the word component in a loose sense here).
> For example, we are using EJBs in other projects, and I think
> it would be great to have a documented way of approaching
> these scenarios:
Please, no alarms about Avalon 5.
Now, as to you request for documentation, that can be satisfied
while we are still in A4.
>
> * Components are implemented as Avalon components, EJBs are shallow
> bridges to them.
> * Components are implemented as EJBs, Avalon components serve as
> interfaces to the components from the non-EJB world (is this doable
> at all?).
> * Hybrid mode: some components are EJBs, some are Avalonized.
>
> The EJB model is just an example here, it would be nice to
> have well documented patterns for doing this integration with
> Servlets, CORBA, COM, etc. I don't know all of these very
> well, so it may be that it is simply not possible to have
> this degree of integration, but I think it would be very good
> to have documented patterns for Servlets and EJBs at least.
>
> Best regards, and thanks for a solid architecture.
:)
There are several approaches we can take. There are several component
models that Avalon can work with (or within). These include:
* EJBs
* CORBA
* Servlets
* Role Your Own
For something like a servlet architecture, the best approach is
embedding
an Avalon container within the servlet. There are two ways you can do
it. For the simple case where you have one servlet servicing all your
requests, you have that contain the embedded Avalon container and make
your calls to that. For a more distributed case, you would bind the
container to JNDI and have all servlets access it. (Use a special
purpose
servlet that exists just to bind the Avalon container).
To use a hybrid environment, where some components are EJBs or CORBA
components and some are Avalon components, you would have to apply the
same trick for the distributed servlets. Bind the Avalon container to
JNDI and access it from all the other components. Unfortunately there
is no portable way to do that. You can't use EJBs to bind the container
either because their environment is too constrained (no access to the
filesystem, no write access to JNDI, etc.).
To use Avalon as your façade to the external EJB/CORBA components you
*must* use the ServiceManager interface because it returns an Object
instead of artificially forcing you to implement Component.
For the Role Your Own components, it is your architecture so you have
to decide.
Hopefully this will get you pointed in the right direction. If there
is anyone willing to donate some detailed instructions on how to best
implement this, the Avalon team would be more than happy to post those
instructions on the web.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>