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:

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:

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:

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.