This post originated from an RSS feed registered with Java Buzz
by Simon Brown.
Original Post: What is SOA?
Feed Title: Simon Brown's weblog
Feed URL: http://www.simongbrown.com/blog/feed.xml?flavor=rss20&category=java
Feed Description: My thoughts on Java, software development and technology.
There's a lot of talk around SOA at the moment but I think that one of the most refreshing statements comes from Gregor Hohpe in the form of "Is SOA really just the same old architecture?". Aside, perhaps, from the comment about a "document-oriented interaction model", my initial thoughts are that he's pretty much spot on. SOA is really just a new name for something that we've all been doing for a while now. Or is it?
At Evolution, we've been talking about SOA for a while now, both internally and with vendors that are selling products that can help realize SOA. SOA is something that I've been meaning to do some more investigation around, but I never really got started due to one thing or another. So, with now as good a time as any, over the next week or so I'm going to try and get to the bottom of exactly what is and isn't SOA.
The interest for me was born from a project that I was involved with last year, where I was part of a team building a highly scalable enterprise application for a company in retail finance. Instead of building a huge monolithic application, the lead architect came up with a solution that was based upon a collection of "services" loosely connected by a messaging infrastructure. The technology involved here isn't really relevant, but an analogy would be a cluster of J2EE application servers, which each node running a different set of message-driven beans. Data would flow into the system from one end and get routed as a message through a series of nodes, with each node applying a different set of business logic to validate, enrich and process the message. Depending on the outcome of that logic, the enriched message would then be redirected to another node for subsequent processing. Eventually, the data would pop out at the other end. There's a term for this type of architecture that's escaping me at the moment, but think pipes and filters with an asynchronous messaging infrastructure underneath. So, each node hosted a different set of business logic and, as far as other nodes were concerned, the implementation was irrelevant. Provided the node upheld the interface for the types of messages it could handle, then the implementation could be switched out in the future if necessary. I forget what the message format was, but the only important thing is that it was standardized within the architecture.
One of the debates that we had over and over again was whether the nodes were true "services" or whether they were just components. Even today, providing a clear-cut answer is difficult because everybody has their own opinions. When I've looked into this before, I've come up with a list of characteristics that could be used to define a service and I'm going to be looking into each of these in more detail over the coming week. Hopefully, even if this doesn't manage to spark any conversation, I'll have looked into SOA in more detail and will have it straight in my head!
Previous Topic
