Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Stateless Session Bean -RMI- External Java System

 
James Owen
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
I would like to ask if some expert can summarize which protocol should be used in the following scenario(RMI or RMI-IIOP).

A Stateless Session Bean(in App Server) needs to invoke a method on an external Java System.

I've read them many times but I still alittle confused about RMI-IIOP or RMI-JRMP , So i would appreciate if someone can help me out
and let me know the reasoning behind selecting a protocol for interfacing SLSB to external java system.

Thanks
James
SCJP Part 5
SCWCD
SCEA 5 part1
 
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper
Posts: 4968
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What is the 'external java system?'

Are you connecting to a remote server? Is it a remote EJB you are connecting to? Is it a servlet you are invoking? Is it a JavaBean that listents on a port and IP address? Are you connecting to a web service that is implemented in Java

If your remote system is really just an EJB, well, RMI-IIOP is the default protocol EJBs use. It's like asking why do we use http when we look up web pages. Well, is just is. There are benefits and drawbacks, but people much better looking than both of us have already decided that two EJBs communicate using this protocol, so we use it.

-Cameron McKenzie
 
James Owen
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Cameron, Thanks for your reply. Yes, i have to connect to a remote server to send a shipping request. The requirements dont specify if its a remote EJB , servlet etc. It jus says "proprietary Java Api". They also dont say that its a "web enabled" system so soap, http url connection etc are not an option(according to me)

I am assuming that i need to connect to the remove server and invoke the shipping method. If i assume that its a EJB then for sure its RMI-IIOP.

But if for knowledge sake, i want to assumne a Java Bean ... In that case what would be the protocol RMI-JRMP? or still RMI-IIOP(as session beans are still part of who callers the shipping api)

Once agains thanks for your reply.
Cheers
 
James Owen
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi
Can someone help me understand if RMI-IIOP over SSL can be used to communicate between Client(in firewall) and application(Not in firewall)
Wouldnt the firewall be an issue?
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what would be the protocol RMI-JRMP? or still RMI-IIOP?


Whether or not your client code is in an EJB is irrelevant. As has already been mentioned, Java EE uses IIOP. However, this doesn't mean your EJBs are restricted to invoking remote methods over IIOP.

Try it out for yourself - Write a couple simple stand-alone remote servants (one using JRMP, the other IIOP). Implement a session bean to look up and invoke each one.

That said I'm not quite sure why you're that concerned about this, other than for purely academic reasons. If the shipping company exposes a remote Java API using either, or perhaps even both, of these protocols they'll more than likely supply you with a JAR containing not only the service interface class(es) but also a utility class to encapsulate the lookup code. After all, an API that requires you hand code the registry details, perform the required lookup, casting and/or narrowing isn't that user friendly.
 
James Owen
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your reply Jonathan.
I was not trying to start a academic discussion. I needed clarification as to what communication protocol can i show in my Deployment Diagram to specify communication between my App server and external vendor Java API. I was very confused between RMI and RMI/IIOP, especially because i read a lot that RMI/IIOP is typically used only in Intranet applications within firewall.

Since in this case we are integrating my system with external vendor system, and both are behind fireall ....i didnt knew if RMI is better option or RMI/IIOP ...You can tell most of my experience has been with webservices and J2EE. Never used RMI in such scenario in real world.
I agree with you regarding the jar files... thats what i assumed too.
Thanks
James
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're right, JRMP does offer better support for HTTP tunneling. The problem with HTTP tunneling is the degradation in performance.

Of course, there's nothing stopping you from thinking outside the RMI box. I think the requirements only mention "a proprietary Java API". In which case why not assume a firewall friendly web-based protocol like Hessian?

Some interesting performance stats can be found here
 
James Owen
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was actually thinking or planning to making assumption to open to firewall ports and use RMI... Would that be bad?
I am all for Hessian but since its a SUN exam I am a little afraid of non standard JEE technologies .. thats why i was limiting my soluction to SUN offered technologies.
We personally use a Tangsol Cache for asyn processing rather than JMS .. but i am planning on using JMS )))
james
 
J J Wright
Ranch Hand
Posts: 254
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am all for Hessian but since its a SUN exam I am a little afraid of non standard JEE technologies


The word "propriety " alone suggests a non-standard approach.

Of course you have to make your own judgment here. As far as my assignment was concerned the requirements stipulated a solution "based on", not "limited to", Java EE technologies.

Besides, in the case of the shipping company we're only making assumptions about a third party.

I am a little afraid of non standard JEE technologies


Again I don't want to unduly influence anyone here. This is only my opinion, which, in the context of this exam, may not be correct. However, I firmly believe that if you have to choose between two solutions, and one is clearly better than the other, then you should not reject the better solution purely on the grounds its not from Sun. If this is meant to be a practical certification it should be about making real world decisions. How would you argue your case in front of stakeholders if all you had to say was "I chose A over B, not because it addresses the requirements better, but because it's from Sun"?

I was actually thinking or planning to making assumption to open to firewall ports and use RMI


If using a particular technology/protocol compromises security, why use it? Again, I might be wrong, but in all honestly I can't see how the examiners would prefer a compromised solution just because it's based entirely on Sun APIs.
 
James Owen
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with you. I would hope that person grading exam is not a Sun fanatic... wanting a sun only solution.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic