I had a conversation with one of our architects recently and he summarized his use of SOA as "The only time we'll use services is when we need async actions otherwise we'll use go direct to the data store"
I thought about this statement and it seems fairly logical as services work well in a publish subscribe model, but I was wondering in what other scenarios you should be looking to use SOA?
Another scenario might be an integration scenario, where you'd like many separate components, or systems, to communicate with each other.
We expose services to our customers because they shouldn't be able to connect to the datasource directly.
We expose services to ourselves because it's easier to spread them over different technologies using wcf.
We expose serivices because we have different userinterfaces for the same datasource. And when we use services we same a third of the work.
It is never only because of the async actions.
SOA can be used as a way to hide the implementation details of your subsystems. If your customers need product information, for instance, it's probably a good idea to wrap your product database or inventory subsystem into a generic service and expose only the subset of functionality and data your customers need. Then, if you ever need to replace or upgrade that subsystem, you'll be able to make those changes transparent to your users and you customer facing software interface.
to integrate different technologies accessing same resources; to achieve certain level of transactional isolation over those different technologies; to keep one business logic written in one place (so there would not be nigthtmares when this logic is to be changed) ...
Another case to use services is when you want to integrate a heterogeneous technology stack.
In other words, if your DB is postgres, but you have code in Java, Perl, Python, and C++, you can write stored procedures and have each programming language call those. If you are working with a DB that doesn't have stored procs, or you want to have the capability of switch those out - or you just want to run over port 80, you could wrap the SQL calls in a service-oriented layer (think websphere) that can now be called by anyone - plus you can put the authentication and authorization logic (connect to LDAP, whatever) in the SOA layer.
You can also use that SOA layer to, say build up a logical routine to do "stuff" with that old COBOL box in the corner that manages invoices or creates statements for customers.
So if you've got a number of legacy systems you want to interconnect - say the sales system to the warehousing system to the order predicting systems - SOA might be one way to achieve that goal. (You can also use a "service bus" to create an event driven system as a better way of orchestrating change.)
Just me talkin'.
There are many scenarios in which you'd benefit from using services. Some of these scenarios have been codified by industry gurus (such as Thomas Erl of SOA fame).
I'd say you want to look for:
Your colleague is right to be cautious. There are a lot of deployment and support variables introduced with adoption of web services.
The point of SOA, that the Telecoms (IMHO) seem to be grasping as a lifeline, is that SOA enabled systems allow you to take legacy and entrenched technologies, and present them as an consistent, controlled API that lets your business users develop new and previously un-thought-of ideas without needing to re-architect everything in the company.
By having a unified language (WSDL) as your interface, you can prepare your technology silos for interoperating. By implementing SOA now, instead of doing direct-to-data-source, you automatically make your data sources consumable by parties and business needs you've never considered.
WSDL is finally Corba-that-works.
WSDL and SOAP generally suffer from the same problem CORBA and DCOM do: contract versioning is a nightmare. This isn't as much of a problem in the degnerate case where you have full control of all clients and servers, but it gets ugly when you begin federating systems, more so when you go inter-enterprise.
At that point you're almost forced to some sort of event driven architecture approach instead of the typical SOAP-as-RPC model of interactions. This doesn't have to mean using ESBs, but viewing the connections between enterprises as connections among ESBs is very useful.
Even then relying on SOAP as a transport gets ugly. Not only do you need to accomodate bidirectional interaction using opposed Web Services, you're still stuch with the versioning problem. Often the SOAP methods dengerate to trivial wrappers around "blobs" defined otherwise (separate XML schemas for example).
There are answers but they're never simple. Best practices for Web services versioning discusses a couple of them.
But SOA does not imply anything async at all. It's just the smart way to implement SOA. SOAs are about loose coupling. The EDA subset of SOAs is about de-coupling, which goes further.
I would use SOA in a system that will be extended in the time inside the organization and probably to others organizations.
For products that could change is nice too, you can replace little parts of it.
At the end you will have lots of lego bricks that you will join together.