"An administrator could use the EAS to..."

* Acquistion
//how are we going to handle things like the SunJVM which can't be redistributed)
// The "view a list" items sounds like we need a SOAP type interface for the repository
// JBoss, Inc. hosts a repository with a SOAP interface; the local repository can be the same
// implementation as that hosted on JBoss, Inc. and thus can be used as a remote repository
// This is useful for "chaining" repositories - the ISV model and Rich's "flying discs"
View a list of available Distributions, Servers, Services and other Software from JBoss
View a list of Software from OEMs
CRUD the list of remote repositories that host Distro and other Software
   (so we can point to multiple ones - JBoss Inc, ISV, etc)
Download a Distribution, Server, Service and other Software from JBoss
Download a piece of Software from an OEM.
// a "package" is the form we will ship all software - "next gen RPM"
View properties of a package
View a list of Software for things that are only relavent to my Apps/Systems
Subscribe to "something" and set up rules for subscription
  (e.g. when new software is available, send notification to mailto:me@abc.com OR soap://host/notif)


* Abstract entity configuration
//This smacks of a thick client "deployment" tool
// I vote we don't support this in the EAS. Let people do it themselves using IDE for J2EE apps
// This is involving changing the default config of Software within an aquired package
Configure a Distribution, Server, Service or J2EE Application
Package distro, server, J2EE App, etc. and put in our local repository


* Versioning
// not sure how atomic these versions will really be
Version a HostInstance/Group
Version a ServerInstance/Group
Version a ServiceInstance/Group
Version a ApplicationInstance/Group
List versions
Commit changes (this assumes all updates made through EAS will not be applied until they are specifically committed)
Abandon changes (this assumes all updates made through EAS will not be applied until they are specifically committed)
Roll back a HostInstance/Group to a particular version
Roll back a ServerInstance/Group to a particular version (non-group version not allowed if using netboot install option)
Roll back a ServiceInstance/Group to particular version (non-group version not allowed if using netboot install option)
Mark a version of some entity as "dependent" on another entity/version.
   (Any version of an Entity can have multiple dependencies.)

* ServerInstance lifecycle
// The EAS should support deploying a Server on a Host in all conceivable configurations
//I vote the only install option that we support initially is "local install"
// each Server deployment includes deploy all Services bundled with it.
Deploy a "JVM" on a HostInstance
Deploy a Server on a HostInstance using a local install
Deploy a Server on a HostInstance using a netboot server
Deploy a Server on a HostInstance two times, both times using a netboot server (will automatically become part of the same ServerInstanceGroup)
Deploy a Server on a HostInstance two times, once as a local install, once using a netboot server
Deploy a Server on a HostInstance two times, both times using a local install sharing components (i.e. one JBOSS_HOME)
Deploy a Server on a HostInstance two times, both times using a local install but not sharing components (i.e. two JBOSS_HOME's)
Deploy a Server on a HostInstance two times, both times using a local install that is configured as a farm. (will automatically become part of the same ServerInstanceGroup)
Undeploy a ServerInstance from a HostInstance (obviously taking all ServiceInstances and ApplicationInstances with it)
View list of all ServerInstances on a HostInstance/Group
Configure a ServerInstance to be a netboot server	
Configure a ServerInstance to make a farmed cluster
Configure the JVM startup options for a ServerInstance
Patch a ServerInstance e.g upgrade JBoss AS from 4.0.1 to 4.0.2 (this includes changes to files above the /server directory, e.g. endorsed libraries)
Start(make available)/Stop (make unavailable)/Restart a ServerInstance


* ServerInstanceGroup lifecycle (v. similar to ServiceInstanceGroup)
Create a ServerInstanceGroup from a set of ServerInstance's.
View information on a ServerInstanceGroup (if individual ServerInstances have been changed independently of the Group, then this information will not match what is actually running), e.g. JVM system property
View list of all ServerInstances in ServerInstanceGroup
Add a ServerInstance into a ServerInstanceGroup
Destroy a ServerInstanceGroup association
Undeploy a ServerInstanceGroup (i.e. undeploy all ServerInstances in the group)
Make ServerInstances in a ServerInstanceGroup work as a cluster
Configure a ServerInstanceGroup (this will apply the change to all ServerInstances potentially overwriting any changes that had been made to individual ServerInstances)
Patch a ServerInstanceGroup (this will apply the change to all ServerInstances potentially overwriting any changes that had been made to individual ServerInstances)
Start(make available)/Stop(make unavailable)/Restart a ServerInstanceGroup (applies to all contained ServerInstances)


* ServiceInstance lifecycle
//List of Services:JCA,JMS,Tomcat,Security,JTA,JNDI
//How are we going to handle Configuration changes across different versions of a Service, e.g. adding a DataSource to the JCA Service one of which is running in the 3.2.7 ServerInstance and one of which is running in 4.0.2 ServerInstance. Since a DataSource has different attributes between those two versions
//How are we going to handle deploying a Service across to two ServerInstances that are different versions, e.g. 3.2.7, 4.0.1. 
// for all of these need to handle the case of the associated ServerInstance being stopped
Deploy a Service on a ServerInstance (not allowed if the install option is netboot)
Deploy a Service on a ServerInstanceGroup (this automatically creates a ServiceInstanceGroup)
Undeploy a ServiceInstance from a ServerInstance (not allowed if the install option is netboot)
//  it should be possible to have a ServiceInstanceGroup containing more than one ServiceInstance installed in a single ServerInstance but not sure how much use it would be since, on an update the ServiceInstances would be sync'd to be the same which would probably end up breaking stuff within a single ServiceInstance
Configure a ServiceInstance e.g. create a DataSource, update a JMS Topic, change a Tomcat port.
Patch a ServiceInstance e.g. upgrade JBoss/Remoting from 1.0.1 to 1.0.2
//What does stopping a ServiceInstance really correspond to?
Start(make available)/Stop(make unavailable)/Restart an ServiceInstance


* ServiceInstanceGroup lifecycle
// for all of these need to handle the case of all/some of the associated ServerInstances being stopped
Create a ServiceInstanceGroup from a set of ServiceInstance's. (have to nominate one as having the primary configuration, which will replace the others on an update)
View information on a ServiceInstanceGroup (if individual ServiceInstances have been changed independently of the Group, then this information will not match what is actually running),e.g. settings specific to the service.
View list of all ServiceInstances in a ServiceInstanceGroup
Add a ServiceInstance into a ServiceInstanceGroup
Destroy a ServiceInstanceGroup association
Undeploy a ServiceInstanceGroup (i.e. undeploy all ServiceInstances in the group)
Configure a ServiceInstanceGroup (this will apply the change to all ServiceInstances potentially overwriting any changes that had been made to individual ServiceInstances)
Patch a ServiceInstanceGroup (this will apply the change to all ServiceInstances potentially overwriting any changes that had been made to individual ServiceInstances)
Start(make available)/Stop (make unavailable)/Restart an ServiceInstanceGroup


* AppliationInstance lifecycle (see ServiceInstance lifecycle)
Configure the J2EE deployment descriptors in an ApplicationInstance
No patching

* AppliationInstanceGroup lifecycle (see ServiceInstanceGroup lifecycle)
Configure the J2EE deployment descriptors in an ApplicationInstanceGroup (this will apply the change to all ApplicationInstances potentially overwriting any changes that had been made to individual ApplicationInstances)
No patching



------------------------
General comments

// A Distribution is really just a useful for grouping stuff together in .zip file. If you extend the defintion of Server to include all the bits /server then there really isn't much need to use Distributions as a concept. ServerInstanceGroups offer more flexibility when describing sets of ServerInstances.
//mazz think in more general terms, Distribution may not necessarily be a "Server" - its anything but it "has" servers in it.  Also, a "Distro" can have more than one "Server" (in JBoss's case, it has three servers - "all", "default" and "minimal" - if the Distro is Java VM, it can possibly have two (JDK and JRE)).

// The distribution (verb) aspects of installation are really just implementation details, that don't need to be exposed to the user. E.g. we saw in the Bluestone demo that an attempt to install an application on a Host would fail if it had not been distributed first. The user shouldn't have to know about that, especially in the case of netboot where the distribution is done at runtime. Well even for netboot there is some sort of distribution phase since you've got to get stuff over to the netboot server. Its just from the use case point of view it doesn't buy the user anything, its not a proper goal, and as such it should be wrapped up in the semantics of "deploy". One area where "distribute" really doesn't make sense is a single local node.

// just doing CRUD on things leads to a lot of use cases

// from looking at weblogic and websphere, they offer the ability to look at Services without first drilling down through a Group>Host>Server navigation hierarchy. Services are toplevel entities. Atleast in WebSphere you get to see Services and filter them by Cell/Node/Server.
//mazz correct - which is why I recommend making "Service" a top-level entity class (in my PowerPoint, that's what I was trying to convey).  We should be able to acquire/install/deploy Services (thus creating ServiceInstances) to ServerInstances.

// what user interface type(s) will be used by the EAS
//mazz i think we are going to go for web interface first - unless you know Swing :-)  Eclipse plugin might be interesting to consider

//What about making the managementagent a windows service using the Java service wrapper
This is done - that's the DPL feature of the Management Agent.  See the dynamic-process-launcher project under jboss-network in private CVS.  Uses Java Service Wrapper specifically.
