Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Servus Architecture

This page gives an overview of the functionality proposed by Servus and how the architecture will support it.

Functionality Overview

Overview.jpg

This diagram describes the types of artifacts involved in Servus and how they relate. We use UML notation to specify the type of the artifact, meaning its meta-model. For example, Doc: WSDLv1 means that a document named Doc is typed by WSDLv1, i.e., conforms to a WSDL version 1 meta-model.

The upper part of the diagram, with grey boxes and dark arrows, represents what already exists in EMF. Regular EMF transformations are capable of getting an XSD representation of types and generate a corresponding Ecore model; from the model, you can generate Java source code; and the reverse direction is also supported (from Java to XSD).

Servus extends EMF by taking into consideration Web Services related artifacts. It provides transformations between WSDL documents, Ecore models and JAX-WS based source code, preserving the references between artifacts. Note that the transformations are specified with respect to the meta-models.

The core concept in Servus is its meta-model. The Servus meta-model is a generic service model, that contains abstractions such as interfaces, bindings and services. It is abstract so that different concrete service descriptions can be mapped to it, but it is very much inspired by WSDL concepts.

Given a WSDL document (be it in version 1 or 2), Servus can transform this document into a model typed by the Servus meta-model. Servus will also use regular EMF transformations to map the referenced XSD to an Ecore model, and the Servus model will reference to the appropriate types in the Ecore model. From the Servus model, we can generate JAX-WS web services artifacts, such as interfaces, client proxies and service skeletons. Note that data types used as parameters or return values are also referenced in the source code.

The last aspect of the diagram is the presence of a Model: Ecore artifact. The Servus model (Model: Servus) is typed by a fixed Servus meta-model. This means that there are explicit references in the document to a Servus Ecore file representing the meta-model. However, sometimes developers want to avoid this dependency. Therefore, Servus also provides a transformation that creates a profile in Ecore. Instead of explicit references, Model: Ecore is a model typed only by Ecore in which Servus typing information is encoded as EAnnotations.

Architecture Overview

Servus is implemented as a series of Eclipse plugins. A detailed description of the plugins and their relationships can be found in the API description.

Back to the top