JRMP vs IIOP

[Denis Wang]

Can anybody explain the difference of these two protocols as long as stub downloading and pass by referrence/value are concerned?
According to this statement,
The most significant difference from IIOP (to JRMP) is that, JRMP does not restrict argument and return types to data values, JRMP handles objects.
I don't know what are the restriction of 'data values'?
Thanks.
Denis

[Sean Walker]

I believe this relates to the fact that via IIOP you can invoke objects remotely but you can't pass a java object itself. Whereas with JRMP you can actually pass Java objects -byte code and all- over the network.

[Denis Wang]

Thanks for your reply.
I am still not sure about the benefit of 'stub downloading'. As long as I can invoke the remote method, who cares whether I download the stub or pass along the parameters/returns back and forth?

[Sean Walker]

Well, if you have an object that has some business logic in it that requires only a moderate amount of state (ie data), its nice to be able to pass that over to the client so that the client can invoke that business logic in process, therefore without having to hit the network on each occasion it does so.
Basically, JRMP makes the Value Object pattern possible (in a seamless manner) across the network.
I'm hardly a guru in these things, so hopefully others will speak up.
BTW, I have seen mention of a Transfer Object pattern too. Anyone know if this is just an alternate name for the Value Object pattern?

[Denis Wang]

Quote from sun:
Transfer Object
Also Known As
Previously known as Value Object
Details:
http://java.sun.com/blueprints/patterns/TransferObject.html

[Sean Walker]

Thank you Dennis
BTW, I should amend slightly what I said about the business logic being the driver for why passing actual objects is useful. Business logic, on its own, is still insufficient to motivate one to use a value.
The business logic should be something you usually run two or more times or in two or more steps. Especially when the client must necessarily interact between these steps. Otherwise, why not just leave the business logic on the server side. (Well, actually, if taking the processing load of the is business logic off of the service-object's tier makes sense, then I guess there is any motivation even when there are not multiple steps of interactions.)
As an example of a case in which you have numerous interactions that you would like to capture in a object and pass to the client tier to avoid incurring network latency, consider a system that handles some sort of sales order submissions. I'll sort of arbitrarily pick a product as an object that isn't too large data-wise to work with. The product, as a line item for the order, has a number of options that have valid and invalid configurations, which you don't want to hit the network to resolve. So you pass the product configuration object as an object to the client-tier. The client can then make a number of calls into its business logic (for the purpose of configuring the product of course) and when the configuration is complete, the client passes it back to the service-object tier.
Hope this has been helpful and not just lengthy! :roll:

[Denis Wang]

thanks for your thorough explaination. I got your point and try to re-phrase it in my own way:
IIOP is much a 'Remote <<Method>>' protocol for Remote Procedure Call. Considering Corba's compreshensive interoperability this makes sense because certain languages don't support the idea of OO well.
JRMP is much a 'Remote <<Object>>' protocol. Java can take full advantage of OOP.
Obviously there are numerous advantages in OOP compared to precedure programming.

[Dushy Inguva]

Herez my own "bold" re-phrasing:
JRMP: Good for 99.9% of the people on this planet who use Java at both the ends.
IIOP: For the one guy who is trying to use Corba n stuff (please.. move to xml instead)
Sorry !!! But i am generally pissed by the way Sun ALWAYS handles all special cases and "never bothers" about the MOST common requirements.
Dushy

[E. Messing]

Java RMI = Remote Method Invocation that is transported over JRMP - java native protocol.
It supports different services than IIOP like : distributed garbage collection, downloading of class files and more.
In JRMP the object itself is sent over the network, de serialized by the other party, and then the method is called.
RMI-IIOP : Remote Method Invocation that is transported using IIOP-which is the protocol used by CORBA OMG. RMI-IIOP was introduced as a "settlement" during the specification of EJB, and some parties of JCP that wanted CORBA interoperability.
Prior to CORBA 2.3 it only supported passing arguments (data types) to remote objects. The remote machine needs to build the object, give it state, and then call the method with the argument sent to it.
It does not broadcast the object itself.
In CORBA 2.3 the "object by value" (sending the object) specification was added (I have never used it though).
JRMP is said to have better performance - mainly because it is not generic as IIOP. Note that both protocols are not secured as is. I think that in most cases they are also sent over SSL - to provide the encryption.