On Aug 22, 2006, at 10:10 AM, Raymond Feng wrote:
More comments in line.
Thanks,
Raymond
----- Original Message ----- From: "Ignacio Silva-Lepe"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, August 22, 2006 6:37 AM
Subject: Re: Service, Reference and Binding models
Hi Raymond, Jim,
Comments in line.
Ignacio
----- Original Message ----- From: "Jim Marino"
<[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, August 21, 2006 8:22 PM
Subject: Re: Service, Reference and Binding models
On Aug 21, 2006, at 4:21 PM, Raymond Feng wrote:
Hi,
I think the SPI models for SCDL service/reference/binding are
now becoming out of sync with the SCA spec. The introduction of
BindlessServiceDefinition (I view it as a service with
NullBinding) also worries me.
We discussed this with Ignacio and part of the issue depends on
how you look at it: a composite service viewed from the outside
is part of the component type for the composite impl. Ignacio,
do you want to elaborate?
Ok, so it seems like Raymond is trying to collapse all three
service definition classes (ServiceDefinition,
BoundServiceDefinition and BindlessServiceDefinition) into
ServiceDefinition, and also both reference definition classes
(ReferenceDefinition and BoundReferenceDefinition) into
ReferenceDefinition. Raymond, let me know if this is not what you
mean. I am not sure why you say they are becoming out of sync.
Having separate classes allows making a distinction between the
cases we care about at run time: a represenation of a service/
reference for a component type, for a composite with a binding,
and for a composite without a binding. Notice that a
BindlessReferenceDefinition can be optimized away and so it has
been. So the classification in the model is deliberate rather than
out of sync. Now, it could be argued that having a separate class
for each case can become unwieldy. On the other hand, having a
single class requires the code to make and enforce the distinction
and could potentially lead to errors, say, if a binding is there
that is not supposed to be. In the end, the distinction needs to
be made in order for the code to handle the cases, and it becomes
a matter of which choice we feel works better at making the
distinction.
Here's where I'm from:
The SCDL model is defined by the SCA spec using XML schema. I think
it would be natural to have the java model classes follow the XSD.
I don't think the Java classes should necessary follow the XSD. We're
dealing with an in-memory data model that *Java* developers must
manipulate. It should therefore follow Java idioms. That said, it may
or may not be useful for the model to follow concepts in the spec,
although it should definitely not do so at the expense of runtime
extensibility or performance.
My general concern with collapsing things, as mentioned by Ignacio,
is going to complicate the model greatly. We had this problem in M1
where it was not apparent which properties of a model object should
be used when.
The SCA spec defines a complexType "sca:Service". The "service"
element in "sca:ComponentType" and the "service" element in
"sca:Composite" are both typed by "sca:Service". This reflects the
Service concept in the SCA programming model and the rationale that
the latest SCA spec decides to replace the "entryPoint" with
"service".
As you listed, now we have three cases:
1) composite.service with bindings
2) composite.service without any bindings
3) componentType.service (without any bindings)
From the modeling perspective, I see the following:
1) A Composite owns a Service which in turn owns a list of Bindings
2) A Composite owns a Service which doesn't own any Bindings
3) A ComponentType owns a Service
What's missing in our model is relationship. For example, we can
neither figure out the parent of a Service
We can figure out the parent of a composite service. I'm not sure of
the value of figuring out the parent of a service on a component type
(see my comment below).
nor the parent of a Binding. As a result, we try to define multiple
model classes to capture the relationship. To me, the deliberation
should be done by builders. Model loaders should be kept simple to
only deal with XML loading.
The model loaders also need to introspect artifacts such as Java
classes and Spring application contexts.
It's also interesting that BindingBuilder is used to build
BoundService or BoundReference today instead of the Bindings and we
cannot support the case that a service with multiple bindings.
This is definitely a problem.
The BoundService contains the information of Service and one of its
Binding. I'm looking for an alternative approach: A Binding owned
by a Service (Binding.getService() will returns the owning Service).
Why do we need to get the parent of the binding? There may be a valid
case but I don't like to put multiple traversals in the model if we
can avoid it. Could you explain why it is needed?
I had some dicussions with Jeremy. We agreed that we could have the
builders follow a delegation pattern: the builder for the parent
(for example, Service) can delegate to the one for the child (for
example, Binding). The same can apply to the ComponentDefinition --
> Implementation chain.
I think this can still be accomodated with a few changes to Service.
I think, we'll have to push some of the functionality around wires
down into a Binding that is built by the binding builder. We can then
have a generic Service class.
I understand different people may have different modeling
philosophy :-). The above is mine to share.
Here's the SCDL syntax extracted from the SCA spec 0.96 draft.
<service name="xs:NCName" multiplicity="0..1 or 1..1 or 0..n or
1..n"?>*
<interface/>
<binding uri="xs:anyURI"?/>*
<reference>wire-target-URI</reference>+
</service>
<reference name="xs:NCName" override="sca:OverrideOptions"?
multiplicity="0..1 or 1..1 or 0..n or 1..n"?>*
<interface/>
<binding uri="xs:anyURI"?/>*
</reference>
I plan to some changes to the models to reflect the spec as
attached below. With the updated model, the BindingBuilder
could simply deal with the binding contained by either the
ServiceDefinition or ReferenceDefinition.
What do you guys think?
Raymond, can you summarize the changes you are proposing?
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
