which protocol to use

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

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.

Thnx Cleuton.

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

Hi Santiago,

You said:

HTTPS: Secure, with state

Which state are we talking about? :roll:

Regards,
Dan

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

port：
HTTP 80
SSL 443
IIOP 1099
JRMP 535
TOMCAT HTTPS 8433

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 ]

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.

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

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.

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.

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

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

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