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