Re: [stp-dev] Idea on Integrating a New Policy tool for GSoc'09'

[Oisin Hurley <oisin.hurley@xxxxxxxxx>]

Hi Udayanga,
Thanks for the update. I've a couple of thoughts on the 'policy
builder'.  (warning long email!)

If we think about it in terms of inputs and outputs it makes the
integration options clearer.  The input to this  piece of software is
a collection of SOAP messages, the output is a collection of policy
choices.  The input could be taken from a 'live stream' of SOAP
messages (e.g. TCPmon - I think there is something like this in WTP
too), or indeed from the file system where there are a bundle of SOAP
messages in files, or from a database for testing, etc, etc. So
there's an extension point straight away --  message source :)

On the output, I'm thinking that a collection of sample policy
assertion files may be the first place to go (another extension point,
takes the in-memory policy assertion and 'does stuff' with it).
Integration with the policy assertion editor/policy instance editor in
STP is best achieved by going through the file system, I think.

I'd also think about structuring this to not predicate SOAP messages
specifically, but to allow another framework extension to do the
policy extraction, and have the SOAP consumer as an exemplar. Then
people who want to do fun things like embed WS-Policy model-compliant
pieces in proprietary RESTful interaction data representations in XML
or JSON could have a crack at it. It makes some space for evolution,
which is vital in this fashion industry.

>From the UI point of view, we could have a File > Import... > Policies
wizard, which would give you the choice of importing policies from any
of the sources that are registered in the policy message sources
extension registry. Then by default these could be put into the
current project, or there may be an advanced way that would allow them
to be redirected elsewhere. I'd definitely start with the current
project, or a directory within the project.

> (2)   Yes, i was thinking kind of same thing.It will be better if we can give out the capability for correctly displaying standardized WS specs such that policy editor will be aware of different specs such as WS-SEC,WS-RM,MTOM,Addreesing,etc when user wants..Making this configuration available will be very a very nice addition. Also i'm hoping to make STP policy editor configured for other minor adjustments such as making it compatible for other WS policy constructs (such as WSP:ExactlyOne) which i think currently does not support , and ability to edit/construct policy instances without manually creating a policy file ,etc..I'm also open to other suggestions on STP Policy Editor if you have some in mind..

On the standards support, if we could provide a way to do something
like New > Other... > Policies > WS-Security Policy then there would
be value in that. Or if we could spot the fact that a certain document
in the workspace is a WS-RM policy instance and decorate the icon
appropriately, then that would be all good. Go into the policy
component code and have a look at some of the XEF examples that David
Bosschaert has been constructing to  show people how to extend that
framework - he's done the Distributed OSGi remote-services definition
file and is working on something a little more complex to codify dOSGi
policy intents in an extensible way. You'll pick up plenty from that
code.

If there is a list of policy-related elements that that the policy
editor doesn't support, then those would be most welcome additions, I
would say.

What else...hmm...there are other pieces of the policy puzzle that I
think we can construct as part of a larger conversion for this policy
project. What I'm thinking of right now is a policy repository tool
(for storage and management) and something like an extensible
generation framework that could allow developers to produce
runtime-specific configuration code and elements from a set of policy
documents.

That's probably worth a larger conversation...

> I hope this has given you some idea on my proposal . However  I would kindly like to know the feasibility and the scope for the final analysis ,  in doing this as a Gsoc project for Eclipse STP project. Thank you again for your concern regarding this idea..

I think that what you have in mind does seem feasible, but one of the
GSoC constraints is time, if I remember correctly, so it's important
not to bite off too much. Maybe when you have read this terribly long
mail (thanks for getting this far)  you might have a chance to clarify
some of your ideas and we could get them written down in a more
task-like manner, and then you could consider the feasibility!

 best regards
   Oisin