Darren Wesemann Blog

Although WSDL, SOAP, UDDI, etc… provide important infrastructure for SOAs, most forget the underlying purpose and value of an SOA, which is to provide a rational framework for distributed component communication between application servers. In the interest of preserving legacy investments, adhering to the reality of the way trading partners communicate today as well as simply being practical, other popular protocols, interfaces and infrastructures (at times very vertical) also provide distributed integration, service reuse and development agility through writing as little code as possible.

For example, FIX and others are protocols in the financial services vertical that are well defined, used widely and offer reuse can accommodate the original ideals of Service Oriented Architectures. Likewise the messaging infrastructure accommodating protocols other than Web Services are just as important to an SOA and should be common and reusable.

SOAs are generally a work-in-progress, and practical service virtualization as well as the underlying broker infrastructure should continually be reviewed. Platform-agnosticism is the cornerstone of true SOA, and therefore WSDL, SOAP, UDDI, or any other Web Services standard should not be exclusive to an SOA.

At http://wintercorp.com/, where the largest databases are cataloged, with their platforms. Impressively, Yahoo tips the scales as the largest commercial database at a mere 100.4 Terabytes, running BSD Unix. Amazon sports two databases on Linux, one 24.8 and the other 18.6 Terabytes. The largest database Winter found was a private meteorology system at Max Planck Institute, a 222.8 Terabytes behemoth. Let’s see… I remember when a 100 Megabyte IBM DASD drive was $1.4 Million (early 90’s), wholly cow, that would be $3.1 Trillion. The busiest database processes over 1 billion SQL statements per hour.

SunGard stresses platform-agnostic service virtualization, which allows for more flexible deployment options and permits the most cost effective configuration without custom coding. The alternative is to base everything on a specific SOA vendor’s infrastructure. SunGard’s customers continuously clamor for agility, so an agnostic approach is the preferred path.

Three years ago, we identified the features we needed in an SOA in order to support the breadth of applications we offer. We established standards for their use, ad process to allow the standards to live and a reference implementation comprised of best-of-breed components (internal to SunGard as well as external) that addressed our requirements. Supporting the process and servicing the reference implementation, we established support infrastructure including repositories for code, documentation, forums, various trackers and an index of services. We call it the CSA, or Common Services Architecture.