Mel Nedelman
Secant Technologies
www.secant.com
[EMAIL PROTECTED]
216-595-3830
----- Original Message -----
From: Geoff Lingham <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, November 08, 1999 11:13 AM
Subject: Re: Deploying & Maintenance
Jim,
I am really glad that you raised this issue about Deployment and
Maintenance, which has been overlooked so far in the EJB specification.
I have just been trying to establish a strategy for deployment of
enterprise components in a large scale environment.
I would like to increase the scope of this issue to include server-side
deployment of enterprise components. How are we going to deploy
middleware application components onto potentially 100's of servers in a
rapid, consistent, robust manner, with minimal loss of service? Also,
how can this be done in an environment with mixed vendor server-side
software, or in a manner which is vendor independent (to allow us to
change server vendors with a minimum of cost and get the EJB benefits we
subscribe to)?
For system integrity, such specifications should also include standards
for querying version numbers of components, logging of component
versions moved into production, specifying deployment version
dependencies and validating dependencies during installation.
Overall, it seems to me that an Enterprise Java Deployment API
specification is required. All server vendors should support an
industry-standard Java API which lets us remotely deploy components via
automated procedures. This would be in addition to the manual GUI
interfaces for deployment which are provided now, and it would allow
rapid, consistent, automated deployment (without having to be aware of
vendor-specific internals).
By way of example, the J2EE server registers the following RMI servers
in the JNDI registry :
- Server Configuration
- Jar Installer
- App Repository
- Web Installer
- Server Activator
- Authenticator
- Database Information
- Server Locator
- Remote Log Reader
- Serial Context Provider
Maybe this is the standard we need?
If EJBs and Enterprise Java is going to succeed in a strategic
production environment then it has to be deployed easily, quickly and
correctly on large numbers of server, and client, nodes in the network.
And we need a standard sooner rather than later.
Thanks,
Geoff
[EMAIL PROTECTED]
Jim Cook wrote:
-----Original Message-----
From: jimcook [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 08, 1999 2:23 PM
To: EJB-INTEREST
Subject: Deploying & Maintenance
Weblogic appears to have a big advantage over many competitors with its
Zero-Administration Client (ZAC). It seems that many of us (not all!)
haven't reached the point in EJB development where deployment is a
concern.
BEA focused on deployment very early in their product lifecycle,
probably as
a feature/benefit of using RMI and taking advantage of RMI's ability to
serialize classes across the wire on demand.
Some Questions:
1. Do any other EJB servers provide similar (or better) tools for
managing
the remote deployment of applications?
2. What are some of the strategies used to push stub/helper classes out
to
the clients? For example, if I add a method to an existing interface,
all of
my applications that use the prior implementation should break, correct?
I was very disappointed to find that CORBA does not allow the dynamic
distribution of classes. For example, if I have a parameter of type
Employee<interface>, and I marshall a class that implements this
interface,
the class that implements must be present on the client. There were many
times that I took advantage of RMI's ability to do this "on the fly".
I realize that these problems are not specific to EJB, however I think
they
will become important to a great many of us as we start to move from
testing
to deployment.
thanks,
jim
------------------------------------------
===========================================================================
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".
