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.
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.
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.
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.
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.
The tooling should give the user the ability to easily add support for various SwitchYard components (e.g. SOAP, Camel, etc.).
Users should be able to easily access and modify application configuration (e.g. gateways, references, etc.).
The tooling should provide an extension to the Eclipse Project Navigator that displays SwitchYard specific project information. For example:
|SwitchYard||Parent node for SwitchYard project details.||name, target namespace|
|Gateways||Container for exported services (i.e. switchyard/composite/service).|
|<service>||An exported service.||name, promted service, interface, policies|
|<binding>||A configured inbound gateway (e.g. SOAP, Camel, HornetQ).||specific to gateway type|
|References||Container for imported services (i.e. switchyard/composite/reference).|
|<reference>||An imported service.||name, promoted reference, interface, policies|
|<binding>||A configured outbound gateway (e.g. SOAP, Camel, HornetQ)||specific to gateway type|
|Components||Container for implementations providing or consuming SwitchYard services(i.e. switchyard/composite/component).|
|<component>||A component implementation.||name, implementation|
|<service>||A provided service.||name, interface|
|<reference>||A required service.||name, interface|
|Artifacts||Container for artifact dependencies (i.e. switchyard/artifacts).|
|<artifact>||An artifact reference||name, URL|
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).
TODO: flesh this out
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).
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:
|BPM||jBPM implementations (BPMN2)|
Java Bean Services
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|
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|
TODO: Tools for working with things like MessageComposer, ContextMapper, etc.
Interface Translation Tools
TODO: e.g. WSDL <=> Java
TODO: JAXB, JSON, Smooks, ...????
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.
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.