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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
