7 Replies Latest reply on Aug 22, 2014 1:48 PM by Maurice G-Oracle

    Limitations of using SCA


      Hello all,


      my name is Caio Casimiro and I am currently working on a project that will use Oracle Tuxedo as the application server.

      At this moment we have a doubt regarding the Oracle Tuxedo SCA (Service Component Architecture). According to the docs, it seems that developing SOA systems based on SCA is the best approach. However, it seems that it's perfectly fine to develop the same system without relying on Tuxedo SCA. As such, we would like to know what are the limitations, if there are any, of using SCA to build SOA applications. Or, what cases or scenarios that are not SCA friendly.


      I must say that the main concern here is performance. We need our application to be able to process millions of transactions per minute, so if SCA affects performance negatively, in any way, it would be a problem.



      Best regards,

      Caio Casimiro.

        • 1. Re: Limitations of using SCA
          Todd Little-Oracle

          Hi Caio,


          Glad to hear you are embarking on a Tuxedo project.  All Tuxedo applications are SOA applications as everything in Tuxedo is a service.  The major advantage that SCA provides in terms of programmer productivity and readability of the application code.  SCA separates the business logic from the underlying technical APIs.  As Tuxedo's SCA support is built on top of the underlying ATMI infrastructure of Tuxedo it's performance is quite good.  That being said, it is certainly possible to write ATMI applications that perform better than an SCA application as the marshalling that the SCA runtime performs is quite generic.  So C++ structures are marshaled and unmarshalled into ATMI buffer types by the generated stubs and skeletons.  Custom marshalling can potentially yield better performance, but at a cost of code complexity.


          My suggestion would be to try both for some service you intend on creating and then benchmark them both to see if the performance difference is significant enough to warrant the complexity of custom marshalling.  If absolute performance is your goal, you should focus on using VIEW/VIEW32 buffers as those require essentially minimal processing in ATMI.  However they aren't as flexible as FML/FML32 buffers in that their structure or content is fixed by the VIEW definition use to define the buffer, whereas FML buffers are more like hashmaps and can contain arbitrarily shaped payloads.


          Regarding the limitations of SCA, mostly it is in the type of C++ structures you can pass.  Complex types such as linked lists, hashmaps, etc., can't be handled by the generated stubs and skeletons.  As well our SCA support only uses basic ATMI features such as tpcall() and not more sophisticated features such as queuing with /Q , event handling with tppost(), asynchronous calls such as tpacall(), or call chains using tpforward().


          Just out of curiosity, what sort of application are you building?  If you have more questions, please ask and I'll try to answer as best I can.



          Todd Little

          Oracle Tuxedo Chief Architect

          • 2. Re: Limitations of using SCA

            Dear Todd Little,


            thank you very much for such comprehensive answer. We are developing a telecom system that, as I said before, must be able to handle a huge volume of transactions.

            From your reply, it seems that the overhead of using SCA might be negligible. However, the limitations on the use of the ATMI features would be a problem. We need to use almost all the ATMI features, especially queuing. Would it be possible to us to extend Tuxedo's SCA in some way to use the whole set of features from ATMI?


            Best regards,

            Caio Casimiro.

            • 3. Re: Limitations of using SCA
              Todd Little-Oracle

              Hi Caio,


              I'm sure we could extend the SCA support, although it's not clear what exactly that means.  The SCA programming model is primarily an RPC modei, i.e., request/response.  So you invoke an SCA service through a stub (generated C++ method) that serializes the parameter(s) into a Tuxedo buffer, invokes the associated service, deserializes the reply buffer into a return type and returns to the caller.  I'm not quite sure how one would map something like /Q into that model. However, you can readily mix and match SCA services with normal ATMI services, so you could have an ATMI service that performs the /Q enqueuing or dequeuing for you.  Also, by queuing I'm assuming you are referring to /Q and not just the normal request queuing that happens for servers automatically.



              Todd Little

              Oracle Tuxedo Chief Architect

              • 4. Re: Limitations of using SCA
                Bruno Taboada

                Hi Todd Little-Oracle, how are the things with you?


                I hope they are well.


                So Today I stopped by to ask a few more questions. This time concerning with creating SCA components. just to give you heads up I also decided not to open a new topic because this topic is already talking about SCA components. I apologise for the inconvenience.


                So I have created SCA server using c++ as language and also based on the /simpapp/simpapp.simpserver samples available in tuxedo samples. The server is working and has been advertised in tuxedo server. However, I would like to yield this server in oracle Tuxedo via salt. I tried creating the following SCDL below. It did not work out completely although the server managed to be advertised properly I couldn't get it working via salt. I mean, SALT has been able to to expose a endpoint webservice for the SCA Component, however SALT can't access or redirect the webservice call to SCA component! here is my settings for SCA components and SALT. see if you could help me? I thank you in advance. I really appreciated your helps so far.



                <?xml version="1.0" encoding="UTF-8"?>


                <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="server">

                    <service name="ToupSvc">

                        <interface.cpp header="ToupSvc.h"/>

                        <interface.wsdl interface="http://localhost.localdomain/application#wsdl.interface(application)"/>



                            <map target="chToup">ToupSvc</map>

                            <inputBufferType target="chToup">STRING</inputBufferType>

                            <outputBufferType target="chToup">STRING</outputBufferType>





                    <component name="ToupSvcComponent">

                        <implementation.cpp library="Toup" header="ToupSvcImpl.h"/>
















                <?xml version="1.0" encoding="UTF-8"?>

                <Definition xmlns="http://www.bea.com/Tuxedo/WSDF/2007" name="application">

                    <WSBinding id="application_Binding">

                        <Servicegroup id="application">

                            <Service name="ToupSvc"/>


                        <SOAP  version="1.1" style="document" use="literal">


                                <Endpoint address="http://localhost.localdomain:8080/ToupSvc" id="application_GWWS1_HTTPPort"></Endpoint>





                • 5. Re: Limitations of using SCA
                  Maurice G-Oracle



                  please take a look at this.


                  If you follow it to the letter you'll have a good starting point.


                  Now what I suspect is going on with your attempt is that the supporting Tuxedo server (the one that hosts the components) needs to be built specifically for SALT using buildscaserver -w (note the '-w'). I forget the exact reason, something to do with linking with SALT-specific bindings. Now this does not mean that the components need to be different, in fact you can have both ATMI and web services servers in the same application.


                  Let us know how it goes.





                  • 6. Re: Limitations of using SCA
                    Bruno Taboada

                    Thank you for replying Maurice. I much appreciated.


                    Let me tell you one thing. I have followed this tutorial as well, however building scaserver with buildscaserver -w does not generate the files which this tutorial mentions. For instance, my buildscaserver -w -c my_component -o mycomponent does not come off with WSDL file. Therefore, I came in here to ask for some help.


                    Anyway, I thank you so much for helping and replying me. I will try once more. whether you need further information about my settings, please feel free to ask me. I really want to understand it deeply. you somehow could help me.


                    Bye. See you around.

                    • 7. Re: Limitations of using SCA
                      Maurice G-Oracle



                      buildscaserver does not generate the WSDL, tmwsdlgen does. However it prepares the binaries for working with SALT GWWS (web services binding), as opposed to not using the '-w' which will work with the ATMI binding.