So, as a result of the above, the method that I will use to outline the service tools in WorkSpace will be based on a relatively granular bottom up model.

One of the most onerous aspects of SODA is dealing with the complexity of the underlying terminology and technology. The approach taken in WorkSpace is to hide this as much as possible and to settle on a terms that are hopefully more descriptive.
The first part of this is to declare that a service consists of two primary parts:

1. An interface
2. An implementation

The implementation is called an endpoint. The endpoint is the part of the Service that accomplishes some business logic. In WorkSpace there are several different types of endpoints and in order to make some form of categorization possible, Services are grouped into Types, each type is associated with a specific endpoint.
Typing of services in this way is purely a developer convenience and in no way does it imply that the consumer of a service needs to know anything specific about its type. The type is to allow the developer to easily understand the endpoint details for the service and to allow the tools to support endpoint specific functionality - for example, a Java source editor or a Business Process Editor. The Service Editor always provides an editor that contains a Service interface designer (that is not type specific) and if appropriate, endpoint editor pages.
Service types include:

• Java (Java Service)
• EJB (EJB Service)
• Business Process (Business Process Service - BPEL)
• Message (Message Service - JMS, Email, SMS, FTP, File etc)
• Transformation (Transformation Service - XSLT)
• and others..

A new Service is created by selecting the required type from the 'New Service Wizard':

Once a Service Type has been selected, a service resource (Service Model) is created and the appropriate Service Editor is displayed. The Editor is derived from a base Service Editor and is specialized for that Service Type by adding endpoint specific pages. These additional pages will either support editor pages for Java, BPEL, XSLT or pages that define a reference to an existing implementation (EJB, Message etc).

The Interface editor is designed to represent the Service Interface using a graphical metaphor and can be used to edit the interface as required for Services where the endpoint is being created, for derived Services (those where the endpoint already exists), editing of the interface will be limited.

There are really two approaches to creating a service, one involves the creation of both the service interface and the endpoint together. The other is a service that is created from an existing endpoint and the interface is therefore derived. Usually the only difference between the two is that in the latter case the interface is usually immutable (as the endpoint is fixed and cannot generally be changed). WorkSpace allows the developer to define either style of service using the same interface designer editor.

Along with the Service Editors, there are two important views in WorkSpace that contribute to a consistent user experience when working with services, these are the Service Explorer and the Enterprise Explorer.
The Service Explorer is somewhat like a mini-registry that shows a list of all services that currently exist in the project (and any referenced projects) and can be used as a source for dragging and dropping service interfaces onto consuming application (such as Business Process diagrams).
The Enterprise Explorer is a view that contains Connection Profiles, these are used to display Servers and their content that are relevent to the developer.

note: Connection Profiles have now been contributed to the Eclipse DTP project.

Connection Profiles are an important part of the SODA experience in WorkSpace and contribute to the ability to easily create services from existing enterprise assets as well as provide a hook for administration and management tools.

Dragging and dropping assest such as EJBs, Queues, Database Stored procedures, existing Services from the Enterprise Explorer into the project will automatically create a service with a default interface. In most cases, the interface will suffice for the service and it can be included in a composite application or packaged and deployed to the Service Container immediately. This is a real developer productivity improvement over traditional service development.

In my next post I will start to outline how Services can easily be used in WorkSpace and how they are deployed to Service Containers.