Jeremy Boynes wrote:
On Sep 23, 2006, at 1:27 PM, Jean-Sebastien Delfino wrote:
Jeremy Boynes wrote:
On Sep 22, 2006, at 12:20 PM, Jim Marino wrote:
If we want interop can't we say use binding.ws since binding.sca
isn't really meant for interop but for optimization and abstraction
of the physical binding? I have a couple of concerns here. The
biggest one is that I don't want to require a web services stack
for the Java runtime (it should be able to run as a very small
footprint, some may not want to use web services). Related to this,
we would then have to select a Java web services stack, which I
would like to avoid.
For Java, I'd actually like to do something where binding.sca is
configurable or potentially not even needed to be specified. For
example, if I'm running on WebLogic, I may want binding.sca to be
T3 but if I'm running on Websphere maybe it is some other
specialized protocol. Or, it could be RMI which would run on both.
Jeremy will probably also throw in the question of whether
binding.sca is really needed ;-)
Why do we need binding.sca?
To connect SCA components we have wires. These wires may be remote
and if so we need a physical connection between the machines hosting
the components at either end. We never specify what transport should
be used, although the policies we apply may dictate one. There
simply is no concept of binding in the assembly here.
To connect to non-SCA components we have to use the protocol and
transport they are expecting. Any SCA concept of default is
meaningless - the SCA runtime cannot arbitrarily choose one as it
must match the one the non-SCA service is using.
I don't quite understand. <binding.sca> is in the SCA 0.96 spec. Are
you suggesting that <binding.sca> should be removed from the SCA
spec? Has this been brought up to the SCA assembly spec workgroup?
Are you saying that you are not going to implement a default binding
(with or without a <binding.sca> element) in Tuscany/Java? or just
that you're not going to support <binding.sca>?
I'm asking why do we need it - what does it allow a user to do that is
not already covered by wiring and physical bindings? What is a
"default binding" useful for?
Knowing why you're doing something is essential for implementing it -
and if we don't know why then its reasonable to ask the spec what they
were thinking.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
My understanding is that the SCA default binding is there to handle the
communication with another SCA service without requiring the application
developer to explicitly choose and configure a WS, EIS, JMS, or whatever
other binding.
The spec also says that the default binding is not intended to be
interoperable. This gives flexibility to runtimes to implement that
binding in the most efficient way in the context of a given assembly.
I'm currently implementing the Tuscany C++ default binding on top of
Axis2C but in the future we may want to implement more optimized
variants (start to turn on the SOAP MTOM - Message Transmission
Optimization Mechanism for example, or use a completely different
protocol like Jim suggested earlier).
Whether or not a <binding.sca> element must be present to tell the
runtime that the default binding is used on a composite service or
composite reference is debatable. The implementation I'm working on does
not require you to specify the <binding.sca> element, but I need a
little more work through some scenarios and double check one more time
with the spec documents to make sure that this is right. It also
obviously supports the <binding.sca> element if it is present.
I can see several use cases for the <binding.sca> element:
- When you want to specify a target service for your reference directly
in your composite, right in the reference definition (as opposed to a
wire which will only work from an outer composite). See section 1.4.2 of
the spec for the details.
- When you want to override the binding specified on a composite
reference or composite service, for example a WS binding, and request
the default binding to be used instead for a particular component
(because it's optimized for example).
- When you want to specify that a service should be available through
the WS, JMS and the default binding for example, then you'll explicitly
specify the three bindings on your service.
There's probably more use cases, but I hope this helps. Maybe other spec
people can also give us their perspective on this?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
