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. 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 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.
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. 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).
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 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]
