|
Lines 25-37
Link Here
|
| 25 |
news://news.eclipse.org/eclipse.stp.</a> |
25 |
news://news.eclipse.org/eclipse.stp.</a> |
| 26 |
|
26 |
|
| 27 |
<h2>Overview</h2> |
27 |
<h2>Overview</h2> |
| 28 |
<p align="left">�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.</p> |
28 |
<p align="left">�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.</p> |
| 29 |
|
29 |
|
| 30 |
<p align="left">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.</p> |
30 |
<p align="left">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.</p> |
| 31 |
|
31 |
|
| 32 |
<p align="left">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.</p> |
32 |
<p align="left">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.</p> |
| 33 |
|
33 |
|
| 34 |
<p align="left">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.</p> |
34 |
<p align="left">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.</p> |
| 35 |
|
35 |
|
| 36 |
<p align="left">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 <a href="http://www.w3.org/TR/wsdl" target="_blank">WSDL</a> and other web service standards.</p> |
36 |
<p align="left">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 <a href="http://www.w3.org/TR/wsdl" target="_blank">WSDL</a> and other web service standards.</p> |
| 37 |
|
37 |
|
|
Lines 41-47
Link Here
|
| 41 |
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: |
41 |
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: |
| 42 |
|
42 |
|
| 43 |
<ul> |
43 |
<ul> |
| 44 |
<li><p align="left"><i>Vendor neutrality</i>: 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 <a href="/projects/dev_processes/validation-phase.php">community involvement</a> in formulating key framework interfaces, so that the largest possible constituency is represented.</p></li> |
44 |
<li><p align="left"><i>Vendor neutrality</i>: 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 <a href="/projects/dev_process/validation-phase.php">community involvement</a> in formulating key framework interfaces, so that the largest possible constituency is represented.</p></li> |
| 45 |
<li><p align="left"><i>Extensibility</i>: 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. |
45 |
<li><p align="left"><i>Extensibility</i>: 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. |
| 46 |
|
46 |
|
| 47 |
<br><br> |
47 |
<br><br> |
|
Lines 49-57
Link Here
|
| 49 |
|
49 |
|
| 50 |
<li><p align="left"><i>Standards-based innovation</i>: 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.</p></li> |
50 |
<li><p align="left"><i>Standards-based innovation</i>: 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.</p></li> |
| 51 |
|
51 |
|
| 52 |
<li><p align="left"><i>Community Involvement</i>: 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 <a href="/projects/dev_processes/validation-phase.php">community</a> involvement.</p></li> |
52 |
<li><p align="left"><i>Community Involvement</i>: 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 <a href="/projects/dev_process/validation-phase.php">community</a> involvement.</p></li> |
| 53 |
|
53 |
|
| 54 |
<li><p align="left"><i>Transparency</i>: 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.</p></li> |
54 |
<li><p align="left"><i>Transparency</i>: 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.</p></li> |
| 55 |
|
55 |
|
| 56 |
<li><p align="left"><i>Agile development</i>: 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.</p></li></ul> |
56 |
<li><p align="left"><i>Agile development</i>: 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.</p></li></ul> |
| 57 |
|
57 |
|
|
Lines 75-81
Link Here
|
| 75 |
<li>The WSDL editing capabilities will be extended to provide the ability to support multiple physical bindings but not limited to JMS, MQ, Tibco, CORBA, and the ability for vendors to easily provide extensions for specific transports, for example Celtix, WSIF, or Synapse.</li> |
75 |
<li>The WSDL editing capabilities will be extended to provide the ability to support multiple physical bindings but not limited to JMS, MQ, Tibco, CORBA, and the ability for vendors to easily provide extensions for specific transports, for example Celtix, WSIF, or Synapse.</li> |
| 76 |
<li>The creation of and configuration of bindings (WSDL) for additional message formats for legacy integration in the SOAN, for example tooling to represent Cobol copy books one the wire or G2++, or CSV records</li> |
76 |
<li>The creation of and configuration of bindings (WSDL) for additional message formats for legacy integration in the SOAN, for example tooling to represent Cobol copy books one the wire or G2++, or CSV records</li> |
| 77 |
<li>The association of runtime policy with said service participants, for example the ability to mark a service provider as secure, load balanced, state-full/stateless, or transactional. This information is then used to create deployment artifacts and model interaction between service consumers and providers. (See SOAN Deployment subproject for list of policies targeted)</li> |
77 |
<li>The association of runtime policy with said service participants, for example the ability to mark a service provider as secure, load balanced, state-full/stateless, or transactional. This information is then used to create deployment artifacts and model interaction between service consumers and providers. (See SOAN Deployment subproject for list of policies targeted)</li> |
| 78 |
<li>Exemplary implementation support for Normalized Message (<a href="http://www.jcp.org/en/jsr/detail?id=208" target="_blank">JBI � JSR208</a>) bindings and transports (WSDL) for collocated or JBI/JVM interactions. The collocated interactions will not be limited to JBI, but JBI will be used as one of the exemplary tool implementations. Thus the editors required to create a JBI plugin, consume JBI services and model interactions with JBI components will be integrated into the relevant editors</li> |
78 |
<li>Exemplary implementation support for Normalized Message (<a href="http://www.jcp.org/en/jsr/detail?id=208" target="_blank">JBI � JSR208</a>) bindings and transports (WSDL) for collocated or JBI/JVM interactions. The collocated interactions will not be limited to JBI, but JBI will be used as one of the exemplary tool implementations. Thus the editors required to create a JBI plugin, consume JBI services and model interactions with JBI components will be integrated into the relevant editors</li> |
| 79 |
<li>The creation of an extensible framework for plugging in additional extensions for configuring bindings, transports and policies. For examples of these see (b,c, and d).</li> |
79 |
<li>The creation of an extensible framework for plugging in additional extensions for configuring bindings, transports and policies. For examples of these see (b,c, and d).</li> |
| 80 |
<li>The WTP validation tools used and extended to validate said contacts/policies</li> |
80 |
<li>The WTP validation tools used and extended to validate said contacts/policies</li> |
| 81 |
<li>The development tools will be able to support additional extensions providing extension points into the editor as well as the schema validator to allow developers to validate their WSDL against the schema which defines that extension.</li> |
81 |
<li>The development tools will be able to support additional extensions providing extension points into the editor as well as the schema validator to allow developers to validate their WSDL against the schema which defines that extension.</li> |
|
Lines 85-91
Link Here
|
| 85 |
<p align="left"><i>SOAN Deployment subproject</i></p> |
85 |
<p align="left"><i>SOAN Deployment subproject</i></p> |
| 86 |
|
86 |
|
| 87 |
<p align="left"> |
87 |
<p align="left"> |
| 88 |
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.</p> |
88 |
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.</p> |
| 89 |
|
89 |
|
| 90 |
|
90 |
|
| 91 |
Explicitly, |
91 |
Explicitly, |
|
Lines 95-117
Link Here
|
| 95 |
<li>An abstract model (EMF) will be created to describe service policies. The initial policies targeted include, message reliability, addressing, contract retrieval, location services, transactional, load balancing, high availability, state-full/stateless, security, SLAs(max response time), governance (how it is audited), message attributes (compression)</li> |
95 |
<li>An abstract model (EMF) will be created to describe service policies. The initial policies targeted include, message reliability, addressing, contract retrieval, location services, transactional, load balancing, high availability, state-full/stateless, security, SLAs(max response time), governance (how it is audited), message attributes (compression)</li> |
| 96 |
<li>Readers and writers will be provided for <a href="http://www.xml.com/" target="_blank">XML</a> & <a href="http://specs.xmlsoap.org/ws/2004/09/policy/ws-policy.pdf" target="_blank">WS-policy</a> description of these policies. Extensions can be added for additional readers and writers</li> |
96 |
<li>Readers and writers will be provided for <a href="http://www.xml.com/" target="_blank">XML</a> & <a href="http://specs.xmlsoap.org/ws/2004/09/policy/ws-policy.pdf" target="_blank">WS-policy</a> description of these policies. Extensions can be added for additional readers and writers</li> |
| 97 |
<li>Validation and matching of services will be provided (for example, are the consumer and provider policies compatible)</li> |
97 |
<li>Validation and matching of services will be provided (for example, are the consumer and provider policies compatible)</li> |
| 98 |
<li>Specific policy patterns will be implemented for <a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss" target="_blank">WS-Security</a>, role based access control, transaction (<a href="http://www.oasis-open.org/committees/%20tc_home.php?wg_abbrev=ws-caf" target="_blank">WS-C and WS-AT</a> implementation), location services (repository policy for contacts and references).</li> |
98 |
<li>Specific policy patterns will be implemented for <a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss" target="_blank">WS-Security</a>, role based access control, transaction (<a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-caf" target="_blank">WS-C and WS-AT</a> implementation), location services (repository policy for contacts and references).</li> |
| 99 |
<li>Policies extensions may also be used to describe policies like message compression, encryption, and Service usage and response time contacts. Samples of some of these will be provided as implementation examples. A base model for policies will be provided together with the models of the specific policies. A default editor will be dynamically created based on the model. However specific editors can be substituted for a specific policy model by providing an extension to edit that policy. All policies will have a default dynamic XML generator, and it is expected that implementations will be provided for specific runtimes. An exemplary implementation will be provided for Celtix, under the Celtix Tools Project subproject.</li> |
99 |
<li>Policies extensions may also be used to describe policies like message compression, encryption, and Service usage and response time contacts. Samples of some of these will be provided as implementation examples. A base model for policies will be provided together with the models of the specific policies. A default editor will be dynamically created based on the model. However specific editors can be substituted for a specific policy model by providing an extension to edit that policy. All policies will have a default dynamic XML generator, and it is expected that implementations will be provided for specific runtimes. An exemplary implementation will be provided for Celtix, under the Celtix Tools Project subproject.</li> |
| 100 |
<li>The definition of the deployment requirements for a service policies, i.e. the service can be collocated, requires JEE, JSE etc, so that deployable configurations can be modeled. This definition is then used by the extension to create the relevant deployment artifacts for that support the specific runtime. For example create a WAR file with security enabled and deploy as a proxy server.</li> |
100 |
<li>The definition of the deployment requirements for a service policies, i.e. the service can be collocated, requires JEE, JSE etc, so that deployable configurations can be modeled. This definition is then used by the extension to create the relevant deployment artifacts for that support the specific runtime. For example create a WAR file with security enabled and deploy as a proxy server.</li> |
| 101 |
</ol> |
101 |
</ol> |
| 102 |
|
102 |
|
| 103 |
|
103 |
|
| 104 |
<p align="left"> |
104 |
<p align="left"> |
| 105 |
This section is NOT attempting to handle service orchestration with <a href="http://www.oasis-open.org/committees/%20tc_home.php?wg_abbrev=wsbpel" target="_blank">BPEL</a>. That is viewed as the scope of a services participant, and will be an internal detail on one of the services in SOAN.</p> |
105 |
This section is NOT attempting to handle service orchestration with <a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel" target="_blank">BPEL</a>. That is viewed as the scope of a services participant, and will be an internal detail on one of the services in SOAN.</p> |
| 106 |
|
106 |
|
| 107 |
<p align="left"><i>Expected Runtime specific extensions subprojects</i></p> |
107 |
<p align="left"><i>Expected Runtime specific extensions subprojects</i></p> |
| 108 |
<p align="left"><b>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.</b> Thus extensions to support ESB�s, Repositories, Brokers, Containers and Data Access services, etc should be built as Runtime extension subprojects.</p> |
108 |
<p align="left"><b>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.</b> Thus extensions to support ESB�s, Repositories, Brokers, Containers and Data Access services, etc should be built as Runtime extension subprojects.</p> |
| 109 |
<p align="left">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. </p> |
109 |
<p align="left">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. </p> |
| 110 |
|
110 |
|
| 111 |
|
111 |
|
| 112 |
<p align="left"><i>Celtix Tools Project </i></p> |
112 |
<p align="left"><i>Celtix Tools Project </i></p> |
| 113 |
|
113 |
|
| 114 |
<p align="left">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</p> |
114 |
<p align="left">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</p> |
| 115 |
|
115 |
|
| 116 |
|
116 |
|
| 117 |
|
117 |
|
|
Lines 140-146
Link Here
|
| 140 |
|
140 |
|
| 141 |
|
141 |
|
| 142 |
<p align="left"> |
142 |
<p align="left"> |
| 143 |
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.</p> |
143 |
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.</p> |
| 144 |
|
144 |
|
| 145 |
|
145 |
|
| 146 |
<p align="left"> |
146 |
<p align="left"> |
|
Lines 171-177
Link Here
|
| 171 |
<li>Management Screens to look at the deployed solution, start / stop / pause services etc.</li> |
171 |
<li>Management Screens to look at the deployed solution, start / stop / pause services etc.</li> |
| 172 |
</ol> |
172 |
</ol> |
| 173 |
|
173 |
|
| 174 |
The very top of the layer is the SOAN level, a view of the policies and interrelations of the services and Quality of Service (QoS) provided but the SOAN. This layer will be used to view inter service policies, connect �compatible� services together, etc. For example polices can be set prior to creating of contracts, settings security levels and even identify key repositories that will be used by the developer. The SOAN layer provides the �business� view of the SOA Network.</p> |
174 |
The very top of the layer is the SOAN level, a view of the policies and interrelations of the services and Quality of Service (QoS) provided but the SOAN. This layer will be used to view inter service policies, connect �compatible� services together, etc. For example polices can be set prior to creating of contracts, settings security levels and even identify key repositories that will be used by the developer. The SOAN layer provides the �business� view of the SOA Network.</p> |
| 175 |
|
175 |
|
| 176 |
<h2>Projects</h2> |
176 |
<h2>Projects</h2> |
| 177 |
|
177 |
|
|
Lines 200-206
Link Here
|
| 200 |
<li>Erica Mitchell, IONA</li> |
200 |
<li>Erica Mitchell, IONA</li> |
| 201 |
<li>Fiona Kennedy, IONA</li> |
201 |
<li>Fiona Kennedy, IONA</li> |
| 202 |
<li>Freeman Fang, IONA</li> |
202 |
<li>Freeman Fang, IONA</li> |
| 203 |
<li>Ga�l Blondelle, EBM WebSourcing</li> |
203 |
<li>Ga�l Blondelle, EBM WebSourcing</li> |
| 204 |
<li>Howard Gao, IONA</li> |
204 |
<li>Howard Gao, IONA</li> |
| 205 |
<li>James Strachan, LogicBlaze</li> |
205 |
<li>James Strachan, LogicBlaze</li> |
| 206 |
<li>Jean-Pierre Laisne, ObjectWeb / Bull</li> |
206 |
<li>Jean-Pierre Laisne, ObjectWeb / Bull</li> |
