This post originated from an RSS feed registered with .NET Buzz by James Avery. Original Post: Adventures in SOA, Part 5 Feed Title: .Avery Blog Feed URL: /blog/Install/BlogNotConfiguredError.aspx Feed Description: .NET and everything nice Latest .NET Buzz Posts Latest .NET Buzz Posts by James Avery Latest Posts From .Avery Blog

I keep telling myself I am going to wait and think about it more before I write another one of these posts, and yet somehow I end up opening up w.bloggar and starting to write.

This post is going to be much shorter than any of the previous posts, as I simply want to reinforce the conclusions that I have come to.

SOA is about system design. SOA is about building a system that is based on loosely coupled services using a standard format (in this case XML). Contrary to what I have said in some of the last posts, I think you can build the services using whatever design and patterns you are most accustomed with, the internals of the service is not what makes a SOA.

Here are a couple posts that helped me come to this conclusion.

Clemens Vasters lays it out pretty clearly when he says "Within a service, OOP stays as much of a good idea as it always was, because it gives us all the qualities of pre-built infrastructure reuse that we've learned to appreciate in recent years. I don't see much realistic potential for business logic or business object reuse, but OOP as a tool is well and alive." in this post.

Steve Maine said it the best though "Do nondistributed object heirarchies have a place in SOA? Absolutely. Use services to expose rich functionality via simple interfaces, and use object heirarchies of arbitrary complexity to implement that functionality. However, no external entity should ever be directly exposed with your behavioral object heirarchy -- any cross-boundary interaction that implies behavior should take place via services only." in this post.

So if you are looking into getting started with SOA, don't get tripped up on how to build the services, but instead worry about what services you are going to build and how they can be isolated. And don't forget about OOP, just don't expose those objects. :)

This week and weekend I am going to start work on the first set of services for my application and hopefully I will have more to write about as I start work on these first services. (And run some perf tests)

-James