What is SOA?

What is SOA?  SOA or Service-Oriented Architecture is a software architecture pattern in which applications or systems are constructed from underlying (and usually distributed) software services that conform to a specific set of characteristics, namely:

1.Contract based
2. Location transparency
3. Autonomous
4. Abstract
5. Reusable
6. Composable
7. Stateless
8. Discoverable
9. Extensible
10. Loosely coupled

The primary goal of SOA is software development agility, i.e. the ability to respond the change easily, and cheaply, thus allowing businesses to rapidly respond to changing markets.

Services are typically (but by no means exclusively) implemented as web services, i.e. they operate over the ubiquitous web HTTP protocol, and are implemented either using XML-based SOAP or the lightweight (and more popular) REST paradigm.

The highly distributed nature of this architecture has resulted in a need for a runtime platform (the Enterprise Service Bus, ESB) to help manage the operation of these services, but also to handle complex enterprise integration scenarios involving multiple (and often legacy) platforms, protocols and security models - products like Oracle Service Bus or the open source Mule ESB.

In addition to being an integration solution, the service-oriented pattern also offers an opportunity for easier implementation of high-level business processes using Business Process Management (BPM) solutions that are often offered as part of the ESB product suite.

Service-oriented architecture is highly relevant to the rapidly growing cloud computing model where applications are built in the cloud as orchestrations over public cloud-based APIs, and we are seeing ESB vendors like WSO2 and MuleSoft in or moving into this space, offering cloud-based versions of their products, as well as API management products.

Some will argue that SOA is not new, and that distributed programming involving services has existed for a long time, and they are right.  However those early efforts stumbled on the hurdles of platform incompatibility and standards complexity.  Now, with ubiquitous, and easy to use protocols like REST, web service API development is growing rapidly, and the integration possibilities seem endless.

(What is SOA, Service Oriented Architecture)

Read More

SOAP vs REST web services

Comparing SOAP to REST for building web services is a bit like comparing apples with pears: SOAP is a protocol, REST is a pattern, and you could, if you felt so inclined, write RESTful services using SOAP.  However, when people ask this question, they usually mean: SOAP (as in WSDL, perhaps RPC style, WS-* standards), as opposed to REST (as in JSON/XML over HTTP)

Assuming you mean this, below are some pros and cons for each, but note this: REST is increasingly becoming the de-facto standard across the web, being used by the big public API providers in preference to SOAP. I reckon it's just a matter of time before this question will just go away.

Read More

Going Public with your Web Service API - Taking Stock

If you are a good SOA believer, you will have a set of lovely services that are being used internally by your applications, and perhaps even by your commercial web applications, say via REST.  It will have dawned on you that your services are already public, being accessible over HTTP, and may have even discovered some enterprising customers have benefited from this fact by writing little client applications.  You think that perhaps it is time to go public, and produce an Amazon or Google style Public API for your business.

So what do you do?   First you need to take stock.

Why do you want to do this?  What is the business case?

Is your API suitable for making public i.e. is it well-designed, consistent, abstract, versioned, secure, monitored, documented, and adequate in capacity, availability and management terms?

Do you want to charge customers for this API?  What about 3rd parties who may want to leverage your API for their own customers?

Read More