Service Composition Tooling

Use Cases

Basic Use Cases

Create a service

User selects a service type and drags it to the palate. The service is created with a default configuration.

Notes:

• This is the equivalent of a service definition in IFL combined with a 'generate' step.
• When the service is initially created, nothing should be deployed into the runtime. In fact, there's really no reason to communicate with the runtime at all at this stage.
• We need to consider how the list of service types is generated. The most direct approach would be to just query the runtime for a list of available service types. Should we include service types that are not available in the current runtime?
• I'm lumping services and flow constructs (e.g. broadcast, split, etc.) in the same boat for now. We can break them out if there is a significant difference in the use cases.

Configure a service

User selects a service on the palate to edit and is presented with a pop-up containing configuration settings specific to the service type. Selecting OK saves the configuration data, while selecting Cancel rolls back to prior configuration settings.

Notes:

• This is equivalent to editing the properties file and/or other service artifacts (e.g. JRuby script) generated for the service type.
• This use case applies to newly created services (haven't been saved/deployed), services that have been persisted, and services that have been deployed to the underlying runtime.
• Where does the default configuration come from? This is normally a product of the generate mojo.
• For the time being, we can code custom views for each service type in the tooling. Longer term, this will have to be extensible so that components can declare/provide an interface customized to the service details.
• It would be nice if we could provide some basic editing features for languages such as JRuby, XSLT, XPath, etc.
• Should we provide a view to the underlying WSDL that has been generated?

Delete a service

User selects a service on the palate to delete. Any connections between the deleted service and other services on the palate are removed. Any configuration associated with the service is purged.

Notes:

• This is equivalent to removing the IFL service definition and associated routing references, followed by a run of the generate mojo.
• Wiring needs to be updated/removed if the service is connected to other services.
• If the application has been persisted and/or deployed, the wiring and service artifacts need to be removed when the user requests a save.

Connect two services

User connects two services with a directed edge on the palate to indicate message flow.

Notes:

• Equivalent to defining a route to/from in IFL.
• How do we specify the exchange pattern for the message flow?

Disconnect two services

User clicks on a directed edge between two services and selects/clicks delete to remove a message flow.

Notes:

• Equivalent to removing a route to/from in IFL.

Save an application

The user can elect to persist the current application at any time in the service composition view. If it's a new application, the user has to choose a name and a destination (see notes).

Notes:

• Saving an application puts it in a persisted, recoverable state so that it can be recalled when the application is unloaded from the composition view.
• We can consider three options for save initially:
  • Store on the file system in the bundle data directory for the web composition tool.
  • Store in an SCM repository, e.g. Subversion
  • Store the application source in the application bundle which is deployed to the runtime. There is a precedent for this in OSGI-OPT/ directory of the bundle.
• Should we save applications automatically?

Load an application

User clicks on a load/open button and is presented with a browser containing a list of applications. The list of applications should be generated off of the set of saved/persisted projects and applications that have been deployed to the underlying runtime.

Notes:

• User should be able to load from:
  • local persisted store for the composition tool bundle
  • file path the user specifies
  • SCM repository
  • Underlying runtime (assuming the required artifacts are available in OSGI-OPT)

Deploy an application

Deploy is an explicit action requested by the user to package and deploy the application to the underlying runtime.

Notes:

• Dynamic composition use cases rely on an automatic refresh of configuration, service artifacts, and service wiring. This could be keyed off of requests to save the application.
• If the application is new, then the underlying operation is a bundle install.
• If the application exists in the underlying runtime, then deploy is either a unisntall/install sequence *or* a bundle refresh.

Start/stop an application

User starts or stops the services on the palate (which represent an application) as a collective unit. The application must be deployed in the underlying runtime before it can be started or stopped.

Notes:

Advanced Use Cases

Monitor message flow

User is able to view messages as they move through the system.

Capture message

User can capture a message at any point in a flow and view the content. The content view should provide a basic view which is only the payload and an advanced view which provides details on the enclosing message exchange, normalized message properties, etc.

Edit message

User can edit the data in a captured message. The basic and advanced views should both support edits where appropriate.

Replay message

User can replay a message flow between services.

Notes:

• Can be used in conjunction with hot deploy to test the effect of a configuration change immediately.
• Can be used in conjunction with edit message to test different message scenarios.

Insert Message

User can create a message and insert it into the flow between services.

Browse for service types

The service type palate should allow for searches of local and remote bundle repositories for additional service types.

API Contracts

Unless otherwise noted, it is assumed that all API contracts will be exposed as services in the OSGi service registry. Here's a high-level summary of contracts that we need. Feel free to add more or elaborate on a given contract.

• Create an application project
• Generate service artifacts
  • Possible that the first two steps could be combined into one. i.e. pass me an IFL string and I will generate the app structure and associated artifacts
• Package an application
• Deploy an application
• Start/Stop an application
• Undeploy an application
• Get application (retrieve a previously deployed app for display in the composition view)
• Refresh an application

For the contracts which depend on maven plugins, I'm wondering if we should package up maven and our plugins into a single bundle and expose a set of services that use an embedded instance of Maven to invoke the goals. This keeps everything in-process, in the current OSGi runtime, and within our current tooling support (not writing stuff twice).

Packaging

The composition tool should be packaged as an OSGi bundle. To the extent possible, all library dependencies should be resolved using import-package and supplied from other bundles installed in the OSGi runtime.

Libraries

List dependent libraries here so that we can hunt down or create bundled versions.

Activator

Any startup logic that is required for the composition tool should be implemented in a BundleActivator implementation.

Distribution

The composition tool will be added to the core distribution of Fuji for all platforms.

This page (revision-13) was last changed on 02-Oct-08 22:26 PM, -0700 by Mark Saunders.
This page was created on 06-Aug-08 17:01 PM, -0700 by KeithBabo.

More info...