Developing Tuxedo Servers with SALT and SCA

The recent release of SALT 10gR3 dramatically changes the effort required to build Tuxedo servers. Prior to this new version of SALT, Tuxedo supported two types of servers, ATMI and CORBA. The CORBA support in Tuxedo is very scalable and provides a great model for distributed object systems, especially where state is involved. The CORBA model is well understood and standardized and applications are built using a remote method call model. ATMI on the other hand is a messaging centric API based upon The Open Group XATMI specification. Servers developed using this API can be highly efficient and scalable, but tend to be rather technical API intensive.

Technical APIs are those APIs that access infrastructure or system functions that are not directly related to the business functions the application provides. Thus APIs that allocate messages, populate messages, send and receive messages, invoke services, etc., are all technical APIs. While not bad in and of themselves, technical APIs can get in the way of programmer productivity.

The SCA Client and Implementation standard defines how a particular programming language should provide SCA capabilities. In the case of C++ it defines the classes and methods that need to be provided by an SCA runtime that supports SCA clients and servers written in C++. This blog entry will show how a Tuxedo ATMI server and an SALT SCA based server are written. To keep the business logic to a minimum and pick a subject area familiar to all I'll use a simple 4 function calculator.

ATMI Servers

In an ATMI server, the developer creates services as C functions. The function is dispatched automatically by Tuxedo, whether in a single thread or in a worker thread for multi-threaded servers. The function receives as an argument a structure that contains such information as the name of the service, some flags, and a pointer to the message sent by the client. The function then extracts the information sent by the client from the message, performs whatever business function needs to be performed, creates and populates a return message, and then returns that message to the client. Here is an ATMI server that implements for services, ADD, SUBTRACT, MULTIPLY, and DIVIDE.

ATMI Calculator Server


Each service implementation uses the the FML32 functions to extract the incoming fields from the message sent by the client, then performs the simply business logic of a calculator. Finally it modifies the original message to remove the input fields, add the result field, and returns that to the client.

SCA Servers

SCA servers in SALT 10gR3 have all of their message handling performed by the SCA container and generated code. These pieces accept a message, extract the appropriate fields, then call a C++ method to perform the business logic. The method simply returns the result to the SCA runtime which in turn creates a reply message and returns that to the client. With the ATMI Binding Extension provided by SALT, a normal ATMI buffer is used to hold the request and reply messages which allows interoperability with ATMI clients and server. Here is an example of a 4 function calculator server written using the SCA container.

SCA Calculator Server

As you can see, there is considerably less code to write for an SCA based server. As well the code is all pure C++ code without any technical or middleware APIs used. This same code could be used in many ways, not just within the context of an SCA service implementation.

Hopefully these two simple examples illustrate some of the benefits of using SCA to implement services. In my next entry, I'll show how this same 4 function calculate can be accessed as a web service and how SALT help makes this a trivial exercise requiring no code changes to either the ATMI server or the SCA server.

Comments:

I assume there must also be some configuration artefacts that bind the FML fields to arguments and methods to services? Could you also post these? Without this, the comparison between the ATMI and SCA implementations is not complete since information that can be deduced from the C code is missing...

Posted by Peter Holditch on August 19, 2009 at 07:28 PM CDT #

Hi Peter, Excellent point. What is missing is the Service Component Definition Language file for the service. That would look like: <?xml version="1.0" encoding="UTF-8"?> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" name="calc.server"> <service name="CALC"> <interface.cpp header="CalculatorService.h"/> <binding.atmi> <inputBufferType target="add">FML32</inputBufferType> <inputBufferType target="subtract">FML32</inputBufferType> <inputBufferType target="multiply">FML32</inputBufferType> <inputBufferType target="divide">FML32</inputBufferType> <outputBufferType target="add">FML32</outputBufferType> <outputBufferType target="subtract">FML32</outputBufferType> <outputBufferType target="multiply">FML32</outputBufferType> <outputBufferType target="divide">FML32</outputBufferType> </binding.atmi> <reference>CalculatorServiceComponent</reference> </service> <component name="CalculatorServiceComponent"> <implementation.cpp library="Calculator" header="CalculatorServiceImpl.h"/> </component> </composite> The above SCDL defines the type of Tuxedo buffer to be used for input and output for each service. The field names by default are taken from the parameter names in the interface definition defined in CalculatorService.h. The contents of CalculatorService.h are: namespace services { namespace calc { class CalculatorService { public: virtual float add(const float addend1, const float addend2) = 0; virtual float subtract(const float sub1, const float sub2) = 0; virtual float multiply(const float multiplicand, const float multiplier) = 0; virtual float divide(const float dividend, const float divisor) = 0; }; } } }

Posted by Todd Little on October 14, 2009 at 03:40 AM CDT #

Hi Todd, There is mention of a CalculatorServiceImpl.h file, what is in that and how is it generated? Actually, could you give a summary of: All the files required to generate a simple stateless service using SCA. Their purpose. How each one is generated.

Posted by Eric Lee on July 22, 2010 at 05:58 PM CDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

This is the Tuxedo product team blog.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today