What's an alternative to SOA?

Thought you'd never ask (maybe you didn't).  This is not new, but hopefully this will encourage a few to look deeper into this option, especially those in enterprises with enterprise architecture teams. Using your favorite search site, have a look at Web-Oriented Architecture (WOA) or Resource-Oriented Architecture (ROA).  I'll use WOA, but ROA is interchangeable for this post.  

The good news about WOA is you probably have many of the technologies and infrastructure components, and know enough about the standards and technologies to get a WOA up and running fairly quickly. If you are an enterprise architect, you may not like the approach or may want to combine it with SOA, big, complex EA and any number of other things, but try to keep an open mind and keep things simple.

To keep things simple, define a small set of standards and technologies that will be used in your WOA. To get started, you will need a basic set of standards/technologies. For example, a good starting point would be:

• HTTP/HTTPS
• URI
• JSON (and/or others)
• REST

If needed, you can add RSS, XML, and other open standards, content types, etc., to define the fundamental set of enabling standards/technologies for your organization's WOA. The objective is to keep WOA-based solutions to a small set of common web standards, and resist any temptation for more complex approaches. Keep it simple. If there appears to be a situation that can't be addressed by your choice of standards, you should search for solutions, ask questions or hire an experienced web consultant (probably not a bad thing to do early in the process as he/she can help you define your WOA standards and technology options), etc., that is, the web (for the most part) has been built on these standards so whatever you need to do should be possible...if you can't figure out how, find someone that can or has!

Looking at the above list you have fundamental distributed service architecture capabilities:

• HTTP/HTTPS - provides messaging and methods
• URI - provides the resource identification (endpoint addressability)
• JSON - provides a simple data representation
• REST - provides the resource (instance, service) model

With these, you can define a very robust WOA.  We have a way to send/receive messages, package messages, define messages, consume/respond to messages.

You'll also need to consider security.  There are several options such as TLS (SSL), OAuth, OpenID, OpenLDAP, encryption, etc.; there are open source and commercial options...but essentially, you need authentication and authorization at a minimum, and you may want more such as accounting, auditing, encryption, etc. 

The heart of a SOA is the Enterprise Service Bus (ESB).  If you consider a SOA model, the ESB "sits in the middle" processing all (most/many...some subset if not all) message requests and responses; it may transform, parse, enrich, strip, burst, etc. processing the message. If you are using WSDL and the plethora of web standards that can be added to WSDL, you'll have a fairly large envelope to process which will take even more time. To process these messages (maintaining SLAs and QoS) would require significant infrastructure, that is scalable and fault tolerant and the end result is likely expensive. If you are using a commercial ESB...even more costs. Complexity and cost, what are the benefits, when will the benefits be realized?

The heart of a WOA is the web server.  There are many options here, and you probably already have your own favorite set of web server technologies.  That said, this may be a good time to have a look at more modern web servers (e.g., nginx). At the simplest level, a web server processes requests, ideally quickly and efficiently and can scale to a large number of users.  In a WOA, requests can be processed locally (by / on the web server) or remotely, by another web tier that hosts/exposes REST endpoints.  The REST service implementation is up to you, what it does and how it does it, is also up to you. That's really it. 

In SOA, a collection of web services isn't sufficient as you need service infrastructure too.  In a WOA, having a web server and REST services is about it.  If you want SLA, QoS or other analytics, you can add those to your web server or your current infrastructure if you don't have them. SOA builds on the basic web infrastructure (adds more infrastructure); WOA is the basic web infrastructure. WOA is used by the Internet, it should meet your needs as well.