Service Oriented Architecture (SOA)?

Question

Can someone explain Service Oriented Architecture simply and concisely without using corporate buzzwords and programmer talk? I'm trying to understand what it is, but all the explanations I find are very confusing.

Answer 1

Service oriented architecture basically means that rather than having a program that does everything, that program will help other programs do what they need to do.

Take, for example, a convenience store. It probably has a cash register. He also has an inventory system. And he probably has Quickbooks.

One way to manage all those functions is to have an all-in-one program: A program that runs the register AND manages inventory AND handles the books. QuickBooks POS is one such type of program.

An SOA breaks each of those things into their own little parts. It can tie together all those diverse things -- the register, the inventory, the books -- even though each is actually done by a different program.

If you don't need a service -- such as computerized cash register -- you don't use it. Each "service" is unitized only as your business needs dictate.

So maybe I use Program A to run the register, and Program B to handle inventory, and Program C to do my accounting -- an SOA allows me to tie those three programs together, as though they were one program.

Actually, most SOA type programs are written as modules.

Suppose I run Mom And Pop Store Software Inc. I sell SOA systems to convenience stores.

I would have a core module. This would be the basic database and hardware to run my system. So, whether you want to run the register, or manage inventory, or do your books, you buy my core module first.

Then, I sell you each service -- each business function -- as a different item. So, if you want to do inventory, I sell you the inventory module. If you want to do cash register, I sell you the cash register module. If you want to do accounting, I sell you the accounting module.

You buy the base module only once and the service modules as you need them. And they all tie together, so that if you have, say, the register and inventory modules, every sale you record at the register can interact with the inventory module and keep track of store stock.

You don't have the accounting module, but the core module will let you make reports -- like total sales, remaining inventory, etc -- so you can use a different accounting program to manage your books based on those reports.

Answer 2

Its all in the name.

Designing an application or product by identifying what services is that going to provide and use.

Most solutions approach in a business process model (I feel that is definitely a very important aspect and needs to be understood and modeled before moving on the service oriented architecture)

The SOA way of doing things is to understand what the inputs and outputs are and treat each operation or process as a service being provided or being requested.

These standards are really basic and if you look at our current economy, this is how we work. We are in a service based industry.

Answer 3

SOA can be hard to understand since not even people in the business can agree on what it really means. I think this quote from the Wikipedia article sums it up well:

"SOA separates functions into distinct units, or services, which are made accessible over a network in order that they can be combined and reused in the production of business applications."

So a really small example. If I am building an e-commerce site I need to calculate shipping costs for peoples purchases. I could build all the logic to do those calculations into the application, but a more SOA way of doing it would be for my application to make calls to Fedex.com to get the shipping costs. If later on I also want to ship via UPS, I would simply link my application to a UPS web service to get UPS shipping rates.  

Answer 4

The real simple answer is designing a system or piece of software that is able to offer itself as a service to other systems and software.  Suppose you have simple software application that trades stocks, if you design it with SOA then ideally it would be easy to use it to display on lcd monitors in a stock brokerage house.  It would also be easy to use the software in say a desktop widget that runs on desktop computer like Vista or OSX or even a mobile phone.  So basically the lcd monitor system, desktop operating system and the mobile phone can all use the software as a service that provides stock trading capabilities.  Some systems will use the entire array of capabilities the software or system with SOA provides or some will use only a few.  The stock brokerage house may use them all, while the widget only uses it for informational purposes.  You can even think of SOA as a hotel, the architecture or structure of the hotel is to provide many services to its customers.  Some customers will use them all some only a few.  The key is in SOA is to treat other systems and software like "customers" or clients that want to use all or portions of the service the software with SOA provides.  This is highly generalized and non-technical.  Just a quick point SOA doesn't not necessarily have to provide a networking facing service.  In very complex systems that are made up of many subsystems some subsystems will "talk" to each other without using a network.  The subsystems may all run on the same platform that is interconnected without the use of a network.