File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes which protocol to use Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "which protocol to use" Watch "which protocol to use" New topic
Author

which protocol to use

Mahmoud Matouk
Ranch Hand

Joined: Mar 21, 2003
Posts: 41
Hi All,

I would like to ask if some expert can summarize when to use each of the 4 protocols (HTTP, HTTPS, IIOP, JRMP)

I've read them many times but I still alittle confused about RMI-IIOP or RMI-JRMP so appreciate some summary or key points.

Thanks
Cleuton Sampaio
Ranch Hand

Joined: Nov 11, 2005
Posts: 181
Hi,

Please note that I haven�t gotten my results yet. I have passed phase I, submitted phase II and taken phase III.

I would like to ask if some expert can summarize when to use each of the 4 protocols (HTTP, HTTPS, IIOP, JRMP)

I've read them many times but I still alittle confused about RMI-IIOP or RMI-JRMP so appreciate some summary or key points.



Well, you should use HTTPS whenever you need secure access to a web site.

IIOP is the native protocol of CORBA components and the EJB 2.0 specification uses it (RMI-IIOP). JRMP is the protocol for the RMI inter-process communication mechanism, which allows a Java class to invoke remote methods in other Java classes. RMI-JRMP is the protocol used to invoke remote objects in Java.

You should use RMI-IIOP to allow your EJBs to be used by Corba applications.


Cleuton Sampaio<br />Systems Architect<br />(SCEA,SCWCD,SCBCD,MCSE,MCSD)
Mahmoud Matouk
Ranch Hand

Joined: Mar 21, 2003
Posts: 41
Thnx Cleuton.
Santiago Urrizola
Ranch Hand

Joined: Apr 27, 2006
Posts: 172
HTTP: Simple request - response web protocol
HTTPS: Secure, with state
JRMP: Native Java to java communication (for ecxample betwen 2 app servers)
IIOP: java to corba


Santiago Urrizola : La Plata - Argentina<br />SCEA (89%-92%)<br /><a href="http://gpitech.wordpress.com/" target="_blank" rel="nofollow">http://gpitech.wordpress.com/</a>
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1164
Hi Santiago,

You said:

HTTPS: Secure, with state


Which state are we talking about? :roll:

Regards,
Dan


William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
Mahmoud Matouk
Ranch Hand

Joined: Mar 21, 2003
Posts: 41
Hi,

State means simply it can remember results from previous requests and use that data in farther requests, on the conterary to HTTP which doesn't remember results.

------------------------------
SCJP, SCWCD, IBM 397
air lulu
Ranch Hand

Joined: Jan 11, 2005
Posts: 42
port:
HTTP 80
SSL 443
IIOP 1099
JRMP 535
TOMCAT HTTPS 8433
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1164
Hi Mahmoud,

So, do you think that HTTPS remembers the state of previous requests? I doubt it does.

Regards,
Dan
[ September 18, 2006: Message edited by: Dan Drillich ]
Tim LeMaster
Ranch Hand

Joined: Aug 31, 2006
Posts: 226
HTTPS - does not mean state. HTTPS is just HTTP over SSL instead of plain text (think telnet).

Both HTTP can HTTPS can be given state using a session (via cookies, URL, or SSL ID. With SSL ID its important to note, the state is still stored in the session just like cookies and URL. The session is keyed on the SSL ID that has been established between the client and the server, however both the client and the server can timeout the SSL ID and request a new one.

In any case its not HTTP or HTTPs holding the state, but a third party mechanism.
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1164
Thank you Tim for the nice explanation!

About:

In any case its not HTTP or HTTPs holding the state, but a third party mechanism.


I wouldn't call cookies and url state embedding a third party mechanism . After all, these two mechanisms are available via the HTTP protocol itself. Maybe we call them - custom solutions based on the HTTP protocol.

By the way, we can pass state via HTML hidden fields also.

Regards,
Dan
Tim LeMaster
Ranch Hand

Joined: Aug 31, 2006
Posts: 226
Cookies and URL rewriting don't hold the state - thats just a key into the third party session provided by the App Server (in case of J2EE) - PHP, ColdFusion, and most web platforms provide a similar mechanism - thats why I call it third-party.

While you could hold state in cookies and the URL directly you would be very limited in the size.
Sub swamy
Ranch Hand

Joined: Oct 02, 2002
Posts: 121
The following is what i found in Mark Cade

"..SSL connections are stateful, and because of this, HTTPS can support sessions without the security risks of URL rewriting or cookies..." -

My understanding is that it is the SSL aspect of HTTPS that makes it stateful.Correct me if otherwise.
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1164
Very interesting Subramanian!

So, how do we access this state information from within the application? Where is it? In the HTTP header maybe....

Regards,
Dan
Cleuton Sampaio
Ranch Hand

Joined: Nov 11, 2005
Posts: 181
Hi, Dan

You access the state information of SSL connections the same way, via HttpSession Object.

The main difference is the client-Id. With HTTPS it is not necessary to use cookies. The server and the client share the secure session.

I do not know the details, but you can find in http://wp.netscape.com/eng/ssl3/draft302.txt
Dan Drillich
Ranch Hand

Joined: Jul 09, 2001
Posts: 1164
Hi Cleuton,

Thank you for the link.

The document says:

5.1 Session and connection states

An SSL session is stateful. It is the responsibility of the SSL
Handshake protocol to coordinate the states of the client and
server, thereby allowing the protocol state machines of each to
operate consistently, despite the fact that the state is not
exactly parallel. Logically the state is represented twice, once
as the current operating state, and (during the handshake protocol)
again as the pending state. Additionally, separate read and write
states are maintained. When the client or server receives a change
cipher spec message, it copies the pending read state into the
current read state. When the client or server sends a change
cipher spec message, it copies the pending write state into the
current write state. When the handshake negotiation is complete,
the client and server exchange change cipher spec messages (see
Section 5.3), and they then communicate using the newly agreed-upon
cipher spec.


Regards,
Dan
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: which protocol to use
 
Similar Threads
HELP: some questions about RMI-IIOP
You must use RMI over JRMP (do not use IIOP) ?
is JRMP over IIOP is same as Java RMI over IIOP?
RMI over JRMP
NX: Is JRMP the default for RMI?