What has been argued in this thread is that a more general API based
solution is better than the protocol based solution. Here I make what
I think is a more compelling argument: the attempt to standardize J2EE
on IIOP will make the interop spec itself irrelevant. I conclude with
some discussion of the API solution, culled from our design, in order
to address some of the technical questions that have come up. When the
complete draft receives the appropriate reviews, we will see to it
that it is circulated on this list.
The pace and the diversity of the technology currently being brought
into the market provides the context for the interop spec. Picture, if
you will, a market where single sign-on and multi phase transactions
over wide area or wireless networks are common place, all further
complicated by the specialization added by the vendors of the
technologies. The specialization is not gratuitous. To date, we see
the underlying transports and both of dominant subsuming protocols
(HTTP, WAP) are all stateless. The OSs and databases involved have
their own realms, and transaction coordinators are applied to
different problem domains. In addition to the standards and
specializations advancing independently of one another, other emerging
technologies, such as XML, and innovations, such as new uses of
UDP/multicast for service advertisement, continue to enter the market.
In this fast paced and expanding market, IIOP plays a small role,
relatively speaking, in that it only fills the niche connecting ORBs.
In contrast to the protocols that are more commonly used, IIOP is
statefull, it makes presumptions about the connected-ness of the
underlying transport, it is dependent on the ORB architecture and
specific interfaces that are supported only on top of ORBs. Because of
the dependence on these interfaces, mandating IIOP further forces all
the participants to re-implement the APIs in terms of those
interfaces. As with RMI-IIOP, where the functional mapping is fairly
new and crude, the results compromising both RMI and IIOP, the APIs
encourage innovation that must then be coerced into something the
protocol and the supporting infrastructure can manage.
This begs the question, what makes this market different? If IIOP was
good enough for interop in a CORBA environment, why not EJB?
The most distinguishing characteristic of the market the interop spec
attempts to address, IMHO, is the components that are being collected
are loosely coupled. The only thing that is more stunning than the
ambitions of connecting loosely coupled systems is the fact that we
are already fielding RFPs from customers to address these
requirements. Take, for example, a cell phone that hypothetically
enrolls a single transaction on CICS, TUXEDO, Encina, and TopEnd. To
do this today, the back end systems enroll with each other as
resources at some point in processing the WAP request. Such as they
are, the vendor APIs involved provide security context (realms) in the
client domain, probably link level SSL support (hardware on the
client, a separate implementation on the the server), protocol
tunneling as needed, and support (enrollment and callbacks) for multiple
coordinators.
Given the time to market concern alone, I would not hope for a
protocol level solution between all the vendors involved. But even on
closer examination, the long term prospects of a protocol solution go
dim because none of the components are implemented on top of ORBs and
hence the best that can be hoped for is the compromises between the
components and the ORBs involved, all probably authored by the ORB
vendors themselves. In any case, the APIs that allow me to federate the
services involving the various vendors must be present, indeed, are
already offered by the vendors, XA being the clearest example. The
result is that the API based solutions that address the loose coupling
requirements will get ushered in by market demand, regardless of what
the interop spec mandates, because they are easier to get right and
can be delivered sooner.
The point of all of this is that under the constraint of integrating
loosely coupled (network and glass house) systems, that is in systems
where there is no common realm or XID, the protocol solution *adds* an
ORB to the mix, an ORB which in turn is forced to add adapters to both
the client and server sides to compensate for the functionality
provided by the vendor's APIs. In turn, the ORB must integrate the
vendors' APIs or re-inventions ot the APIs. In the API based approach,
the implementation of the API hides the complexity and is authored by the
vendors, leveraging their expertise. Consequently, the API solutions
arrive sooner and are more robust. In the protocol solution, because
the implementation must be/are probably shouldered by the ORB vendors
themselves, the implementations both lag behind and compete with
solutions that use roughly the same APIs. Ultimately interest in the
standards necessarily wane to the point where the standard is a failure.
Put succinctly, the pace, complexity and scope which interop
standardization attempts rules out the protocol solution because the
API solution, being simpler, clearer and more compelling, will attract
implementations from all the vendors involved. By contrast, the
protocol solution adds another level of complexity and compromise
without apparently adding value and ultimately hinges on the ability
to trade on the CORBA brand. If the protocol solution is standardized,
the conundrum that results from customers choosing between the
features they demand and the standard they prefer would serve only to
further confuse the market.
It is all rather a shame since the API solution in no way precludes
the use of IIOP based solutions. Indeed, some applications require ORB
based solutions, and vendors, ourselves included, encourage their use
where applicable.
To illustrate the API solution consider the following excerpts from the
design authored by two of our architects, Anno and Sriram.
The problem space for EJB, JMS and JDBC is largely the same. We assert
the problem space concerns the J2EE container as much as the EJB
container. From this assertion we conclude that the interop
requirements are for J2EE components to use deployed EJB components
and resources such as JMS topics and queues, and JDBC data sources
from another vendor's J2EE container.
To address the requirements, we've proposed that agents for one another's
J2EE containers are hosted in each J2EE container (the host). These
agents (container proxies) are extensions of the concepts of
application deployment and assembly already present in J2EE. The agent
could be deployed as JAR files or as an alternative possibly even as
Java Standard Extensions.
We expect the agent will contain a JNDI provider, a deployment
descriptor, a XA resource (javax.transaction.xa.XAResource) and a
LoginModule (javax.security.auth.spi.LoginModule). The host's runtime
uses the agent's JNDI provider to obtain proxies and connection
factories (JDBC/JMS), its XAResource for transaction recovery and
coordination, and its LoginModule to authenticate principals in the
absence of a trust relationship and/or to add principals to implement
a role mapping.
The agent actively enrolls in the current transaction and maps the
host's security principals to ones its own provider understands. The
agent uses the TransactionManager (javax.transaction.TransactionManager)
to access the transaction of the calling thread and enlists its
XAResource. We presume a factory for either SSL sockets, or
Signatures initialized for signing. It is the agent's responsibility
to provide implementations (such as proxy stubs) but there no
assumptions on how that is achieved. For example, a vendor could choose
to implement some portion of the API, say the the proxies, as native
(JNI) or synthetic (java.lang.reflect.Proxy) code. It is entirely up
to the vendor to accommodate such functionality as versioning, dynamic
loading, much as is available in Java already.
A host (container) can use the agent's deployment descriptor to make
the resource manager connection factories available to the deployment
tool in the host. This applies to the standard types, javax.sql.DataSource,
javax.jms.QueueConnectionFactory, javax.jms.TopicConnectionFactory, and
javax.mail.Session, as well as the upcoming connector types.
This illustrates how the J2EE container hosts proxies to other J2EE
containers in order to address the interop requirements. The down side
of this approach is that the container's foot print increases with
each agent (proxy container), but, as with the quality of the
underlying JVM, we expect this to be manageable in practice. Also, the
approach trades the flexibility offered by pluggable solutions against
the risks of poor quality implementations. This risk is present in any
event, and contrasts with experience with JDBC, JNDI and other APIs
where ultimately the high quality implementations emerge in a timely
way.
===========================================================================
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".
