while the technical discussion on this topic has some value, the post below
imo is the most interesting.
as we move to internet deployment cycles measured in weeks or even days,
these issues become critically important. geoff may be reaching a bit when
he desires uniformity to the level which allows heterogeneous servers to be
highly integrated, but i think it's valid to desire at least this level of
capability within a server family.
i'd be interested in hearing (from vendors or users) how various products
handle this. my view is that IBM (VisualAge + WebSphere/Studio + DB2) gives
the most complete coverage.
> -----Original Message-----
> From: Geoff Lingham [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, November 08, 1999 8:14 AM
> To: [EMAIL PROTECTED]
> 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
>
> ------------------------------------------
> << File: BDY.RTF >>
===========================================================================
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".
