Re: Fresh Perspective (edited)

[Stephen McConnell <mc...@osm.net>]

[resending after correcting a couple of gramatic mistakes that
would have read opposite to what I intended]

Leo Sutic wrote:

 >Stephen,
 >
 >I think I follow what you mean. So far you have described (as
 >Peter Donald pointed out) something very close to my proposal
 >regarding component specific namespaces.
 >
 >I'm fine with what it is you say, and the thought behind it.
 >
 >But consider this situation:
 >
 >Component A has a dependency D. Now, A can be any component,
 >and D describes a dependency. For example, A may be a mail
 >client and D says "I need a mail server to send mail". Whether
 >this is expressed as a need for a certain interface or in
 >another way is not relevant.
 >

     D --> A

 >
 >
 >Component B satisfies the dependency D. For example, B may
 >be a mail server, and thus has associated metadata that
 >specifies "I am a mail server and I can send mail". B has
 >no dependencies.
 >
 >So far so good - the assembler can trivially wire up A with
 >B, and everything is fine.
 >

     B --> D <-- A

     (where <-- == depoends & --> provides)

 >
 >Now: We add a second mail server C that
 >also satisfies D. This in itself is not a problem, as we
 >can assume that unless anything is specified, C and B
 >are interchangeable.
 >

     B --> D <-- A
     C --> D

 >We can also fairly easily add some
 >extra info to A saying that "when you ask for a mail server,
 >you will get B, and never C":
 >
 >  <component class="A">
 >    <!-- makes sure that B provides the mail-server for A -->
 >    <provide role="mail-server" via="B"/>
 >  </component>
 >
 >  <component class="B"/>  <!-- provides mail-server -->
 >
 >  <component class="C"/>  <!-- provides mail-server -->
 >
 >So the addition of C isn't really a problem. We can
 >"override" the assembler's heurstics and tell it to pick
 >a certain implementation. (This is basically the component-local
 >namespaces proposal.)
 >
 >Now for the problem: Instead of always giving B to A, we would
 >like the following:
 >
 >  A shall get B when sending to apache.org, and C otherwise
 >
 >That is, for A, a lookup("mail-server") should result in
 >B if it is about to send email to anyone at apache.org, and C
 >otherwise.
 >
 >The thing is that the assembler can neither wire A and B nor A
 >and C, as the choice between B and C isn't done until runtime.
 >
 >In A4 and ECM, this is done via a ComponentSelector. A would,
 >instead of asking for MailServer.ROLE, ask for MailServer.ROLE +
 >"Selector", and pass a hint (the email address in this case) to
 >the selector in order to get the mail server component.
 >
 >The problem is that A would have to be aware that there was a
 >runtime selection policy in place. It had to request a Selector.
 >For the case above, A would have to pass the email address in
 >anyway, but suppose the policy wasn't whether the mail went to
 >apache.org or not - suppose it was the time of day or whatever.
 >A would now not need to provide a hint.
 >
 >That is the problem, and now for a solution that I hope is in
 >line with what you are trying to achieve:
 >
 >Let S be a component that somehow selects between B and C.
 >

     B --> D <-- DS --> D
     C --> D

     (where DS is a selector for service type D, which exposed
     service policy that differentiates itself from generic D
     services)

 >What
 >can we say about S in terms of dependencies? Well, it is obviously
 >dependent on B and C, but we need to express that.
 >

At this point I disagree.  Your introducing a dependency to a
implementation.  Whatever the solution, the dependency of the selection
cannot/should-not be linked to implementation - however, the selector
could be a component that has a dependency on a type repository, and
through that dependency, can gain references to the set of relavant
candidate services types, and from this, maintain internal state as
the appropriate service.

    DR --> TR <-- DS --> D

End result is the same ..
just without hard wiring to a implementation.

 >So let's
 >add an attribute to B that, in effect, states "@apache.org ONLY!",
 >and we add a similar attribute to C that states "NOT TO @apache.org".
 >

At this point point we are introducing information that I would consider
to be application specific (which is ok) .. and as such, we need to shift
our mind-set to an application level componet that handles provision of
a component using runtime informantion.

 >Then we declare that S has two dependencies: It needs one mail
 >server that can send to apache.org, and one that can send to any
 >other place. We also declare that S provides a mail server. Just
 >like B and C, S says "I am a mail server, and I can send mail".
 >
 >No problem in verifying dependencies, right?
 >

You could "theoretically" create a type level service selector for
a main service and constract type level attribute that differentiated
a main server for apache.org.  I would not do that - but we'll come to
that in a tick.  Bottom line - it is possible to declare the
above as policy of an instance of service type D".

 >
 >Now, just as we added a line to make sure that A got B and not C,
 >let's hard-wire A to S instead. Since S will select the right
 >server among B and C, A should get the right one, right? No. :(
 >

Yes! :-)
Because the selector is not a selector ECM style.  It is a component
that declares that it provides service D - and through the attribution 
of meta-attributes, the selector is no long simply a supplier of D,
its a supplier of Dx, differentiatable from Dy or Dz.

 >
 >Since there is no way to tell the container that S does not in itself
 >provide the required service, but rather can help the container
 >select a supplier, we're out of luck.
 >

Incorrect.  Are you thinking in terms of "interface" or "service"?
Using a "service" defintion, your declaring a uniquely identifiable
profile of interface class, interface version, and attributes.  This 
identity can be matched to equivilent dependdency declarations.
Am I missing the point in the above argument?
(its very possible - its late).

 >A way around this is to let S be a facade to B and C. The first thing
 >S does is to look up B and C, and then forwards all method calls
 >as appropriate.
 >

Hang on - we have taken a jump.  There are two seperate and distinct
selection phases.  The information used in these two different cases
concerns:

    1. type information
    2. runtime information

Type information can be used to support very fine grain differntiation
of a service provider - but it not appropriate for runtime information.
In your example, your "could" attribute "org.apache" as a policy
feature (although I don't like the idea).  I prefer to think of this as 
establishing differentiation in terms of the quaility-fo-service, and
through this differentiation, faciliitate the runtime delivery of the
appropriate behaviour to a component during composition.

 >
 >
 >What I don't like about this is that S becomes "a mail server component
 >that selects among other mail servers depending on an email address"
 >instead of "a component that selects among other components depending
 >on an email address".
 >

My approach here would be:

   1. define a component that has a dependecy on the two differentiatable
      quality-of-service profiles

     Dx <-- Q --> D
     Dy <--

        (where Q is a component implementation, dependent on two
         different service profiles that happen to be the same
         interface)

   2. implement the D interface and handle the email address argument -
      the implementation can determine if the address contains
      "appache.org" and direct the operation to the appropriate service.

 >I'd like to be able to plug in selection policies in the container,
 >independent of what it is they are selecting between - mail servers,
 >signature taglines, whatever. Maybe I want to post-process every mail
 >sent to @apache.org in some special way. If S was independent of
 >the type of service it selected on, I could use S for that as well.
 >
 >But if we tie S to become a "MailServerManager", then it is only
 >that...
 >
 >Do you have any idea of how to solve this use case in your framework?
 >

Yes.

Define an extended ComponentLocator that takes runtime information as a
supplimentary argument - e.g. lookup( <openque-role>, <policy> ).  The
component manager will be supplied by a container based on policy
attributed to the component type. The policy would say ... for this
component, use component locator class org.apache.PolicyBasedLocator.
The implementation of PolicyBasedLocator would extend the framework
DefaultLocator, referring assembly to the default locator (which would
setup the different services you need), and the implementation of
lookup( role, policy ) would handle the policy management side. The
policy could be handled in a similar way - perhaps you could put in
place policy handlers based on query type - e.g. a policy handler
related to domain names.

Should this be part of the framework ?

I don't think so. In the above scenario, the client will have to
narrow to a derived component manager type. The only benefit of
having the manager in the framework is if the lookup( role, policy )
is supplied as part of ComponentLocator.  But this introduces
problems (at least problems in my head because I only have room for
three or four simultanouse threads).  The problem is that of fear,
uncertanty and doubt. Fear that the introduction of the method at the
framework level will lead to circumnavigation of formal component
declarations, uncertainty due to lack of any formal structure notion
of what policy is (as compared to meta which we have been working
with for quite some time), and doubt about the potential for a
clean default immplementation that makes sense in the short term.
If I weight this against the overhead of narrowing a component
locator to a know type that is gaurantee to be supplied, I think
the "out-of-framework" approach is ok.

Keep in mind that this solution is implying that we specify a
component locator policy as part of the meta of a component type, that
will be supported by all generic containers (so this is seriouse).

To summarise this:

    a) a component type would be able to declare a policy that
       would allow a container to resolve a non-standard component
       locator (e.g. classname or locator factory)

    b) generic containers, as part of lifecycle handling of
       components would be required to validate this policy, and on
       composition/servicing of a component, instantiate such a
       service locator and populate it with services in the normal
       way.

    c) a non-standard component manager as a minimum should be
       treated as a fully fleged component in that it may declare
       its own dependecies - and as such, the type level validation
       of a component declaring a customer locator, would require
       validation of the customer locators dependencies as part of
       the overall component dependencies.


 >
 >For the general case, what I want is this:
 >
 >  + A should not have to care that there is a selection policy
 >    in place.
 >
 >

Agree - selection policy should/must/can be transparent to the consumer.

 >
 >  + Selection policies should be able to be linked (first apply rule A,
 >    the rule B, and so on).
 >

Should be possible providing selction mechanisms are declared as
components with dependecies.  I.e. selector X has dependency on selector
Y has dependency on service Z.  I.e. just treat selectors as components
with formal dependecies (but keep in mind that this could get 
complicated when we look at potential recursive dependecies).

 >  + If A supplies a hint for the selection policy, it should work
 >    even if there is no policy in place.
 >

If you come up with a selector (type or instance) and that selector
knows what a hint means, then presumably that selector will do what you
want.  From the point of view of generic type management, I don't know
what hint means - I don't want to know what hint means.

Conclusion - its an orthogonal issue as as such my position is agnostic.
(I've always wanted an opportunity to say that - thanks Leo)
:-)

 >  + Policies should be independent of the type of service they apply
 >    to. For example, a TimeOfDayPolicy should be able to select
 >    among mail servers or SAX transformers equally well.
 >

I think it too early to say.  I have use-cases for selection policy
linked to service type variants and I have implementations (prototype)
that have validated that the approach works.  I think there are a lot of
possible approaches here and I'm confident that n months from now we
will all have a better feeling for what is needed - and I think we do
have the time for that.

Cheers, Steve.

 >
 >/LS
 >
 >
 >--
 >To unsubscribe, e-mail: 
<ma...@jakarta.apache.org>
 >For additional commands, e-mail: 
<ma...@jakarta.apache.org>
 >
 >
 >

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Fresh Perspective (edited)

[Leo Simons <le...@apache.org>]

> > Define an extended ComponentLocator that takes runtime 
> > information as a
> > supplimentary argument - e.g. lookup( <openque-role>, <policy> ).  The
> > component manager will be supplied by a container based on policy
> > attributed to the component type. The policy would say ... for this
> > component, use component locator class org.apache.PolicyBasedLocator.
> > The implementation of PolicyBasedLocator would extend the framework
> > DefaultLocator, referring assembly to the default locator (which would
> > setup the different services you need), and the implementation of
> > lookup( role, policy ) would handle the policy management side. The
> > policy could be handled in a similar way - perhaps you could put in
> > place policy handlers based on query type - e.g. a policy handler
> > related to domain names.
> > 
> > Should this be part of the framework ?
> 
> Yes yes yes yes yes yes!
> 
> If lookup (role, data-for-possible-policy) can be implemented
> as lookup(role) - that is, the policy can be ignored, then
> *all* ComponentLocators can implement this. No downcast needed.

and the "if" is the important part. Can/should policy be ignored,
always?

> You worry about validation of policy constraints, but I do not see
> why this is a problem. The policy can only select among existing
> components, so all you have to do is declare those components as
> dependencies of the PolicyLocator.
> 
> > Keep in mind that this solution is implying that we specify a
> > component locator policy as part of the meta of a component type, that
> > will be supported by all generic containers (so this is seriouse).
> 
> No - the locator policy is not a property of the component itself.
> 
> What is a property is the *type* of the policy argument to 
> lookup(role,policy), but if the type is wrong, then the policy should
> be ignored. Remember, lookup(role,policy) can be implemented as
> lookup(role) (that is, ignore policy). This, in fact, is what
> you *have* to do if no policy is supplied.

IOW, Steve thinks of a strong policy hint definition in metadata in the
case of a PolicyLocator, whereas Leo Sutic thinks of a weak policy hint
definition (ie only java object type).

If strong policy hint definitions are a better idea for these complex
situations, then it is probably better to hava a separate interface for
a PolicyLocator and a downcast.

We don't know yet if this is the case (lack of experience). Anyone?

- Leo Simons



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Fresh Perspective (edited)

[Leo Sutic <le...@inspireinfrastructure.com>]

> From: Stephen McConnell [mailto:mcconnell@osm.net] 

> Yes! :-)
> Because the selector is not a selector ECM style.  It is a component
> that declares that it provides service D - and through the attribution

> of meta-attributes, the selector is no long simply a supplier of D,
> its a supplier of Dx, differentiatable from Dy or Dz.

> Am I missing the point in the above argument?

No, what you describe is *exactly* what I say in the lines just below:

>  >A way around this is to let S be a facade to B and C. The first
thing
>  >S does is to look up B and C, and then forwards all method calls
>  >as appropriate.

You do seem to contradict yourself below: First you want a
service-specific
selector, and then you allow for pluggable policy locators that could
select among any service.

> Define an extended ComponentLocator that takes runtime 
> information as a
> supplimentary argument - e.g. lookup( <openque-role>, <policy> ).  The
> component manager will be supplied by a container based on policy
> attributed to the component type. The policy would say ... for this
> component, use component locator class org.apache.PolicyBasedLocator.
> The implementation of PolicyBasedLocator would extend the framework
> DefaultLocator, referring assembly to the default locator (which would
> setup the different services you need), and the implementation of
> lookup( role, policy ) would handle the policy management side. The
> policy could be handled in a similar way - perhaps you could put in
> place policy handlers based on query type - e.g. a policy handler
> related to domain names.
> 
> Should this be part of the framework ?

Yes yes yes yes yes yes!

If lookup (role, data-for-possible-policy) can be implemented
as lookup(role) - that is, the policy can be ignored, then
*all* ComponentLocators can implement this. No downcast needed.

You worry about validation of policy constraints, but I do not see
why this is a problem. The policy can only select among existing
components, so all you have to do is declare those components as
dependencies of the PolicyLocator.

> Keep in mind that this solution is implying that we specify a
> component locator policy as part of the meta of a component type, that
> will be supported by all generic containers (so this is seriouse).

No - the locator policy is not a property of the component itself.

What is a property is the *type* of the policy argument to 
lookup(role,policy), but if the type is wrong, then the policy should
be ignored. Remember, lookup(role,policy) can be implemented as
lookup(role) (that is, ignore policy). This, in fact, is what
you *have* to do if no policy is supplied.

In the email example, we know that the policy parameter to
lookup will be an email address (keeping it simple). 

(Inside A):
    ...
    address = "someone@apache.org";
    server = lookup ("mail-server", address);
    ...

*That* is a property of the component type.

But how we interpret this type is *not* a property of the
component type. You can, for example, have a policy based
on domain, full address, TLD. The important thing is that the
input to the policy is an email address.

And that you can verify.

/LS


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>