SOA. Just the basic facts. In 5 minutes.

What a SOA is not

SOA does not mean using web services.
SOA is not just a marketing term.
SOA also does not just mean ‘using distributed services’.

What a SOA is

SOA is an architecture of business services (usually distributed and sometimes ‘connected’ by means of a service bus) that operate independently of each other, advertise what services they offer through well-defined interfaces and can be heavily re-used not only to aid development productivity of the IT department but to enable use of existing IT assets/systems. Ultimately, this means quicker turn around of IT projects, improving how IT serves the business and thus improves business agility.

‘Service’ orientation means that logic is provided via a suite of services which should be seen as ‘black boxes’. They do stuff, but you or the services consuming them don’t need to know what’s going on under the hood, only what messages they require as input (usually SOAP messages) and what the service will do for / return to you. A black box service doesn’t have to be a  web service, though they are the most commonly implemented type of service for maximum distribution and cross-platform compatibility.

So whilst that goes some way in explaining what SOA is on a general level using these developer written ‘services’… What SOA really is, is A FUNDAMENTAL CHANGE IN THE WAY YOU DO BUSINESS via a top down transformation requiring real commitment from the business, not just IT. That requires a change in mind-set of the top people.

Characteristics of a black box ‘service’ in a SOA

– Loosely coupled (minimizes service dependency)
– Contractual (adherence to well-defined service interface contracts… ‘if you wanna do business you need to abide by my interface contract’)
– Abstract (service is a black box, internal logic is hidden from service consumers)
– Reusable (divide and conquer! – We divide up business logic to basic reusable services)
– Composable (can be used as a building block to build further composite services)
– Stateless (retains little to no information about who it interacts with)
– Discoverable (describes itself, a bit like a CV so that the service can be found and assessed ‘hello I’m a service, here is my CV’)

What can these services do?

Whatever you need them to do in order to satisfy business change needs / requirements. Common functions of services include:

– Perform business logic
– Transform data
– Route messages
– Query data sources
– Apply business policy
– Handle business exceptions
– Prepare information for use by a user interface
– Generate reports
– Orchestrate conversations between other services

The business benefits of implementing a SOA strategy

– Open standards based
– Vendor neutral
– Promotes discovery
– Fosters re-usability
– Emphasizes extensibility
– Promotes organizational agility
– Supports incremental implementation (bit by bit development)

What a SOA might look like

The below shows a business application based on a SOA.

The lowest level of operation consists of application logic, including existing API’s, DAL code and legacy systems. This may include ‘application connectors’ that are middle men that interface between a simple exposed API and large systems like ERP, MRP etc).
This low-level application logic is then exposed as basic level services (application orientated services as they are a wrapper for parts of the application logic).
These basic level services form the building blocks of composite level services. More application aligned services are combined together to form services that are more aligned with the business, thus are more business orientated services. This can include exposing a business process as an independent business service.
Basic (application orientated) and composite (more business orientated) services can then be orchestrated by business processes.
These business processes may include human interaction points where user interfaces are required. Processes can also be initiated via user interfaces (requests / orders / applications etc).

Steps in Implementing a SOA with web services

1) Creating and exposing services (development team creating component services)
2) Registration of services (SOA isn’t truly in place when you just have random web services sitting on different web servers exposing WSDL. Where services are just consumed based on word of mouth and passing WSDL documents around.  A SOA requires a directory of its available services where all available services can be registered. UDDI 3.0 being the standard when using web services. This directory is the yellow pages for the services).
3) Address security. Exposing business logic as services over large networks opens up a serious set of security challenges. Security standards must be implemented for the services so that consumers of services can meet the security requirements.
4) Ensure reliability. Services must be monitored to make sure they are always up (high availability) and performance must be monitored to ensure reliability.
5) Concentrate on governance. How are all of these steps governed? What are the policies that should be enforced at runtime. Compliance is also important.

SERVICES THAT ARE EXPOSED, REGISTERED, SECURE AND PERFORM WELL FORM A SOLID SOA FOUNDATION.

That’s all for now. Hopefully that paints a very top-level picture of what SOA is, what it is not and how you should go about implmenting it (with the all important business buy in).

SOA : The very basics

SOA is one of those subject areas I’ve read a lot about of late.  I’ve delved deep into this topic to really grasp an understanding of what the topic entails and fundamentally what it means.  There tends to be a lot of guff (my word for ill-informed talk of a popular subject) in and around this topic and so in this article I’m hoping to sort out this guff and give newbies to the subject a bare bones definitive explanation.

A second reason why I wanted to write a bit about SOA is that I’ve heard twice this week the term ‘SOA Server’. Now whilst I understand what is trying to be conveyed (most likely a reference to an Enterprise Service Bus), it’s not like there is a single server product that just ‘does’ SOA in the same way your DNS server resolves IP to host names or your DHCP server ensures your network hosts have an IP address handed to them.

SOA what is it then?

SOA for the absolute beginner stands for Service Orientated Architecture. The name itself provides a clue to its fundamental meaning in that it’s an architecture for your Information Technology systems. Essentially it is the design and construction of service based IT.

Services are everywhere in our daily lives as our list below demonstrates:

1) The ATM provides you with a cash dispensing service

2) The sandwich shop offers you a sandwich making service

3) The courier offers you with a delivery service.

We just forget that we are being offered services every single day.

Using our example above of the ATM, Sandwich Shop and Courier services, it’s important to remember that not only are these serving us as customers but they are offering services to each other to enable their businesses to thrive. The sandwich shop clearly requires cash from an ATM to ensure that sandwich provisions can be bought and in certain cases the courier company services the sandwich shop by delivering the sandwiches to hungry customers. The ATM maintenance chaps also need to keep their energy up and so the sandwich service is a regular means of satisfying those lunch time hunger pangs. Whichever way you look at a scenario, services are provided and consumed by each other. In short, services consume other services to provide services and ultimately this is the goal of a Service Orientated Architecture.

Condensing what Service Orientated Architecture is into a single sentence I would say that it is An approach to building component service based IT systems.

SOA as a strategy

The more commonly used term used (instead of ‘approach’) is ‘business strategy’. SOA is one of several Business Strategies that ultimately result in a more effective running business because business change leads the way instead of the business being controlled by ‘what the IT can do’.

Having large complicated systems that don’t really talk to each other and invoke large costly ‘change’ projects that take months to complete is not an ideal scenario for a business that needs be dynamic. When I say dynamic, I mean having the ability to change with the market as well as change internal business processes without the need for long drawn out IT projects. Large costly systems are the shackles of business change and so taking a component service approach to designing IT systems is the key to freeing businesses from these shackles.

Employing a Service Orientated Strategy will allow the business to drive change and not the other way around. IT and the Business are more in line with each other.

Taking a SOA approach.

Now it’s clear why SOA is an important strategy to invest in, we need to know in what way SOA can help obtain this goal of a Business Driven IT Infrastructure.

The main goals of SOA is to allow IT to create component services using the latest frameworks (J2EE, .NET, Oracle Fusion, SAP Netweaver) and key technologies (XML!), leverage current IT assets that a business has already heavily invested in and to re-use services in a Lego brick type way. Re-use of already written services means that you write less code, there is less code to maintain when a service needs to change when being consumed by a bigger application, support for that application becomes simpler because change to a service component needs to happen in one place only.

Component services doesn’t mean just ‘Web Services’. Web Services are a type of component service but the main point of component services to wrap more bulky logic (normally old legacy systems) into simple service endpoints that do as little as possible (lots of tiny services doing lots of useful jobs means that other services can build on these and offer a greater level useful services).

Web Services

It would be criminal to leave the scene of a SOA discussion without covering the topic of web services and how they are changing the way companies interact internally (between systems) and globally with customers and partners. Web Services are a type of component service that should really be called ‘Business Services’ as they expose business logic over an inter-enterprise or global network. This has opened the door for disparate system interaction by connecting completely different systems through a common communications method using open standards. Essentially the introduction of web services has completely changed the landscape in terms of business to business interactions and internal systems interaction.

Since web services use HTTP and open standards such as SOAP to communicate, the consuming and providing systems do not need to understand anything about each other. You may have a SAP ERP system talking to an external .NET based ordering system and either doesn’t need to understand what the other is doing behind the scenes. All the consuming service needs to know is what information it needs from the service provider and in what format (the message) it needs to request it in.

Amazon has several exposed web services that allow you to query their catalogue. One particular web service allows a web service client to provide a product code and have a price returned instantly for that product. Many sites on the web today use web services transparently so you will never really know how much web services use you really do use.

Web services are the future and a major part of a SOA strategy.

SOA and Business Process Management

BPM, SOA and EAI are 3 of the most commonly used acronyms in my field. They are big areas of focus on many of today’s IT roadmaps as they are areas that are very closely aligned, but understanding the differences is important. Business Process Management is part of a good SOA strategy and can depend on the Enterprise Application Integration domain for improving system to system or user to system interaction for business processes. They interoperate as area’s of focus but understand that BPM and EAI are sub activities of SOA. Making improvements to business processes and connecting your systems are goals that should be detailed in a SOA strategy. SOA should be the umbrella strategy for BPM and EAI projects.

Summary

SOA is changing the face of business and IT interactions by improving relations, lowering the cost of supporting the IT engine and reducing the need for major cost investments in large packages by developing in-house systems on a component services foundation. My intention in this article was to literally touch the service of SOA, it is a large area and the tools used as part of the strategy are a plenty so please dig deeper into SOA and understand it from a day-to-day systems perspective and how it is helping in making the goals detailed above a reality.