Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Talk:Swordfish Documentation: Policy Resolver"

 
(3 intermediate revisions by the same user not shown)
Line 32: Line 32:
  
 
----
 
----
 +
 +
Comments jkindler
 +
 +
Integration Tests shall cover all possible parameter values of the policies.
 +
 +
Comment: I feel that it should be possible to test that within the unit/functional tests that are executed during the build. The integration tests should be confined to test one positive and one negative scenario resolving within Equinox.

Latest revision as of 07:39, 6 March 2009

Coments from owolf:

The initial service Lookup only provides the function of a lookup based on Service Data contained in the WSDL.

Comment: Policies might also be part of the WSDL (Policy Attachments)

A policy based service lookup enables service provisioning based on quality of service criteria.

Comment: Service Resolver is not related to provisioning at all. I'd rather call it "service endpoint resolution".


• The agreed policy shall be included into the message header for validation purposes.

Comment: This is out of scope for the policy matching service resolver.

Integration Tests shall cover all possible parameter values of the policies. Documentation on the matching process and available policy assertions shall be provided in the Swordfish Documentation Wiki.

Comment: Concrete policies are out of scope for the generic resolver component.

A limited number of assertions will only be supported in the initial version.

Comment: Even the initial version should be flexible enough to allow for any number of assertions.

How much reuse of the SOPERA Policy resolver or a corresponding component in Policy Editor of the Eclipse STP would be possible?

Comment: Please don't talk about SOPERA here,

Which assertions do we want to support in the first version?

Comment: The first version of the framework component should be provided long with an exemplary implementation of a policy assertion and the corresponding matching rules if they differ from standard ws-policy matching.


Comments jkindler

Integration Tests shall cover all possible parameter values of the policies.

Comment: I feel that it should be possible to test that within the unit/functional tests that are executed during the build. The integration tests should be confined to test one positive and one negative scenario resolving within Equinox.

Back to the top