see below
> Richard Monson-Haefel wrote:
[snip]
> The problem is, you would have to Javatize (create some level of Java
> connectivity in) every subsystem of each enterprise to make them all
use Java
> remote interfaces. Java is a great language but lets not expect the
entire world
> to support it (See Microsoft). Its going to become very common for
EJB servers
> to front-end large and powerful Tx Managers like CICS, Encina, Tuxedo,
etc. The
> vendors of these systems are not going to reengineer to their products
to a Java
> RMI API specified by EJB. They have far to many other customers who
don't use
> EJB to make that a priority. If we did decide to standardize on Java
> RMI-Whatever and some API, then we might as well throw in the towel
and start
> learning MTS because vendors won't support it. It may seem like its a
Java only
> world, but its not. A lot of my C++ friends would be miffed it was.
>
Let's look at three different types of J2EE server communication:
1. J2EE server communicates with J2EE server. Here Your arguments
above don't matter, because both severs already live in a
'Javatized' world. I haven't heard any reasonable argument
favoring IIOP over an API based solution in this context yet.
2. J2EE server uses non-J2EE transactional resource. In this
case an API-based solution (Connector API) like the JDBC API
is already planned. IMHO this is the technical superior
solution. It puts the burden of implementing the Connector API
on the vendors of the non-Java resources, but I don't agree with
You that these vendors see this issue low on their priority list.
All RDBMS vendors were quite fast to support JDBC, IBM provided
a JMS API for MQSeries soon after standardization, and so on.
Additionally, these vendors won't have a lot of trouble
providing such an interface if they are already supporting
(or willing to support) IIOP and OTS, which You seem to assume.
3. Non-J2EE Tx Manager or other non-Java Client accesses J2EE
server. Here communication via IIOP really is the best solution.
Your argument about not 'Javatizing' non-Java environments
applies fully for this type of communication.
I hope everyone agrees that there are lots of uses of a J2EE
server which don't involve communications of type 3.
That leads to the conclusion that IIOP communication should be
standardized (especially because most of the work has already
been done), but it shouldn't be mandatory.
That would allow some J2EE vendors to specialize on optimized
support for heterogeneous environments while others could deliver
optimized solutions for pure Java environments.
And then simply let the customers decide.
Wolf Siberski
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
