Non-Web services SOA handles trading on NYMEX

By Rich Seeley, News Writer 02 Oct 2007 | SearchWebServices.com

News on SOA, EAI, Web services Digg This!     StumbleUpon     Del.icio.us

Web services are too slow for financial exchanges where Java Messaging Service (JMS)-based service-oriented architecture (SOA) is the better choice, argues Hub Vandervoort, CTO of the Enterprise Infrastructure Division at Progress Software Corp.

HTTP SOAP just isn't reliable enough nor does it have the performance for the kind of traffic we're talking about here. Hub Vandervoort CTO of the Enterprise Infrastructure Division, Progress Software Corp.

He points to a JMS SOA implementation he is overseeing at the New York Mercantile Exchange (NYMEX), Inc., which is a subsidiary of NYMEX Holdings, Inc. (NYSE: NMX) and the world's largest physical commodities future exchange. The SOA implementation, announced by Progress this past week, is designed to handle a massive messaging increase resulting from the transition from floor trading to side-by-side electronic trading and the launch of the Dubai Mercantile Exchange. The new implementation will support what Progress calls "massive volumes of orders, price prints and trades including up to 1.2 million contracts per day, a 38% increase in volume, and process more than 50,000 messages per second, a tenfold increase over the former implementation."

Vandervoort is an advocate of not equating SOA with Web services, a position supported this past week by Jignesh Shah, product line director, SOA Governance at Software AG, who said: "The notion that Web services equals SOA has quickly been dismissed."

"It most definitely is an SOA," Vandervoort said of the NYMEX implementation. "Web services are not used at all. With most financial services firms, especially in the front office trading environment and especially as it relates to exchanges, you simply can't meet their performance objectives with the WS-standards today. HTTP SOAP just isn't reliable enough nor does it have the performance for the kind of traffic we're talking about here."

The business case for moving to an SOA based on the Sonic enterprise service bus technology from Progress was the introduction of electronic commodities trading, which would have swamped the decade old hub-and-spoke messaging system at NYMEX, said Ian Wall, senior vice president of technology.

"The business case was primarily we took a look at our infrastructure and we took a look at our future needs and did the math," Wall said. "From the way the commodities market has moved to a lot of activity on the screen as well as on the trading floor, we took a look at that new world and future business needs and what kind of a load would that put on our infrastructure. We had a sense of the capacity of our existing infrastructure and obviously the two didn't add up for us for our future needs."

One equation that didn't add up for the old hub-and-spoke system was the almost geometric impact of increases in electronic trading.

"We were facing significant growth on our messaging infrastructure," Wall explained. "If we got 40 percent more business electronically that could translate to a load on our system of 500 percent or 600 percent to deal with things like electronic market data which obviously comes at you at a much greater rate than from a trading floor."

In 2004, when NYMEX began to plan for the expansion in trading that they were already projecting, the 10-year-old technology could handle 5,000 messages a second at best, Vandervoort said. That wasn't sufficient for near-term projected growth of 15,000 transactions per second. So the exchange began an initial Sonic ESB implementation in 2005 to get to the 15,000 message per second level and reduce the latency of message traffic, the Progress CTO said.

Reducing latency at peak trading times is particularly important to a financial exchange, he said, noting the old system would beginning queuing messages as peaks approached the 5,000 per second level.

"That buffering would introduce a lot of latency into the trade flow," Vandervoort said. "Sometimes messages would be caught up in a queue for upwards of 20 seconds or a minute. Those kinds of latencies come at the worst possible time, usually during market surges is when the most price volatility is happening. It's when you most want to be on your feet and reacting. Introducing up to a minute of delay at those critical times is the worst possible scenario."

The SOA implementation will handle 50,000 messages per second even though today the exchange is experiencing volumes closer to 20,000 messages per second, Vandervoort said.

Mark Francetic, vice president of software development at NYMEX, said that capacity is a major requirement even though the exchange isn't at those peak levels yet.

"Their intention is to keep a minimum 100 percent margin over what the current peaks are," Vandervoort explained.

For more information JMS-based SOA monitors CERN particle accelerators Sonic beefs up ESB for large-scale SOA deployments

The SOA uses event-driven pub/sub semantics in a loosely coupled architecture that is based on JMS instead of Web services as the principle standard, the Progress CTO said. But in all other ways it is service-oriented, he said.

"Services are built very much as services would be in a Web services world," Vandervoort said. "There are well-defined interfaces on the boundaries of those services. There is true loose coupling because it's using pub/sub asynchronous event semantics. It's composed from a process standpoint very much like a Web services-based SOA would be in that the processes flow from service-to-service in the execution of the trade cycle."

The loose coupling also allows the exchange to incorporate new business operations such as the Dubai Energy Exchange into their existing SOA infrastructure," the Progress CTO said.

"They are using our Dynamic Routing Infrastructure, which is basically a multi-cluster architecture for federation to allow them to support the Dubai Exchange as an integrated single-bus environment even though from a governance standpoint it's a separate operation. So there are multiple domains operating as a single logical bus."

Tags: SOA implementations,  Service-oriented architecture (SOA) development,  Enterprise Services Bus (ESB),  Data governance and management for SOA,  VIEW ALL TAGS

Digg This!     StumbleUpon     Del.icio.us