-
Notifications
You must be signed in to change notification settings - Fork 4
sca
NSF features a model/diagram editor for creating executable models of interconnected service components. The graphical notation was inspired by the Service Component Architecture notation, and runtime model execution was created to be similar to OSGi component/service wiring. Nasdanika SCA models can be stored in XMI format and/or in a CDO repository.
Open Help > Install New Software, enter http://www.nasdanika.org/server/repository
into "Work with" text field, and then check "Nasdanika SCA Modeler".
You'll need Eclipse modeling edition, or you should install Sirius into an existing Eclipse installation.
Create a modeling project, or convert other type of project to a modeling project - right click on the project, select Configure > Convert to Modeling project. Then open File > New wizard and select Nasdanika/Nasdanika SCA Model.
Switch to the Modeling Perspective, right-click on the project and then on "Viewpoints Selection" menu item. Check "Nasdanika SCA" and click OK.
Then open the new model file, right-click on the root composite and select New Representation > new Composite diagram.
Enter a new diagram name and click OK. The new empty diagram will open in the editor.
The diagram will also appear in the model explorer view under the composite and under representations.aird
file.
Nasdanika SCA composite consists of components and nested composites connected by wires. A composite may export services and import service references and properties.
All model elements have description and configuration properties. Configuration shall be either a JSON object definition or a URL of JSON object definition.
In addition to schemes supported by java.net.URL
the following two additional schemes are supported:
-
bundle
- resource in the same bundle, e.g.bundle://config/MyComposite.json
. This scheme can be used to allow independent editing of the model and configuration and variability through fragments. -
resource://<bundle>/<resource>
- resource in a specified bundle, e.g.resource://org.myorg.mybundle/config/MyComponent.json
.
Exports a service from a composite. Can be wired to a service provided by one of composite's components.
Imports property.
Imports reference. Reference type can be selected from a drop-down. To define service/reference types create an ECore model, create EClassifiers - data types or classes - in the model and then use "Load resource" on the SCA model to link the type model to the SCA model.
Runtime component can be created in three mutually exclusive ways:
- By using a component factory at runtime to create a component from a template component with specified ID. Factory filter can be provided to select only specific component factories. If component with a given ID is not created by any available component factory and component's "Optinal" property is set to false (default), then a runtime exception is thrown. Otherwise, references wired to component's services are not set.
- Using a template component. A model with template component definition shall be loaded as resource and then Implementation reference shall be set to point to the template component.
- Using an implementation class. A model with class definition shall be loaded as resource and then Implementation Class reference shall be set to point to the implementation class. The implementation class shall extend
org.nasdanika.cdo.sca.Component
. As such the model which defines implementation class shall load sca.ecore model as resource.
Components which don't have any services are immediately activated. Component which exposes services can be marked as immediately activated by setting "Immediately Activated" property to true.
Nested composite, double-click opens a composite sub-diagram. Composite can optionally specify either implementation or implementation class similar to Component.
Composite implementation class shall extend org.nasdanika.cdo.sca.Composite
.
References composite defined elsewhere.
Service is a border node of component, composite, or composite reference and defines a service exposed by the component by type and optional name.
Reference is a border node of component, composite, or composite reference and defines a service referenced by the component.
Component, composite, or composite reference property.
Connects Service Export or Reference with Service or Reference Import.
Connects property with Property Import.
A runtime component is created by calling a model component's createRuntimeComponent(BundleContext, Context)
. Then the runtime component's
createServiceProvider(ServiceProviderContext)
method is used to create a ServiceProvider. SimpleServiceProviderContext is an out-of-the-box implementation of ServiceProviderContext.
ServiceProvider is used to obtain service references. Services are obtained from service references. ServiceProvider and ServiceReference interfaces extend AutoCloseable and shall be closed after use.
Model components can be either obtained from a ComponentFactory or loaded from model resources or CDO repository. BundleResourceComponentFactory is an implementation of ComponentFactory which loads model components from bundle resources.
Both model and runtime components extend CDOObject, so they can be stored in a CDO repository.
Components and service providers created by components can be used in different scopes.
In this scenario a composite is created, used and closed during processing of a single request. This is similar to the cloud model where VM's are created for a specific task and are disposed upon task completion.
A composite's service provider can also be stored as a session attribute and be used, for example, to drive a multi-step wizard. In this case a listener shall be used to close the composite's service provider when the owning session gets closed.
In this scenario a service provider is created in activate()
and closed in deactivate()
.
Runtime components/composites can be persisted in a CDO repository. This approach can be used for execution of long-running asynchronous processes.
Runtime component can use getServiceProviderContext(ServiceProviderContext rootContext)
protected method to obtain service provider context to execute code in the
context of the composite. For example, a component representing a human participant can expose a task service interface. When that service is
invoked, the component would store task request in the participant's task list. Later, when the participant opens their task list and completes the task,
the participant component obtains service provider context and invokes a service to pass execution to the subsequent activity in the process.