Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stp-dev] Last chance for Feedback: SOA Tree Proposal 
Thanks for the doc, Adrian. For some reason when I look at
the Fraktur fonts you've used, I automatically think of
Kartoffelsalat :)

In preparation for submission to the EMO, I've turned the doc
into an HTML form for the website (attached). There are a
few links and bits that need to be updated.

I'll be back with more comments later - I just wanted to put
this format out there before you made changes!

 cheers
  --oh

Introduction

SOA Tree is a proposed sub-project under the top-level project Eclipse SOA Tools Platform (STP). This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare the intent and scope of the SOA Tree sub-project. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and join the project. Please send all feedback to the Eclipse STP forum until a proper newsgroup is established.

Background

The Eclipse SOA Tools Platform project contains tools for designing, building, configuring and deploying SOA applications. The current STP Intermediate Model component bridges different existing Eclipse STP editors (such as BPMN and SCA) through a common SOA metamodel. Users can transport SOA artifacts between editors by invoking transformations to and from the Intermediate Model instance. This ensures that elements such as services and processes are shared across the different perspectives of various SOA stakeholders, thus minimizing duplication and the risk for errors when building complex SOA systems.

The aim of this proposal is to extend the scope of the existing STP-IM component to better editor coverage while at the same time ensuring a seamless experience by reducing the need for manual transformations. In addition the proposal aims at providing functionality for connecting SOA editors to runtime projects and components in order to bridge the gap between SOA design and runtime.

Description

The purpose of the SOA Tree proposal is to create a project that can serve as a central Eclipse SOA modeling container useful for a wide variety of existing and upcoming SOA editors, runtime and platforms. By employing a simple and easily extendable SOA metamodel as its core, the SOA Tree will provide a consistent, always-in-sync representation of common SOA artifacts in an Eclipse workspace.

Additionally, by providing connectivity to runtime projects and SOA repositories, the SOA Tree instance will be kept in sync with evolutions of these artifacts at runtime, updating properties such as QoS parameters in its model.

The following are a simplified list of the envisaged functionalities:

  • Transformations between different Eclipse Editors
  • Keeping a synchronized version of SOA artifacts within a SOA-oriented workspace using a builder-type approach
  • Updating model information in SOA editors with runtime data (from monitoring)
  • Feeding model information to deployment tools (potentially using SCA as format) and runtime tools (useful for interpreting monitoring data).
  • Obtaining information from SOA repositories (such as lists of services or governance information)

Project Scope

The SOA Tree project will focus on integrating existing and upcoming Eclipse projects related to SOA editors and runtime tools. It primarily targets the scope of the existing Eclipse STP project and the upcoming Eclipse SOA TLP.

Out of Scope

The proposal does not aim at providing a runtime project, or a runtime monitoring tool. It does not envisage the creation of live views of SOA systems but rather the enablement of efficient utilization of a large variety of tools and editors for building SOA systems.

Proposed Components

The following initial components will comprise the SOA Tree:

  • Trunk - the Core Metamodel and API (initial existing code in STP-IM): contains the SOA elements and their inter-relations, enabling the storing of distilled SOA elements used by different editors and tools.
  • Branches - the Transformation Plug-ins (initial existing code in STP-IM): contain the logic required to move and convert information between editors, tools and the core metamodel instance.
  • Phloem - the Builder (tentative initial contribution in STP-IM bugzilla) ensures the constant updating of SOA artifacts in the core as well as in the corresponding editors and tools (e.g. when saving a diagram, update the appropriate artifacts in the core while also enabling the update of the corresponding artifact in related editors or tools).
  • Leaves - the Editor Extensions (initial existing code in STP-IM), extensions and improvements to editors and tools for adding SOA Tree-specific functionality at design time (e.g. views allowing the enrichment of certain SOA elements in the core or configuration menus for customizing the amount of information to be moved to/from the core).
  • Roots - the Runtime Connections: for moving information to and from runtime tools and repositories when needed in order to have a “living” core, providing a good reality snapshot. This can be useful when diagrams are out of sync or when aggregated monitoring information is required to update graphical elements. Also for generating deployment information in a common format that could be based on SCA for instance.

Relationship with other Eclipse projects

The Policy Editor sub-project will be build on top of the Eclipse Platform and will have relationships with other Eclipse projects.
  • Eclipse SOA Tools Project
  • BPMN Modeler Project
  • SCA Tools Project
  • Eclipse BPEL Project
  • Java Workflow Tooling Project
  • Swordfish
  • EBAM (upcoming proposal)
  • Other runtime projects
  • SOA Industrial Working Group to provide useful feedback and requirements throughout the project’s evolution.
Other projects will be added to this list as necessary.

Organization

We propose that this sub-project will take place under the top level project STP.

Proposed initial committers

  • Adrian Mos, INRIA (lead) - STP-IM component committer
  • Andrea Zoppello, Engineering - STP-IM component committer
  • Gianfranco Boccalon, Engineering
  • Luca Rossato, Engineering
  • Luca Barozzi, Engineering
  • Fy Ravoajanahary, INRIA
  • Juan Cadavid, INRIA

Initial Code Contributions

The initial code contribution will be the currently existing STP Intermediate Model component.

Interested Parties

  • Stéphane Drapeau, Obeo
  • Oisín Hurley, Progress Software
  • Oliver Wold, SOPERA
  • Vincent Zurczak, EBM WebSourcing
  • Antoine Toulmé, Intalio
  • Marc Dutoo, OpenWide
  • Paul Brebner, NICTA

    • Back to the top