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