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:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
