Luciano, Mike:

thanks for the detailed answer. Yes, I am aware there are different types. I
am not so concerned having to declare an implementation within the same
domain. As a matter of fact, it looks to me that it is not even within an
entire domain, but within a composite since there is an implementation type
which is "implementation.composite", so the scope to which an implementation
declaration is exposed is fairly limited (which is good).

I am more concerned of "cross domain" interactions and in particular how,
say, a .Net based web service gets "assembled". In that case you won't be
able to find a valid implementation to expose as a composite. In "cross
domain" interactions you are also left to use Web Services technologies
(which I'm fine with, it'd be a shame to find no real use for WS-* after all
this energy spent :-).

Do you have a sample for that use case?

thanks,

JJ-

On Sat, May 17, 2008 at 5:34 AM, Mike Edwards <
[EMAIL PROTECTED]> wrote:

> Jean-Jacques Dubray wrote:
>
>> Luciano:
>>
>> thanks, actually in the test/bpel/helloworld-reference composite
>> definition
>> you also have a component defined with a binding.ws and there to, there
>> is
>> an implementation.java element. Is it required?
>>
>> <!-- Simple ws-reference -->
>>    <!--
>>    <component name="HelloWorldService">
>>        <implementation.java class="helloworld.HelloWorldServiceImpl"/>
>>        <reference name="greetingsService">
>>            <binding.ws uri="http://localhost:8085/GreetingsService"/>
>>        </reference>
>>    </component>
>>    -->
>>
>> Would you consider ws bindings as the preferred way to implement  cross
>> domain composites?
>>
>> JJ-
>>
>>  Jean-Jacques,
>
> There may be a misunderstanding going on here....
>
> Where there is a component in SCA, that says that there is a piece of code
> present which implements some function - and that the code provides function
> via one or more services and consumes function provided elsewhere through
> zero or more references.
>
> That code is called an implementation - and the implementation can be any
> one of many kinds - Java, BPEL, C++, JavaScript, Ruby, etc.  But there must
> be an implementation of some kind - and the component declaration is obliged
> to point at one.
>
> In this case, the HelloWorldService component has an implementation that is
> a Java POJO - the class
> helloworld.HelloWorldServiceImpl.  While this test could have used some
> other implementation type such as BPEL, it IS required to have SOME
> implementation - otherwise there is no function that the component can
> provide.
>
> The fact that the implementation is a Java POJO does not prevent the
> service interface or the reference interface being declared using WSDL and
> it also does not prevent the service or reference using a binding that is a
> Web service binding also using a WSDL, should that be desirable.
>
> Here is a simple example of a component implemented by a BPEL process and
> exposed as a Web service:
>
> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
>    targetNamespace="http://bpel";
>    xmlns:hns="
> http://tuscany.apache.org/implementation/bpel/example/helloworld";
>    name="bpel">
>
>    <component name="BPELHelloWorldComponent">
>        <implementation.bpel process="hns:HelloWorld"/>
>        <service name="helloPartnerLink">
>            <interface.wsdl
>                 interface="
> http://tuscany.apache.org/implementation/bpel/example/helloworld.wsdl#
>                 wsdl.interface(HelloPortType)" />
>            <binding.ws />
>        </service>
>    </component>
>
> </composite>
>
> ....no Java in sight !
>
> PS - you will find that component in a new BPEL Sample I've recently
> committed to the Tuscany SVN - called  "helloworld-bpel-ws".
>
> Yours,  Mike.
>



-- 
Jean-Jacques Dubray
425-445-4467

Reply via email to