Forks,

 I made an outline for policy framework support based on my
understanding on SCA policy framework spec and Tuscany project. If I
have any misunderstanding or mistake, please don't hesitate to point
out.

 I think we may need to implement three kinds of stuffs related to
policy framework.
1. Policy meta-data
 Add corresponding model classes for policy artifacts, including
PolicySet, IntentMap, and Qualifier etc.
 Add policy related attribute ( @requires, @policySet) support for
SCA artifact element which may be associated with concrete PolicySet.
We may create a subclass of ModelObject contains extensibility fields
for intent attributes. Various model objects (services, references,
binding etc.) could extend this class and have intents placed on them.
 Loader classes which are responsible for creating policy model
classes with Stax parsing. Loaders for policy artifacts embedded in
SCDL could be common loader extensions registered to loader
LoaderRegistry.
 Since intents are defined in a system scope intents.xml, it should
have a separate root loader like CompositeLoader and a loader
extension for individual intent. All intents model will be registered
to IntentRegistry. Which is a global intents repository and is also
responsible for providing intend related helper methods that may be
used by policy match engine, such as enumerating all qualified intents
of a unqualified intent, handling profile intent. An URL for
intents.xml may need to be added to TuscanyRuntime and we may also
have API deploying intent to IntentRegistry at runtime.
 Requires intent attribute could be added to SCA artifacts model by
parsing component type XML files, parsing service or reference entries
in a SCDL or introspected from annotations in the case of Java. The
first two would be handled by STaXElementLoaders. For annotations,
e.g. @requires("confidentiality/message") , we would add an
ImplementationProcessor which introspects the java class.

2. Policy matching engine
 PME is responsible for searching the concrete policy sets attached
to SCA artifacts. After loading phase is complete, the runtime will
have a whole picture of intents and concrete policy set. The builder
or connector can get the concrete policy of a specified artifact by
calling PME and passing the model class of the artifact as parameter.
PME will execute the algorithm described in policy framework spec and
raise the proper exception when the policy is invalid. When the
runtime artifacts are created by the builders, the builder would get
all of the matched policies from PME and iterate through policies
looking for recognized policies (i.e. to enforce the policy is
implemented by the builder itself). After this is complete, the wiring
infrastructure (WireService) would be responsible for cycling through
the policies and inserting interceptors into a RuntimeWire that it
gives to the Reference, Service or Component.

3. Policy enforcement
 As we said above, there may be two kinds of policy enforcement
points. One is on interceptor and the other relies on implementation
individual builders of binding or other artifact.

 For interceptor enforcement, some PE interceptor can be shared
between multiple artifact types, e.g. message level confidentiality,
including data encryption/decryption, xml signature/validation. We may
need to have a global registry which maintains mappings from qualified
intent name to PE interceptor, somewhat like what Tuscany currently
does with data binding. In the connecting phase, WireService can
automatically retrieve proper interceptors and add them to
corresponding inbound/outbound InvocationChain of the artifact. And
the concrete policy sets which get by calling PME can pass to the
interceptor as constructor or setter parameters.

We may also need a mechanism to plug in WS-policy engine to handle
WS-policy attachment embedded in policy set.


If I'm not sufficiently clear, I would be only too happy to elaborate.
Any comments are welcome. If we can have agreement on the basis of the
ideas, I'd like to begin to implement a prototype soon.

Regards,
Felix

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to