You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Raymond Feng <en...@gmail.com> on 2009/11/17 18:47:23 UTC
[2.x] InterfaceContracts on the RuntimeEndpoint/RuntimeEndpointReference
Hi,
We now have three interface contracts on a RuntimeEndpoint or
RuntimeEndpointReference.
Let's use an example to illustrate this:
There are two components: Payment and CreditCardPayment. Payment has a
reference to CreditCardPayment. Both are implemented in Java. We decide to
use binding.ws to connect these two components. A WSDL portType is created
to define the interface. To facilitate the java implementations, we run
"wsimport" to generate the JAX-WS interface (say scatours.CreditCardPayment)
and use it in the Payment and CreditCardPayment implementations.
The Payment implementation class would have:
@Reference
protected scatours.CreditCardPayment creditCardPayment
In the composite file, we can configure the Payment component reference with
a interface.wsdl:
<component name="Payment" ...>
<reference name="creditCardPayment">
<interface.wsdl interface="...">
<binding.ws .../>
</reference>
</component>
Now we can have up to three interface contracts for the "creditCardPayment"
reference.
1) componentType.reference.interfaceContract: This is the interface contract
that the business logic uses to call the service provider. In our example,
it's introspected from @Reference and the interface is a Java interface:
scatours.CreditCardPayment.
2) component.reference.interfaceContract: This is the interface contract
that is specified using the component/reference/interface.??? element. If no
interface.??? is not present, then it inherits from the componentType which
is 1).
3) component.reference.binding. interfaceContract: This is the interface
contract that binding layer expects. For Web Service binding, it is the WDSL
that Web Service is published. The construction of this interface contract
is binding-specific. For binding.ws, we use the following order:
* Check if the binding.ws element has wsdlElement attribute that points
to a WSDL
* Check if the component/reference/interface.wsdl is present
* Generate the WSDL from the component/componentType reference interface
(java2wsdl in this example).
Going back to the RuntimeEndpointReference SPI, we now have three methods to
represent 1, 2 and 3:
getReferenceInterfaceContract() --> 1 (For reference promotions, it uses the
componentType.reference.interfaceContract of the atomic component)
getInterfaceContract() --> 2
getBindingInterfaceContract --> 3
>From data transformation perspective, the source contract is 1 and the
target contract is 3. Interface contract 2 is mostly for the wiring
compatibility checking.
The RuntimeEndpoint has similar methods:
getServiceInterfaceContract() --> 1 (For service promotions, it uses the
componentType.service.interfaceContract of the atomic component)
getInterfaceContract() --> 2
getBindingInterfaceContract --> 3
Thanks,
Raymond
---
Raymond Feng
Apache Tuscany PMC Member: http://tuscany.apache.org
Co-author of Tuscany In Action (A book on Tuscany SCA):
http://tuscanyinaction.com/
Re: [2.x] InterfaceContracts on the RuntimeEndpoint/RuntimeEndpointReference
Posted by ant elder <an...@gmail.com>.
On Wed, Nov 18, 2009 at 8:41 AM, Simon Laws <si...@googlemail.com> wrote:
> ...snip
>>
>> ComponentReference: The component-level reference configuration
>> Reference: The componentType-level reference definition
>> Binding: The binding configuration
>>
>
> If we have to add extra text here to clarify what each of the methods
> returns why don't we add that text (or something contraction of it) to
> the method name itself? I don't think that less is more in this case.
> I don't think matching the assembly model interface is necessarily an
> advantage as I don't find component.getService().getService()
> particularly clear either.
>
> I can live with...
>
> getComponentReferenceInterfaceContract()
> getBindingInterfaceContract()
>
> Can we have the following though.
>
> getComponentTypeReferenceInterfaceContract()
>
> or even
>
> getImplementationReferenceInterfaceContract()
>
> or similar
>
> Regards
>
> Simon
>
+1 on those comments, getImplementationReferenceInterfaceContract is
long but its much clearer.
...ant
Re: [2.x] InterfaceContracts on the RuntimeEndpoint/RuntimeEndpointReference
Posted by Simon Laws <si...@googlemail.com>.
...snip
>
> ComponentReference: The component-level reference configuration
> Reference: The componentType-level reference definition
> Binding: The binding configuration
>
If we have to add extra text here to clarify what each of the methods
returns why don't we add that text (or something contraction of it) to
the method name itself? I don't think that less is more in this case.
I don't think matching the assembly model interface is necessarily an
advantage as I don't find component.getService().getService()
particularly clear either.
I can live with...
getComponentReferenceInterfaceContract()
getBindingInterfaceContract()
Can we have the following though.
getComponentTypeReferenceInterfaceContract()
or even
getImplementationReferenceInterfaceContract()
or similar
Regards
Simon
Re: [2.x] InterfaceContracts on the RuntimeEndpoint/RuntimeEndpointReference
Posted by Raymond Feng <en...@gmail.com>.
What about the following methods?
getReferenceInterfaceContract()
getComponentReferenceInterfaceContract()
getBindingInterfaceContract()
They match the interface names we have for the assembly model as follows:
ComponentReference: The component-level reference configuration
Reference: The componentType-level reference definition
Binding: The binding configuration
For RuntimeEndpoint, these methods will be:
getServiceInterfaceContract()
getComponentServiceInterfaceContract()
getBindingInterfaceContract()
Raymond
--------------------------------------------------
From: "Simon Laws" <si...@googlemail.com>
Sent: Tuesday, November 17, 2009 11:52 AM
To: <de...@tuscany.apache.org>
Subject: Re: [2.x] InterfaceContracts on the
RuntimeEndpoint/RuntimeEndpointReference
> Hi Raymond
>
> I think the mapping as you explain it makes sense although I don't
> think that the SPI naming is as clear as it could be. If we are going
> to maintain the three methods on the Endpoint/Endpoint reference I
> think we should switch to being more explicit otherwise we will be
> having this conversations again. For example, on the reference side...
>
> getComponentTypeReferenceInterfaceContract()
> getComponentReferenceInterfaceContract()
> getReferenceBindingInterfaceContract()
>
> Simon
Re: [2.x] InterfaceContracts on the RuntimeEndpoint/RuntimeEndpointReference
Posted by Simon Laws <si...@googlemail.com>.
Hi Raymond
I think the mapping as you explain it makes sense although I don't
think that the SPI naming is as clear as it could be. If we are going
to maintain the three methods on the Endpoint/Endpoint reference I
think we should switch to being more explicit otherwise we will be
having this conversations again. For example, on the reference side...
getComponentTypeReferenceInterfaceContract()
getComponentReferenceInterfaceContract()
getReferenceBindingInterfaceContract()
Simon