On Mar 22, 2006, at 10:10 AM, Jim Marino wrote:
On Mar 22, 2006, at 9:32 AM, Jeremy Boynes wrote:
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.
Yes. At first I read this as "I *do* think.." which scared me :-) I
need to check my vision again. We're in agreement here.
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.
Maybe I should have been clearer - by "not mediate the parameters"
I mean that the runtime cannot violate pass by reference. For
Java<-->Java in particular, which I would guess will be at least
90% of local calls (which we should optimize for), the strategy for
doing this should be passing references directly. For other
situations I don't have an opinion other than it should be done in
a handler or interceptor or extension and not in the core runtime.
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.
This to me is a "nice to have" sometime in the future but not
something we should optimize for right now.
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.
I think we need to follow the spec here.
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".
Yes. What would you propose here? Also, could you provide a
description of what happens when an invoke is done across two local
Java services?
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.
Yes, I forgot to preface the first "bindings" with transport binding.
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.
Declare = register, nothing more. They are just extensions included
in the baseline. We do need some way of naming them though.
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.
Relative cost is a "preference" isn't it? The implementation type
bases this preference on a selfish calculation since it does not
know what the source type is. What's the difference?
Jeez, I'm having trouble reading today - I also didn't see per
parameter vs. general. Sorry and nevermind the dumb question :-)
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
