Hey
> Sorry, I do not agree.
> While XML/HTTP will probably be used heavily for the frontend of systems,
> IIOP is already a standard for communication between servers. Almost all
> EJB vendors support it today. With XML your data is substantially larger
> in size and this means higher transfer latency. Thus, I find it very
> unlikely that vendors will throw away IIOP for XML/HTTP.
Perhaps not throw away what they got, but large-scale ubiquitous
interoperability will be done through XML/HTTP, not IIOP.
> IIOP is the defacto standard for interoperability between EJB
> servers, even if jBoss does not support it.
Any EJB server can talk to jBoss through JRMP, and jBoss can talk to any EJB
server through IIOP.
> With IIOP you can create clients and servers in C, C++, Java, COBOL
> and Smalltalk. This means that if you find out that some service
> is too slow you can rewrite it in C++ without having to update your
> clients.
Right... so, you're going to code your clients against a J2EE-ish server
interface, and then port the server to C if the Java one can't handle it??
Don't think so..
> And there is a lot of IIOP-based software around. For example,
> if we did not care about RMI, we could use an IIOP-based OTS
> implementation written in C++.
True, but still... I just don't see the big value-add...sorry
/Rickard
