Jim Marino wrote:
A couple of us have started to discuss this as well in relation to
Celtix...My main concerns, which there appears to be agreement, are:
1. We are not instituting a "canonical" form model similar to JBI in the
runtime. I think Jeremy stated this is not the case
Having trouble parsing :-)
I do not think we should have a "canonical" form model similar to JBI.
I do think we should identify a set of common forms to reduce the number
of format conversions we need to implement.
2. Local invokes - i.e. where semantics are "pass-by-reference" - honor
that and do not have *parameters* mediated. This appears non-controversial.
Let's be controversial then :-)
The contract is "pass-by-reference" not "pass-pointer-by-value" - if the
runtime chooses to mediate the pointer format then it is free to do so.
This may enable us to support local calls across language - e.g.
converting a Java object reference to a pointer in C++. It is the
runtime's responsibility to make sure the memory model is not violated.
3. Mediation is done using handlers and intereceptors. I think we are
also in agreement here.
+1
I still have questions around how the "container" and "bindings" declare
support for certain data binding formats. We need to come up with a
design here. For example, would the following be a valid approach in
your opinion (I haven't thought too much about it so it is kind of vague)?
1. Implementation types declare whether they support pass-by-ref. Since
this is a Java runtime, pass-by-ref means object references in the VM.
I'd modify that slightly to say the service contract determines if
parameters are passed by reference. Any implementation offering that
service contract must be able to support it.
The type of runtime must not impact the service contract and the runtime
must fail an attempt to deploy a contract that cannot be fulfilled.
The type of message used by the runtime is currently unspecified - in
our Java runtime we are defining the content format to be "reference to
any Java Object".
2. Bindings register themselves can be queried for what formats they
support. They may delegate to some data binding service.
I think we need to distinguish between transport binding and data
binding. Transports should delegate all serialization to data bindings.
3. Tuscany may want to "declare" some common formats such as Java-->SDO,
SDO-->, StaX stream-->Java, Java-->Stax, SDO-->StaX, JAXB-->Java etc.
and have interceptors or handlers perform those transformations. These
handlers could be registered with a wire builder and inserted into an
invocation chain
"Declare" to me implies something special. I think these are transforms
that we include in our "baseline" profile - they are no different to
ones provided by users.
Yes, they register their availability and the wire builder selects them
as appropriate when constructing the wire.
4. Implementation types and bindings declare what pass-by-value formats
they support in order of preference.
This may be what you meant but I think this depends on the wiring
requirements. The implementation type shouldn't specify a general
preference; instead it should say which ones are supported for a
particular parameter and provide a relative cost for each. The wire
builder calculates cost for source and target and selects the most
efficient wire.
Dan, I know you have a bunch of thoughts on this, so it would be
interesting to discuss them in this thread.
Please, this is key so the more perspectives the better.
--
Jeremy
