You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Scott Kurz <sc...@gmail.com> on 2007/05/07 15:52:27 UTC
A few issues with HelloWorld WS sample
I was looking over the HWWS/HWWSclient sample pair, and had the following
observations/questions:
1) For helloworld-wsclient, the HelloWorldServiceComponent does not use the
@Reference annotation. So, according to the Java Component Impl spec, Sec
1.2.7,
shouldn't we, during introspection, calculate the helloWorldService to
represent a Property, not a Reference? Yet we promote it to a
Composite-level reference.
Does this make sense?
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>
3) The Composite reference uses the 'class' attr on <interface.java>
<interface.java class="helloworld.HelloWorldService" />
Isn't this supposed to be an attr named 'interface'? This may als
show, to a degree, that the Composite-level reference is really useless if
it doesn't even matter that this is wrong.
Scott
Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
Posted by scabooz <sc...@gmail.com>.
+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" <en...@gmail.com>
To: <tu...@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" <js...@apache.org>
> To: <tu...@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 <en...@gmail.com> 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" <an...@gmail.com>
>>>> To: <tu...@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 <js...@apache.org> 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 includes the Service Binding URI when there are multiple
>>>> > services. When <service> is inside the <component> the component in
>>>> > Tuscany
>>>> > has just a single service but when <service> is outside then the
>>>> component
>>>> > also has a service using the SCA binding.
>>>> >
>>>> > So in the above example the WS endpoint is either
>>>> > http://localhost:8080/HelloWorldServiceComponent/HelloWorldService or
>>>> > http://localhost:8080/HelloWorldServiceComponent depending on if the
>>>> > <service> is inside or outside the <component>.
>>>> >
>>>> > Is this the expected behaviour?
>>>> >
>>>> > ...ant
>>>> >
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>
>>>>
>>>
>>
>>
>> --
>> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
Posted by Raymond Feng <en...@gmail.com>.
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" <js...@apache.org>
To: <tu...@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 <en...@gmail.com> 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" <an...@gmail.com>
>>> To: <tu...@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 <js...@apache.org> 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 includes the Service Binding URI when there are multiple
>>> > services. When <service> is inside the <component> the component in
>>> > Tuscany
>>> > has just a single service but when <service> is outside then the
>>> component
>>> > also has a service using the SCA binding.
>>> >
>>> > So in the above example the WS endpoint is either
>>> > http://localhost:8080/HelloWorldServiceComponent/HelloWorldService or
>>> > http://localhost:8080/HelloWorldServiceComponent depending on if the
>>> > <service> is inside or outside the <component>.
>>> >
>>> > Is this the expected behaviour?
>>> >
>>> > ...ant
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
>>
>
>
> --
> 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: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
Posted by ant elder <an...@gmail.com>.
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 <js...@apache.org> 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 <en...@gmail.com> 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" <an...@gmail.com>
> >> 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 <js...@apache.org> 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 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)
> <http://helloworld#wsdl.interface%28HelloWorld%29>" />
> >> >> > <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)<http://helloworld#wsdl.interface%28HelloWorld%29>"
> />
> >> >> > < 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 includes the Service Binding URI when there are multiple
> >> > services. When <service> is inside the <component> the component in
> >> > Tuscany
> >> > has just a single service but when <service> is outside then the
> >> component
> >> > also has a service using the SCA binding.
> >> >
> >> > So in the above example the WS endpoint is either
> >> > http://localhost:8080/HelloWorldServiceComponent/HelloWorldService or
> >> > http://localhost:8080/HelloWorldServiceComponent depending on if the
> >> > <service> is inside or outside the <component>.
> >> >
> >> > Is this the expected behaviour?
> >> >
> >> > ...ant
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
>
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Promoting and configuring services in an SCA domain, was: A few
issues with HelloWorld WS sample
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 <en...@gmail.com> 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" <an...@gmail.com>
>> To: <tu...@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 <js...@apache.org> 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 includes the Service Binding URI when there are multiple
>> > services. When <service> is inside the <component> the component in
>> > Tuscany
>> > has just a single service but when <service> is outside then the
>> component
>> > also has a service using the SCA binding.
>> >
>> > So in the above example the WS endpoint is either
>> > http://localhost:8080/HelloWorldServiceComponent/HelloWorldService or
>> > http://localhost:8080/HelloWorldServiceComponent depending on if the
>> > <service> is inside or outside the <component>.
>> >
>> > Is this the expected behaviour?
>> >
>> > ...ant
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
Posted by ant elder <an...@gmail.com>.
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 <en...@gmail.com> 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" <an...@gmail.com>
> To: <tu...@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 <js...@apache.org> 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 includes the Service Binding URI when there are multiple
> > services. When <service> is inside the <component> the component in
> > Tuscany
> > has just a single service but when <service> is outside then the
> component
> > also has a service using the SCA binding.
> >
> > So in the above example the WS endpoint is either
> > http://localhost:8080/HelloWorldServiceComponent/HelloWorldService or
> > http://localhost:8080/HelloWorldServiceComponent depending on if the
> > <service> is inside or outside the <component>.
> >
> > Is this the expected behaviour?
> >
> > ...ant
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
Posted by Raymond Feng <en...@gmail.com>.
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" <an...@gmail.com>
To: <tu...@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 <js...@apache.org> 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 includes the Service Binding URI when there are multiple
> services. When <service> is inside the <component> the component in
> Tuscany
> has just a single service but when <service> is outside then the component
> also has a service using the SCA binding.
>
> So in the above example the WS endpoint is either
> http://localhost:8080/HelloWorldServiceComponent/HelloWorldService or
> http://localhost:8080/HelloWorldServiceComponent depending on if the
> <service> is inside or outside the <component>.
>
> Is this the expected behaviour?
>
> ...ant
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
Posted by ant elder <an...@gmail.com>.
On 5/17/07, Jean-Sebastien Delfino <js...@apache.org> 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 includes the Service Binding URI when there are multiple
services. When <service> is inside the <component> the component in Tuscany
has just a single service but when <service> is outside then the component
also has a service using the SCA binding.
So in the above example the WS endpoint is either
http://localhost:8080/HelloWorldServiceComponent/HelloWorldService or
http://localhost:8080/HelloWorldServiceComponent depending on if the
<service> is inside or outside the <component>.
Is this the expected behaviour?
...ant
Re: Promoting and configuring services in an SCA domain, was: A few
issues with HelloWorld WS sample
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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" <sc...@gmail.com>
> To: <tu...@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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
Posted by scabooz <sc...@gmail.com>.
+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" <sc...@gmail.com>
To: <tu...@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 <js...@apache.org> 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: 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: Promoting and configuring services in an SCA domain, was: A few issues with HelloWorld WS sample
Posted by Scott Kurz <sc...@gmail.com>.
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 <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Promoting and configuring services in an SCA domain, was: A few issues
with HelloWorld WS sample
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: A few issues with HelloWorld WS sample
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: A few issues with HelloWorld WS sample
Posted by scabooz <sc...@gmail.com>.
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>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: A few issues with HelloWorld WS sample
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Comments inline.
Scott Kurz wrote:
> I was looking over the HWWS/HWWSclient sample pair, and had the following
> observations/questions:
>
> 1) For helloworld-wsclient, the HelloWorldServiceComponent does not
> use the
> @Reference annotation. So, according to the Java Component Impl
> spec, Sec
> 1.2.7,
> shouldn't we, during introspection, calculate the helloWorldService to
> represent a Property, not a Reference? Yet we promote it to a
> Composite-level reference.
> Does this make sense?
Here's from that spec:
370 2. If its type is complex, then if the type is an interface marked
by @Remotable, then it is a reference;
371 otherwise, it is a property.
According to that text, the sample looks correct to me, as
HelloWorldService is annotated with @Remotable.
>
> 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.
> 3) The Composite reference uses the 'class' attr on <interface.java>
> <interface.java class="helloworld.HelloWorldService" />
>
> Isn't this supposed to be an attr named 'interface'? This may als
> show, to a degree, that the Composite-level reference is really
> useless if
> it doesn't even matter that this is wrong.
>
> Scott
>
It's not useless :) not specifying an interface on a composite reference
is correct, if you don't specify the interface by default the interface
of the promoted reference will be used.
We currently do not issue a warning if you have extra attributes like
"class", there was a discussion on the list recently about doing XML
schema validation when we load SCA assembly XML files, when this is in
place you will probably get a warning.
Thanks for reporting this, I just checked in a fix under revision r536006.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org