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";
>> > 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
