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 ;-)
Jim
On Sep 22, 2006, at 11:58 AM, Andrew Borley wrote:
Are there any plans at the moment for binding.sca in the Java
codebase? One of the obvious uses for binding.sca in Tuscany is to
connect up the Java and C++ codebases..
Andy
On 9/22/06, Mike Edwards <[EMAIL PROTECTED]> wrote:
Sebastien,
This sounds like a good approach to me.
Yours, Mike.
Jean-Sebastien Delfino wrote:
> Hi,
>
> I think it's about time that we implement the SCA <binding.sca>
> "default" binding, about 10 months after the publication of the
initial
> SCA spec v0.9 :)
>
> As far as I can remember all discussions on the subject, the
idea has
> always been to reuse the Web Service binding for this, with some
> simplifying assumptions and good defaults (WS-I basic profile,
> doc-lit-wrapped, no need to specify a WSDL binding or even a WSDL
> interface).
>
> Reusing the Web Service binding extension code is probably the
simplest
> at this point but will create a dependency between this new
> extensions/sca binding and the existing extensions/ws. I think
it's OK
> for now as our Web Service binding extension is still very light
weight
> and we can assume that people looking at Tuscany for an SOA
runtime will
> want the Web Service extension in the distribution. So if
there's no
> objection I'm planning to just do that: reuse the Web Service
binding
> extension and implement the SCA default binding extension as a thin
> layer on top of it.
>
> In the longer term the Web Service extension will probably grow (to
> support more WS profiles, SOAP versions, WS policies etc.) so
we'll have
> to find a better solution and maybe carve out of the Web Service
> extension a small subset that can be shared between the two
extensions
> or just used by the SCA default binding extension.
>
> Dos that plan sound OK? Any thoughts?
>
---------------------------------------------------------------------
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]
