Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [stp-dev] Integration of Service Creation with Policy Editor planned for Ganymede release

Hi Andrei,

Andrei Shakirin wrote:
Hi David and Johnson,

I would like to discuss in detail the integration of Service Creation with Policy Editor planned for Ganymede release.
Some of topics were described and discussed in wiki: http://wiki.eclipse.org/Policy_Framework_in_STP.

Open questions:
1. How we will manage policy files in service project (JAX-WS) and how policies will mapped to service?
   a) as separate files with .policy extension
      In this case it is necessary to map policy files to wsdl (or individual operations/bindings in wsdl). Simple scenario could be just save policy files into service project and suppose that all of them will be automatically attached to service.
   b) as ws-policy attachments
      In this case policies will be saved directly in WSDL and WSDL elements will contain references to these policies. The largest problem in this case is that WTP WSDL editor don't support policy references at the moment (it just ignores them). Therefore we cannot activate Policy Editor from WSDL editor. I think we can make proposal to WTP project to extend WSDL editor on such way (display policy references and, by click, activate our policy editor registered on corresponded extension point). But I am afraid it is not realistic for Ganymede.
From my point of view this is also an open question. As far as the XEF editor goes, it is happy to take policies from anywhere but I agree that it would be good in the context of STP to define where policies are going to be attached. I think defaulting to 'service' may not always work because sometimes policies are attached to endpoints or operations and there could be more than one of those. Also a project could contain more than one service in which case you cannot automatically attach. For ws-policy attachments, an alternative to storing them directly in the WSDL could be to store them in a separate file which then points to somewhere in the WSDL. Something like this is supported by CXF, for an example see: https://svn.apache.org/repos/asf/incubator/cxf/trunk/systests/src/test/java/org/apache/cxf/systest/ws/policy/rm-external.xml
2. Will we support Policy Repository for Ganymede?
   a) File System based implementation;
   b) DB based implementation;
   c) no Policy Repository, just policy files saved in service project (JAX-WS).
I would vote for a) based on an interface. As mentioned on the Wiki page (http://wiki.eclipse.org/STP/GUILookAndFeelIntegrationProposal#XML_Schemas) we will use the ISchemaProvider interface. What we should do is provide an implementation that works with the file system but allow people to write alternatives (e.g. for use with a Database). The XEF Editor already provides one that works with the file system (the URLSchemaProvider: http://dev.eclipse.org/svnroot/stp/trunk/org.eclipse.stp.policy/org.eclipse.stp.xef/src/org/eclipse/stp/xef/URLSchemaProvider.java).
3. How we will manage XML Schemas for Policy Assertions?
   Issues are described in http://wiki.eclipse.org/STP/GUILookAndFeelIntegrationProposal#XML_Schemas
I think this is very closely related to point 2 above as the XML Schemas for policy assertions could be provided through the Policy Repository interface. The XEF editor allows multiple of these to be used together.

Regarding your 5 areas:
> 1) Eclipse project, where processing policy is located (or dedicated subfolder in this eclipse project). This is already implemented in http://dev.eclipse.org/svnroot/stp/trunk/org.eclipse.stp.policy/org.eclipse.stp.xef.test/src/org/eclipse/stp/ui/xef/editor/XMLXPathView.java#getSchemaProvider(). We might lift it out of the testing fragment and make this a ISchemaProvider class of its own.
> 2) File system.
The implementation of 1) currently looks at the all the *.xsd files in the project where the edited file is. However, feeding it different URLs that live outside of the Eclipse Project would work too...
> 3) Remotely stored schemas (http accessable).
This currently has limited support. The XEF Schema Registry currently tries to do this for schemas indirectly referenced by schemas in the ISchemaProvider that cannot be resolved through it.
> 4) Default embedded schemas.
I was thinking that if we do 5 that these schemas could simply by entered into the WTP Schema Catalog...
> 5) Standard Eclipse policy catalog
This currently has limited support. I actually have some code that does this for schemas that are referenced by schemas in the ISchemaProvider. Maybe it needs to be refactored to be turned into an ISchemaProvider of its own. I'll commit my initial version over the coming few days and we should be able to take it from there...
4. What kind of policy validation we will implement for Ganymede?
   a) simple schema validation;
   b) rule-based validation;
   c) validation framework based solution.
I suggest to keep the first iteration as simple as possible: manage policy files in service project only; provide schema based validation; store custom assertion XML schemas in service project; do not support Policy Repository. When we will have first integrated solution, it could be extended by additional features and functionality.
What is your opinion?
Yes - let's do the basic things first, like actually embedding the XEF editor in the WTP-based policy editor. I completely agree.

Cheers,

David

----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

Back to the top