User story : Configuration and deployment
<<< Back to [[Final soa model design]]
- Requirements
- Model interactions
- XXXs: Missing information
- (Draft)
- Roles involved: SOA Architect, Administrator, Developer
-
Goals
- Ease the management of the client-side configuration of the web services routing
- Monitor the required web services to detect changes
- Ease the deployment of only part of an application
-
Features
- Tell the SOA which URLs to use by generating a .properties file
- Provide ways to easily gather the required data
- Discovery
- Properties import
- Allow to use EasySOA-proxified URLs
- Make the file available through HTTP and its configuration editable online
- Provide ways to easily gather the required data
- Detect services changes
- Send relevant notifications when a service depended on has changed/is missing
- Display warnings when a deployable should have been updated/deployed after a service change
- (XXX: Which features to support deployment goals?)
- Tell the SOA which URLs to use by generating a .properties file
A company has a SOA for which the list of the URLs required by its Java web services is packaged in each JAR, through a .properties file.
- GIVEN
- WHEN
- THEN
- GIVEN
- WHEN
- THEN
- Blah
(test) As a developer, I want to
As an architect,
-
I want to let EasySOA tell my generic Java SOA runtime which service to use by each service consumer, so that I can use EasySOA as an easily accessible reference when I want to know which uses which, as well as being able to get benefits of EasySOA tunnel proxy (test with various simulation tools & scenarii, monitoring discovery / sla / service subscriber events)
-
I want to tell EasySOA which uses which easily using available info (discovery, property import + transformation)
-
I want EasySOA to provide this info as a property file to my SOA platform easily
-
=> EasySOA 1. generates it (see prototype), 2. LATER deploys it (ex. as maven dep, using "copy deps" server)
-
=> alternate solution : EasySOA uses as its reference an SCM-stored property file (manually maintained, or generated devtool-side) known by its URL
As a developer having to deploy a new version of only a single (service) implementation,
- (HTTP-provided routing conf) I want to update easily (in a single place, minimal or no conf redeploy) the (production) routing configuration so all clients will target the new version
- (HTTP-provided routing conf) I want a simple Java client fetching these properties using HTTP, so that I can easily integrate deployed HTTP props in my Java SOA
As a deployer / debugger having to quickly deploy on a production version a patch including a new version of a single (service) implementation ,
-
(partial redeploy) I want to provide this information to my generic Java SOA runtime in an online manner, so that I can change this configuration without having to redeploy everything (maven deps)
-
=> TODO Q CXXXXX why can't they redeploy only the jar ? Props granularity (only one or more) ?? Use also snapshots (then timestamp required) ?? Provide detailed user story !
As a developer / resp. deployer,
- I want to be notified when a deliverable(s) has not changed while its service (definition) has changed in design / resp. impl, so I can look into development (?) / resp. deployment mistakes
- => devtime (maven pom) / resp. runtime (classpath, osgi, maven deployment plugin) deliverable discovery
As a deployer,
- I want to compare runtime discovered-deliverables (& conf ?) (using classpath or osgi) to implementation-discovered ones (project pom), so I can be sure that everything (deliverables & conf) has been deployed / is up to date
- => runtime vs devtime deliverable comparison
- => the best deployment or runtime deliverable discovery alternative out of : classpath, (osgi), maven deployment plugin