You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Jean-Sebastien Delfino (JIRA)" <de...@tuscany.apache.org> on 2008/07/09 14:57:31 UTC

[jira] Created: (TUSCANY-2469) Lightweight implementation of the SCA default binding over the corba binding

Lightweight implementation of the SCA default binding over the corba binding
----------------------------------------------------------------------------

                 Key: TUSCANY-2469
                 URL: https://issues.apache.org/jira/browse/TUSCANY-2469
             Project: Tuscany
          Issue Type: Bug
            Reporter: Jean-Sebastien Delfino
             Fix For: Java-SCA-Next


I'd like to have an implementation of the SCA default binding over the corba binding, as a lightweight alternate to the current SOAP/Axis2 based implementation.

This implementation should be as transparent to the application developer and assembler as the current default binding implementation (i.e. not impose special constraints on the service interfaces, or additional codegen or deployment or admin steps). We should also make sure that it is able to flow instances of our main data bindings (including JaxB and SDO).

Having that would also allow us to verify that the current SCA binding is easily pluggable / replaceable by others who decide to integrate Tuscany but want to use a different prototol than SOAP inside their SCA domain.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Assigned: (TUSCANY-2469) Lightweight implementation of the SCA default binding over the corba binding

Posted by "Raymond Feng (JIRA)" <de...@tuscany.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Raymond Feng reassigned TUSCANY-2469:
-------------------------------------

    Assignee: Raymond Feng

> Lightweight implementation of the SCA default binding over the corba binding
> ----------------------------------------------------------------------------
>
>                 Key: TUSCANY-2469
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2469
>             Project: Tuscany
>          Issue Type: Wish
>          Components: Java SCA Misc Binding Extensions
>            Reporter: Jean-Sebastien Delfino
>            Assignee: Raymond Feng
>             Fix For: Java-SCA-Next
>
>         Attachments: sca-binding-corba-jira-2469-21-july.patch, sca-binding-sdo-problem-jira-2469-30-july.patch
>
>
> I'd like to have an implementation of the SCA default binding over the corba binding, as a lightweight alternate to the current SOAP/Axis2 based implementation.
> This implementation should be as transparent to the application developer and assembler as the current default binding implementation (i.e. not impose special constraints on the service interfaces, or additional codegen or deployment or admin steps). We should also make sure that it is able to flow instances of our main data bindings (including JaxB and SDO).
> Having that would also allow us to verify that the current SCA binding is easily pluggable / replaceable by others who decide to integrate Tuscany but want to use a different prototol than SOAP inside their SCA domain.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (TUSCANY-2469) Lightweight implementation of the SCA default binding over the corba binding

Posted by "Raymond Feng (JIRA)" <de...@tuscany.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615651#action_12615651 ] 

Raymond Feng commented on TUSCANY-2469:
---------------------------------------

The 1st patch is applied under r678786. Thanks,

> Lightweight implementation of the SCA default binding over the corba binding
> ----------------------------------------------------------------------------
>
>                 Key: TUSCANY-2469
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2469
>             Project: Tuscany
>          Issue Type: Wish
>          Components: Java SCA Misc Binding Extensions
>            Reporter: Jean-Sebastien Delfino
>             Fix For: Java-SCA-Next
>
>         Attachments: sca-binding-corba-jira-2469-21-july.patch
>
>
> I'd like to have an implementation of the SCA default binding over the corba binding, as a lightweight alternate to the current SOAP/Axis2 based implementation.
> This implementation should be as transparent to the application developer and assembler as the current default binding implementation (i.e. not impose special constraints on the service interfaces, or additional codegen or deployment or admin steps). We should also make sure that it is able to flow instances of our main data bindings (including JaxB and SDO).
> Having that would also allow us to verify that the current SCA binding is easily pluggable / replaceable by others who decide to integrate Tuscany but want to use a different prototol than SOAP inside their SCA domain.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (TUSCANY-2469) Lightweight implementation of the SCA default binding over the corba binding

Posted by "Wojtek Janiszewski (JIRA)" <de...@tuscany.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wojtek Janiszewski updated TUSCANY-2469:
----------------------------------------

    Attachment: sca-binding-corba-jira-2469-21-july.patch

Hi,
I've made some progress to SCA binding over CORBA. This patch adds:
1. Binding-sca-corba module
2. Some changes to existing CORBA binding modules, which enables handling Java interfaces which are not specific for CORBA
3. Integration test for SCA default binding over CORBA binding.

I've also some doubts about:

1. Service/reference target configuration. In axis2 implementation of SCA binding we have URI in default. In CORBA impl. I'm using corbaname URI. Should we normalize them somehow, or leave them specific for implementation?

2. We want SCA binding over CORBA binding to be transparent for user. What about providing name service? Lets consider following case: user creates service binding, users URI points to localhost and we have no name service provided by environment (ie. we don't use host-jee). Should we spawn name service in background or should user run it manually?

3. What about compatibility between corba and axis2 implementations of SCA default binding? Should both support the same structures identically? For now CORBA binding handles only some CORBA types, ie. it don't support Java collections, Java enums - should we also support them?

Thanks,
Wojtek

> Lightweight implementation of the SCA default binding over the corba binding
> ----------------------------------------------------------------------------
>
>                 Key: TUSCANY-2469
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2469
>             Project: Tuscany
>          Issue Type: Wish
>          Components: Java SCA Misc Binding Extensions
>            Reporter: Jean-Sebastien Delfino
>             Fix For: Java-SCA-Next
>
>         Attachments: sca-binding-corba-jira-2469-21-july.patch
>
>
> I'd like to have an implementation of the SCA default binding over the corba binding, as a lightweight alternate to the current SOAP/Axis2 based implementation.
> This implementation should be as transparent to the application developer and assembler as the current default binding implementation (i.e. not impose special constraints on the service interfaces, or additional codegen or deployment or admin steps). We should also make sure that it is able to flow instances of our main data bindings (including JaxB and SDO).
> Having that would also allow us to verify that the current SCA binding is easily pluggable / replaceable by others who decide to integrate Tuscany but want to use a different prototol than SOAP inside their SCA domain.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (TUSCANY-2469) Lightweight implementation of the SCA default binding over the corba binding

Posted by "Raymond Feng (JIRA)" <de...@tuscany.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618530#action_12618530 ] 

Raymond Feng commented on TUSCANY-2469:
---------------------------------------

Patch applied and enabled under r681221 along with the fix r681219. Thanks

> Lightweight implementation of the SCA default binding over the corba binding
> ----------------------------------------------------------------------------
>
>                 Key: TUSCANY-2469
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2469
>             Project: Tuscany
>          Issue Type: Wish
>          Components: Java SCA Misc Binding Extensions
>            Reporter: Jean-Sebastien Delfino
>            Assignee: Raymond Feng
>             Fix For: Java-SCA-Next
>
>         Attachments: sca-binding-corba-jira-2469-21-july.patch, sca-binding-sdo-problem-jira-2469-30-july.patch
>
>
> I'd like to have an implementation of the SCA default binding over the corba binding, as a lightweight alternate to the current SOAP/Axis2 based implementation.
> This implementation should be as transparent to the application developer and assembler as the current default binding implementation (i.e. not impose special constraints on the service interfaces, or additional codegen or deployment or admin steps). We should also make sure that it is able to flow instances of our main data bindings (including JaxB and SDO).
> Having that would also allow us to verify that the current SCA binding is easily pluggable / replaceable by others who decide to integrate Tuscany but want to use a different prototol than SOAP inside their SCA domain.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (TUSCANY-2469) Lightweight implementation of the SCA default binding over the corba binding

Posted by "Jean-Sebastien Delfino (JIRA)" <de...@tuscany.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Sebastien Delfino resolved TUSCANY-2469.
---------------------------------------------

    Resolution: Fixed

Looks ok to me so I'm going to makr this issue fixed, we can create new more specific issues if/when we run into bugs, limitations or requests for new features.

> Lightweight implementation of the SCA default binding over the corba binding
> ----------------------------------------------------------------------------
>
>                 Key: TUSCANY-2469
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2469
>             Project: Tuscany
>          Issue Type: Wish
>          Components: Java SCA Misc Binding Extensions
>            Reporter: Jean-Sebastien Delfino
>            Assignee: Raymond Feng
>             Fix For: Java-SCA-Next
>
>         Attachments: sca-binding-corba-jira-2469-21-july.patch, sca-binding-sdo-problem-jira-2469-30-july.patch
>
>
> I'd like to have an implementation of the SCA default binding over the corba binding, as a lightweight alternate to the current SOAP/Axis2 based implementation.
> This implementation should be as transparent to the application developer and assembler as the current default binding implementation (i.e. not impose special constraints on the service interfaces, or additional codegen or deployment or admin steps). We should also make sure that it is able to flow instances of our main data bindings (including JaxB and SDO).
> Having that would also allow us to verify that the current SCA binding is easily pluggable / replaceable by others who decide to integrate Tuscany but want to use a different prototol than SOAP inside their SCA domain.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (TUSCANY-2469) Lightweight implementation of the SCA default binding over the corba binding

Posted by "Wojtek Janiszewski (JIRA)" <de...@tuscany.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12619155#action_12619155 ] 

Wojtek Janiszewski commented on TUSCANY-2469:
---------------------------------------------

Hi,
I've commited change under r681871. Now SCA default binding over CORBA creates name server for service bindings which points to localhost (it results from transparent nature of SCA def. binding - now user doesn't need to create name server seperately).
I'd also like to allow user to create name servers in <binding.corba>, by using another attribute in configuration, ie. 
<binding.sca uri="corbaname::localhost:5080#ScenarioFourReuse" createNameServer="true"/>

Thanks,
Wojtek

> Lightweight implementation of the SCA default binding over the corba binding
> ----------------------------------------------------------------------------
>
>                 Key: TUSCANY-2469
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2469
>             Project: Tuscany
>          Issue Type: Wish
>          Components: Java SCA Misc Binding Extensions
>            Reporter: Jean-Sebastien Delfino
>            Assignee: Raymond Feng
>             Fix For: Java-SCA-Next
>
>         Attachments: sca-binding-corba-jira-2469-21-july.patch, sca-binding-sdo-problem-jira-2469-30-july.patch
>
>
> I'd like to have an implementation of the SCA default binding over the corba binding, as a lightweight alternate to the current SOAP/Axis2 based implementation.
> This implementation should be as transparent to the application developer and assembler as the current default binding implementation (i.e. not impose special constraints on the service interfaces, or additional codegen or deployment or admin steps). We should also make sure that it is able to flow instances of our main data bindings (including JaxB and SDO).
> Having that would also allow us to verify that the current SCA binding is easily pluggable / replaceable by others who decide to integrate Tuscany but want to use a different prototol than SOAP inside their SCA domain.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Re: [jira] Updated: (TUSCANY-2469) Lightweight implementation of the SCA default binding over the corba binding

Posted by Raymond Feng <en...@gmail.com>.
Hi,

I fixed the SDO issue with r681219.

I also had to adjust the dependencies to add databinding-axiom to get the 
CORBA itest case working. I'll commit the changes now.

Thanks,
Raymond

--------------------------------------------------
From: "Wojtek Janiszewski (JIRA)" <de...@tuscany.apache.org>
Sent: Wednesday, July 30, 2008 7:25 AM
To: <de...@tuscany.apache.org>
Subject: [jira] Updated: (TUSCANY-2469) Lightweight implementation of the 
SCA default binding over the corba binding

>
>     [ 
> https://issues.apache.org/jira/browse/TUSCANY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Wojtek Janiszewski updated TUSCANY-2469:
> ----------------------------------------
>
>    Attachment: sca-binding-sdo-problem-jira-2469-30-july.patch
>
> Hi,
> this patch adds some functionality, it's also help request for problem I 
> couldn't manage.
>
> What was done and works:
> 1. binding-corba-runtime module reorganization to allow creating SCA 
> binding over CORBA
> 2. Passing JAXB objects in CORBA SCA binding
> 3. JUnit tests in itest/corba (they fail due to problem described below, 
> remove tuscany-databinding-sdo dependency to get 2 of 3 tests working)
>
> Problems:
> 1. WSDLInterfaceContract creation
> I've reused binding-ws-wsdlgen module to create interface contract. It 
> fails at 
> org.apache.tuscany.sca.databinding.sdo.SDOTypeHelper.addResolvedXSDs at 
> line 165. I've tried some debugging as well as creating interface contract 
> from scratch and still have no idea how to handle creating 
> WSDLInterfaceContract. Any thoughts, clues?
>
> Thanks,
> Wojtek
>
>> Lightweight implementation of the SCA default binding over the corba 
>> binding
>> ----------------------------------------------------------------------------
>>
>>                 Key: TUSCANY-2469
>>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2469
>>             Project: Tuscany
>>          Issue Type: Wish
>>          Components: Java SCA Misc Binding Extensions
>>            Reporter: Jean-Sebastien Delfino
>>             Fix For: Java-SCA-Next
>>
>>         Attachments: sca-binding-corba-jira-2469-21-july.patch, 
>> sca-binding-sdo-problem-jira-2469-30-july.patch
>>
>>
>> I'd like to have an implementation of the SCA default binding over the 
>> corba binding, as a lightweight alternate to the current SOAP/Axis2 based 
>> implementation.
>> This implementation should be as transparent to the application developer 
>> and assembler as the current default binding implementation (i.e. not 
>> impose special constraints on the service interfaces, or additional 
>> codegen or deployment or admin steps). We should also make sure that it 
>> is able to flow instances of our main data bindings (including JaxB and 
>> SDO).
>> Having that would also allow us to verify that the current SCA binding is 
>> easily pluggable / replaceable by others who decide to integrate Tuscany 
>> but want to use a different prototol than SOAP inside their SCA domain.
>
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
> 

[jira] Updated: (TUSCANY-2469) Lightweight implementation of the SCA default binding over the corba binding

Posted by "Wojtek Janiszewski (JIRA)" <de...@tuscany.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wojtek Janiszewski updated TUSCANY-2469:
----------------------------------------

    Attachment: sca-binding-sdo-problem-jira-2469-30-july.patch

Hi,
this patch adds some functionality, it's also help request for problem I couldn't manage.

What was done and works:
1. binding-corba-runtime module reorganization to allow creating SCA binding over CORBA
2. Passing JAXB objects in CORBA SCA binding
3. JUnit tests in itest/corba (they fail due to problem described below, remove tuscany-databinding-sdo dependency to get 2 of 3 tests working)

Problems:
1. WSDLInterfaceContract creation
I've reused binding-ws-wsdlgen module to create interface contract. It fails at org.apache.tuscany.sca.databinding.sdo.SDOTypeHelper.addResolvedXSDs at line 165. I've tried some debugging as well as creating interface contract from scratch and still have no idea how to handle creating WSDLInterfaceContract. Any thoughts, clues?

Thanks,
Wojtek

> Lightweight implementation of the SCA default binding over the corba binding
> ----------------------------------------------------------------------------
>
>                 Key: TUSCANY-2469
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2469
>             Project: Tuscany
>          Issue Type: Wish
>          Components: Java SCA Misc Binding Extensions
>            Reporter: Jean-Sebastien Delfino
>             Fix For: Java-SCA-Next
>
>         Attachments: sca-binding-corba-jira-2469-21-july.patch, sca-binding-sdo-problem-jira-2469-30-july.patch
>
>
> I'd like to have an implementation of the SCA default binding over the corba binding, as a lightweight alternate to the current SOAP/Axis2 based implementation.
> This implementation should be as transparent to the application developer and assembler as the current default binding implementation (i.e. not impose special constraints on the service interfaces, or additional codegen or deployment or admin steps). We should also make sure that it is able to flow instances of our main data bindings (including JaxB and SDO).
> Having that would also allow us to verify that the current SCA binding is easily pluggable / replaceable by others who decide to integrate Tuscany but want to use a different prototol than SOAP inside their SCA domain.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (TUSCANY-2469) Lightweight implementation of the SCA default binding over the corba binding

Posted by "Jean-Sebastien Delfino (JIRA)" <de...@tuscany.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Sebastien Delfino updated TUSCANY-2469:
--------------------------------------------

    Issue Type: Wish  (was: Bug)

> Lightweight implementation of the SCA default binding over the corba binding
> ----------------------------------------------------------------------------
>
>                 Key: TUSCANY-2469
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2469
>             Project: Tuscany
>          Issue Type: Wish
>          Components: Java SCA Misc Binding Extensions
>            Reporter: Jean-Sebastien Delfino
>             Fix For: Java-SCA-Next
>
>
> I'd like to have an implementation of the SCA default binding over the corba binding, as a lightweight alternate to the current SOAP/Axis2 based implementation.
> This implementation should be as transparent to the application developer and assembler as the current default binding implementation (i.e. not impose special constraints on the service interfaces, or additional codegen or deployment or admin steps). We should also make sure that it is able to flow instances of our main data bindings (including JaxB and SDO).
> Having that would also allow us to verify that the current SCA binding is easily pluggable / replaceable by others who decide to integrate Tuscany but want to use a different prototol than SOAP inside their SCA domain.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (TUSCANY-2469) Lightweight implementation of the SCA default binding over the corba binding

Posted by "Jean-Sebastien Delfino (JIRA)" <de...@tuscany.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Sebastien Delfino updated TUSCANY-2469:
--------------------------------------------

    Component/s: Java SCA Misc Binding Extensions

> Lightweight implementation of the SCA default binding over the corba binding
> ----------------------------------------------------------------------------
>
>                 Key: TUSCANY-2469
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2469
>             Project: Tuscany
>          Issue Type: Wish
>          Components: Java SCA Misc Binding Extensions
>            Reporter: Jean-Sebastien Delfino
>             Fix For: Java-SCA-Next
>
>
> I'd like to have an implementation of the SCA default binding over the corba binding, as a lightweight alternate to the current SOAP/Axis2 based implementation.
> This implementation should be as transparent to the application developer and assembler as the current default binding implementation (i.e. not impose special constraints on the service interfaces, or additional codegen or deployment or admin steps). We should also make sure that it is able to flow instances of our main data bindings (including JaxB and SDO).
> Having that would also allow us to verify that the current SCA binding is easily pluggable / replaceable by others who decide to integrate Tuscany but want to use a different prototol than SOAP inside their SCA domain.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (TUSCANY-2469) Lightweight implementation of the SCA default binding over the corba binding

Posted by "Wojtek Janiszewski (JIRA)" <de...@tuscany.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12620330#action_12620330 ] 

Wojtek Janiszewski commented on TUSCANY-2469:
---------------------------------------------

What do you think about current status of this module? What I think is missing are more JUnit tests. Any ideas?
I'm also wondering if it's somehow possible to use SDO as an exception - now any SDO cannot be used, SDO and JAXB cannot be mixed together. Any thoughts?

> Lightweight implementation of the SCA default binding over the corba binding
> ----------------------------------------------------------------------------
>
>                 Key: TUSCANY-2469
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2469
>             Project: Tuscany
>          Issue Type: Wish
>          Components: Java SCA Misc Binding Extensions
>            Reporter: Jean-Sebastien Delfino
>            Assignee: Raymond Feng
>             Fix For: Java-SCA-Next
>
>         Attachments: sca-binding-corba-jira-2469-21-july.patch, sca-binding-sdo-problem-jira-2469-30-july.patch
>
>
> I'd like to have an implementation of the SCA default binding over the corba binding, as a lightweight alternate to the current SOAP/Axis2 based implementation.
> This implementation should be as transparent to the application developer and assembler as the current default binding implementation (i.e. not impose special constraints on the service interfaces, or additional codegen or deployment or admin steps). We should also make sure that it is able to flow instances of our main data bindings (including JaxB and SDO).
> Having that would also allow us to verify that the current SCA binding is easily pluggable / replaceable by others who decide to integrate Tuscany but want to use a different prototol than SOAP inside their SCA domain.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.