Service Creation (SC) Subproject

The Service Creation (SC) subproject defines the extension points that allow tooling vendors to define the degree of integration they would like to do with the STP project. This page will outline what the main aims are for the SC project. We will investigate how it fits into the larger STP project and outline the deliverables that will result.

What is the SC Project about?

The STP CF and SOAS projects will provide the APIs and mechanisms required to support and expand the modelling of SOANs under the chosen assembly paradigm. However the management of the relationship between the SOA model tooling provided by STP and the actual implementation tooling(s) will be done by the SC subproject

  • Top Down approach where the user begins the process of defining the what SOA Network should look like, then creates the necessary entities required by the runtime which provides the service.
  • Bottom Up, where the existing tool is used to create a service, but this information then needs to be populated into the STP project.

The SC project is about creating an assembly model in either of these ways by allowing existing tooling products to gradually integrate with the STP platform and its modelling features.

Depending on this degree of integration, the core functionalities provided could be

  • exposing the content of the projects in the current workspace as SOAN building blocks (i.e. in the SCA paradigm:componentTypes)
  • central management of SOAN resources (e.g. all "STP enabled" projects would automatically be made available under an SOAN resource view or similar)
  • automatic update of SOAN models as the implementation details of the service they reference change (bottom up approach)
  • automatic update (or notification) of project when the SOAN model modify the requirements of the service implementation they host (top down approach)
  • automated project creation based on the info available from an SOAN model (top down approach)
  • etc.

The ultimate goal is to support fully integrated top-down and bottom-up development approaches as well as a mix of both in an agile way. For basic integration, it is envisioned that existing tools would require little or no modification in order to participate as a component in the STP tooling platform (Bottom Up approach where the STP project learns from the outputs of the existing tool). As the degree of integration increases, then the tooling is capable of communicating with the STP components, and the high level SOAN project can direct the runtime tooling.

As stated above the SC project will promote gradual integration in order to limit the initial impact on the code base of the tools being integrated.

What will be developed for the SC subproject?

This section will cover the initial deliverables that will be made. Some of these will go beyond that which is strictly part of the SC sub project but will be provided as a proof of concept. The following is a breakdown of the main components:

STP Project paradigm

There will be two types of project visible to those using the STP tooling:

  • SOAN projects: to design and manage SOAN assemblies. These would be a very high level project used to define large enterprise system which would use the underlying STP model to manipulate and persist the data. A project of this type would not focus on the implementation details, its only concern would be to be aware of and manage each individual implementation project.

  • Service implementation projects: to actually produce the implementation. It would take the form a decorative nature that would be added on top of the natures already required by the runtime implementing the service. The idea is that the project could still manage itself internally as it wishes while this extra Service Implementation (SI) nature would provide the necessary link/channel between the assembly structure and the implementation. This nature/builder would:

    • Not interfere with the original natures of the project
    • Handle the mapping between the STP model and that used by the existing tooling and runtime component.
    • Act as the notification channel between the SOAN project and the SI project
    • Have an associated builder that would manage the synch up between SOAN project and the SI project (for example by showing entries in the problem views when synch issues arise)
    • Likely be based on the introspector framework put forward by the SCA specs in the sense that an SI nature will reference a known introspector (as part of its attributes) and then the SI builder would delegate business processes to that introspector.

SOAN resources management

We need a mechanisms that developers will be able to use to find usable building blocks for their SOAN project. A resource view that would group all components usable by an SOAN project in the current workspace would be one possible option.

Examples of content in that resource view would include:

  • The service implementations being currently worked on in projects of the current workspace
  • imported pre-packaged services (e.g. .ear, .war, .jar, ...
  • Elements already defined in SOAN project(s) of the workspace but not yet implemented.
  • The view should render implementation entries under the light of an assembly paradigm not their native paradigm
  • The view should update itself automatically and in real time, at least for implementation hosted in project of the current workspace (e.g. by tracking the SI natures for example) and for model elements being defined in SOAN projects

Platform extension mechanisms

STP core will provide the necessary extension points to the model, but those extensions will not be sufficient to integrate specific Service Implementation tools sets. In addition an umbrella extension point will be required to regroup all extensions relevant to a runtime as well as the tools associated to this runtime. The scope of this extension point will expand as the project will evolve but its initial contents will include:

  • Supported interface(s): those extensions would be defined separately and then referenced here (to allow for reusability)
  • Supported implementation(s): those extensions would be defined separately and then referenced here (so to allow for reusability)
  • The reference to its relevant introspector or introspector adapter (to integrate with the SI nature)
  • Project creation handler (for top down approach approach)
  • Container/deployment handler
  • Packaging handler
  • etc.

Exemplary Implementation

It is planned that Apache CXF open source ESB will be used as an exemplary implementation of the runtime tooling using the SC project.

An initial proposal of the contributions break down for the SC sub project can be found here