You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2006/09/23 17:40:10 UTC
Why do we need binding.sca?, was: [C++] Should the SCA binding reuse the Web Service binding code
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.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Why do we need binding.sca?, was: [C++] Should the SCA binding reuse the Web Service binding code
Posted by Jim Marino <jm...@myromatours.com>.
>>
>>
>
> 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 open to entertaining the idea of having it removed from the spec
as long as there is a way for people to have the runtime select a
physical binding. Assuming it is not removed, on the question of what
the actual physical manifestation of binding.sca is for Tuscany/Java,
I would prefer that be left to configuration. I don't want to require
bundling a web services stack with every distribution and would like
to avoid the question of which stack would be selected. I would also
like to give people more options, for example choosing an optimized
binary protocol since interop can be covered through binding.ws.
Jim
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Why do we need binding.sca?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
A few comments inline :)
[snip]
Mike Edwards wrote:
> Folks,
>
> I'm not sure that adding more comments inline is going to help
> clarity, so I'll try to make my points standalone here:
>
> 1) My view is that binding.sca was intended to imply "the binding that
> the SCA runtime system will use if you specify no other specific binding"
>
> - implying that a detailed choice will be made by the runtime
> - implying that you the assembler/developer don't really care - all
> you want is that references should connect to the target services in
> some way that works
>
> 2) I agree with Jeremy's point that in many cases, you don't need to
> explicitly specify <binding.sca/> in your compositions - since it's
> the default, you "get it for free"
>
Yes, as I said earlier in this thread, that's how I'm implementing it. I
think it woulnd't hurt to add some text to the 0.96 spec doc to make
this more clear.
> 3) HOWEVER, if I specify <binding.ws/> or some other specific binding
> on a component, that does mean "the runtime must use the ws binding
> for this service / reference" and the runtime is NOT allowed to choose
> any other binding. This allows developers/assemblers to be specific
> about the protocols they want to use, if they so wish.
>
> 4) Given the potential to reuse/override implementations in components
> in a composite, I MAY find myself with an implementation that declares
> itself to use (say) <binding.ws/> that I wish to use in a context
> where I don't want to use the ws binding. In this case, I should be
> able to override the binding specified on the implementation. This
> could be with <binding.jms/> say - but it could also be with
> <binding.sca/>. The latter case is useful where I want to say "use
> the system binding for this one", especially to ensure that wires will
> work properly for that component.
>
> Wires may be a contract - but whether they are valid is another
> matter. A wire can be drawn between incompatible endpoints - in that
> case the Wire is invalid and an error gets raised. Compatible bindings
> on each end is one requirement, amongst a host of others (eg
> interfaces must be compatible, policy sets must be compatible)
>
> 5) I agree with Jeremy's sentiment that it would be a good idea for an
> SCA runtime to allow configuration of which protocol would get used
> for its binding.sca.
>
+1, I've started a first implementation option using Axis2C, but it will
be possible to configure other options. We now know how to add --enable
and --with options in out configure scripts, that will help too.
> 6) binding.sca is clearly of no use for services or references which
> address things external to the SCA System.
>
> To sum up:
>
> - I think that binding.sca has a place, it has some uses
> - We should be flexible about which protocol get used for binding.sca
>
Yes, agreed.
> Yours, Mike.
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Why do we need binding.sca?
Posted by Mike Edwards <mi...@gmail.com>.
Folks,
I'm not sure that adding more comments inline is going to help clarity,
so I'll try to make my points standalone here:
1) My view is that binding.sca was intended to imply "the binding that
the SCA runtime system will use if you specify no other specific binding"
- implying that a detailed choice will be made by the runtime
- implying that you the assembler/developer don't really care - all you
want is that references should connect to the target services in some
way that works
2) I agree with Jeremy's point that in many cases, you don't need to
explicitly specify <binding.sca/> in your compositions - since it's the
default, you "get it for free"
3) HOWEVER, if I specify <binding.ws/> or some other specific binding on
a component, that does mean "the runtime must use the ws binding for
this service / reference" and the runtime is NOT allowed to choose any
other binding. This allows developers/assemblers to be specific about
the protocols they want to use, if they so wish.
4) Given the potential to reuse/override implementations in components
in a composite, I MAY find myself with an implementation that declares
itself to use (say) <binding.ws/> that I wish to use in a context where
I don't want to use the ws binding. In this case, I should be able to
override the binding specified on the implementation. This could be
with <binding.jms/> say - but it could also be with <binding.sca/>. The
latter case is useful where I want to say "use the system binding for
this one", especially to ensure that wires will work properly for that
component.
Wires may be a contract - but whether they are valid is another matter.
A wire can be drawn between incompatible endpoints - in that case the
Wire is invalid and an error gets raised. Compatible bindings on each
end is one requirement, amongst a host of others (eg interfaces must be
compatible, policy sets must be compatible)
5) I agree with Jeremy's sentiment that it would be a good idea for an
SCA runtime to allow configuration of which protocol would get used for
its binding.sca.
6) binding.sca is clearly of no use for services or references which
address things external to the SCA System.
To sum up:
- I think that binding.sca has a place, it has some uses
- We should be flexible about which protocol get used for binding.sca
Yours, Mike.
scabooz wrote:
> Replies in line
>
> Dave
>
> ----- Original Message ----- From: "Jeremy Boynes" <jb...@apache.org>
> To: <tu...@ws.apache.org>
> Sent: Tuesday, September 26, 2006 2:20 AM
> Subject: Re: Why do we need binding.sca?
>
>
>> On Sep 25, 2006, at 6:47 PM, scabooz wrote:
>>
>>> Sebastien did a good job enumerating the rationale for why the
>>> <binding.sca>
>>> exists in the specifications. Perhaps your concern is over the name
>>> of the
>>> binding, and not the specific reason for its existence? I could be
>>> convinced that "default" is a bad name, but we'd need a suggestion for
>>> an improvement.
>>
>>
>> It wasn't really but now that you mention it default does tend to
>> imply a well-known value. I would be concerned users may assume a
>> specific protocol will always be the default (e.g. the original
>> proposal on this thread about making WS the default for the C++
>> runtime) whereas the goal of the spec is to allow the container to
>> choose which protocol it considers optimal. The semantic is
>> "unspecified" rather than "default" but that is not a good description.
>>
>
> "Unspecified" binding doesn't work for me. Something like
> "built-in", "system", "fabric", "ESB" gets closer to the concept.
>
>>>
>>> <binding.sca> differs from a wire in the fact that a wire only denotes
>>> a relationship between two components. A binding specifies the message
>>> format/transport-protocol to be used when the given components
>>> interact. A
>>> wire is only valid if both ends of the wire are using the same (or
>>> compatible)
>>> binding. The definition of compatible is under construction at the
>>> moment.
>>
>>
>> "Only"? I think a wire is more emphatic than that - it /defines/ a
>> relationship between two components. As you say, a binding specifies
>> the message format/transport protocol which is essential for non-SCA
>> interactions but which is also the very thing we are trying to
>> abstract away in the assembly model for SCA-to-SCA relationships.
>
>
> Agreed. The <binding.sca> concept does that very well, especially when
> you don't even need to type it into the XML.
>
>>
>> Validity is also true for <binding.sca> but unlike a wire a binding
>> is only attached to one party in the relationship making
>> compatibility and validity harder to achieve. With the ability to
>> decompose a composite to different address spaces potentially
>> implemented by different SCA runtimes
>
>
> No. I'm reading "different SCA runtimes" to mean vendor1 and
> vendor2 SCA runtimes. There is no federation of the SCA
> System concept across different SCA runtimes. <binding.sca> is
> bounded by the SCA system and therefore bounded by a vendor
> runtime implementation. I know that SCA system is vaguely defined
> in the specs right now. However, my point still holds.
>
>> , use of a _default_ binding is insufficient as the platforms hosting
>> the related components may have different _defaults_ with no
>> guarantee of interop.
>
>
> That's precisely the point. <binding.sca> is non-interoperable by
> definition, which means that a vendor can provide value add, optimized
> capabilty without affecting the portability of the SCDL or the business
> service/consumer implementations. If vendor1 and vendor2 want to interop,
> their services/reference must choose an interoperable binding. There is no
> wire in this case that can express the relationship between the
> service/reference because the relationship occurs outside the scope of SCA.
> Web services would be my recommendation for an interoperable binding.
>
>> However, the presence of a wire in the assembly is a clear contract
>> that the SCA system must obey or default on [sorry, couldn't resist]
>>
>
>>>
>>> When two components are related via a reference-value or via a wire,
>>> the
>>> <binding.sca> capability (I'm trying hard not to say default
>>> binding) is automatically
>>> associated with the relationship. IMHO, the <binding.sca> element
>>> need not be
>>> specified.
>>
>>
>> I agree - in fact I would go further and say that <binding.sca> need /
>> never/ be specified, making it a redundant concept that could be
>> removed from the spec.
>>
>
> Except for the cases that Sebastien noted which lead to the need to
> override/remove/change a binding specified lower in the composition
> hierarchy. If there is an alternative way to accomplish this, then I
> would be very open to hearing it, but the concept
> must continue to exist. Don't you think it would be funny to have a
> first class concept without an XML serialization?
>
> In any case, when the policy work gets straightened out (there's a draft
> spec now) we'll see the need to attach policy to bindings. Attaching
> policy
> to <binding.sca> will be a 1st class concept also. I'd hate to have a
> different way to attach policy for the "builtin","system","fabric","ESB"
> binding as compared to every other binding in the world.
>
>>> I would expect that the vast majority of SCA services will be wired and
>>> composed using the _default_ binding, without explicitly stating it.
>>>
>>> There are several known issues in the Assembly spec that relate to the
>>> _default_ binding, especially in the context of recursive
>>> composition, and
>>> with binding overrides in general. Proposals are being discussed.
>>
>>
>> --
>> Jeremy
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Why do we need binding.sca?
Posted by scabooz <sc...@gmail.com>.
I think that summarizes the points of discussion/contention. I'm not
sure that you were convinced about a particular point, so let's make
sure that JIRAs/spec issues are opened as appropriate. You
mentioned spec issue 44, which I believe is surfacing and attempting
to resolve all the points but the last. If you disagree, then let's get the
issues opened.
IMHO, the last point seems to be outside the scope of SCA. The
owners of two different runtime implementations are certainly free
to collaborate on the infrastructure to make this happen. I don't think
the spec would have to say anything about it.
Dave
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, September 26, 2006 6:37 PM
Subject: Re: Why do we need binding.sca?
> On Sep 26, 2006, at 12:01 PM, scabooz wrote:
>
>> Jeremy,
>>
>> We need to bring these threads back together. Mike's comments
>> further reinforce the concepts.
>>
>
> Agreed. If I can summarize:
> * the current need for <binding.sca> is to support rare cases of
> overrides
> * most assemblies will not need it at all
> * _default_ is a bad term for a binding, but better than other
> options so far :-)
> * we have spec issues pertaining to promotion (specifically issue 44)
> * we need to examine federated configurations, especially multi-
> vendor ones
>
> Did I miss anything?
> --
> Jeremy
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Why do we need binding.sca?
Posted by Jeremy Boynes <jb...@apache.org>.
On Sep 26, 2006, at 12:01 PM, scabooz wrote:
> Jeremy,
>
> We need to bring these threads back together. Mike's comments
> further reinforce the concepts.
>
Agreed. If I can summarize:
* the current need for <binding.sca> is to support rare cases of
overrides
* most assemblies will not need it at all
* _default_ is a bad term for a binding, but better than other
options so far :-)
* we have spec issues pertaining to promotion (specifically issue 44)
* we need to examine federated configurations, especially multi-
vendor ones
Did I miss anything?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Why do we need binding.sca?
Posted by scabooz <sc...@gmail.com>.
Jeremy,
We need to bring these threads back together. Mike's comments
further reinforce the concepts.
<snip>
>
> I'm confused. <binding.sca> seems like a very different concept to
> all other bindings. They all define protocols etc. but <binding.sca>
> does not; they allow interaction with non-SCA services, <binding.sca>
> does not; they support interop, <binding.sca> does not. They need to
> be typed into the XML, <binding.sca> does not.
>
<binding.sca> does define a protocol, the developer nor the assembler
just doesn't know what it is. The rest of your points are correct. It's an
optimization to simplify the binding concept. We're running out of ways
to say the same thing, so I'll refer you back to all the previous emails.
> That a user does not need to type it in get back to my original
> question - why do we need it?
>
We need it in the rare cases of overrides, etc.
<snip>
> Ah - we have a real disconnect here. I agree SCA system is vaguely
> defined but what is specified is that it is a logical domain of
> control that spans multiple address spaces. It is the domain of
> control throughout which SCA concepts (especially wiring) apply. The
> assembly model does not constrain this to be a single-vendor, single-
> runtime domain.
Ok, the spec can be fixed to clarify the concept as I outlined it above.
> Now individual implementations of SCA may be
> constrained to homogeneous or even single address-space
> configurations but that should be viewed as a limitation of that
> implementation rather than part of the specification.
Agreed.
> Other
> implementations, whether from a single vendor or a federation, can
> support the multi-platform distribution of an assembly.
>
Agreed.
<snip>
> I think the different ways we view a system may be relevant here. I
> agree that for any connection that goes outside the SCA system then
> you need to specify an interoperable binding so can't use
> <binding.sca> - it is irrelevant if the other services use SCA or
> not, they are a outside our domain of control and SCA concepts do no
> apply.
Agreed
>
> Within a system though things are interoperable by definition. It
> does not matter whether they come from a single vendor or a
> federation, to the user there is a single domain in which SCA
> concepts apply.
I can imagine that 2 vendors got together and decided to allow
SCA System federation across their products. I hope they are sharing
their implementations of <binding.sca>, etc. I don't see what that has
to do with this discussion.
> Within an SCA assembly, a user can specify
> connections using wires and the implementation must ensure that the
> relationship define by that wire is materialized. How that is
> achieved is a function of the implementation(s) and <binding.sca>
> does not help here.
It does help because as Mike said (a point that I forgot to mention)
bindings MUST be honored by the runtime. A _wire_ in a higher level
composite CANNOT ignore the binding specified on lower level services
and references (which must also match). We obviously need to clarify
this point as well.
>
> As soon as you go to a multi-address space configuration then you are
> going to have different _defaults_ associated with <binding.sca> (be
> it explicitly specified or not) - I can't think of any implementation
> that would not use different protocols for remote vs. in-address-
> space invocations.
>
I am completely missing your point, I think. The <binding.sca>
implementation that lives between two collocated components
is simply an optimization of the implementation that lives between
two remote components. It's not a different binding.
>
> I think this may be the crux of the matter here. We have known issues
> associated with the propagation/overriding of physical binding
> definitions in conjunction with composition; we did not have those in
> the 0.9 era.
>
>> Don't you think it would be funny to have a
>> first class concept without an XML serialization
>
> We do: <wire>
>
>> In any case, when the policy work gets straightened out (there's a
>> draft
>> spec now) we'll see the need to attach policy to bindings.
>> Attaching policy
>> to <binding.sca> will be a 1st class concept also. I'd hate to have a
>> different way to attach policy for the
>> "builtin","system","fabric","ESB"
>> binding as compared to every other binding in the world.
>
> I've not caught up with the latest spec but I have been assuming that
> there would be a way to associate policies with wires for all those
> cases where there is no <binding> specified at all (e.g. for wires
> within a composite). Wouldn't that support this without the need to
> introduce a special binding that is, ironically, different from every
> other binding in the world?
>
The <wire> element hardly ever exists either.
> --
> Jeremy
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Why do we need binding.sca?
Posted by Jeremy Boynes <jb...@apache.org>.
On Sep 26, 2006, at 6:26 AM, scabooz wrote:
> ----- Original Message ----- From: "Jeremy Boynes"
> <jb...@apache.org>
>> On Sep 25, 2006, at 6:47 PM, scabooz wrote:
>>
>>> Sebastien did a good job enumerating the rationale for why the
>>> <binding.sca>
>>> exists in the specifications. Perhaps your concern is over the
>>> name of the
>>> binding, and not the specific reason for its existence? I could be
>>> convinced that "default" is a bad name, but we'd need a
>>> suggestion for
>>> an improvement.
>>
>> It wasn't really but now that you mention it default does tend to
>> imply a well-known value. I would be concerned users may assume a
>> specific protocol will always be the default (e.g. the original
>> proposal on this thread about making WS the default for the C++
>> runtime) whereas the goal of the spec is to allow the container
>> to choose which protocol it considers optimal. The semantic is
>> "unspecified" rather than "default" but that is not a good
>> description.
>>
>
> "Unspecified" binding doesn't work for me. Something like
> "built-in", "system", "fabric", "ESB" gets closer to the concept.
Me neither :-) But then, if we're having problems naming it perhaps
we don't need it ;-)
>>>
>>> <binding.sca> differs from a wire in the fact that a wire only
>>> denotes
>>> a relationship between two components. A binding specifies the
>>> message
>>> format/transport-protocol to be used when the given components
>>> interact. A
>>> wire is only valid if both ends of the wire are using the same
>>> (or compatible)
>>> binding. The definition of compatible is under construction at
>>> the moment.
>>
>> "Only"? I think a wire is more emphatic than that - it /defines/ a
>> relationship between two components. As you say, a binding
>> specifies the message format/transport protocol which is
>> essential for non-SCA interactions but which is also the very
>> thing we are trying to abstract away in the assembly model for
>> SCA-to-SCA relationships.
>
> Agreed. The <binding.sca> concept does that very well, especially
> when
> you don't even need to type it into the XML.
I'm confused. <binding.sca> seems like a very different concept to
all other bindings. They all define protocols etc. but <binding.sca>
does not; they allow interaction with non-SCA services, <binding.sca>
does not; they support interop, <binding.sca> does not. They need to
be typed into the XML, <binding.sca> does not.
That a user does not need to type it in get back to my original
question - why do we need it?
>>
>> Validity is also true for <binding.sca> but unlike a wire a
>> binding is only attached to one party in the relationship making
>> compatibility and validity harder to achieve. With the ability to
>> decompose a composite to different address spaces potentially
>> implemented by different SCA runtimes
>
> No. I'm reading "different SCA runtimes" to mean vendor1 and
> vendor2 SCA runtimes. There is no federation of the SCA
> System concept across different SCA runtimes. <binding.sca> is
> bounded by the SCA system and therefore bounded by a vendor
> runtime implementation. I know that SCA system is vaguely defined
> in the specs right now. However, my point still holds.
Ah - we have a real disconnect here. I agree SCA system is vaguely
defined but what is specified is that it is a logical domain of
control that spans multiple address spaces. It is the domain of
control throughout which SCA concepts (especially wiring) apply. The
assembly model does not constrain this to be a single-vendor, single-
runtime domain. Now individual implementations of SCA may be
constrained to homogeneous or even single address-space
configurations but that should be viewed as a limitation of that
implementation rather than part of the specification. Other
implementations, whether from a single vendor or a federation, can
support the multi-platform distribution of an assembly.
>
>> , use of a _default_ binding is insufficient as the platforms
>> hosting the related components may have different _defaults_ with
>> no guarantee of interop.
>
> That's precisely the point. <binding.sca> is non-interoperable by
> definition, which means that a vendor can provide value add, optimized
> capabilty without affecting the portability of the SCDL or the
> business
> service/consumer implementations. If vendor1 and vendor2 want to
> interop,
> their services/reference must choose an interoperable binding.
> There is no
> wire in this case that can express the relationship between the
> service/reference because the relationship occurs outside the scope
> of SCA.
> Web services would be my recommendation for an interoperable binding.
I think the different ways we view a system may be relevant here. I
agree that for any connection that goes outside the SCA system then
you need to specify an interoperable binding so can't use
<binding.sca> - it is irrelevant if the other services use SCA or
not, they are a outside our domain of control and SCA concepts do no
apply.
Within a system though things are interoperable by definition. It
does not matter whether they come from a single vendor or a
federation, to the user there is a single domain in which SCA
concepts apply. Within an SCA assembly, a user can specify
connections using wires and the implementation must ensure that the
relationship define by that wire is materialized. How that is
achieved is a function of the implementation(s) and <binding.sca>
does not help here.
As soon as you go to a multi-address space configuration then you are
going to have different _defaults_ associated with <binding.sca> (be
it explicitly specified or not) - I can't think of any implementation
that would not use different protocols for remote vs. in-address-
space invocations.
>> However, the presence of a wire in the assembly is a clear
>> contract that the SCA system must obey or default on [sorry,
>> couldn't resist]
>>
>
>>>
>>> When two components are related via a reference-value or via a
>>> wire, the
>>> <binding.sca> capability (I'm trying hard not to say default
>>> binding) is automatically
>>> associated with the relationship. IMHO, the <binding.sca>
>>> element need not be
>>> specified.
>>
>> I agree - in fact I would go further and say that <binding.sca>
>> need / never/ be specified, making it a redundant concept that
>> could be removed from the spec.
>>
>
> Except for the cases that Sebastien noted which lead to the need to
> override/remove/change a binding specified lower in the composition
> hierarchy. If there is an alternative way to accomplish this, then I
> would be very open to hearing it, but the concept
> must continue to exist.
I think this may be the crux of the matter here. We have known issues
associated with the propagation/overriding of physical binding
definitions in conjunction with composition; we did not have those in
the 0.9 era.
> Don't you think it would be funny to have a
> first class concept without an XML serialization
We do: <wire>
> In any case, when the policy work gets straightened out (there's a
> draft
> spec now) we'll see the need to attach policy to bindings.
> Attaching policy
> to <binding.sca> will be a 1st class concept also. I'd hate to have a
> different way to attach policy for the
> "builtin","system","fabric","ESB"
> binding as compared to every other binding in the world.
I've not caught up with the latest spec but I have been assuming that
there would be a way to associate policies with wires for all those
cases where there is no <binding> specified at all (e.g. for wires
within a composite). Wouldn't that support this without the need to
introduce a special binding that is, ironically, different from every
other binding in the world?
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Why do we need binding.sca?
Posted by scabooz <sc...@gmail.com>.
Replies in line
Dave
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Tuesday, September 26, 2006 2:20 AM
Subject: Re: Why do we need binding.sca?
> On Sep 25, 2006, at 6:47 PM, scabooz wrote:
>
>> Sebastien did a good job enumerating the rationale for why the
>> <binding.sca>
>> exists in the specifications. Perhaps your concern is over the name of
>> the
>> binding, and not the specific reason for its existence? I could be
>> convinced that "default" is a bad name, but we'd need a suggestion for
>> an improvement.
>
> It wasn't really but now that you mention it default does tend to imply a
> well-known value. I would be concerned users may assume a specific
> protocol will always be the default (e.g. the original proposal on this
> thread about making WS the default for the C++ runtime) whereas the goal
> of the spec is to allow the container to choose which protocol it
> considers optimal. The semantic is "unspecified" rather than "default"
> but that is not a good description.
>
"Unspecified" binding doesn't work for me. Something like
"built-in", "system", "fabric", "ESB" gets closer to the concept.
>>
>> <binding.sca> differs from a wire in the fact that a wire only denotes
>> a relationship between two components. A binding specifies the message
>> format/transport-protocol to be used when the given components interact.
>> A
>> wire is only valid if both ends of the wire are using the same (or
>> compatible)
>> binding. The definition of compatible is under construction at the
>> moment.
>
> "Only"? I think a wire is more emphatic than that - it /defines/ a
> relationship between two components. As you say, a binding specifies the
> message format/transport protocol which is essential for non-SCA
> interactions but which is also the very thing we are trying to abstract
> away in the assembly model for SCA-to-SCA relationships.
Agreed. The <binding.sca> concept does that very well, especially when
you don't even need to type it into the XML.
>
> Validity is also true for <binding.sca> but unlike a wire a binding is
> only attached to one party in the relationship making compatibility and
> validity harder to achieve. With the ability to decompose a composite to
> different address spaces potentially implemented by different SCA
> runtimes
No. I'm reading "different SCA runtimes" to mean vendor1 and
vendor2 SCA runtimes. There is no federation of the SCA
System concept across different SCA runtimes. <binding.sca> is
bounded by the SCA system and therefore bounded by a vendor
runtime implementation. I know that SCA system is vaguely defined
in the specs right now. However, my point still holds.
>, use of a _default_ binding is insufficient as the platforms hosting the
>related components may have different _defaults_ with no guarantee of
>interop.
That's precisely the point. <binding.sca> is non-interoperable by
definition, which means that a vendor can provide value add, optimized
capabilty without affecting the portability of the SCDL or the business
service/consumer implementations. If vendor1 and vendor2 want to interop,
their services/reference must choose an interoperable binding. There is no
wire in this case that can express the relationship between the
service/reference because the relationship occurs outside the scope of SCA.
Web services would be my recommendation for an interoperable binding.
> However, the presence of a wire in the assembly is a clear contract that
> the SCA system must obey or default on [sorry, couldn't resist]
>
>>
>> When two components are related via a reference-value or via a wire, the
>> <binding.sca> capability (I'm trying hard not to say default binding) is
>> automatically
>> associated with the relationship. IMHO, the <binding.sca> element need
>> not be
>> specified.
>
> I agree - in fact I would go further and say that <binding.sca> need /
> never/ be specified, making it a redundant concept that could be removed
> from the spec.
>
Except for the cases that Sebastien noted which lead to the need to
override/remove/change a binding specified lower in the composition
hierarchy. If there is an alternative way to accomplish this, then I
would be very open to hearing it, but the concept
must continue to exist. Don't you think it would be funny to have a
first class concept without an XML serialization?
In any case, when the policy work gets straightened out (there's a draft
spec now) we'll see the need to attach policy to bindings. Attaching policy
to <binding.sca> will be a 1st class concept also. I'd hate to have a
different way to attach policy for the "builtin","system","fabric","ESB"
binding as compared to every other binding in the world.
>> I would expect that the vast majority of SCA services will be wired and
>> composed using the _default_ binding, without explicitly stating it.
>>
>> There are several known issues in the Assembly spec that relate to the
>> _default_ binding, especially in the context of recursive composition,
>> and
>> with binding overrides in general. Proposals are being discussed.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Why do we need binding.sca?
Posted by Jeremy Boynes <jb...@apache.org>.
On Sep 25, 2006, at 6:47 PM, scabooz wrote:
> Sebastien did a good job enumerating the rationale for why the
> <binding.sca>
> exists in the specifications. Perhaps your concern is over the
> name of the
> binding, and not the specific reason for its existence? I could be
> convinced that "default" is a bad name, but we'd need a suggestion for
> an improvement.
It wasn't really but now that you mention it default does tend to
imply a well-known value. I would be concerned users may assume a
specific protocol will always be the default (e.g. the original
proposal on this thread about making WS the default for the C++
runtime) whereas the goal of the spec is to allow the container to
choose which protocol it considers optimal. The semantic is
"unspecified" rather than "default" but that is not a good description.
>
> <binding.sca> differs from a wire in the fact that a wire only denotes
> a relationship between two components. A binding specifies the
> message
> format/transport-protocol to be used when the given components
> interact. A
> wire is only valid if both ends of the wire are using the same (or
> compatible)
> binding. The definition of compatible is under construction at the
> moment.
"Only"? I think a wire is more emphatic than that - it /defines/ a
relationship between two components. As you say, a binding specifies
the message format/transport protocol which is essential for non-SCA
interactions but which is also the very thing we are trying to
abstract away in the assembly model for SCA-to-SCA relationships.
Validity is also true for <binding.sca> but unlike a wire a binding
is only attached to one party in the relationship making
compatibility and validity harder to achieve. With the ability to
decompose a composite to different address spaces potentially
implemented by different SCA runtimes, use of a _default_ binding is
insufficient as the platforms hosting the related components may have
different _defaults_ with no guarantee of interop. However, the
presence of a wire in the assembly is a clear contract that the SCA
system must obey or default on [sorry, couldn't resist]
>
> When two components are related via a reference-value or via a
> wire, the
> <binding.sca> capability (I'm trying hard not to say default
> binding) is automatically
> associated with the relationship. IMHO, the <binding.sca> element
> need not be
> specified.
I agree - in fact I would go further and say that <binding.sca> need /
never/ be specified, making it a redundant concept that could be
removed from the spec.
> I would expect that the vast majority of SCA services will be wired
> and
> composed using the _default_ binding, without explicitly stating it.
>
> There are several known issues in the Assembly spec that relate to the
> _default_ binding, especially in the context of recursive
> composition, and
> with binding overrides in general. Proposals are being discussed.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Why do we need binding.sca?
Posted by scabooz <sc...@gmail.com>.
Sebastien did a good job enumerating the rationale for why the <binding.sca>
exists in the specifications. Perhaps your concern is over the name of the
binding, and not the specific reason for its existence? I could be
convinced that "default" is a bad name, but we'd need a suggestion for
an improvement.
<binding.sca> differs from a wire in the fact that a wire only denotes
a relationship between two components. A binding specifies the message
format/transport-protocol to be used when the given components interact. A
wire is only valid if both ends of the wire are using the same (or
compatible)
binding. The definition of compatible is under construction at the moment.
When two components are related via a reference-value or via a wire, the
<binding.sca> capability (I'm trying hard not to say default binding) is
automatically
associated with the relationship. IMHO, the <binding.sca> element need not
be
specified.
I would expect that the vast majority of SCA services will be wired and
composed using the _default_ binding, without explicitly stating it.
There are several known issues in the Assembly spec that relate to the
_default_ binding, especially in the context of recursive composition, and
with binding overrides in general. Proposals are being discussed.
Dave Booz
----- Original Message -----
From: "Jeremy Boynes" <jb...@apache.org>
To: <tu...@ws.apache.org>
Sent: Monday, September 25, 2006 2:44 AM
Subject: Re: Why do we need binding.sca?
> On Sep 24, 2006, at 9:32 PM, Jean-Sebastien Delfino wrote:
>
>>
>> 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.
>
> How does that differ from a wire?
>
>> 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).
>
> The lack of interop here is one of the reasons that I think this is
> problematic. We can't interop with non-SCA services as to do that we need
> to know the protocol etc. they use - IOW we need a specific binding like
> WS. We can't interop with other SCA systems unless they happen to use the
> same default; SCA is designed for large-scale heterogeneous systems and
> they are not likely to use the same default and so to interop between
> them the user will either need to specify a wire (if they are centrally
> administered) or use a physical binding as if the other side was a
> non-SCA one.
>
> I don't see how a default binding is useful - a user will either be
> decoupled and use physical bindings, or they will have a SCA system that
> would use wires.
>
>>
>> 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.
>
> I think this is a problematic scenario now that we have the recursive
> model. This may have made sense with the old module concept but by
> embedding address information in a composite you prevent its reuse. One
> of the main objectives of the composite change was to allow that by
> treating composites as types rather than instances and as such they
> should not have such instance-related information.
>
> There is a case for absolute references to non-SCA resources but those
> would be associated with real bindings to those services (e.g. via WS or
> JMS). Within the SCA domain though the connection should be done with
> wires and so there is no need for a non-interoperable binding.
>
>>
>> - 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).
>
> Why would someone use a non-interoperable default binding for that when
> they can override with a wire? The SCA system can do more optimization
> with a wire where it has information on both ends than it can with a
> binding where it only knows one side.
>
>>
>> - 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.
>
> What does it mean to make a service available through the default
> binding? It can't be used to talk to non-SCA services or with other SCA
> implementations and within a single SCA domain the service is there to be
> wired.
>
> I would actually be very concerned if by adding a <binding.sca> element
> to a service users were able to bypass the wiring and connection model of
> the assembly spec and break the encapsulation a composite is meant to
> provide.
>
>> There's probably more use cases, but I hope this helps. Maybe other spec
>> people can also give us their perspective on this?
>
> Thanks for providing them and I think it helps discussion. I haven't seen
> though that there is anything so far can cannot be addressed through the
> SCA wiring model or through physical bindings when interop is required. I
> would suggest we are better off keeping the model consistent and so
> should consider dropping the concepts of default binding and
> <binding.sca> entirely.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Why do we need binding.sca?
Posted by Jeremy Boynes <jb...@apache.org>.
On Sep 24, 2006, at 9:32 PM, Jean-Sebastien Delfino wrote:
>
> 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.
How does that differ from a wire?
> 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).
The lack of interop here is one of the reasons that I think this is
problematic. We can't interop with non-SCA services as to do that we
need to know the protocol etc. they use - IOW we need a specific
binding like WS. We can't interop with other SCA systems unless they
happen to use the same default; SCA is designed for large-scale
heterogeneous systems and they are not likely to use the same default
and so to interop between them the user will either need to specify a
wire (if they are centrally administered) or use a physical binding
as if the other side was a non-SCA one.
I don't see how a default binding is useful - a user will either be
decoupled and use physical bindings, or they will have a SCA system
that would use wires.
>
> 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.
I think this is a problematic scenario now that we have the recursive
model. This may have made sense with the old module concept but by
embedding address information in a composite you prevent its reuse.
One of the main objectives of the composite change was to allow that
by treating composites as types rather than instances and as such
they should not have such instance-related information.
There is a case for absolute references to non-SCA resources but
those would be associated with real bindings to those services (e.g.
via WS or JMS). Within the SCA domain though the connection should be
done with wires and so there is no need for a non-interoperable binding.
>
> - 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).
Why would someone use a non-interoperable default binding for that
when they can override with a wire? The SCA system can do more
optimization with a wire where it has information on both ends than
it can with a binding where it only knows one side.
>
> - 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.
What does it mean to make a service available through the default
binding? It can't be used to talk to non-SCA services or with other
SCA implementations and within a single SCA domain the service is
there to be wired.
I would actually be very concerned if by adding a <binding.sca>
element to a service users were able to bypass the wiring and
connection model of the assembly spec and break the encapsulation a
composite is meant to provide.
> There's probably more use cases, but I hope this helps. Maybe other
> spec people can also give us their perspective on this?
Thanks for providing them and I think it helps discussion. I haven't
seen though that there is anything so far can cannot be addressed
through the SCA wiring model or through physical bindings when
interop is required. I would suggest we are better off keeping the
model consistent and so should consider dropping the concepts of
default binding and <binding.sca> entirely.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Why do we need binding.sca?
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Why do we need binding.sca?
Posted by Jeremy Boynes <jb...@apache.org>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Why do we need binding.sca?, was: [C++] Should the SCA binding
reuse the Web Service binding code
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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.
>
> --
> Jeremy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
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>?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org