Best practices: using ICE with object containers

[kwaclaw]

This relates to my last question regarding ICE and EJBs.

I am wondering if there are any best practices for how one should expose existing container managed objects (like EJBs or Spring beans, or objects managed by some IoC container) through an ICE API.

It seems that with ICE favouring one approach to concurrency control and life-cycle management, and the container having its own ideas about the same issues, there is some mismatch that seems hard to resolve.

Are there some special techniques that are helpful?

Karl

[matthew]

Hi Karl,

I'm not really sure what problems you are encountering. Perhaps if you expressed the question in more concrete terms, it would be easier to help you. For example, what lifecycle does the container impose, and why can't you similarly match the Ice object's lifecycle.

[kwaclaw]

Hi Karl,

I'm not really sure what problems you are encountering. Perhaps if you expressed the question in more concrete terms, it would be easier to help you. For example, what lifecycle does the container impose, and why can't you similarly match the Ice object's lifecycle.

I may not have expressed myself clearly, as things are not clear in my head.

For instance, if the application server receives a call for an object (EJB), it gets (or instantiates) the object from the container (factory) and dispatches the call to it. I don't see how ICE comes into the picture, as it would have to do what the application server does.

Obviously I can write a separate ICE process that calls into the application server as a client (through remoting), but that adds a level of complexity.

EJB containers support calling EJBs through IIOP without such a proxy server. So, I assume proper ICE support would have to be built into the application server itself.

Now, given a framework like Spring, which does not necessarily require an application server, things look more hopeful, as ICE can assume the role of the server. But is still more cumbersome compared to the built-in Spring remoting which allows for declaratively exposing a bean as a remote service. See for instance here: Chapter 17. Remoting and web services using Spring


Just trying to find an elegant way to get ICE inserted.

Karl

[joshmoore]

Our initial implementation of the OMERO server was a Spring context within a JBoss server. We currently support both a JBoss and an Ice-based server, which was relatively straight-forward using Ice's tie classes and the Spring interceptors which were already in place within JBoss.

If you have JBoss with Spring, I can explain how to go about this.

If not, keep things simple. Using Ice and Spring together is really no issue at all. The only way to get Ice and JBoss to work together short of significant work on the JBoss remoting library is to have the Ice thread pool active "symbiotically" within JBoss. This works and we've done it, but it's not really sensible.

[kwaclaw]

Thank you for your feedback.

Our initial implementation of the OMERO server was a Spring context within a JBoss server. We currently support both a JBoss and an Ice-based server, which was relatively straight-forward using Ice's tie classes and the Spring interceptors which were already in place within JBoss.

If you have JBoss with Spring, I can explain how to go about this.

Actually, I am in the position of recommending how to structure the application server. So far, I am kind of fixed on Spring, but as I may have to expose some services as web services, something beside ICE may have to be used as server. It could be JBOSS (or similar) or it could be a SOAP/web service wrapper for the ICE-based application.

If not, keep things simple. Using Ice and Spring together is really no issue at all. The only way to get Ice and JBoss to work together short of significant work on the JBoss remoting library is to have the Ice thread pool active "symbiotically" within JBoss. This works and we've done it, but it's not really sensible.

Violates the KISS principle...
Just curious, If you have an ICE-based OMERO server, why do you also offer a JBOSS based version?

Karl

[joshmoore]

Just curious, If you have an ICE-based OMERO server, why do you also offer a JBOSS based version?
Karl

JBoss is what we shipped first, and so there are already clients written to the RMI interface which must be supported.

As for your architecture, if I were in your position I'd suggest coming up with a stable Ice server, using Spring internally. When it comes time for web services, you can either:

• have a Java web container act as a client to Ice
• use Ice's PHP bindings to build a REST interface
• start a second Ice.Communicator within the web/app server using co-location.

Hope that's of some use.
~Josh.

[kwaclaw]

As for your architecture, if I were in your position I'd suggest coming up with a stable Ice server, using Spring internally. When it comes time for web services, you can either:

• have a Java web container act as a client to Ice
• use Ice's PHP bindings to build a REST interface
• start a second Ice.Communicator within the web/app server using co-location.

Hope that's of some use.
~Josh.

Yes, I was already contemplating the first option, but possibly with ASP.NET.

Thank you very much,

Karl