The SOA (Service Oriented Architecture) Tools Platform Project (STP) - a top-level project proposal - is an open source project of eclipse.org, overseen by a Project Management Committee (PMC) and project leaders. The PMC Planning Council coordinates identified resources of the project against a Project Development Plan. All the work will be done in subprojects of SOA Tools Platform Project.
This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare its intent and scope. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to http://www.eclipse.org/newsportal/thread.php?group=eclipse.stp.
“SOA Tools” is a vast domain, however there are a set of key requirements that run across the domain. The goal of this proposed project is to put the fundamentals in-place so that an extensible tool set made of components and exemplary tools for constructing SOA applications is created. STP will leverage the existing work of the other projects like Data Tools and Web Tools Platform projects.
A developer using the proposed SOA Tooling project is interested in an environment that is easy to use -- one in which the challenges of application development are due to the problem domain, not the complexity of the tools employed. To this end, the project will strive to create a highly usable and consistent environment that works well with associated technologies, whether being used by a developer working/creating a service, an administrator maintaining or monitoring a production system, or constructing a larger SOA Network.
Such an environment starts with key frameworks designed both for use and extensibility. Examples include the location or creation of a service consumer or provider, the consumption of these services, the configuration of the physical attributes (transport, message format) and the policies required to access or consume the like (security policy, access control, transactional, availability). Further the ability to locate and add services to the SOA interactions like transformation, routing, for process orchestration to a broker or end-point needs to be addressed.
Finally the creation of Artifacts that can be used to deploy, enforce or manage said SOA participants’ needs to be created from the Eclipse tooling in an extensible way.
The proposed project will not try to attempt to define every type of service in a SOA but to define the contracts to unify them into a SOA through an extensible framework and model the policies and interactions with an abstraction so that multiple specific vendor implementations can be supported from the vendor independent models of WSDL and other web service standards.
The SOA Tools Platform (STP) project will include extensible frameworks and exemplary tools, enabling a diverse set of plug-in offerings specific to particular SOA participant technologies and supported by the STP ecosystem. In the spirit of Eclipse, the project will be guided by the following values:
Vendor neutrality: We intend to provide SOA service construction, policy and service interaction frameworks and tools not biased toward any vendor. Our intention is that STP be leveraged to provide the Eclipse community with the widest range of choices possible. To this end, we seek community involvement in formulating key framework interfaces, so that the largest possible constituency is represented.
Extensibility: We recognize both the common need for SOA tooling infrastructure and the desire to extend the offerings in new and innovative ways. To support these efforts, our components will be designed for, and make good use of, extensibility mechanisms supported by Eclipse.
It should be noted that this project would define a number of extension points using the Eclipse plugin mechanism. The structure of the SOA tools will need to be abstracted so that out of the box we will provide functionality that is common across all toolkits (e.g. basic WSDL creation and editing) but will rely on underlying runtime toolkits extending platform to offer their services into the toolkit. For example, the ability to create complex routing components would be made available as an Eclipse plugin that would extend the basic STP to support open source projects like Celtix, ServiceMix and Mule.
Standards-based innovation: This proposed project will deliver an extensible, standards-based tooling foundation on which the widest possible range of vendors can create value-added development products for their customers and end-users. Where standards exist, we will adhere to them. At least, at first, where standards are emerging, we will wait for them to emerge; this can be re-evaluated later according to user needs and contributor availability. Where multiple technologies are widely used for a given functional need, we will attempt to support each, subject only to technical feasibility and our goal of providing the most capable and extensible foundation long term.
Community Involvement: Success for STP, as with other eclipse.org projects, is as much a factor of community involvement as the technical merit of its components. We strongly believe that STP will achieve its full potential only as the result of deep and broad cooperation with the Eclipse membership-at-large. Thus, we will make every effort to accommodate collaboration, reach acceptable compromises, and provide a project management infrastructure that includes all contributors, regardless of their affiliation, location, interests, or level of involvement. Regular meetings covering all aspects of STP, open communication channels, and equal access to process will be key areas in driving successful community involvement.
Transparency: As with all projects under the eclipse.org banner, key information and discussions at every level – such as requirements, design, implementation, and testing – will be easily accessible to the Eclipse membership-at-large.
Agile development: We will strive to incorporate into our planning process innovations that arise once a project is underway, and the feedback from our user community on our achievements to date. We think an agile planning and development process, in which progress is incremental, near-term deliverables are focused, and long-term planning is flexible, will be the best way to achieve this.
SOA applications, services and deployments (we will call this the SOAN, the SOA Network) are ones that are created across two axes, the principles of creating a service and the methodology for deploying these services in a network, the SOAN.
Service Creation subproject
Ideally when a SOA service is created, the contract (STP will use WSDL), the implementation and the physical attributes should be independent of each other. STP will re-enforce this architecture for all service creation tooling provided in this proposed project.
SOAN Deployment subproject
Ideally when a SOAN is created, a separation of Resources, Components, Business Services, and Presentation is desired. Most people don’t agree on the exact terms, but all agree on the patterns for creating a re-useable network of both application and infrastructure participants. The STP platform will focus on providing the tooling required to tie these entities together based on their contracts and policies.Explicitly,
This section is NOT attempting to handle service orchestration with BPEL. That is viewed as the scope of a services participant, and will be an internal detail on one of the services in SOAN.
Expected Runtime specific extensions subprojects
Exemplary implementations can be provided for specific tooling of runtimes, provided they are built on the extensions and are pluggable for the specific vendor or open source implementations so that the extensible framework is not compromised. Thus extensions to support ESB’s, Repositories, Brokers, Containers and Data Access services, etc should be built as Runtime extension subprojects.
Over and above the participants there are some key enabling technologies in a SOAN. These include ESB’s, Repositories, Brokers, Containers and Data Access, which are present in every SOA deployment. These specific participants will be also tackled in the initial scope. Additional services can be tackled with the addition of members to this project. These subprojects build on the concepts and deliverables from the above two subproject in addition to the DTP (Data Tools Platform) project.
Celtix Tools Project
This proposed project will explicitly tackle the tooling of specific implementations of ESB’s, Repositories, Brokers, Containers and Data Access. Thus the abstraction layers created by the above projects will be used to create extensions to tool the Celtix, ServiceMix, or used with any other JBI container. This forms both an example and exemplary tool implementation for the end-end usage of the Tools provided include
Note, JBI Tooling might be deemed enough scope to subdivide this sub-project.
In a SOA network the Quality of Service is one of the key characteristics, this includes High Availability, security, response times, transactional, management and logging, for example ARM. These dynamics define the “value” of the network to deliver on a service contract SLA (service level agreements). The modeling and tooling of each of these are out of scope of the initial proposal, but the visualization of these attributes and design based on them is in scope, together with interaction with them in the SOAN to provide or enforce the SLA’s.
Although the scope of STP includes exemplary tool implementations for open source and commercial ESB participants and services, these are not necessarily intended to be the definitive extensibility generators provided. Instead, they are intended to serve two purposes. First, they are intended to enable users to immediately use these artifacts (for example using a WTP generated application in a SOA deployment), although possibly without exploiting all their features. Second, they are intended to serve as examples to both commercial and open source developers who want to integrate consumption/interaction with SOA participants into Eclipse STP framework. It is consistent with the goals of this project that the exemplary extensions become superseded by more complete implementations provided by third parties, both commercial and open source.
The key behind this proposal is that the entire Eclipse membership, not just for those intimately involved with SOA will benefit from the tooling.
Logical Model Architecture
The diagram describes the key components that will be delivered as part of the SOA Tools Project. At its core is a suite of contract design and development tools that allow users to create services with additional validation. From a design time perspective, it will provide a number of extension points to extend the basic functionality. Extensions provided but not limited to include:
Back to the top