Hi
Thanks for your reply.
I would contest that connection management should not be mentioned in the
spec, even if it is not part of the formal spec per say. If the spec is to
be practically useful - rather than just of academic interest - some
common behaviour needs to be available to the bean author.
Looking at the goals of the spec from the 1.1 draft (with my _emphasis_):
* The Enterprise JavaBeans architecture will be the standard component architecture
for build-ing distributed object-oriented business applications in the Java�
programming language. The Enterprise JavaBeans architecture will make it possible
to build distributed applications by combining components developed using tools from
_different vendors_.
* The Enterprise JavaBeans architecture will make it easy to write applications:
Application developers will not have to understand low-level transaction and
state management details; multi-threading; resource pooling; and other complex
low-level APIs.
* Enterprise JavaBeans applications will follow the Write Once, Run Anywhere��
philosophy of the Java programming language. An enterprise Bean can be developed
once, and then _deployed on multiple platforms without recompilation or
source code modification_.
[JAC - I assume platform here to mean the whole lot - appserver and all]
* The Enterprise JavaBeans architecture will define the contracts that enable tools
from
multiple vendors to develop and deploy components that can _interoperate at runtime_.
* The Enterprise JavaBeans architecture will be compatible with existing server
platforms.
Vendors will be able to extend their existing products to support Enterprise
JavaBeans.
* The Enterprise JavaBeans architecture will be compatible with other Java programming
language APIs.
* The Enterprise JavaBeans architecture will provide interoperability between
enterprise
Beans and non-Java programming language applications.
* The Enterprise JavaBeans architecture will be compatible with the CORBA protocols.
* The Enterprise JavaBeans architecture will address the development, deployment, and
_runtime aspects of an enterprise application�s life cycle_.
To me, these highlighted requirements place connection management firmly within the
spec. If I can't rely on the lifecycle of connections and their interaction
with EJBs, then my application is not platform portable.
[ A few other comments below... ]
Comments ?
Joel Crisp, Senior Java Architect, SUN PS Java Center
Rickard �berg wrote:
>
> Hi!
>
> Joel Crisp wrote:
> > Can someone in the know clarify the issue of when clients are expected
> > to make and terminate connections to the server ?
> >
> > Is this supposed to be part of the spec ? If so, the following questions
> > apply, if not, please clarify the owner of this issue as part of the spec.
>
> This is strictly implementation related and is not, and should be, in
> the spec.
>
> > Is there a way to force a client to maintain a virtual connection (i.e. hold
> > bean stubs) but drop the socket connection ? IHAC who wants to
> > support a degree of off-line working, but can't disconnect from the
> > server as it (Tengah3.2) seems to hold the connection open forever.
>
> You could use my SmartProxy package to do this. See:
> http://www-und.ida.liu.se/~ricob684/java/smartproxy/docs/index.html
Unfortunately we can't use this package in a commercial context. You might
also be in infringement of trademark and copyright/IPR registrations from
Inprise - who use the term "smartproxy" in the Visibroker ORB.
>
> > My assumption at the moment is that a connection is opened with the
> > first retrieval of a "Home" interface, and closed with the GC of the
> > last active instance of a Home, Session or Entity bean in the
> > client. This doesn't seem to work in Tengah or ND.
>
> How the RMI framework handles this is dependent on the specific
> implementation. I suggest contacting [EMAIL PROTECTED] for details.
>
> > If this is the case I think that more control is needed to manage
> > the underlying transport layers in order to 1) manage errors by permitting
> > a client to perform a hard disconnect irrespective of the handles it has
> > open 2) permit off-line disconnection/re-connection of the transport layers
> > without affecting the EJB handles.
>
> Again, both these issues are related to the specific RMI/EJB
> implementations and is out of the scope of the EJB specification.
> However, my SmartProxy package deals with (/can deal with) both of these
> issues, regardless of the EJB server used.
I don't think that this is sufficient for real-world use. Interoperability
at Appserver level is one reason why customers are interested in the use
of EJB, and the perceived issue with CORBA is lack of standardisation of the APIs
for the container and support services. If EJB goes the same way we could
lose the vendor independence - which would be very bad.
>
> HTH :-)
>
> /Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> Homepage: http://www-und.ida.liu.se/~ricob684
>
> ===========================================================================
> 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".
===========================================================================
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".
