You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/09/17 20:22:20 UTC
Resolving Services
In order to satisfy my RT about service attributes used to provide
automated assembly logic, we need to make some API changes to Meta.
What we are comparing is a Service Reference (i.e. requires service) to
a component (i.e. Type) implementation. The Service descriptor with all
the attributes provides the rules to interpret the attributes. To that
end, we need the Service to generate a Comparator.
public class Service extends Descriptor
{
// .... skip everything else
public java.lang.Comparator getComparator()
{
// logic to build the comparator using predicates, etc.
}
}
That way we can create a nice little utility that would find the best
match:
public final class MetaUtil
{
private MetaUtil() {}
public static final Object findBestMatch( List components,
Service service )
{
// Order so that the best match comes first
Collections.order( components, service.getComparator() );
return components.get(0);
}
}
Granted, it can still be overridden by an assembly file, but
this way we can provide the default logic to find the best way to
generate the assembly file to begin with.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolving Services
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>> Berin Loritsch wrote:
>>
>>>
>>> I see. This is like the EJB thing. The implementation of the
>>> component
>>> does not directly implement the work interface :/. This is so that the
>>> client code can have the interfaces published in a separate JAR, and
>>> the
>>> implementation isn't required to have that JAR in its classpath. In
>>> that case, the <type|component> definition would have a
>>> ServiceReference
>>> which would point to an externally declared ServiceDescriptor.
>>
>>
>> Yes and no.
>> The use case is a component that is generating object refernces.
>> From the client perspective the object reference is the service,
>> however, the service implementation may be in a completely different
>> container/host/machine. In this ecample you need the Type to contain
>> information about the characteristics of the service it will provide
>> but the definition of the service should be seperate (because it
>> could be in another jar in another JVM).
>
>
> Well, it is essentially the EJB like thing (they are on separate
> machines/JVMs/etc.). The descriptor for the service is in the EJB
> Container which publishes them via JNDI.
>
> I am thinking of a way for a local container to determine whether the
> remoted service implementation is the proper one for the client. In
> that case, we would need the containers to be able to communicate enough
> to propogate the necessary descriptors accross the wire.
I have a working solution to this using the IIOP protocol. Basically I
create a valuetype that is a service description variant. This
valuetype emerges on the client (another container) and can be
internalized as a candidate service provider - something like a Type
proxy. But I should mention that its very much work-in-progress. The
objective is that a service established in container "A should be
exportable to container B as candidate provider. So far I've manged to
do this without forcing component activation until such time that a real
end-client actually uses the service. On invocation of an operation on
the servive instance, the activation process is triggered, possibly
spanning multiple compoents across multiple containers (all nice and
transparent to the client).
>
>
>> In writing the above sentence I noticed that I was avaoiding the use
>> of Service and ServiceDescriptor and I think the reason is that the
>> terms are not incorrect.
>>
>> The current ServiceDescriptor should be renamed to ServiceReference
>> - it is part of a type
>>
>> The current DependencyDescriptor should be renamed to
>> DependencyReference
>> - it is part of a type
>>
>> The current Service class should be renamed to ServiceDescriptor
>> - it is indepedent of a type
>>
>> With the above changes things would start to make a little more sense.
>>
>> What do you think?
>
>
> I agree. In my mind, that is what I was saying, but I was confusing
> Service with ServiceDescriptor. So yes, we should name the classes
> that reference externally defined things as References. We should
> also name classes that describe unique concepts as Descriptors. It
> is a natural way to think. It will help emmensely both in our
> conversations and for new users of the API.
>
I'll put this in place ASAP.
>
>>> In summary, keep the service *reference*, but declare the service
>>> *descriptor* separately.
>>
>>
>> I'm under the impression that this is what is in place (pending
>> documetation updating). I also think this will become a lot clearer
>> with the renaming I've suggested above.
>
>
> Ok. Let me know when the docs are updated :). I will still press
> toward my MetaData enabled Fortress implementation, but right now
> I am focusing on other portions (which are going in the Container
> package, like porting the wrapper classes to deal with legacy
> systems, and improving classloader facilities).
>
> I am trying to keep Container free of *any* dependencies.
>
>
>>>> The implementation isn't in place yet but I was planning on
>>>> assigning the Servive instance when constructing the
>>>> DepedencyDescriptor instance. As such, the DepedencyDescriiptor
>>>> would already have a direct reference to the context infurred by
>>>> the Service defintion.
>>>
>>>
>>> I am not following you here. Are you saying that the
>>> DependencyDescriptor will have a direct reference to the
>>> ServiceDescriptor? If so, that's fine. As to when things are parsed/
>>> etc. that is up to the Meta library.
>>
>>
>> Lets' clean up terminology and come back to this afterwards.
>> I'll also privde feedback on the servlet question under a seperate
>> email.
>
>
> Sounds good.
>
>
Cheers, Steve.
--
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>
Re: Resolving Services
Posted by Berin Loritsch <bl...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>> In writing the above sentence I noticed that I was avaoiding the use
>> of Service and ServiceDescriptor and I think the reason is that the
>> terms are not incorrect.
>>
>> The current ServiceDescriptor should be renamed to ServiceReference
>> - it is part of a type
>>
>> The current DependencyDescriptor should be renamed to DependencyReference
>> - it is part of a type
>>
>> The current Service class should be renamed to ServiceDescriptor
>> - it is indepedent of a type
>>
>> With the above changes things would start to make a little more sense.
>>
>> What do you think?
>
>
> I agree. In my mind, that is what I was saying, but I was confusing
> Service with ServiceDescriptor. So yes, we should name the classes
> that reference externally defined things as References. We should
> also name classes that describe unique concepts as Descriptors. It
> is a natural way to think. It will help emmensely both in our
> conversations and for new users of the API.
I just thought of something. The DependencyDescriptor (in its current
form) represents information on how to find the Type that best matches
this dependency. For that reason, I think DependencyDescriptor is an
apt name.
However, I do think we need a TypeReference which is used for the
assembly mechanism to match the TypeDescriptor to the requested
ServiceReference.
Did I lose you?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolving Services
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
> Berin Loritsch wrote:
>>
>> I see. This is like the EJB thing. The implementation of the component
>> does not directly implement the work interface :/. This is so that the
>> client code can have the interfaces published in a separate JAR, and the
>> implementation isn't required to have that JAR in its classpath. In
>> that case, the <type|component> definition would have a ServiceReference
>> which would point to an externally declared ServiceDescriptor.
>
> Yes and no.
> The use case is a component that is generating object refernces. From
> the client perspective the object reference is the service, however, the
> service implementation may be in a completely different
> container/host/machine. In this ecample you need the Type to contain
> information about the characteristics of the service it will provide but
> the definition of the service should be seperate (because it could be in
> another jar in another JVM).
Well, it is essentially the EJB like thing (they are on separate
machines/JVMs/etc.). The descriptor for the service is in the EJB
Container which publishes them via JNDI.
I am thinking of a way for a local container to determine whether the
remoted service implementation is the proper one for the client. In
that case, we would need the containers to be able to communicate enough
to propogate the necessary descriptors accross the wire.
> In writing the above sentence I noticed that I was avaoiding the use of
> Service and ServiceDescriptor and I think the reason is that the terms
> are not incorrect.
>
> The current ServiceDescriptor should be renamed to ServiceReference
> - it is part of a type
>
> The current DependencyDescriptor should be renamed to DependencyReference
> - it is part of a type
>
> The current Service class should be renamed to ServiceDescriptor
> - it is indepedent of a type
>
> With the above changes things would start to make a little more sense.
>
> What do you think?
I agree. In my mind, that is what I was saying, but I was confusing
Service with ServiceDescriptor. So yes, we should name the classes
that reference externally defined things as References. We should
also name classes that describe unique concepts as Descriptors. It
is a natural way to think. It will help emmensely both in our
conversations and for new users of the API.
>> In summary, keep the service *reference*, but declare the service
>> *descriptor* separately.
>
> I'm under the impression that this is what is in place (pending
> documetation updating). I also think this will become a lot clearer
> with the renaming I've suggested above.
Ok. Let me know when the docs are updated :). I will still press
toward my MetaData enabled Fortress implementation, but right now
I am focusing on other portions (which are going in the Container
package, like porting the wrapper classes to deal with legacy
systems, and improving classloader facilities).
I am trying to keep Container free of *any* dependencies.
>>> The implementation isn't in place yet but I was planning on assigning
>>> the Servive instance when constructing the DepedencyDescriptor
>>> instance. As such, the DepedencyDescriiptor would already have a
>>> direct reference to the context infurred by the Service defintion.
>>
>> I am not following you here. Are you saying that the
>> DependencyDescriptor will have a direct reference to the
>> ServiceDescriptor? If so, that's fine. As to when things are parsed/
>> etc. that is up to the Meta library.
>
> Lets' clean up terminology and come back to this afterwards.
> I'll also privde feedback on the servlet question under a seperate email.
Sounds good.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolving Services
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>
>> Berin Loritsch wrote:
>>
>>> It is _Service_. Service defines the rules for which attributes it
>>> will
>>> allow for the decision process, and how it interprets them. We use the
>>> Comparitor from the Service to compare a DependencyDescriptor against
>>> the list of Components.
>>
>>
>>
>>
>> I agree that the Service should be defining rules - but it is still
>> the DepedencyDescriptor (which references the Service) that defines
>> the criteria.
>
>
> Right.
>
>>>> * A Container is handling selection of a Type from possibly
>>>> multiple alternatives based on an unresolved dependency.
>>>
>>>
>>> Right. And the Comparitor that the Service creates assists in the
>>> decision process. We *could* have it built from a utility class
>>> that accepts the Service and the DependencyDescriptor. The two
>>> put together will allow us to have one Comparator that does what we
>>> want.
>>
>>
>> Ok - in my head I'm assuming that a DepedencyDescriptor will already
>> have a reference to the Service instance it is qualifying.
>
>
> I haven't made that assumption. If that's the case than yes, the
> DependencyDescriptor creates the Comparitor
>
>
>>>> * A Type is consider a candidate by virtue of the fact that
>>>> it declares that it provides the service through exposure
>>>> of a ServiceDescriptor
>>>
>>>
>>> Right, and I am saying that the ServiceDescriptor should be pulled
>>> *out* of the generic Type and made its own entity. If a component
>>> implements a Service, we will know because it implements the interface.
>>
>>
>> Wrong. I have several components that declare and implement
>> particular services, however, this does not imply that the component
>> Type physically implemenmts those interfaces. Merlin assumes that the
>> default "protocol" for service access is based on a types
>> implementation of an interface, however, Merlin also recognizes
>> alternative protocols. For example, Merlin can handle company X that
>> provdies service Y via protocol Z. Giving the ability to a componet
>> to declare that it is the source of service establishment is not the
>> same as saying that it is the source of service access (although the
>> majority of cases this is true).
>
>
> I see. This is like the EJB thing. The implementation of the component
> does not directly implement the work interface :/. This is so that the
> client code can have the interfaces published in a separate JAR, and the
> implementation isn't required to have that JAR in its classpath. In
> that case, the <type|component> definition would have a ServiceReference
> which would point to an externally declared ServiceDescriptor.
Yes and no.
The use case is a component that is generating object refernces. From
the client perspective the object reference is the service, however, the
service implementation may be in a completely different
container/host/machine. In this ecample you need the Type to contain
information about the characteristics of the service it will provide but
the definition of the service should be seperate (because it could be in
another jar in another JVM).
In writing the above sentence I noticed that I was avaoiding the use of
Service and ServiceDescriptor and I think the reason is that the terms
are not incorrect.
The current ServiceDescriptor should be renamed to ServiceReference
- it is part of a type
The current DependencyDescriptor should be renamed to DependencyReference
- it is part of a type
The current Service class should be renamed to ServiceDescriptor
- it is indepedent of a type
With the above changes things would start to make a little more sense.
What do you think?
>
>
> What I am saying is that everything about the service should not *have*
> to be declared in the <type> definition.
We both agree on this.
> Moving the service declaration
> into a separate descriptor file will allow multiple components to
> "implement" the service. Whether there is an actual Java interface
> is irrelevant.
Yep.
>
> In summary, keep the service *reference*, but declare the service
> *descriptor* separately.
I'm under the impression that this is what is in place (pending
documetation updating). I also think this will become a lot clearer
with the renaming I've suggested above.
>
>>>> * Ranking of candidate types is achieved by the application of
>>>> "constraints" declared under the DependencyDescriptor relative to
>>>> the attribute values declared under the ServiceDescriptor exposed
>>>> by the candidate Type.
>>>
>>>
>>> The ServiceDescriptor (which should be declared *once* for all
>>> implementing types) provides the basic rules of interpretation. The
>>> DependencyDescriptor provides the values we are concerned with. So
>>> we probably need our Comparator generated from both the Service and
>>> Dependency Descriptors.
>>
>>
>> The implementation isn't in place yet but I was planning on assigning
>> the Servive instance when constructing the DepedencyDescriptor
>> instance. As such, the DepedencyDescriiptor would already have a
>> direct reference to the context infurred by the Service defintion.
>
>
> I am not following you here. Are you saying that the
> DependencyDescriptor will have a direct reference to the
> ServiceDescriptor? If so, that's fine. As to when things are parsed/
> etc. that is up to the Meta library.
Lets' clean up terminology and come back to this afterwards.
I'll also privde feedback on the servlet question under a seperate email.
Cheers, Steve.
--
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>
Re: Resolving Services
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> It is _Service_. Service defines the rules for which attributes it will
>> allow for the decision process, and how it interprets them. We use the
>> Comparitor from the Service to compare a DependencyDescriptor against
>> the list of Components.
>
>
>
> I agree that the Service should be defining rules - but it is still the
> DepedencyDescriptor (which references the Service) that defines the
> criteria.
Right.
>>> * A Container is handling selection of a Type from possibly
>>> multiple alternatives based on an unresolved dependency.
>>
>> Right. And the Comparitor that the Service creates assists in the
>> decision process. We *could* have it built from a utility class
>> that accepts the Service and the DependencyDescriptor. The two
>> put together will allow us to have one Comparator that does what we
>> want.
>
> Ok - in my head I'm assuming that a DepedencyDescriptor will already
> have a reference to the Service instance it is qualifying.
I haven't made that assumption. If that's the case than yes, the
DependencyDescriptor creates the Comparitor
>>> * A Type is consider a candidate by virtue of the fact that
>>> it declares that it provides the service through exposure
>>> of a ServiceDescriptor
>>
>> Right, and I am saying that the ServiceDescriptor should be pulled
>> *out* of the generic Type and made its own entity. If a component
>> implements a Service, we will know because it implements the interface.
>
> Wrong. I have several components that declare and implement particular
> services, however, this does not imply that the component Type
> physically implemenmts those interfaces. Merlin assumes that the default
> "protocol" for service access is based on a types implementation of an
> interface, however, Merlin also recognizes alternative protocols. For
> example, Merlin can handle company X that provdies service Y via
> protocol Z. Giving the ability to a componet to declare that it is the
> source of service establishment is not the same as saying that it is the
> source of service access (although the majority of cases this is true).
I see. This is like the EJB thing. The implementation of the component
does not directly implement the work interface :/. This is so that the
client code can have the interfaces published in a separate JAR, and the
implementation isn't required to have that JAR in its classpath. In
that case, the <type|component> definition would have a ServiceReference
which would point to an externally declared ServiceDescriptor.
What I am saying is that everything about the service should not *have*
to be declared in the <type> definition. Moving the service declaration
into a separate descriptor file will allow multiple components to
"implement" the service. Whether there is an actual Java interface
is irrelevant.
In summary, keep the service *reference*, but declare the service
*descriptor* separately.
>>> * Ranking of candidate types is achieved by the application of
>>> "constraints" declared under the DependencyDescriptor relative to
>>> the attribute values declared under the ServiceDescriptor exposed
>>> by the candidate Type.
>>
>> The ServiceDescriptor (which should be declared *once* for all
>> implementing types) provides the basic rules of interpretation. The
>> DependencyDescriptor provides the values we are concerned with. So
>> we probably need our Comparator generated from both the Service and
>> Dependency Descriptors.
>
> The implementation isn't in place yet but I was planning on assigning
> the Servive instance when constructing the DepedencyDescriptor instance.
> As such, the DepedencyDescriiptor would already have a direct reference
> to the context infurred by the Service defintion.
I am not following you here. Are you saying that the
DependencyDescriptor will have a direct reference to the
ServiceDescriptor? If so, that's fine. As to when things are parsed/
etc. that is up to the Meta library.
>> Thank you for the clarification.
>>
>> BTW, one thing that bugs me about the whole "Type" thing is that while
>> the meta package is implemented to work with generic Types does not mean
>> that the programmer does. I don't like everything being a generic
>> "Type" because then I can't easily separate and group processing on
>> whole classes of Types like Service, Component, Stage, and Extension.
>> I have to parse all of them as a "Type" and then manually separate them
>> out later. I find that annoying.
>
> Let's dig into this a little more.
>
> Firstly - I'm assuming that Stage can be folded into a
> DependencyDescriptor + attribuite and that Extension can be folded into
> a ServiceDescriptor + attribute. By folding Stage and Extension we end
> up with two distinct and functionally different meta level classes -
> Type and Service. A Type declares its relationship to a Service via (a)
> a DependencyDescriptor and/or a (b) ServiceDescriptor.
:) Yep. That would be a nice way of folding the abilities.
> Type != Service.
That is what I was getting at. The docs online suggest that.
> Secondly - the term "componet" - I belive (at this level) the term is
> simply too generic.
> Consider the following:
>
> component Type (class, attributes, dependecies, service delcarations,
> etc.)
> component Profile (Type populated with data concerning instantiation
> criteria and policy)
> component instance (Profile instantiated relative a lifestyle policy)
>
> A Type may by used by many Profiles
> A Profile may be used by many Instances.
All Meta should do is declare the description of the component
implementation (Is this Type or Profile? not sure), and let the
container take care of the instance management. MetaInfo is info
about something. We should limit its scope to that purpose.
> When we use the term "component" I basically thinking "an instance of a
> profile".
I am thinking "an IMPLEMENTATION of a service".
>> PS, can you fix the ServiceDescriptor? On your site docs you have
>> something like this:
>>
>> <type>
>> <services>
>> <service>
>> <!-- All the stuff about the service -->
>> </service>
>> </services>
>> </type>
>
> I'll check the docs - I know there is stuff that still reflects the
> assumption that the service is defined within the type.
So it should be
<service>
<!-- All the stuff about the service -->
</service>
and the rest of the stuff is just wrong, right?
>> If this type is supposed to describe a Service, which maps to an
>> interface, then there is only *one* service possible. Also, I think
>> the "type" element is unnecessary--it should be implied.
>
> Not totally following - the <type><services><service><reference> points
> to a service descriptor. It is statement that a component derived from
> the type will establish a service referrd to by the reference.
A Service is a description of the interface that a client uses to
interact with a component. That description can also define the
selection criteria rules. As such, each ServiceDescriptor (not
reference) should be its own entity.
I am referring to <service><role> *not* <service><reference>.
>> I would be
>> happier for a service XML descriptor to be declared like this:
>>
>> <service>
>> <!-- All the stuff about the service -->
>> </service>
>
> Ummm, it is!
>
> A <classname>.xservice contains:
>
> <service>
> <version1.2.3</version>
> <attributes>
> <attribute key="a-key" value="a-value"/>
> </attributes>
> </service>
>
> But the xdocs are not in place yet :-(
Aha! I was going by the XDocs which suggested that the proper
definition was:
<type>
<services>
<service>
<version>1.2.3</version>
<attributes>
<attribute key="a-key" value="a-value"/>
</attributes>
</service>
</services>
</type>
Which is clearly the wrong model.
> Been too busy with an embedded version of Tomcat running inside Merlin
> as a component - I'm also playing with component based servlets (i.e.
> Servlet's implemeting Avalon lifecycle interfaces). Some interesting
> aspects arise with respect to the overall containment management
> principals which I'm looking into now. Basically in the Tomcat scanrio
> you have a container that is instantiating the component and I'm working
> on leveraging Merlin assembly to take the instantiated component
> (Servlet) and applying lifecycle processing to it before it enters into
> the classic Servlet lifecycle.
Honestly, I find it improper to hijack a component that is controlled by
another container (i.e. Tomcat), and enforce your own lifecycle on it.
You will find many surprises that you can do without.
There are two approaches to solving this problem.
1) Sidestep it. Have Merlin operating along side of the servlet. Use a
servlet for the sole purpose of instantiating Merlin and binding it
to a JNDI context. It is loaded on startup with a higher priority
than all the other servlets. Any time you need to use Merlin, pull
it from JNDI.
2) Embed it. Have the servlet manage the root container (that also has
the interface that the servlet uses to process requests). When the
Servlet is recycled, so is Merlin.
Cocoon uses the Embedded approach, although it does allow for the
sidestepped approach to provide a parent container to Cocoon.
Both of these work quite well, and it is the quickest way of getting
something working without too much incident. If your servlet needs
to communicate with an external server, or parent server, then you
should have a "proxy" component that forwards the requests to the
external server. That way we can have something like JAMES or a
Business Process Managment Server on another machine/process, and
be able to use it within the Servlet without trying to destroy the
Servlet spec.
By hijacking the Servlet directly, you are also locking yourself into
one Servlet Container vendor. While Tomcat is an excellent piece of
software, Caucho Resin will toast it in performance. I would encourage
you not to hijack the servlet spec, and either sidestep the problem
or embed merlin.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolving Services
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>
>> Berin Loritsch wrote:
>>
>>> In order to satisfy my RT about service attributes used to provide
>>> automated assembly logic, we need to make some API changes to Meta.
>>> What we are comparing is a Service Reference (i.e. requires service)
>>> to a component (i.e. Type) implementation. The Service descriptor
>>> with all the attributes provides the rules to interpret the
>>> attributes. To that end, we need the Service to generate a Comparator.
>>
>>
>>
>>
>> Is it Service or DepedencyDescriptor that generates the comparitor?
>
>
>
> It is _Service_. Service defines the rules for which attributes it will
> allow for the decision process, and how it interprets them. We use the
> Comparitor from the Service to compare a DependencyDescriptor against
> the list of Components.
I agree that the Service should be defining rules - but it is still the
DepedencyDescriptor (which references the Service) that defines the
criteria.
>
>
>> * A Container is handling selection of a Type from possibly
>> multiple alternatives based on an unresolved dependency.
>
>
> Right. And the Comparitor that the Service creates assists in the
> decision process. We *could* have it built from a utility class
> that accepts the Service and the DependencyDescriptor. The two
> put together will allow us to have one Comparator that does what we
> want.
Ok - in my head I'm assuming that a DepedencyDescriptor will already
have a reference to the Service instance it is qualifying.
>
>
>> * The dependency is declared through a DependencyDescriptor
>> that uses a ReferenceDescriptor to point to a Service.
>
>
> Right.
>
>> * A Type is consider a candidate by virtue of the fact that
>> it declares that it provides the service through exposure
>> of a ServiceDescriptor
>
>
> Right, and I am saying that the ServiceDescriptor should be pulled
> *out* of the generic Type and made its own entity. If a component
> implements a Service, we will know because it implements the interface.
Wrong. I have several components that declare and implement particular
services, however, this does not imply that the component Type
physically implemenmts those interfaces. Merlin assumes that the default
"protocol" for service access is based on a types implementation of an
interface, however, Merlin also recognizes alternative protocols. For
example, Merlin can handle company X that provdies service Y via
protocol Z. Giving the ability to a componet to declare that it is the
source of service establishment is not the same as saying that it is the
source of service access (although the majority of cases this is true).
>
>
>> * Ranking of candidate types is achieved by the application of
>> "constraints" declared under the DependencyDescriptor relative to
>> the attribute values declared under the ServiceDescriptor exposed
>> by the candidate Type.
>
>
> The ServiceDescriptor (which should be declared *once* for all
> implementing types) provides the basic rules of interpretation. The
> DependencyDescriptor provides the values we are concerned with. So
> we probably need our Comparator generated from both the Service and
> Dependency Descriptors.
The implementation isn't in place yet but I was planning on assigning
the Servive instance when constructing the DepedencyDescriptor instance.
As such, the DepedencyDescriiptor would already have a direct reference
to the context infurred by the Service defintion.
>
>> So considering we has two service descriptors SD1 and SD2 and we want
>> to compare these for order. The Comparitor implemetation needs the
>> DepedencyDescriptor as the source of criteria for ranking. The
>> compare operation is invoked such that:
>>
>> int j = comparitor.compare( SD1, SD2 );
>>
>> In which case it seems to me that the Comparitor factory is the
>> DependencyDescriptor class - not the Service class. Alternatively,
>> you could also look at the DepedecyDescriptor as a comparator. Anyway
>> - yes - this would be a usefull addition to the meta package.
>
>
> Actually it would be a separate utility class. It needs the *rules*
> from the ServiceDescriptor, and the *values* from the
> DependencyDescriptor to arrive at the subset of components we can
> consider.
>
> Thank you for the clarification.
>
> BTW, one thing that bugs me about the whole "Type" thing is that while
> the meta package is implemented to work with generic Types does not mean
> that the programmer does. I don't like everything being a generic
> "Type" because then I can't easily separate and group processing on
> whole classes of Types like Service, Component, Stage, and Extension.
> I have to parse all of them as a "Type" and then manually separate them
> out later. I find that annoying.
Let's dig into this a little more.
Firstly - I'm assuming that Stage can be folded into a
DependencyDescriptor + attribuite and that Extension can be folded into
a ServiceDescriptor + attribute. By folding Stage and Extension we end
up with two distinct and functionally different meta level classes -
Type and Service. A Type declares its relationship to a Service via (a)
a DependencyDescriptor and/or a (b) ServiceDescriptor.
Type != Service.
Secondly - the term "componet" - I belive (at this level) the term is
simply too generic.
Consider the following:
component Type (class, attributes, dependecies, service delcarations,
etc.)
component Profile (Type populated with data concerning instantiation
criteria and policy)
component instance (Profile instantiated relative a lifestyle policy)
A Type may by used by many Profiles
A Profile may be used by many Instances.
When we use the term "component" I basically thinking "an instance of a
profile".
>
> PS, can you fix the ServiceDescriptor? On your site docs you have
> something like this:
>
> <type>
> <services>
> <service>
> <!-- All the stuff about the service -->
> </service>
> </services>
> </type>
I'll check the docs - I know there is stuff that still reflects the
assumption that the service is defined within the type.
>
> If this type is supposed to describe a Service, which maps to an
> interface, then there is only *one* service possible. Also, I think
> the "type" element is unnecessary--it should be implied.
Not totally following - the <type><services><service><reference> points
to a service descriptor. It is statement that a component derived from
the type will establish a service referrd to by the reference.
> I would be
> happier for a service XML descriptor to be declared like this:
>
> <service>
> <!-- All the stuff about the service -->
> </service>
Ummm, it is!
A <classname>.xservice contains:
<service>
<version1.2.3</version>
<attributes>
<attribute key="a-key" value="a-value"/>
</attributes>
</service>
But the xdocs are not in place yet :-(
Been too busy with an embedded version of Tomcat running inside Merlin
as a component - I'm also playing with component based servlets (i.e.
Servlet's implemeting Avalon lifecycle interfaces). Some interesting
aspects arise with respect to the overall containment management
principals which I'm looking into now. Basically in the Tomcat scanrio
you have a container that is instantiating the component and I'm working
on leveraging Merlin assembly to take the instantiated component
(Servlet) and applying lifecycle processing to it before it enters into
the classic Servlet lifecycle.
Cheers, Steve.
--
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>
Re: Resolving Services
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> In order to satisfy my RT about service attributes used to provide
>> automated assembly logic, we need to make some API changes to Meta.
>> What we are comparing is a Service Reference (i.e. requires service)
>> to a component (i.e. Type) implementation. The Service descriptor
>> with all the attributes provides the rules to interpret the
>> attributes. To that end, we need the Service to generate a Comparator.
>
>
>
> Is it Service or DepedencyDescriptor that generates the comparitor?
It is _Service_. Service defines the rules for which attributes it will
allow for the decision process, and how it interprets them. We use the
Comparitor from the Service to compare a DependencyDescriptor against
the list of Components.
> * A Container is handling selection of a Type from possibly
> multiple alternatives based on an unresolved dependency.
Right. And the Comparitor that the Service creates assists in the
decision process. We *could* have it built from a utility class
that accepts the Service and the DependencyDescriptor. The two
put together will allow us to have one Comparator that does what we
want.
> * The dependency is declared through a DependencyDescriptor
> that uses a ReferenceDescriptor to point to a Service.
Right.
> * A Type is consider a candidate by virtue of the fact that
> it declares that it provides the service through exposure
> of a ServiceDescriptor
Right, and I am saying that the ServiceDescriptor should be pulled
*out* of the generic Type and made its own entity. If a component
implements a Service, we will know because it implements the interface.
> * Ranking of candidate types is achieved by the application of
> "constraints" declared under the DependencyDescriptor relative to
> the attribute values declared under the ServiceDescriptor exposed
> by the candidate Type.
The ServiceDescriptor (which should be declared *once* for all
implementing types) provides the basic rules of interpretation. The
DependencyDescriptor provides the values we are concerned with. So
we probably need our Comparator generated from both the Service and
Dependency Descriptors.
> So considering we has two service descriptors SD1 and SD2 and we want to
> compare these for order. The Comparitor implemetation needs the
> DepedencyDescriptor as the source of criteria for ranking. The compare
> operation is invoked such that:
>
> int j = comparitor.compare( SD1, SD2 );
>
> In which case it seems to me that the Comparitor factory is the
> DependencyDescriptor class - not the Service class. Alternatively, you
> could also look at the DepedecyDescriptor as a comparator.
> Anyway - yes - this would be a usefull addition to the meta package.
Actually it would be a separate utility class. It needs the *rules*
from the ServiceDescriptor, and the *values* from the
DependencyDescriptor to arrive at the subset of components we can
consider.
Thank you for the clarification.
BTW, one thing that bugs me about the whole "Type" thing is that while
the meta package is implemented to work with generic Types does not mean
that the programmer does. I don't like everything being a generic
"Type" because then I can't easily separate and group processing on
whole classes of Types like Service, Component, Stage, and Extension.
I have to parse all of them as a "Type" and then manually separate them
out later. I find that annoying.
PS, can you fix the ServiceDescriptor? On your site docs you have
something like this:
<type>
<services>
<service>
<!-- All the stuff about the service -->
</service>
</services>
</type>
If this type is supposed to describe a Service, which maps to an
interface, then there is only *one* service possible. Also, I think
the "type" element is unnecessary--it should be implied. I would be
happier for a service XML descriptor to be declared like this:
<service>
<!-- All the stuff about the service -->
</service>
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Resolving Services
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> In order to satisfy my RT about service attributes used to provide
> automated assembly logic, we need to make some API changes to Meta.
> What we are comparing is a Service Reference (i.e. requires service)
> to a component (i.e. Type) implementation. The Service descriptor
> with all the attributes provides the rules to interpret the
> attributes. To that end, we need the Service to generate a Comparator.
Is it Service or DepedencyDescriptor that generates the comparitor?
* A Container is handling selection of a Type from possibly
multiple alternatives based on an unresolved dependency.
* The dependency is declared through a DependencyDescriptor
that uses a ReferenceDescriptor to point to a Service.
* A Type is consider a candidate by virtue of the fact that
it declares that it provides the service through exposure
of a ServiceDescriptor
* Ranking of candidate types is achieved by the application of
"constraints" declared under the DependencyDescriptor relative to
the attribute values declared under the ServiceDescriptor exposed
by the candidate Type.
So considering we has two service descriptors SD1 and SD2 and we want to
compare these for order. The Comparitor implemetation needs the
DepedencyDescriptor as the source of criteria for ranking. The compare
operation is invoked such that:
int j = comparitor.compare( SD1, SD2 );
In which case it seems to me that the Comparitor factory is the
DependencyDescriptor class - not the Service class. Alternatively, you
could also look at the DepedecyDescriptor as a comparator.
Anyway - yes - this would be a usefull addition to the meta package.
Cheers, Steve.
>
>
> public class Service extends Descriptor
> {
> // .... skip everything else
>
> public java.lang.Comparator getComparator()
> {
> // logic to build the comparator using predicates, etc.
> }
> }
>
>
> That way we can create a nice little utility that would find the best
> match:
>
> public final class MetaUtil
> {
> private MetaUtil() {}
>
> public static final Object findBestMatch( List components,
> Service service )
> {
> // Order so that the best match comes first
> Collections.order( components, service.getComparator() );
> return components.get(0);
> }
> }
>
> Granted, it can still be overridden by an assembly file, but
> this way we can provide the default logic to find the best way to
> generate the assembly file to begin with.
>
--
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>