Openomics: innovation drives value

"Thanks to Sun technology, we are continuing to bring innovative identity management solutions to market and driving growth."
Hervé Prot, CEO, Symeos

Specialized in Web services security, Symeos provides online identity management, federated authentication services and single sign-on technologies for customers across multiple industries, including banking and finance. With the support of Sun, Symeos has developed a new scalable identity management product called EGO to support the more than 10 million expected users.

Read the whole story at http://www.sun.com/customers/servers/symeos.xml  to learn how the combinaison of Sun systems, storage and software reduced the Symeos development cost by 60%, delivered a 99.999% infrastructure availability and improved Web application server performance by 92%. Symeos is a member of the Sun Startup Essentials program.

"Latency matters. Amazon found every 100ms of latency cost them 1% in sales. Google found an extra .5 seconds in search page generation time dropped traffic by 20%. A broker could lose $4 million in revenues per millisecond if their electronic trading platform is 5 milliseconds behind the competition."
Latency is Everywhere (...), High Scalability Blog, Todd Hoff

Sun customers can turn to Gigaspaces to hide the network latencies and dramatically increase the performance of their multi-tier applications. Since the release of Java Real Time System (JRTS) 2.0, Gigaspaces customers can now turn back to Sun to further decrease the application latency of their business-critical transactions. Today's proofpoint is covering some engineering work at Gigaspaces this year around JRTS 2.0 to meet the stringent needs of our Financial Services customers with respect to market transaction latencies.

Today, most banks have migrated their internal software development from C/C++ to the Java language because of well-known advantages in development productivity (Java Platform), robustness & reliability (Garbage Collector) and platform independence (Java Bytecode). They may even have gotten better throughput performance through the use of standard architectures and application servers (Java Enterprise Edition). Among the few banking applications that have not been able to benefit yet from the Java revolution, you find the latency-critical applications connected to the trading floor. Why? Because of the unpredictable pauses introduced by the garbage collector which result in significant jitter (variance of execution time).

"If you've got some trades going through at 10 milliseconds and some at 1 millisecond, that's a problem. Our customers don't like variance."
Steve Rubinow, CTO, NYSE

In the context of a customer proof-of-concept this summer and in the light of the 2.0 release of Java Real Time System --JRTS 1.0 had the bad prerequisite of source code changes--, Gigaspaces revisited the opportunity for Java Real Time to serve the low-latency requirements of trading applications. Gigaspaces XAP 6.5, Solaris 10 and both Java 5.0 standard and real-time JVMs were used for the benchmark. The test scenario included a trade matching engine and…

Today's post is the first instance of an on-going series of technology adoption proofpoints. They are short real-life success stories about our application partners leveraging Sun technologies and innovation to create value for the end-customer. They will be, for the most part, the result of our developer support work at ISV Engineering. Unless there had been some public coverage of that work, proofpoints will be anonymized; only the industry and application segment will be identified --so you can still relate them to your own market and customers. So there we go...

After a server crash at a major European bank, two companies got a phone call; Sun because the logo is on the box, and the ISV whose application --a SWIFTnet messaging platform-- was running on it. The call came very quickly because the crash had led to corrupted data. Our joint investigation showed that one VxFS extend --the bank was using the Veritas File System 4.1-- contained old/bad financial data mixed with correct data. The problem was believed to happen after a new VxFS extend was allocated but before its metadata was written. By default, VxFS does not zero newly-allocated extends. For business environments where data integrity is critical, Veritas recommends the mount -o blkclear option that guarantees that uninitialized data does not appear in a file. That solution induced however an 15% performance loss with the application, unacceptable for the customer, and increased disk footprint of the C-ISAM (embedded database) data files.

The Solaris 10 operating system and ZFS filesystem was tested as an alternative solution and used as is with no additional flag. Due to its guaranteed data integrity, application data was found 100% correct after a stringent series of (20) crash tests. The application performance increased by 10% with ZFS compared to VxFS. In addition, the application's cold recovery process, which is started after a power failure, was taking only 15 seconds on ZFS when all C-ISAM database files have been checked. Finally, it was demonstrated that the ZFS built-in snapshot mechanism could be used to implement a Point-in-Time solution eliminating the need of expensive storage with snapshot capabilities.

As a result of this joint engineering work, the ISV listed ZFS as the recommended filesystem to all its customers. Based on this recommendation, customers have migrated to Solaris 10, from earlier releases of Solaris on Sparc, or are planning to do it. Based on ZFS, which is an integral part of the (free) Solaris and OpenSolaris distributions, the ISV solution is more competitive, guaranteeing data integrity --equals higher availability-- and reducing cost of ownership --no VxFS license, no expensive storage-- while delivering full performance.