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

["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.