2008/9/30 Kenneth Saks <Kenneth.Saks_at_sun.com>
> On Sep 30, 2008, at 7:23 AM, Baptiste MATHUS wrote:
>
> More generally, what we are looking is how to get rid of the needs for
> specific ports for say JNDI, EJB remote calls, and so on to the appserver,
> as we're not guaranteed our client side will have access to the server side
> other than by the HTTP/S ports.
> We'd like every communications between the server and the client be
> tunnelled inside a http/s tube.
>
>
> Hi Baptiste,
>
> I assume your requirement for migration is the reason you want the HTTP
> option rather than just implementing the EJB components as webservice
> endpoints? It would be a whole lot easier to achieve the extent of
> decoupling you're looking for.
>
Well, we're not using HTTP for decoupling. We're more doing it because of
networking constraints, and just use as a kind of transport layer under RMI.
Network administrators generally prefer to have HTTP channels, likely...
And WebServices won't fit since we would need to design DTOs for each
services/EJBs with the corresponding graph we need to expose.
At the moment, we're just using the spring http-invoker and use our object
on the client side the same way that on the server one.
Specifically, it includes serializing not only classical properties, but
also lazy-loaded ones without any problem.
Doing it via webservice, as it will try to just serialize the whole POJOs
graph, will just fail most of the time with a LazyInitializationException
(Hibernate, but would be all the same with another persistence-provider).
Yes, we know we could also keep the Session open to permit loading, but then
we would be kind of sending a whole part of the db to the client for each
query :). For me, this is kind of a no-go for WebService, 'cause I don't see
how it could ever become transparent. Maybe one day, we'll have something
like <ws:lazyloaded /> for a given property, then everything might become
possible :). But that's another discussion.
Anyway, as you guessed, the main point we're just considering migration, not
refactoring/rewriting everything :-)...
>
>
> So my questions are quite simple :
> * Is there something related to EJB architecture I should be aware of that
> could render this need very annoying? Really, I'd be interested into knowing
> all potential bad-side effects. At the moment, we're fully satisfied with
> http-invoking, but I might have missed something that would not suit EJB
> specificities.
>
>
> For invocations on the Remote EJB view where the caller and callee are part
> of the same Java EE implementation, the spec does not mandate that IIOP be
> used. It only requires the semantics of RMI-IIOP, meaning : pass-by-copy
> for parameters and return values, the associated set of required RMI-IIOP
> types, support for tx and security propagation, etc. In that respect
> there's nothing stopping a vendor from having an implementation of the
> Remote view over HTTP as long as it's transparent to both the caller and
> callee.
>
Great. Thanks for the spec sum-up and clarification. I appreciate.
> Glassfish does not currently offer a Remote over HTTP option for this
> case.
>
Argh. That could be a problem for us. This is a pity as I've been pushing GF
for some months now, and this could become a non-starter point :-/. Do you
think integrating spring http-invoker would be feasible? I mean, is there a
way to inject another implementation for EJB transport, for example?
Cheers.
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !