GSocProposalEclipseSTP

Google Summer of Code 2009 Proposal

Subject

Policy Derivation tool for STP Policy Editor + WS-Policy Awareness

Name

U.S. Wickramsinghe

Email

[mastershield2007@gmail.com] [060539m@uom.lk]

Project Title

Policy Derivation Tool for STP Policy Editor + WS-Policy Awareness

Project Details

The main goal of this project is to provide an extensible framework for Policy Derivation, from WS compliant XML Messages and Provide it as at tool for integration with the STP Policy Editor for editing these derived messages .

Policy Extraction would be of great importance to Web services related scenarios such as for Web Service clients to build a compatible policy , reading the SOAP messages coming from the Service side if the web service itself don't wish to publish it's policies . Also it would be very useful for different SOA platforms and ESB’s(Enterprise Service Bus ) to generate compatible policy by extracting the WS compliant policies out by reading the messages coming form other SOA endpoints. Hence with Integration of such a tool to Eclipse Policy Editor, we would be able to feed the derived policy instances to the editor itself and users can therefore edit the derived policy/policies to their liking , as STP policy editor supports rich functionality for such work.

In normal scenarios SOAP like XML messages are built in using the policies available in client or server side , hence providing 1:1 mapping of the applied policy and message built accordingly . Since policy derivation tool is adhering to a ‘reverse’ Process of the same scenario there may be multiple policies for a single message coming in (Hence 1:n mapping) and therefore policy framework should be adhering to these constraints as well.

Following are some abstract level modeling and architectural points I have come up with after some discussion with STP community on how to integrate this with STP Policy Editor.

Providing extensions for  multiple message sources such as abstract interfacing for selecting XML sources from various points such as Local File
System , Wire level input Stream (ie:-from a TCP Mon kind of interface) , Database source

Providing ability to extract policies from various XML standards (ie:-SOAP,JSON, JMS, Proprietary REST XML) that are compliant to standard WS   
specifications and making the internal data model extensible for such scenarios where users of both proprietary or standard XML messaging systems 
could make full use of the tool.

Providing extensions for  storing derived policies in various output sources (ie:- file System, database ,etc)

Providing  a good architectural model such that the framework gives ability for extracting multiple policies for  a given WS compliant message

I have done some work in the area of WS Security Policy extraction (Still in incubation stages) from soap messages hence that will be of great importance to this project where I will be able to apply the knowledge I gained on WS policy ,XML security and standard WS Specifications in to the current context of the project . I consider this as an added advantage for the design phase of the project as well where I would be able to leverage some design concepts and coding of this prototype in to the proposed new tool .

Among other main objectives of this project is to make STP Policy Editor aware of standard WS specifications (ie:-WS-SEC,WS-RM,MTOM,WS Addressing). This will provide STP editor with some collection of exemplars making it readily available for WS specs compliant policy instance editing . This will also enable Eclipse STP UI react to any XML instance explicitly or implicitly , for the related WS specs , like graphical icons, and menus reacting to an policy instance it may aware of. Since Policy Builder will be able to detect WS Spec compliant message instances directly , STP Editor can be made aware of the spec it should support for the respective policy instance as well .This will be an added advantage or feature Policy Builder tool could provide with respective to the WS policy awareness for the STP editor.

Other goals of this proposal include making STP Editor available for other/future WS:Policy constructs (ie:- wsp:Choice , wsp:Required,etc) that currently does not support . I will be willing to make necessary add-ons for current policy model or STP ui , if time permits .

Abstract Architectural View for Policy Builder