My Life with SOA

I was recently asked to write about my history using SOA technologies. I was asked to write a paragraph. I failed. :) There's a lot to cover, and here it is:

I got my start with service-oriented architectures well before SOA was a buzzword in 1995 at Southwestern Bell Telephone, on a project by the name of Datagate. At the time, there were really no tools or libraries to help with the process, so we built everything in C from the ground up. There are a number of elements that are immediately associated with SOA in today's world, such as SOAP and UDDI. In Datagate, there were corresponding technologies. The exchange protocol that we used was a proprietary format designed to be concise and limit bandwidth use. Today, industry standards such as SOAP exist to allow interoperation and tools development. Most SOA environments rely on a Directory Service to allow client applications to discover active service instances. In today's world, that's typically UDDI, and in Datagate we built our own directory service that complied with the X.500 standards of the time. Current SOA implementations provide services hosted by an application engine such as WebLogic or JBoss. Datagate services ran as independent processes, but were managed by a central Resource Manager that monitored and reported the health state of infrastructure and business services. Eventually, we added a PKI to the system, and again, there were few tools at the time, so much of what we did we had to build ourselves.

One of the keys to success within a SOA environment is that mentality, a way of thinking about services, that is different from building stand-alone applications. SOA provides opportunities for high-availability and scalability that standalone applications cannot provide. But the real power of SOA, the idea that makes it really exciting, is the idea that we can capture complex business rules one time in a service, and re-use that service over and over. If we have a service that captures, for example, the rules that allow a customer to buy a certain stock, we can capture that once in a business service. That business service is then responsible to guard the data. We can test that service to a high standard, and any client that wants to buy a stock will go through that service, using well-tested logic. If we then decide to create a new application that requires the same logic, we don't have to recreate the logic that's already there. We can re-use it. This is important because we already have a service that we've been using, and trust to do the right thing. It's also important because it represents a cost savings to the business. We don't have to re-write, re-test and re-deploy a new implementation. This lets us provide the latest flashy interface, while using the same business logic that we've come to trust over time.

I started at my next employer, Connectria, in 1998, and worked on-site at A. G. Edwards, Inc. for six-and-half years. We did a number of projects there using SOA technologies as they developed into what they are today. My first SOA project there was a project named ClientOne, which delivered a new Broker Workstation to all of the brokers around the United States. We mentored application teams as they wrote thin-client applications that were delivered through the Broker Workstations.

My next big SOA project there was AGEconnect - the project which delivered the website agedwards.com for many years. I was an architect on this project's architecture teams through a couple major iterations. In the first iteration, we delivered a SOA-based architecture using two application engines, Dynamo and Tengah (now WebLogic). In the second iteration, we completely re-architected the framework to be based in WebLogic. Many supporting technologies were required and included in the new architecture, including LDAP, Apache HTTPD, F5's Big-IP appliance, and WSD appliances. We hosted the system on Sun hardware. There were four WebLogic engines each on four Sun machines in the home office, with the same on the failover site. We rolled out with about 80,000 clients on the system, which eventually grew to 300,000 or more.

On my final project at A. G. Edwards, I was the team leader for the BLServer component of their Gateway project. The Gateway project was focused on migrating some key functionality to an external provider. This provider was using some dated technologies to deliver content over the network, specifically, proprietary protocols. In addition, this external client had a nightly four-hour update window during which we needed to continue to accept updates. BLServer was one of a collection of services designed to wrap those proprietary services with standards-compliant services. BLServer included at its core a clustered message-driven web service that queued requests into JMS queues (the provider was Tibco) and then applied them in order during the external provider's uptime. The throughput requirements (about 300,000 transactions per 8-hour day) and the ordering requirements that exist for updating clients' financial accounts made this a particularly interesting and challenging project.

I started at my present employer, Asynchrony Solutions, Inc., in 2004, where I have also been a member of SOA projects. On the first I was the team leader on a project to deliver a system that could both push documents near to point-of-use around the world, and to pull data from disparate systems and deliver it around the world. That is, a federated system. This system employed Model 2 servlets hosted under Tomcat and JMS to meet the demanding performance requirements on networks that are often slow or unreliable. The JMS provider in this case was originally ActiveMQ, but we replaced it with JORAM when ActiveMQ was found to have difficulty reconnecting after network failures.

The next was to demonstrate to a client in the healthcare industry how SOA might work for them. We delivered a pilot application that allowed clients to view their prescriptions, appointments, doctors and other information using a web browser. It allowed healthcare providers to review patient information using a browser on workstations, iPods, and Blackberries. This application demonstrated the capabilities of both SOAP-based and RESTful services, and both Java and Ruby clients.

The next project made available an opensource SOA stack for the Army that developers could use to implement SOA solutions, then deploy them within a production-level environment using primarily commercial implementations of SOA stack components, such as WebLogic and Systinet. The developers' stack included a service compliance tool that would alert them to possible governance violations before deployment, and a stack compliance tool that would allow them to replace components of the SOA stack and verify that they delivered the same functionality.