Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
+1 I forwarded to the Assembly WG lead. The intention was (as you said): HelloWorldComponent is just a shortcut of HelloWorldServiceComponent/HelloWorldService if HelloWorldService is the only service. Dave - Original Message - From: Raymond Feng [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Wednesday, May 30, 2007 2:10 AM Subject: Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample Hi, I don't think the spec is clear about the case that a component with a single service. Line 2375: Where a component has only a single service, the default value of the Service Binding URI is null, so that the effective URI is: Base Domain URI for a scheme / Component URI IMO, this contradicts with the statement in Line 2316: For a binding of a service the URI attribute defines the URI relative to the component which contributes the service to the SCA domain. The default value for the URI is the the value of the name attribute of the binding. Further more, it creates inconsistency for the client side to figure out the endpoint address of the target service. For example, the client side only knows that HelloWorldServiceComponent provides the HelloWorldService and it doesn't care if HelloWorldServiceComponent provides other services or not. But now the client is required to have such knowledge to tell the endpoint address of HelloWorldServiceComponent/HelloWorldService. To me, HelloWorldComponent is just a shortcut of HelloWorldServiceComponent/HelloWorldService if HelloWorldService is the only service. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, May 29, 2007 10:49 PM Subject: Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample My understanding of the spec is the following: - independent of whether or not a service is promoted, a service is offered by a component - if a component has only one service then the default URI is base domain URI / component-name - I haven't seen a statement in the spec saying that the service should also be available at base domain URI / component name / service name in this case. That leaves us with a single URI, which should be the same in both cases (whether the service is promoted or not): http://localhost:8080/HelloWorldServiceComponent ant elder wrote: I'm not sure if you're saying its wrong or right that the endpoint is changing in the helloworld example? ...ant On 5/25/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Here is my understanding of the Spec about the URI for a service binding: Let's assume that we have the following declaration: component: c1 service: s1 binding: name=b1 uri=uri1 binding: name=b2 binding: If the base URI for http is http://localhost:8080/;, the URIs for the three bindings for component c1 will be: http://localhost:8080/c1/uri1 (uri attr is used) http://localhost:8080/c1/b2 (uri is default to the name of the binding, I'm not sure why the spec says the name is a QName) http://localhost:8080/c1/s1 (uri is default to the name of the binding which is default to the name of service) If s1 is the only service for c1 and s1 only has one binding, I assume the following uri is also available (in addation to the explicit one): http://localhost:8080/c1 Do you agree? Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, May 25, 2007 3:34 AM Subject: Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample On 5/17/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: scabooz wrote: Sebastien, I have a slightly different perspective, inline below. Dave snip 2) What is the point of promoting it anyway? It seems the only point of promoting it would be to allow this Composite to serve as the impl for another component. Since we don't do that in this simple sample, doesn't it just add confusion? It seems to be the SCDL should look something like this, ideally: component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldServiceComponent/ reference name=helloWorldService binding.ws wsdlElement= http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort) / /reference /component What you're proposing is correct, but I think that the best practice should be to promote services and references that use bindings and go out of an SCA domain, to allow their bindings and endpoints to be reconfigured at deployment time, by using a deployment composite for example. The spec introduced the ability to put bindings on component services and references. For top level components, that's where the bindings
Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
The problem is when the service is promoted the way the Tuscany runtime works is that the RuntimeComponent gets an additional service added (named with $promoted$. prefix) so then at line 196 in the Axis2ServiceBindingProvider this is taken to mean the binding name should be added to the URI even though there really is only the one service. Seems a bit hacky for the Axis2 binding to ignore service names starting with $promoted$. so how else could this be fixed? Should most of the code in the computeActualURI be moved to the runtime somewhere? ...ant On 5/30/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: My understanding of the spec is the following: - independent of whether or not a service is promoted, a service is offered by a component - if a component has only one service then the default URI is base domain URI / component-name - I haven't seen a statement in the spec saying that the service should also be available at base domain URI / component name / service name in this case. That leaves us with a single URI, which should be the same in both cases (whether the service is promoted or not): http://localhost:8080/HelloWorldServiceComponent ant elder wrote: I'm not sure if you're saying its wrong or right that the endpoint is changing in the helloworld example? ...ant On 5/25/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Here is my understanding of the Spec about the URI for a service binding: Let's assume that we have the following declaration: component: c1 service: s1 binding: name=b1 uri=uri1 binding: name=b2 binding: If the base URI for http is http://localhost:8080/;, the URIs for the three bindings for component c1 will be: http://localhost:8080/c1/uri1 (uri attr is used) http://localhost:8080/c1/b2 (uri is default to the name of the binding, I'm not sure why the spec says the name is a QName) http://localhost:8080/c1/s1 (uri is default to the name of the binding which is default to the name of service) If s1 is the only service for c1 and s1 only has one binding, I assume the following uri is also available (in addation to the explicit one): http://localhost:8080/c1 Do you agree? Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, May 25, 2007 3:34 AM Subject: Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample On 5/17/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: scabooz wrote: Sebastien, I have a slightly different perspective, inline below. Dave snip 2) What is the point of promoting it anyway? It seems the only point of promoting it would be to allow this Composite to serve as the impl for another component. Since we don't do that in this simple sample, doesn't it just add confusion? It seems to be the SCDL should look something like this, ideally: component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldServiceComponent/ reference name=helloWorldService binding.ws wsdlElement= http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort) http://helloworld#wsdl.port%28HelloWorldService/HelloWorldSoapPort%29 / /reference /component What you're proposing is correct, but I think that the best practice should be to promote services and references that use bindings and go out of an SCA domain, to allow their bindings and endpoints to be reconfigured at deployment time, by using a deployment composite for example. The spec introduced the ability to put bindings on component services and references. For top level components, that's where the bindings should go (IMHO) as a best practice. Promoted services and references don't really have a meaning when a composite is included (which is what happens at deployment). Just seems like extra baggage to me. I think it will be clear when a composite is developed, whether or not it is intended to be deployed or used as an implementation. Your perspective makes the assumption that all composites might one day be used as an implementation. I am taking the opposite position. None of this is critical, as both are supported...just makes for good discussion. snip The initial intent was to allow services and references to be reconfigured at deployment time. This confuses me a bit, but I think that there are multiple ways to do this: (1) Initially declare composite services/references, and instead of including the composite directly in the domain, use your composite as the implementation of a component in another composite, and override the service/reference configuration on that new component. (2) Initially specify the
Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
Hi, I don't think the spec is clear about the case that a component with a single service. Line 2375: Where a component has only a single service, the default value of the Service Binding URI is null, so that the effective URI is: Base Domain URI for a scheme / Component URI IMO, this contradicts with the statement in Line 2316: For a binding of a service the URI attribute defines the URI relative to the component which contributes the service to the SCA domain. The default value for the URI is the the value of the name attribute of the binding. Further more, it creates inconsistency for the client side to figure out the endpoint address of the target service. For example, the client side only knows that HelloWorldServiceComponent provides the HelloWorldService and it doesn't care if HelloWorldServiceComponent provides other services or not. But now the client is required to have such knowledge to tell the endpoint address of HelloWorldServiceComponent/HelloWorldService. To me, HelloWorldComponent is just a shortcut of HelloWorldServiceComponent/HelloWorldService if HelloWorldService is the only service. Thanks, Raymond - Original Message - From: Jean-Sebastien Delfino [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Tuesday, May 29, 2007 10:49 PM Subject: Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample My understanding of the spec is the following: - independent of whether or not a service is promoted, a service is offered by a component - if a component has only one service then the default URI is base domain URI / component-name - I haven't seen a statement in the spec saying that the service should also be available at base domain URI / component name / service name in this case. That leaves us with a single URI, which should be the same in both cases (whether the service is promoted or not): http://localhost:8080/HelloWorldServiceComponent ant elder wrote: I'm not sure if you're saying its wrong or right that the endpoint is changing in the helloworld example? ...ant On 5/25/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Here is my understanding of the Spec about the URI for a service binding: Let's assume that we have the following declaration: component: c1 service: s1 binding: name=b1 uri=uri1 binding: name=b2 binding: If the base URI for http is http://localhost:8080/;, the URIs for the three bindings for component c1 will be: http://localhost:8080/c1/uri1 (uri attr is used) http://localhost:8080/c1/b2 (uri is default to the name of the binding, I'm not sure why the spec says the name is a QName) http://localhost:8080/c1/s1 (uri is default to the name of the binding which is default to the name of service) If s1 is the only service for c1 and s1 only has one binding, I assume the following uri is also available (in addation to the explicit one): http://localhost:8080/c1 Do you agree? Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, May 25, 2007 3:34 AM Subject: Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample On 5/17/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: scabooz wrote: Sebastien, I have a slightly different perspective, inline below. Dave snip 2) What is the point of promoting it anyway? It seems the only point of promoting it would be to allow this Composite to serve as the impl for another component. Since we don't do that in this simple sample, doesn't it just add confusion? It seems to be the SCDL should look something like this, ideally: component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldServiceComponent/ reference name=helloWorldService binding.ws wsdlElement= http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort) / /reference /component What you're proposing is correct, but I think that the best practice should be to promote services and references that use bindings and go out of an SCA domain, to allow their bindings and endpoints to be reconfigured at deployment time, by using a deployment composite for example. The spec introduced the ability to put bindings on component services and references. For top level components, that's where the bindings should go (IMHO) as a best practice. Promoted services and references don't really have a meaning when a composite is included (which is what happens at deployment). Just seems like extra baggage to me. I think it will be clear when a composite is developed, whether or not it is intended to be deployed or used as an implementation. Your perspective makes the assumption that all composites might one day be used as an implementation. I am taking
Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
A few more comments and ideas. [snip] scabooz wrote: +1 to Scott's point. The spec does not assert that services are only available outside of a Domain when they are promoted as composite level services. Dave - Original Message - From: Scott Kurz [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, May 17, 2007 3:51 PM Subject: Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample Sebastien, I'm interested how it would matter whether you promoted it or not? If you have a non-default binding on a component-level service that it is visible to the world already.And I thought the default binding was not intended to allow you to cross domain boundaries. Yes, a service on a top level component, with a non-default binding is visible outside the domain. I don't have an issue with this case. That pattern is supported and I have modified the HelloWorldWS sample to use it. I have issues with the use of bindings on services offered by components in nested composites, but that's probably a different discussion... The deployed composite which contributed this component to the domain can be updated if you wish to modify the deployed component (so you don't need the domain composite level service to do so). I'm not sure I understand what you're proposing to update the composite containing the component and its service and binding declarations. Are you talking about using a deployment composite as described in the spec in 1.10.4.2 add Deployment Composite update Deployment Composite or are you thinking about opening the SCA contribution, changing the composite inside the contribution, and updating/reinstalling it as described in 1.10.4.1 install Contribution update Contribution? -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
My understanding of the spec is the following: - independent of whether or not a service is promoted, a service is offered by a component - if a component has only one service then the default URI is base domain URI / component-name - I haven't seen a statement in the spec saying that the service should also be available at base domain URI / component name / service name in this case. That leaves us with a single URI, which should be the same in both cases (whether the service is promoted or not): http://localhost:8080/HelloWorldServiceComponent ant elder wrote: I'm not sure if you're saying its wrong or right that the endpoint is changing in the helloworld example? ...ant On 5/25/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Here is my understanding of the Spec about the URI for a service binding: Let's assume that we have the following declaration: component: c1 service: s1 binding: name=b1 uri=uri1 binding: name=b2 binding: If the base URI for http is http://localhost:8080/;, the URIs for the three bindings for component c1 will be: http://localhost:8080/c1/uri1 (uri attr is used) http://localhost:8080/c1/b2 (uri is default to the name of the binding, I'm not sure why the spec says the name is a QName) http://localhost:8080/c1/s1 (uri is default to the name of the binding which is default to the name of service) If s1 is the only service for c1 and s1 only has one binding, I assume the following uri is also available (in addation to the explicit one): http://localhost:8080/c1 Do you agree? Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, May 25, 2007 3:34 AM Subject: Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample On 5/17/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: scabooz wrote: Sebastien, I have a slightly different perspective, inline below. Dave snip 2) What is the point of promoting it anyway? It seems the only point of promoting it would be to allow this Composite to serve as the impl for another component. Since we don't do that in this simple sample, doesn't it just add confusion? It seems to be the SCDL should look something like this, ideally: component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldServiceComponent/ reference name=helloWorldService binding.ws wsdlElement= http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort) / /reference /component What you're proposing is correct, but I think that the best practice should be to promote services and references that use bindings and go out of an SCA domain, to allow their bindings and endpoints to be reconfigured at deployment time, by using a deployment composite for example. The spec introduced the ability to put bindings on component services and references. For top level components, that's where the bindings should go (IMHO) as a best practice. Promoted services and references don't really have a meaning when a composite is included (which is what happens at deployment). Just seems like extra baggage to me. I think it will be clear when a composite is developed, whether or not it is intended to be deployed or used as an implementation. Your perspective makes the assumption that all composites might one day be used as an implementation. I am taking the opposite position. None of this is critical, as both are supported...just makes for good discussion. snip The initial intent was to allow services and references to be reconfigured at deployment time. This confuses me a bit, but I think that there are multiple ways to do this: (1) Initially declare composite services/references, and instead of including the composite directly in the domain, use your composite as the implementation of a component in another composite, and override the service/reference configuration on that new component. (2) Initially specify the bindings directly on your component services/references. To reconfigure them you'll need to include your composite in another composite, and specify your service/reference configuration in new composite services/references in that new composite. Option 1 has the side effect of hiding the internal structure of your composite, but it may be OK in cases like HelloWorld or our Calculator sample, where you would expose only the Calculator service and hide the other service components. Option 2 allows you to keep all your components at the domain level, but won't allow you to rewire a reference if it was wired in the original composite (unless I'm missing something). The samples do not demonstrate any of this rewiring anyway, so we can change:
Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
I'm not sure if you're saying its wrong or right that the endpoint is changing in the helloworld example? ...ant On 5/25/07, Raymond Feng [EMAIL PROTECTED] wrote: Hi, Here is my understanding of the Spec about the URI for a service binding: Let's assume that we have the following declaration: component: c1 service: s1 binding: name=b1 uri=uri1 binding: name=b2 binding: If the base URI for http is http://localhost:8080/;, the URIs for the three bindings for component c1 will be: http://localhost:8080/c1/uri1 (uri attr is used) http://localhost:8080/c1/b2 (uri is default to the name of the binding, I'm not sure why the spec says the name is a QName) http://localhost:8080/c1/s1 (uri is default to the name of the binding which is default to the name of service) If s1 is the only service for c1 and s1 only has one binding, I assume the following uri is also available (in addation to the explicit one): http://localhost:8080/c1 Do you agree? Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, May 25, 2007 3:34 AM Subject: Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample On 5/17/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: scabooz wrote: Sebastien, I have a slightly different perspective, inline below. Dave snip 2) What is the point of promoting it anyway? It seems the only point of promoting it would be to allow this Composite to serve as the impl for another component. Since we don't do that in this simple sample, doesn't it just add confusion? It seems to be the SCDL should look something like this, ideally: component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldServiceComponent/ reference name=helloWorldService binding.ws wsdlElement= http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort) / /reference /component What you're proposing is correct, but I think that the best practice should be to promote services and references that use bindings and go out of an SCA domain, to allow their bindings and endpoints to be reconfigured at deployment time, by using a deployment composite for example. The spec introduced the ability to put bindings on component services and references. For top level components, that's where the bindings should go (IMHO) as a best practice. Promoted services and references don't really have a meaning when a composite is included (which is what happens at deployment). Just seems like extra baggage to me. I think it will be clear when a composite is developed, whether or not it is intended to be deployed or used as an implementation. Your perspective makes the assumption that all composites might one day be used as an implementation. I am taking the opposite position. None of this is critical, as both are supported...just makes for good discussion. snip The initial intent was to allow services and references to be reconfigured at deployment time. This confuses me a bit, but I think that there are multiple ways to do this: (1) Initially declare composite services/references, and instead of including the composite directly in the domain, use your composite as the implementation of a component in another composite, and override the service/reference configuration on that new component. (2) Initially specify the bindings directly on your component services/references. To reconfigure them you'll need to include your composite in another composite, and specify your service/reference configuration in new composite services/references in that new composite. Option 1 has the side effect of hiding the internal structure of your composite, but it may be OK in cases like HelloWorld or our Calculator sample, where you would expose only the Calculator service and hide the other service components. Option 2 allows you to keep all your components at the domain level, but won't allow you to rewire a reference if it was wired in the original composite (unless I'm missing something). The samples do not demonstrate any of this rewiring anyway, so we can change: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws service name=HelloWorldService promote=HelloWorldServiceComponent interface.wsdl interface=http://helloworld#wsdl.interface(HelloWorld) / binding.ws / /service component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldImpl / /component /composite to composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld;
Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
On 5/17/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: scabooz wrote: Sebastien, I have a slightly different perspective, inline below. Dave snip 2) What is the point of promoting it anyway? It seems the only point of promoting it would be to allow this Composite to serve as the impl for another component. Since we don't do that in this simple sample, doesn't it just add confusion? It seems to be the SCDL should look something like this, ideally: component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldServiceComponent/ reference name=helloWorldService binding.ws wsdlElement= http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort)/ /reference /component What you're proposing is correct, but I think that the best practice should be to promote services and references that use bindings and go out of an SCA domain, to allow their bindings and endpoints to be reconfigured at deployment time, by using a deployment composite for example. The spec introduced the ability to put bindings on component services and references. For top level components, that's where the bindings should go (IMHO) as a best practice. Promoted services and references don't really have a meaning when a composite is included (which is what happens at deployment). Just seems like extra baggage to me. I think it will be clear when a composite is developed, whether or not it is intended to be deployed or used as an implementation. Your perspective makes the assumption that all composites might one day be used as an implementation. I am taking the opposite position. None of this is critical, as both are supported...just makes for good discussion. snip The initial intent was to allow services and references to be reconfigured at deployment time. This confuses me a bit, but I think that there are multiple ways to do this: (1) Initially declare composite services/references, and instead of including the composite directly in the domain, use your composite as the implementation of a component in another composite, and override the service/reference configuration on that new component. (2) Initially specify the bindings directly on your component services/references. To reconfigure them you'll need to include your composite in another composite, and specify your service/reference configuration in new composite services/references in that new composite. Option 1 has the side effect of hiding the internal structure of your composite, but it may be OK in cases like HelloWorld or our Calculator sample, where you would expose only the Calculator service and hide the other service components. Option 2 allows you to keep all your components at the domain level, but won't allow you to rewire a reference if it was wired in the original composite (unless I'm missing something). The samples do not demonstrate any of this rewiring anyway, so we can change: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws service name=HelloWorldService promote=HelloWorldServiceComponent interface.wsdl interface=http://helloworld#wsdl.interface(HelloWorld) / binding.ws / /service component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldImpl / /component /composite to composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws component name=HelloWorldServiceComponent service name=HelloWorldService interface.wsdl interface=http://helloworld#wsdl.interface(HelloWorld) / binding.ws / /service implementation.java class=helloworld.HelloWorldImpl / /component /composite ... which is slightly simpler. I made that change in revision r538384. Dave, Going back to this This new form is slightly more compact as we save a promote=... attribute, but we could also take a different view here and say: - HelloWorldService is made visible as a Web service outside the SCA domain, - So the best practice is to promote it outside of the domain composite, using a composite service. That's the initial form we had (see the assembly XML above), which triggered that discussion. The second form, with the Web Service binding on the component/service would be used to configure services used only inside the domain. HelloWorld can probably accomodate both :) and both forms work with the latest Tuscany runtime. I'd be interested to get thoughts on this, as I'd like our samples to help promote the best practices. -- Jean-Sebastien One practical significance of this with the Tuscany runtime is that the service endpoint url changes depending on which of these is used. The WS endpoint url
Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
Hi, Here is my understanding of the Spec about the URI for a service binding: Let's assume that we have the following declaration: component: c1 service: s1 binding: name=b1 uri=uri1 binding: name=b2 binding: If the base URI for http is http://localhost:8080/;, the URIs for the three bindings for component c1 will be: http://localhost:8080/c1/uri1 (uri attr is used) http://localhost:8080/c1/b2 (uri is default to the name of the binding, I'm not sure why the spec says the name is a QName) http://localhost:8080/c1/s1 (uri is default to the name of the binding which is default to the name of service) If s1 is the only service for c1 and s1 only has one binding, I assume the following uri is also available (in addation to the explicit one): http://localhost:8080/c1 Do you agree? Thanks, Raymond - Original Message - From: ant elder [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Friday, May 25, 2007 3:34 AM Subject: Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample On 5/17/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: scabooz wrote: Sebastien, I have a slightly different perspective, inline below. Dave snip 2) What is the point of promoting it anyway? It seems the only point of promoting it would be to allow this Composite to serve as the impl for another component. Since we don't do that in this simple sample, doesn't it just add confusion? It seems to be the SCDL should look something like this, ideally: component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldServiceComponent/ reference name=helloWorldService binding.ws wsdlElement= http://helloworld#wsdl.port(HelloWorldService/HelloWorldSoapPort)/ /reference /component What you're proposing is correct, but I think that the best practice should be to promote services and references that use bindings and go out of an SCA domain, to allow their bindings and endpoints to be reconfigured at deployment time, by using a deployment composite for example. The spec introduced the ability to put bindings on component services and references. For top level components, that's where the bindings should go (IMHO) as a best practice. Promoted services and references don't really have a meaning when a composite is included (which is what happens at deployment). Just seems like extra baggage to me. I think it will be clear when a composite is developed, whether or not it is intended to be deployed or used as an implementation. Your perspective makes the assumption that all composites might one day be used as an implementation. I am taking the opposite position. None of this is critical, as both are supported...just makes for good discussion. snip The initial intent was to allow services and references to be reconfigured at deployment time. This confuses me a bit, but I think that there are multiple ways to do this: (1) Initially declare composite services/references, and instead of including the composite directly in the domain, use your composite as the implementation of a component in another composite, and override the service/reference configuration on that new component. (2) Initially specify the bindings directly on your component services/references. To reconfigure them you'll need to include your composite in another composite, and specify your service/reference configuration in new composite services/references in that new composite. Option 1 has the side effect of hiding the internal structure of your composite, but it may be OK in cases like HelloWorld or our Calculator sample, where you would expose only the Calculator service and hide the other service components. Option 2 allows you to keep all your components at the domain level, but won't allow you to rewire a reference if it was wired in the original composite (unless I'm missing something). The samples do not demonstrate any of this rewiring anyway, so we can change: composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws service name=HelloWorldService promote=HelloWorldServiceComponent interface.wsdl interface=http://helloworld#wsdl.interface(HelloWorld) / binding.ws / /service component name=HelloWorldServiceComponent implementation.java class=helloworld.HelloWorldImpl / /component /composite to composite xmlns=http://www.osoa.org/xmlns/sca/1.0; targetNamespace=http://helloworld; xmlns:hw=http://helloworld; name=helloworldws component name=HelloWorldServiceComponent service name=HelloWorldService interface.wsdl interface=http://helloworld#wsdl.interface(HelloWorld) / binding.ws / /service
Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
+1 to Scott's point. The spec does not assert that services are only available outside of a Domain when they are promoted as composite level services. Dave - Original Message - From: Scott Kurz [EMAIL PROTECTED] To: tuscany-dev@ws.apache.org Sent: Thursday, May 17, 2007 3:51 PM Subject: Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample Sebastien, I'm interested how it would matter whether you promoted it or not? If you have a non-default binding on a component-level service that it is visible to the world already.And I thought the default binding was not intended to allow you to cross domain boundaries. The deployed composite which contributed this component to the domain can be updated if you wish to modify the deployed component (so you don't need the domain composite level service to do so). What did you have in mind? Scott On 5/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Dave, Going back to this This new form is slightly more compact as we save a promote=... attribute, but we could also take a different view here and say: - HelloWorldService is made visible as a Web service outside the SCA domain, - So the best practice is to promote it outside of the domain composite, using a composite service. That's the initial form we had (see the assembly XML above), which triggered that discussion. The second form, with the Web Service binding on the component/service would be used to configure services used only inside the domain. HelloWorld can probably accomodate both :) and both forms work with the latest Tuscany runtime. I'd be interested to get thoughts on this, as I'd like our samples to help promote the best practices. -- Jean-Sebastien - 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]
Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
Sebastien, I'm interested how it would matter whether you promoted it or not? If you have a non-default binding on a component-level service that it is visible to the world already.And I thought the default binding was not intended to allow you to cross domain boundaries. The deployed composite which contributed this component to the domain can be updated if you wish to modify the deployed component (so you don't need the domain composite level service to do so). What did you have in mind? Scott On 5/16/07, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Jean-Sebastien Delfino wrote: Dave, Going back to this This new form is slightly more compact as we save a promote=... attribute, but we could also take a different view here and say: - HelloWorldService is made visible as a Web service outside the SCA domain, - So the best practice is to promote it outside of the domain composite, using a composite service. That's the initial form we had (see the assembly XML above), which triggered that discussion. The second form, with the Web Service binding on the component/service would be used to configure services used only inside the domain. HelloWorld can probably accomodate both :) and both forms work with the latest Tuscany runtime. I'd be interested to get thoughts on this, as I'd like our samples to help promote the best practices. -- Jean-Sebastien - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
