SCA and SDO become SOA essentials for banking system

Service Component Architecture (SCA) and Service Data Objects (SDO), which last month began moving through the standards process at OASIS and JCP, are already being implemented in a bank processing system.

How useful are the Service Component Architecture (SCA) and Service Data Objects (SDO) specifications? Alan Walters,

CTO at Cachet Solutions LLC., says his bank processing system couldn't run without them.

We came to the stark realization that we needed a much more capable design out of the box than we had.
Alan Walters
CTOCachet Solutions LLC.

Vendors in the Open SOA group that developed SCA and SDO, and submitted them to the OASIS and JCP standards bodies late last month, have argued the specs are already mature enough to be implemented in service-oriented architecture (SOA) applications. Walters has done just that.

Cachet Solutions is a startup application service provider (ASP) that is betting its future on the implementations of SCA and SDO by Rogue Wave Software, a division of Quovadx, Inc., in its HydraSCA and HydraSDO products.

Walters recalled showing his initial design for a bank processing system to Cory Isaacson, president of Rogue Wave, who suggested adding the SCA and SDO technology.

When he showed his initial design to Isaacson, Walters was told something most architects don't like to hear. Issacson said, "You know this is an excellent first try, but we have a lot of experience with large scale financial institutions and given your requirements, you're going to run into performance problems."

Isaacson suggested that without SCA, the system wouldn't be able to efficiently use the hardware resources including multi-core processors to handle the loads from bank customers with thousands of accounts receivable (AR) transactions. Without SDO the planned system wouldn't be able to efficiently handle the multiple data formats banks and their customers would be using.

"We realized we really hadn't thought it through well enough," Walters said. "We came to the stark realization that we needed a much more capable design out of the box than we had."

So Cachet became an early adopter of the HydraSCA service execution framework and the HydraSDO tools for parsing data formats.

Including the Rogue Wave implementations of SCA and SDO into his system design provided his company with a product it can sell to banks where scalability and processing speed are important, Walters said.

"We process payments out of a lockbox and we match those payments to open AR from a bank's customer," he said, explaining the requirements for his system. "A given customer can have literally tens of thousands of open AR records on any night. We can get hundreds or thousands of payments from the bank for that customer. Multiply all of that times the number of customers, times the number of banks and we're moving massive data through our systems."

A benchmark test of the redesigned system with SCA and SDO convinced the Cachet CTO that it could meet the demands.

"Right off the bat in a test environment we could take a test company that had 15,000 open AR records, hundreds of payments, all the associated data and load and process the whole thing in three minutes," Walters said. "That gives us enormous credibility with the banks."

The ability of Rogue Wave's SDO-based tool to handle multiple data formats is also important because bank and customer data comes in an unpredictable mix of old and new standards, he said.

"There's lots of different formats," Walters said. "That's where we talk about SDOs. You've got the old BAI (Banking Administration Institute) format, you've got custom formats that are like BAI but aren't BAI, and then you've got EDI (Electronic Data Interchange). The newer systems use XML as well."

For more information
SOA specs SCA and SDO headed for OASIS and the JCP

Technological independence with SCA and SDO

He is anticipating getting all these data formats and more from the banks and the customers involved in the AR processing.

Explaining how the SDO technology will work with a bank's legacy backend systems, he said, "We're going to have to put some client-side software and hardware to extract and send and on the other side feed and input the data. We're putting a client applet out there and it's actually sending and receiving the data back and forth through our main gateway using HydraSDO. So we're doing a conversion locally. We're doing a check on that data to see whether we have to send the whole thing or just updates from the dataset. Once we determine that, we can just send an SDO object right down the pike to our gateway and load that directly into our system."

Walters said he didn't really understand the power of SDO until Isaacson explained it to him. Now, he can't imagine how his system could work without it. "For us it is critical," he said. "It's an absolute must have. I don't know what it's going to mean to other people, but we couldn't do our work without it."

Dig deeper on Service Component Architecture (SCA)

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close