SwitchYard Eclipse Tooling

    Purpose

    The purpose of this document is to define the general direction for Eclipse tools supporting SwitchYard development and to outline general requirements for the tools.

    Strategy

    Maven Integration

    The basic tooling strategy for SwitchYard will center upon using Maven as the build system of choice SwitchYard projects.  This implies the use of Eclipse m2e.  The rationale behind this:

    • SwitchYard projects created within Eclipse should be buildable using common automated build/release management systems (e.g. Hudson/Jenkins).
    • Build artifacts for SwitchYard projects produced by Eclipse should exactly match those built by external build/release management systems.
    • Eclipse tooling can reuse capabilities provided by SwitchYard Maven plugins.
    • A user should be able to exactly recreate any of the provided SwitchYard quickstarts using Eclipse tooling.

    WTP/WST Integration

    The tooling should also support integration with WTP/WST tooling.  This will allow SwitchYard projects to make use of existing tools for:

    • Creation and editing of artifact types supported by SwitchYard (e.g. jBPM, Drools, etc.).
    • Deployment, testing and debug during development (i.e. WST servers integration).
    • Management of the SwitchYard runtime (e.g. configuration, etc.).
    • Interaction with SOA artifact repositories (i.e. Guvnor).
    • SwitchYard project facet that can be added to existing JEE projects.

    Initial Goals

    The initial goals for the tooling are to get the SwitchYard application developer up and running as quickly as possible.  The initial functionality will focus on creating basic stubs for various SwitchYard artifacts which should serve as a starting point for the developer: a basic template for a project, service or transformation.

    Functionality

    Application Development

    The following should be provided to support the SwitchYard application developer:

    • New project wizard - should create and configure a new project similar to the ones created using Forge tools or Maven archetype.
    • New service wizard - should create a stub for a SwitchYard service and ensure the project's pom.xml is configured correctly to support the type of service (e.g. including relevant component dependencies).
    • New transformation wizard - should create a stub for a transformation.  This may be invoked from within a class which implements transformations (e.g. to create a new transformation method).
    • Configuration of existing projects - update the project's pom.xml to include required SwitchYard dependencies and build plugins and attach SwitchYard facets to the project.
    • WTP/WST integration to support running/debugging SwitchYard applications.

    Runtime Configuration

    The tooling should give the user the ability to easily add support for various SwitchYard components (e.g. SOAP, Camel, etc.).

    Application Configuration

    Users should be able to easily access and modify application configuration (e.g. gateways, references, etc.).

    Project Navigator

    The tooling should provide an extension to the Eclipse Project Navigator that displays SwitchYard specific project information.  For example:

     

    Tree Node
    Description
    Properties
    Actions
    SwitchYardParent node for SwitchYard project details.name, target namespace
    • Configure capabilities (runtime version, components)
    • Edit properties
    GatewaysContainer for exported services (i.e. switchyard/composite/service).
    • Promote service (add gateway)
    <service>An exported service.name, promted service, interface, policies
    • Delete
    • Add gateway (binding)
    • Edit properties
    <binding>A configured inbound gateway (e.g. SOAP, Camel, HornetQ).specific to gateway type
    • Delete
    • Edit properties
    ReferencesContainer for imported services (i.e. switchyard/composite/reference).
    • Promote reference
    <reference>An imported service.name, promoted reference, interface, policies
    • Delete
    • Add gateway (binding)
    • Edit properties
    <binding>A configured outbound gateway (e.g. SOAP, Camel, HornetQ)specific to gateway type
    • Delete
    • Edit properties
    ComponentsContainer for implementations providing or consuming SwitchYard services(i.e. switchyard/composite/component).

    <component>A component implementation.name, implementation
    • Edit properties
    <service>A provided service.name, interface
    • Promote service
    • Edit properties
    <reference>A required service.name, interface
    • Promote reference
    • Edit properties
    ArtifactsContainer for artifact dependencies (i.e. switchyard/artifacts).
    • Add artifact
    <artifact>An artifact referencename, URL
    • Delete
    • Edit properties

     

    The project navigator provides a good platform for incrementally adding support for project configuration.  All actions available in the navigator should also be available in the configuration editor.  An editor provides a better context for working with application configuration (especially for top down workflows) and the navigator actions should be considered shortcuts for common tasks.

     

    Because navigator actions could be affecting the switchyard.xml file in the project, care must be taken to ensure both the view and editor are aware of changes made by the other (i.e. both should use workspace listeners).

    Configuration Editor

    TODO: flesh this out

    Validation

    The following validation should be performed on the configuration:

    • Unique component names
    • Unique service names (component/service and composite/service)
    • Unique reference names (component/reference and composite/reference)
    • Promote attributes must resolve to a service or reference (note, component name is only required if the name is used by more than one component)
    • Application name must match composite name (i.e. switchyard@name == switchyard/composite@name)
    • If application namespace is defined, it must match the composite target namespace.
    • Type compatibilty - the validator should raise warnings if interface types are incompatible and no transformers are available

     

    Exception levels for the validator should be configurable (e.g. raise errors vs. warnings).

    Service Development

    SwitchYard provides a framework for producing services using various implementation technologies.  Because of this, SwitchYard tooling will rely on existing tooling available for these technologies (e.g. Java, BPM, etc.).  When possible, SwitchYard will provide extensions  so users may more easily integrate SwitchYard services into their implementations (e.g. auto-complete for @Reference used in Java bean implementations).

     

    The following is a list of areas where extensions may be provided:

    • New Wizards - custom new wizards may be provided for each implementation type.  The wizard can ensure that project is correctly configured (e.g. adding SwitchYard BPM support, adding project facet, etc.) and can stub out the implementation appropriately (e.g. adding @Service to a Java class).
    • Editor Extensions - extensions should be provided to allow users to easily define service and reference details within the native editor (e.g. SwitchYard service widget in BPM, auto-complete in Java editor, etc.)
    • WTP Project Facets - if a WTP facet is provided for a specific implementation technology, the SwitchYard tooling should ensure that facet is configured on the project if the technology is uses.
    • Validation - if any special validation is required for SwitchYard extensions, those should be added to either the SwitchYard project validator or the validator used by the specific technology, if supported (e.g. validating the existence of referenced services).

     

    The following table summarizes the requirements for the currently supported SwitchYard implementation types:

     

    Component Type
    Descirption
    New Wizard
    Editor Extension
    WTP Facet
    Validation
    Bean (Java CDI)Java CDI implementation

    Extends Java class wizard:

    • Select service interface
    • Add @Service to class definition
    • Method stubs
    • Auto-complete for @Reference values
    ???
    • Errors for unresolved references
    • Error if service type is not in the class's type hierarchy
    BPMjBPM implementations (BPMN2)



    BPEL




    CamelCamel routes



    Clojure




    DroolsRules



    Java Bean Services

    TODO...

    BPM Services

    TODO...

    BPEL Services

    TODO...

    Camel Services

    TODO...

    Clojure Services

    TODO...

    Drools Services

    TODO...

    Gateway Bindings

    Tools should be provided for creating and editing gateway bindings for services and references.  A framework should be provided for common editing common gateway elements:

    • Service or reference being promoted
    • Interface details
    • Message composer
    • Context mapper

    In addition to the common elements, additional tools may be required to simplify the process of configuring a gateway (e.g. Java => WSDL).

     

    The following table summarizes the requirements for the currently supported gateway types:

     

    Gateway Type
    Type Settings
    Notes
    SOAP
    • WSDL file location
    • WSDL port name
    • Context path
    • Port

    Utilities should be available for generating WSDL files from implementation interfaces (e.g. Java to WSDL). Option to automatically create any necessary transformers.

    Camel, Generic URI

    Camel, Atom

    Camel, Direct

    Camel, File

    Camel, Timer

    Camel, Seda

    Camel, Mock

    HornetQ

     

    SOAP Gateways

    Camel Gateways

    Generic URI

    File

    Atom

    Direct

    Timer

    Seda

    Mock

    HornetQ Gateways

    Common Tools

    TODO: Tools for working with things like MessageComposer, ContextMapper, etc.

    Additional Utilities

    Interface Translation Tools

    TODO: e.g. WSDL <=> Java

    Transformation Tools

    TODO: JAXB, JSON, Smooks, ...????

    Test Tools

    The tools should allow the developer to easily create test cases for:

    • Service implementations - test service logic.
    • Service bindings - test endpoint integration.
    • Transformations - test transformation logic.

    Extension Development

    The tooling should support the development of SwitchYard extensions.  The tooling should allow for the creation of stubs for:

    • Components providing support for custom implementation or binding types.
      • Creation of new ExchangeHandler types.
      • Creation of new Activator types.
      • Creation of configuration model XSDs and associated model code.
    • Custom transformation types.
    • Custom serialization types.