Hi Shiva, Thanks a lot for the comments..The points you made are of great help.
Regards, Altaf On Fri, Oct 31, 2008 at 1:49 AM, Balasubramanyam, Shivakumar < [EMAIL PROTECTED]> wrote: > Altaf, > > I looked at SCA three months ago and spend couple of weekends (night-outs > actually). > > SCA will be great solution going forward where applications that are > written in C++ needs to work in multiple environments (consumers could be > C++ or Java) and act as a container of any sorts. > > Issue is that, the current SCA-native code does not cut it. My evaluation > was below, > > Dislikes: > 1. usage of namespaces and exceptions are not supported in all embedded > platforms.[not a concern on server side] > 2. I really don't like the existing approach which requires the marshalling > of operation arguments in the Proxy/Wrapper to an intermediate > ParamterTypes. Also, the code is duplicated in DataObject > This can be achieved by using something like, > map<"datatype_stringname", void* data> that can be passed to the model to be > serialized. Even better, using boost::any will allow genericity and > I would follow the concept of pushing the service binding information > out of stub/wrapper just like the transport or RPC modules. > 3. Removing dependency on any fixed parsing technology (xml in this case) > 4. No need for dynamic type identification over the wire format [which is > actually a great feature on the luxury platforms] > 5. For C++ only environment, concept of domain, composite, components is an > overload. > 6. Also, for CPPImplementation, the wrapper code does not need to make this > intermediate conversion of types and RPC invocations (Please let me know if > I am wrong). Cuz, the real implementation already supports function > descriptions. Well, I will see if I can provide samples. > > > Likes: > 1. Best comment was the layered design of core, model and extensions. > ServiceProxy, ServiceWrappers and Operation (which is basically a generic > way of storing RPC identifiers) > > I actually got the SCA tweaked to remove the SDO and DAS and the code size > was less than 500KB. I preferred static data marshalling factory of all > types to get rid of the SDO and DAS. The wire protocol format in the service > binding should be sufficient to make it interoperable. > > Please note that, I have disliked some very nice features of SCA mainly to > make it practical in embedded world.These points may make no sense on the > server side with greater availability of memory, cpu and storage. > > My conclusion was to base the framework on WSDL + OSGi + SCA (conversations > feature is really nice and lacks in WSDL). > > I will revisit SCA after some time to see if SDO can be developed with > lower footprint (i don't need all the features of SDO like change summary). > > > > Thanks, > Shiva > > ------------------------------ > *From:* Altaf Muneer [mailto:[EMAIL PROTECTED] > *Sent:* Wednesday, October 29, 2008 11:19 PM > *To:* [email protected] > *Subject:* Re: Tuscany SCA Native > > Hi Haleh, Simon, > > Thanks for the responses and comments.. > > > Do you have a pure C/C++ environment or is this an environment where Java > and C++ components will be used in the same composite? > We have a pure C/C++ environment.. > We are planning to use Tuscany SCA native (a stripped down version if that > is possible) in an embedded environment > > > At the moment I think it's a matter of looking at how the existing > bindings work an doing similar. > Yeah, i think thats what we will try to do.. > > Thank you for your time and suggestions > > Regards, > Altaf > > On Wed, Oct 29, 2008 at 8:24 PM, haleh mahbod <[EMAIL PROTECTED]> wrote: > >> Hi Atlaf, >> >> Do you have a pure C/C++ environment or is this an environment where Java >> and C++ components will be used in the same composite? >> >> Haleh >> >> On Wed, Oct 29, 2008 at 7:25 AM, Simon Laws <[EMAIL PROTECTED]>wrote: >> >>> Hi Altaf >>> >>> Some comments in line... >>> >>> Simon >>> >>> On Wed, Oct 29, 2008 at 2:03 PM, Altaf Muneer <[EMAIL PROTECTED]>wrote: >>> >>>> Hi, >>>> >>>> I was just checking the SCA Native strain of Tuscany and I had the >>>> following questions.. >>>> >>>> Is there any ongoing work in Tuscany SCA Native? (I noticed that the >>>> last release was in May 2007) >>> >>> >>> Not a lot. I did just check in a patch that one of the community >>> contributed but other than that there hasn't been recent discussion about >>> how to move it forward. Good opportunity if you want to get involved;-) >>> >>> >>> >>>> Is there any support for C in Tuscany SCA Native? >>> >>> >>> Not yet FAIK. There is a spec for C component types ( >>> http://www.osoa.org/download/attachments/35/SCA_ClientAndImplementationModelforC_V100.pdf?version=1) >>> but no implementation of it yet. >>> >>> >>>> Are there any resources which will help one add new bindings for Tuscany >>>> SCA native? >>> >>> >>> It looks a bit thin at the moment. At the moment I think it's a matter >>> of looking at how the existing bindings work an doing similar. >>> >>> >>>> >>>> I would be grateful if anybody can answer these questions/ point me to >>>> some resources where I can find answers to these questions. >>>> >>>> Regards, >>>> Altaf >>>> >>> >>> >> >
