[GLASSFISH-6371] Be able to use EJB3 using a http tunnel Created: 30/Sep/08  Updated: 01/May/13

Status: Open
Project: glassfish
Component/s: grizzly-kernel
Affects Version/s: V3
Fix Version/s: future release

Type: New Feature Priority: Major
Reporter: batmat Assignee: oleksiys
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


Issuezilla Id: 6,371

 Description   

Hi,

After having considered migration to EJB3, we realize that GF doesn't have an
"http-invoker" feature.

In fact, we'd like to be able to tunnel all our call to the server through an
http one.

The better would be being able that the client doesn't need anything else than
http to (1) resolve the remote ejb reference, (2) call it. To sum up, would be
great if GF has the corresponding feature of JBoss (e.g. see
http://wiki.jboss.org/wiki/Accessing_EJB3s_over_HTTP_HTTPS or
http://wiki.jboss.org/wiki/EJBOverHTTPWithUnifiedInvoker).

At least, we'd be interested into knowing how we could inject say our transport
classes (integrating spring http-invoker), and we'd also be glad to know if
there's any chance that it gets into GF if we provide a patch for it.

Cheers.
Thanks for your work, GF is already a masterpiece.



 Comments   
Comment by km [ 01/Oct/08 ]

Looks like this is an interesting feature request. Thanks for filing it as such.
If I understand it correctly, you need some standard servlets that will tunnel
EJB calls via HTTP. This is useful for all the applications that have EJB
components, but don't have Web components that front end those EJB components.

IMO, JBoss makes you do too many configuration changes for this to be achieved.

Comment by batmat [ 01/Oct/08 ]

> IMO, JBoss makes you do too many configuration changes for this to be achieved.
I totally, fully, wholeheartedly agree. This configuration is a nightmare.

What I would dream of would be to be able to configure a glassfish out of the
box using say a particular setup-firewallconstrained[cluster].xml and be done
(and providing the right jndi property to access).

More generally, for me, this feature request is about being able to reduce the
number of needed ports, to simplify a firewall configuration. And more
importantly, to delete the dynamic ports/be able to specify fixed ones. Kind of
UnifiedInvoker as it exists in JBoss.

If you think it'd be a good thing to file another FR and link it to this one,
please just let me know.
Thanks.

Comment by Bill Shannon [ 01/Oct/08 ]

I know it's not exactly what you asked for, but given that you're separating
the client and server by a firewall, implying that they're more loosely
coupled, have you considered using JAX-WS to expose your EJBs as web services?
Yes, it's a somewhat different programming model, but it might be a better
match for your environment.

Comment by batmat [ 01/Oct/08 ]

Hi Shannon,
Well, at least, Sun coworkers are coherent. See the discussion with Ken Saks
and his proposal here:
https://glassfish.dev.java.net/servlets/ReadMsg?list=ejb&msgNo=527 .

To sum up, no. We're not considering WS programming for many reasons I describe
in the given thread.
Cheers.

Comment by Ken Cavanaugh [ 02/Oct/08 ]

One of the features we have been discussing for GFv3 is port unification for all protocols.
This would mean that HTTP, WS, and IIOP could all be handled over the same port.
Does this solve the requirement, or do you need more than just the same port?
We do occasionally see requests to allow tunneling of RMI-IIOP requests over HTTP,
but so far this has not been sufficiently common to consider implementing it.

Of course, you can also look at invoking EJBs directly from the HTTP path,
as others have discussed.

Comment by batmat [ 02/Oct/08 ]

> This would mean that HTTP, WS, and IIOP could all be handled over the same port.
Does this solve the requirement, or do you need more than just the same port?
That's not exactly the same thing, but it would definitely be a damned good
thing to convince people here about Java EE servers, and more precisely about GF
part.

So, I guess this could be sufficient.

> We do occasionally see requests to allow tunneling of RMI-IIOP requests over
HTTP, but so far this has not been sufficiently common to consider implementing it.
Do you see it as an interesting/acceptable request but don't have time to
implement it, or is it just not gonna be accepted even if we try to provide a
patch for it that'd suit you?

Cheers

Comment by batmat [ 27/Nov/08 ]

> One of the features we have been discussing for GFv3 is port unification for
all protocols. This would mean that HTTP, WS, and IIOP could all be handled over
the same port.

That feature would be really interesting. Isn't it this one:
https://glassfish.dev.java.net/issues/show_bug.cgi?id=4322.

Maybe the current issue should be put as related?

Cheers.

Comment by Tom Mueller [ 23/Jun/10 ]

Kedar no longer on project.

Comment by Tom Mueller [ 06/Mar/12 ]

Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

Comment by jthoennes [ 26/Mar/12 ]

This is related to the port unification feature I am also looking for a long time now.
See GLASSFISH-4073: Move CORBA transport to Grizzly (https://java.net/jira/browse/GLASSFISH-4073).

If we could access the ORB for JNDI and EJB access using the Grizzly port unification framework
(port finder and port filter). See http://antwerkz.com/blog/port-unification-in-glassfish-3-part-1.

Batman, did you find any workaround so far?

Comment by Tom Mueller [ 04/Jan/13 ]

Moving to EJB component.

Comment by marina vatkina [ 04/Jan/13 ]

You can use EJBs as JAX-RS endpoints. Assigning to the JAX-RS for further evaluation.

Comment by kumara [ 24/Apr/13 ]

Well, programming in JAX-RS was already suggested as a solution and in that case there is nothing that the server has to do, the application needs to change.

The most concrete comments about a solution was use of port unification to ensure that IIOP traffic is on the same port as http. While this is not exactly a http tunnel, it might be enough for some scenarios.

I am going to request grizzly-kernel team to add a pointer to port unification documentation so that anyone referring to this issue has a handy reference on how to configure IIOP traffic on same port as http.

If port unification is not sufficient, given the availability of JAX-RS programming model and better integration between EJB and JAX-RS, the most prudent option is to change the application.

After adding the document pointer, please assign this back to orb sub-component.

Comment by oleksiys [ 24/Apr/13 ]

Is Corba (IIOP) working on top of Grizzly?
If not then port unification will not work.

Comment by jthoennes [ 25/Apr/13 ]

A related issue is also whether OpenMQ would work using port unification. I think the new OpenMQ 5.0 is based on Grizzly, isn't it?

Comment by oleksiys [ 01/May/13 ]

yes, MQ should work.

Generated at Wed Apr 26 19:52:43 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.