Adventures in SOA, Part 5
Tuesday, January 06 2004
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
Comments
- #1 Joseph Riesen on 7.07.2005 at 8:16 AM
-
BTW, thanks for all of these posts. I've been pondering SOA for some time and been digging through old blogs from a few years ago when others were trying to figure it all out.
It surprises me, at that, that I have to dig through blogs from a year and a half ago to get a straight answer on how to implement SOA. Everyone explains how cool it is, and flexible, yadda yadda, but I can't seem to find any official answer on how to do it in .NET.
BTW, I find it funny that your flip-flopping on how to *implement* the services is almost identical to what I've been doing over the last few days (SOA facade on OOP, no wait, everything as a service, no wait, OOP is okay). Yesterday, I ended up coming to the same conclusion - SOA is primarily about interfaces, not implementation (at this point in time).
Still, Udi's rather unorthodox approach to programming interests me...
