You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Meeraj Kunnumpurath <M....@voca.com> on 2006/08/15 13:48:11 UTC
RE: Create distribution for bindings, or how to switch binding
implementations
Jervis,
Few thoughts ...
I think flexibility and ease of use is important in terms of switching
between bindings, not just two implementations of the same transport
(for example axis and XFire for WS binding), but also between two
different transports (WS and JMS for example). With one of the ESBs I
have been using it is as simple as switching the protocol in the
endpoint URI for the target component. For example, you can switch
between Axis to XFire, by changing the endpoint URI of the component
from axis:http://localhost:81/services to
xfire:http://localhost:81/services, and if you want to switch from WS to
JMS, it is as simple as changing the URI to jms://myQueue. I think the
gist is providing the flexibility to expose the services over a variety
of transports, even more than one if that is deemed necessary. According
to my understanding this issues are all addressed by the SCA spec.
I think the spec mandates support for SCA and web services bindings and
talks about having extensibility mechanisms for other kinds of bindings.
Though it should be possible to expose services across multiple
bindings, multiple implementations of the same transport (XFire and Axis
for example) wouldn't make much sense, as the implementation type itself
is transparent to the service consumer, unless different ports are used
by the different bindings. I think, may be the issue is the mandatory
binding binding.ws from the spec perspective. You could look at
binding.ws as the default WS binding used by the SCA runtime
implementation (using axis for example) and to use a different WS
binding one could use the extension model and have a binding like
binding.ws.xfire.
Ta
Meeraj
-----Original Message-----
From: Liu, Jervis [mailto:jliu@iona.com]
Sent: 15 August 2006 03:56
To: tuscany-dev@ws.apache.org
Subject: Create distribution for bindings, or how to switch binding
implementations
Hi,
I can see from yesterday's IRC chat that we had a quick discussion on
how to create distribution for bindings. I think the main problem we are
facing is how to switch binding implementations. For example, we may
want to switch the implementation of binding.ws between axis2 and celtix
for helloworldws sample, in an easy and user friendly way. The approach
Jeremy proposed should work: package the binding as an extension and
somehow install it into the runtime(put it into the extension dir?) . So
this is definitely one option. But I think we should also provide
alternatives to better address following scenarios:
1, Tuscany users installed a generic Tuscany distribution, and they
would like to be able to switch binding implementations without moving
libraries around or changing any directories. I think we can improve
usability if users only need to change a config file.
2. Some applications may want to use two binding implementations at the
same time.
It seems to me that we will need a configuration somewhere to specify
the specific binding implementation. Can we have a proprietary entry in
scdl file sth like <binging.ws.axis2/> or <binding.ws
bindingImplementation=axis/>? Any comments are welcome. To better track
this thread, I have created jira 621.
https://issues.apache.org/jira/browse/TUSCANY-621. I also enclosed
relevant IRC chat log for your info.
Thanks,
Jervis
(05:27:47) cr22rc: jboynes : I'm ok about taking it out .. but what are
we looking for doing for samples needing axis wsbservice binding
(05:28:44) jboynes: I want to package the axis binding as an extension
that can be installed in the runtime
(05:29:46) jboynes: so to run the sample you add the axis extension to
your installation
(05:30:43) ant: or we may have a distribution that includes axis right?
(05:31:03) jboynes: sure
(05:32:32) jboynes: I want to make sure that the basic concept (core + a
bunch of extensions) works
(05:33:19) kgoodson left the room (quit: Read error: 110 (Connection
timed out)).
(05:33:23) ant: could we talk about the ServletHost stuff now?
(05:33:33) jboynes: so we don't end up in a situation where an extension
only works if it is packed into a distro in a special way
(05:33:40) jboynes: I need a couple more
(05:33:48) jboynes: I need to eat
(05:35:32) ant: ok, well ping when you're ready
(05:48:04) jboynes: ant: hi, better now I've had breakfast :)
(05:48:30) ant: yum
(05:48:31) jboynes: sorry for holding things up - I just reached the
pass out or get cranky phase
(05:48:48) dkulp left the room (quit: "using sirc version
2.211+KSIRC/1.3.12").
(05:49:19) ant: ok so there's an interface ServletHost
(05:50:02) jboynes: yep
(05:50:10) ant: so the WS binding should use that to register a servlet
for each ws endpoint
This message has been checked for all email viruses by MessageLabs.
*****************************************************
You can find us at www.voca.com
*****************************************************
This communication is confidential and intended for
the exclusive use of the addressee only. You should
not disclose its contents to any other person.
If you are not the intended recipient please notify
the sender named above immediately.
Registered in England, No 1023742,
Registered Office: Voca Limited
Drake House, Three Rivers Court,
Homestead Road, Rickmansworth,
Hertfordshire, WD3 1FX
This message has been checked for all email viruses by MessageLabs.
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Create distribution for bindings, or how to switch binding implementations
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 15, 2006, at 4:48 AM, Meeraj Kunnumpurath wrote:
> Jervis,
>
> Few thoughts ...
>
> I think flexibility and ease of use is important in terms of switching
> between bindings, not just two implementations of the same transport
> (for example axis and XFire for WS binding), but also between two
> different transports (WS and JMS for example). With one of the ESBs I
> have been using it is as simple as switching the protocol in the
> endpoint URI for the target component. For example, you can switch
> between Axis to XFire, by changing the endpoint URI of the component
> from axis:http://localhost:81/services to
> xfire:http://localhost:81/services, and if you want to switch from
> WS to
> JMS, it is as simple as changing the URI to jms://myQueue. I think the
> gist is providing the flexibility to expose the services over a
> variety
> of transports, even more than one if that is deemed necessary.
> According
> to my understanding this issues are all addressed by the SCA spec.
>
Yes this is exactly what the spec aims at and what I think is one of
its main values. Sometimes it can be tricky, for example, not
extending Remote in RMI.
> I think the spec mandates support for SCA and web services bindings
> and
> talks about having extensibility mechanisms for other kinds of
> bindings.
> Though it should be possible to expose services across multiple
> bindings, multiple implementations of the same transport (XFire and
> Axis
> for example) wouldn't make much sense, as the implementation type
> itself
> is transparent to the service consumer, unless different ports are
> used
> by the different bindings. I think, may be the issue is the mandatory
> binding binding.ws from the spec perspective.
There are probably two levels from the spec perspective. SCA doesn't
mandate the use of web services but there is a specified web services
binding for people that want to use web services with SCA.
> You could look at
> binding.ws as the default WS binding used by the SCA runtime
> implementation (using axis for example) and to use a different WS
> binding one could use the extension model and have a binding like
> binding.ws.xfire.
>
> Ta
> Meeraj
>
> -----Original Message-----
> From: Liu, Jervis [mailto:jliu@iona.com]
> Sent: 15 August 2006 03:56
> To: tuscany-dev@ws.apache.org
> Subject: Create distribution for bindings, or how to switch binding
> implementations
>
> Hi,
>
> I can see from yesterday's IRC chat that we had a quick discussion on
> how to create distribution for bindings. I think the main problem
> we are
> facing is how to switch binding implementations. For example, we may
> want to switch the implementation of binding.ws between axis2 and
> celtix
> for helloworldws sample, in an easy and user friendly way. The
> approach
> Jeremy proposed should work: package the binding as an extension and
> somehow install it into the runtime(put it into the extension
> dir?) . So
> this is definitely one option. But I think we should also provide
> alternatives to better address following scenarios:
>
> 1, Tuscany users installed a generic Tuscany distribution, and they
> would like to be able to switch binding implementations without moving
> libraries around or changing any directories. I think we can improve
> usability if users only need to change a config file.
>
> 2. Some applications may want to use two binding implementations at
> the
> same time.
>
> It seems to me that we will need a configuration somewhere to specify
> the specific binding implementation. Can we have a proprietary
> entry in
> scdl file sth like <binging.ws.axis2/> or <binding.ws
> bindingImplementation=axis/>? Any comments are welcome. To better
> track
> this thread, I have created jira 621.
> https://issues.apache.org/jira/browse/TUSCANY-621. I also enclosed
> relevant IRC chat log for your info.
>
> Thanks,
> Jervis
>
> (05:27:47) cr22rc: jboynes : I'm ok about taking it out .. but what
> are
> we looking for doing for samples needing axis wsbservice binding
> (05:28:44) jboynes: I want to package the axis binding as an extension
> that can be installed in the runtime
> (05:29:46) jboynes: so to run the sample you add the axis extension to
> your installation
> (05:30:43) ant: or we may have a distribution that includes axis
> right?
> (05:31:03) jboynes: sure
> (05:32:32) jboynes: I want to make sure that the basic concept
> (core + a
> bunch of extensions) works
> (05:33:19) kgoodson left the room (quit: Read error: 110 (Connection
> timed out)).
> (05:33:23) ant: could we talk about the ServletHost stuff now?
> (05:33:33) jboynes: so we don't end up in a situation where an
> extension
> only works if it is packed into a distro in a special way
> (05:33:40) jboynes: I need a couple more
> (05:33:48) jboynes: I need to eat
> (05:35:32) ant: ok, well ping when you're ready
> (05:48:04) jboynes: ant: hi, better now I've had breakfast :)
> (05:48:30) ant: yum
> (05:48:31) jboynes: sorry for holding things up - I just reached the
> pass out or get cranky phase
> (05:48:48) dkulp left the room (quit: "using sirc version
> 2.211+KSIRC/1.3.12").
> (05:49:19) ant: ok so there's an interface ServletHost
> (05:50:02) jboynes: yep
> (05:50:10) ant: so the WS binding should use that to register a
> servlet
> for each ws endpoint
>
>
> This message has been checked for all email viruses by MessageLabs.
>
>
>
> *****************************************************
>
> You can find us at www.voca.com
>
> *****************************************************
> This communication is confidential and intended for
> the exclusive use of the addressee only. You should
> not disclose its contents to any other person.
> If you are not the intended recipient please notify
> the sender named above immediately.
>
> Registered in England, No 1023742,
> Registered Office: Voca Limited
> Drake House, Three Rivers Court,
> Homestead Road, Rickmansworth,
> Hertfordshire, WD3 1FX
>
>
> This message has been checked for all email viruses by MessageLabs.
>
> ---------------------------------------------------------------------
> 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