When to use SOA (Service Oriented Architecture) [closed]

Answer 1

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.

Answer 2

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 services because we have different user interfaces for the same datasource. And when we use services we save a third of the work.

It is never only because of the async actions.

Answer 3

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'.

Answer 4

Another scenario might be an integration scenario, where you'd like many separate components, or systems, to communicate with each other.

Answer 5

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.

Answer 6

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.