Practical SOA for a newbie

Question

I am a total newbie to the world of SOA. As such, I am looking at some "SOA frameworks/technologies", and trying to understand how to utilize them to build a highly scalable (Facebook class) website.

There are several "pains" I am trying to solve here:

1. Composability (+ managing dependencies, Pub/Sub)
2. Language-independence of services
3. Scalability & Performance
4. High availability

I looked into some technologies that answer a subset of the above criteria:

1. Thrift - Facebook's cross-platform RPC platform
2. WCF - supports SOAP, JSON & REST, so it can be considered language-interoperable. Generates WSDL files that can be use to generate java proxies.
3. Microsoft DSS - just inclued it in my survey, but it doesn't seem relevant as it is highly state-driven and .NET specific.
4. Web Services

Now, I understand how I get some aspects of composability and language-independence out of the above. But, I haven't found much concrete information (not buzz) about how to use the above / other tools for scalability and high availability. So finally I get to my question:

How does one leverage SOA technologies to solve the pains I defined above? Where can I find technical guides for that? I am looking for more than just system diagrams, but rather actual libraries, code samples, APIS...

Answer 1

Worth a look at: http://www.manning.com/davis/ ?

Answer 2

Check out the Mule project which bundles the CXF services stack and also the Mule REST pack which provides RESTful alternatives. I think you'll see it addresses all of your pains and there are lots of examples in the documentation as well as the distribution.

Answer 3

IDesign.net has a bunch of great downloads for WCF.

Answer 4

I think the question has more to do with the concepts involved than the tools. Answers to the items:

1. Understand and internalize bounded context. Keeping unrelated pieces separate its important to get real reuse on different services. Related technologies won't help you on this, its you that separate the app in appropriate contexts, which you can appropriately reuse for different services.
2. Clear endpoint for communication based on known protocols allows implementing different pieces with different technologies
3. Having the operations flow like independent actions based on different protocols, gives you a lot of places where you can add tiers. Is a particular sub-process of the overall process using lots of resources and the server can't take it anymore, just move to a separate server. Load kept growing, and that server isn't taking it anymore, add an additional server and load balance. You also have more opportunity to use caching and connection pooling.
4. Have a critical sub-process that needs to be available all the time, add a server so you can have a fail over. Have an overall process that needs to be "available" all the time, use queues for pieces that can be processed later.

Do you really need to support that type of load? Set appropriate performance/load/interoperability targets that relate to the specific scenario. If you really need to support that type of load, I recommend you get someone on board who has dealt with it.

If it is something for a load that might eventually be, identify the bounded contexts and design the interaction between those with a SOA mindset. Keeping the code clean is all you have to do for the rest, use TDD, loose coupling, focused integration tests, etc in your code base. With good code, if you later need to separate pieces of the system, it will be a lot easier.

Answer 5

May I recommend the book: Enterprise Service Oriented Architectures published by Springer Verlag.

Answer 6

All of the advice here is well and good, but don't worry about it until you really need to.

Focus on building a usable, functional application that people really like. When you start running into problems, then start handling bottlenecks.

You will never be able to foresee every way an application will fail, so how can you tell if [[insert tech here]] is your answer?

Answer 7

There are interesting and relevant things said about services and architecture by Amazon's CTO - Werner Vogels:

• An interview about the Amazon technology platform
• A post on his blog - "Eventually Consistent - Revisited"
• A 50 min presentation about Availability & Consistency