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