Skip to content
This repository has been archived by the owner on Feb 22, 2019. It is now read-only.
Pavel Vlasov edited this page Jul 1, 2015 · 4 revisions

Nasdanika 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.

Installation

Open Help > Install New Software, enter http://www.nasdanika.org/server/repository into "Work with" text field, and then check "Nasdanika SCA Modeler".

install

Modeling

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.

new_model_wizard

Switch to the Modeling Perspective, right-click on the project and then on "Viewpoints Selection" menu item. Check "Nasdanika SCA" and click OK.

viewpoint_selection

Then open the new model file, right-click on the root composite and select New Representation > new Composite diagram.

sca_new_representation

Enter a new diagram name and click OK. The new empty diagram will open in the editor.

sca_empty_diagram

The diagram will also appear in the model explorer view under the composite and under representations.aird file.

diagrams in the model explorer

Notation

sca_notation

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.
service export Service Export

service export properties Exports a service from a composite. Can be wired to a service provided by one of composite's components.

property import Property Import

property import properties

Imports property.

reference import Reference Import

reference import properties

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.

type model type model in project browser

component Component

component properties

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.

scatest model

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.

composite Composite

composite properties

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.

composite reference Composite Reference

composite_reference properties

References composite defined elsewhere.

service Service

service properties

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 Reference

reference properties

Reference is a border node of component, composite, or composite reference and defines a service referenced by the component.

property Property

property properties

Component, composite, or composite reference property.

wire Wire

Connects Service Export or Reference with Service or Reference Import.

property setting Property Setting

Connects property with Property Import.

Runtime

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.

Scopes

Components and service providers created by components can be used in different scopes.

Request

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.

Session

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.

OSGi Component

In this scenario a service provider is created in activate() and closed in deactivate().

Persistent

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.