which was meant to be configured in an extension point (but later should probably use the reall AppliImpl model as configuration)
What's not done for now in this API prototype, do it in FraSCAti implementation(s) (our own, Studio...) and others (Light, Talend ?) :
To know what happens,
state (in FraSCAti only STARTED & STOPPED, add STARTING & STOPPING)
an evented way to be updated by info especially state change, ex. nuxeo events (but only nuxeo) or handlers (beware of FraSCAti wrapped side)
To manage it,
provisioning : how the app is provided at the place said (path) ; for now manually as artifactItems, LATER do it at registerContribution time, LATER for other impls (Archiva ??)
packaging : how the app is packaged ; for now jar(s) & root composite name
management UI : for now web explorer TODO test it ; LATER list, integrated in environment UI & env start...
To apply other EasySOA features to it,
link it to registry model app : AppliImpl and its deployables
link it to features (that should be) based on the model, like list of services accessible from Scaffolder, list of UIs... (API Contract #99)
allow to activate monitoring and other ProxyFeatures
More focused on FraSCAti EasySOAApps :
We need to map FraSCAti EasySOA applications to deployables (see #99). The logical way to do it is one jar per deployable, and map versioning the Maven way.
OSGi brings runtime information useful in EasySOA, ex. live module info & versioning for deployables => TODO INRIA would OSGi-ifying FraSCAti EasySOA applications (Studio, on-demand proxies and remote probes) bring them ?
TODO INRIA other ideas on how to best integrate & provide info to EasySOA ?
Each Environment is linked to n Servers (starting an environment means starting all of its servers)
Each server contains n "ServiceImpls", each one of them representing both:
A single service implementation, as viewed by the model
Any artifact than can be deployed on a certain type of Servers.
ServiceImpls can be aggregated as AppliImpls, that hasn't much semantic for now in the API, but could be used to stand for "a group of artifacts to deploy together".
When an Environment is started, TunnelingNodes are created on a independant (FraSCAti) Server, to hold ProxyFeatures to use between a service and its reference.
Here are our current ideas of a startable & manageable application in EasySOA / Nuxeo.
Scenarii :
Prototype :
What's not done for now in this API prototype, do it in FraSCAti implementation(s) (our own, Studio...) and others (Light, Talend ?) :
To know what happens,
To manage it,
To apply other EasySOA features to it,
More focused on FraSCAti EasySOAApps :
We need to map FraSCAti EasySOA applications to deployables (see #99). The logical way to do it is one jar per deployable, and map versioning the Maven way.
OSGi brings runtime information useful in EasySOA, ex. live module info & versioning for deployables => TODO INRIA would OSGi-ifying FraSCAti EasySOA applications (Studio, on-demand proxies and remote probes) bring them ?
TODO INRIA other ideas on how to best integrate & provide info to EasySOA ?