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 Summary

The STP policy editor is an Eclipse editor for editing WS-Policy content or other XML content that is based on XML-Schema with a graphical editor. While based on the XML Editing Framework (XEF), STP policy editor provides nice and convenient framework for adding/deleting/editing xml elements for the policy instances based on the schema provided . Primary goal of the proposed project is to make use of this functionality of the STP policy editor to make way for a whole new policy tool + an extensible framework , which should extract the underline policy assertions , of any XML based WS Standards compliant (ie:- WS Security ,WS RM,WS Addressing,WS MTOM , etc) Message that is provided to it.

Among other objectives of the proposal are to make STP Policy Editor WS:Policy aware by providing collection of configuration options for the policy Editor tool while providing out of the box editing capabilities for editing xml instances accordingly to WS compliant standards. Several other objectives includes making policy editor available for other/future WS:Policy constructs that currently does not support and making minor adjustments in usability of the editor.

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

Project Plan

Since the scope of the project is some what spanned across several aspects and due to time constraints endured by Google ,I am planning to engage in this project primarily in 4 phases . Initial phase will be more focusing on familiarizing myself with Eclipse and it’s component platform , Eclipse WTP and STP Policy Editor , coding standards and related stuff.

In the second phase I am planning to discuss with the Eclipse Community the model and architectural approach that should be adhered .This is obviously of utmost importance since policy derivation tool (policy builder) has number of extension points and integration points with STP Policy Editor . After some discussion I would be able to come up with a requirement specification and with some further discussion and brain storming we would be able finalize the design aspect of this. Design would mainly consist of the Architecture and API for making way for the required extension points and data model discussed above . And then real implementation work for this framework and API will begin .And at the end of this stage I’m planning to implement some stubs for proof of concept and as prototypes , using the API i would be developing.

The third phase would commence with actual implementation of some of the extension scenarios for message sources , outputs , etc. For example I will be implementing concrete message source coming from a local file directory deriving policies for SOAP type messaging for WS Security specs and making the output XML available in local file system . This third phase would certainly contain bulk of the work , developing concrete implementations of message sources , types and outputs . However I’ll be mainly focusing on deriving policy instances for WS Security,WS Addressing and RM specs and others will be considered later in the stage .I’ll also go into UI aspects as well since STP Editor integration greatly relies on the usability of this tool and how well it will be handled .

The fourth and final stage would start focusing on standards support for STP Policy Editor making required configurations options in both UI and back-end with the use of Eclipse XEF ,ui interfaces ,etc . Additional requirement would be to make STP editor WS Policy aware of it’s current policy instances being edited .However this will be easily possible with derived policy instances (constructed by policy builder tool ) but regarding other arbitrary instances we may have to come up with some strategy. I will also look into other extensible scenarios of this framework and develop concrete implementations for different sources ,out puts and message types and specs as possible(ie:-various input/output sources, XML ,JSON message types, other WS specs support). Forth stage should be comprised of testing and documentation preparation as well . Sample unit / integration testing will be provided for most of the scenarios while making available a comprehensive java doc API Documentation Guide along with an efficient online tutorial .

This Tool will be tested and fixed for possible bugs along with development cycle in each phase .In the mean time , if time permits I will look into additional goals like providing useful patches for STP policy editor and extending policy builder further for different circumstances as possible .I will be going through lot of exciting work and will certainly put all my effort to make this project a success.

Project Schedule

April 15th to May 23rd

Google has included nearly 1 1/4 months for community bonding in GSOC 2008. I will use this period to execute my initial phase plans for the project. I would also like to start the second phase at the end of this period , for gathering requirements and discussions on architectural details.

May 23rd to 15th June

I would commence coding for the project as planned for developing the Framework and API parts. Phase 2 mid and end stages will be executed in this period.

June 11th to July 6th

At the the start of this period I will be finished implementing the API and framework and some prototypes. Executing the 3rd phase , I will be drawn into Bulk of the development work as planned .I will get feedback from the community for work and progress so far.

July 7th to July 13th

Mid term Evaluation period. After submission of mid evaluation work I’ll continue my work on the 3rd phase which will be on it’s middle stages and try to end the 3rd phase with the end of this period.

July 13th to August 10th

Fix bugs discovered .Reviews with mentors respective to the mid evaluation Results. Start phase 4 of the project plan . Finish most of the work in the 4th phase with the end of this period.

August 10th to August 17th

Executing final stages of the 4th phase ,writing tutorials and documentation regarding the policy builder tool and related aspects. Engaging in additional goals and any missed targets that has not been full filled yet and end of the 4th and final phase of work.

August 17th to August 24th

Submission for final evaluation after a full comprehensive review.

August 25th

Final Results for GSoc 2009

References

Apache Axis2

Apache Rampart

WSO2 Oxygen Tank

WSO2 Carbon

Computer Science and Engineering Department, University of Moratuwa, Sri Lanka