When to use SOA (Service Oriented Architecture)?

We expose services to our customers because they shouldn't be able to connect to the datasource directly.

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.

– lomaxx Jun 9 '09 at 13:17 2 There is ofcourse a scenario where that is possible. We mostly have web-UIs and desktop-UIs. Which won't work with a dll.

– the_ajp Jun 9 '09 at 13:22 4 If you have a very heterogeneous web ui environment, Java, . Net, PHP, RoR then shipping DLLs is not so helpful. Using services to overcome a very heterogeneous environment is also a common use of SOA.

– Colin Desmond Jun 9 '09 at 13:32.

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). SOAPatterns I'd say you want to look for: Legacy application reuse Business process reuse (multiple use cases for same process) Implementation abstraction (platform, language, persistence abstraction) Your colleague is right to be cautious.

There are a lot of deployment and support variables introduced with adoption of web services.

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

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.

1 Or put another way, to use it to Decouple Integration from Implementation. – Martin Spamer Oct 9 '09 at 11:06.

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

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.

There is another school of related thought termed SOAD (Service Orientated Application Design) exists were every component of the system is a service. This is to leverage the benefits offered by the environment that they are built with (EJB, WCF) i.e. You get lots of free plumbing.

Some more resource on this at Building a SOA SOA Design Pattern Achieving integrity in a SOA Achieving Flexibility/Maintainability in a SOA.

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.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.