SOA Vs. Spring

Hello All,

I would like to share with Spring's community a big debate that we are conducting at my work place this days.

As a member in the Architecture team we where asked to roll out the "Information System high level architecture"

In the group we found out that there are 2 main "camps" -

Group A - in short: SOA
Details: We should eliminate the concept of systems and think about developing services. Each service should be autonomous, re-entrant (stateless), SLA based... bla bla bla.
This group believes that every layer should be loosely coupled to the other layers using an Enterprise System Bus (ESB). The UI (WEB) should talk with the logic through web services etc.


Group B - "System of systems"
This group believes that SOA should bring evolution not revolution to our existing architecture. this group think that we should continue to build systems but we need to think of them as system of systems and the way to wire them up is using Dependency Injection (e.g. Spring). We believe that eliminating a one big monolithic system can be achieved in-process using DI Container and that the ESB/Web-Services (out of process) is a performance killer and an anti-OO technology. We believe that there is a place for a ESB/SOA in our architecture - but only as a way to integrate between systems/legacy and not over-use it as if it was a Microkernel.....

What do you guys think - who is in favor of group A and who is in favor of group B and why? - do you think that using Spring promotes the purpose of SOA or is it bad and promotes a back-door for one big monolithic system??

For the protocol - I'm in group B ;)

Though i can't share much of internal architecture, we are using combination of SOA & Spring in the project.
We have some external set of services that we have no control over & we need to leverage them. We are using Spring, Dozer to simplify the process of accessing these services [through usage of Adapter pattern. We have highly decouple systems]
the front-end uses JSF which in turn uses Service Locator pattern, not knowing whether the Service is local [for mock tests] or remote, again using Spring.
Most imptly, we wanted to use Spring's AOP [including transaction demarcations], DI, templating features...
I know SOA could be a overhead since it is an evolving process but there are advantages of using web-services, ESB etc.
I would suggest looking into ServiceMix from apache. it has pretty good support for Spring. Also, look into Apache Axis for making your life easier in developing services [though i would recommend XFire bcoz it nicely integrates with Spring]
I think its important to first assess whether you need SOA in your company, including cost implications, maintenance overhead etc... People from Group A might be reading those CIO magazines & suggest by reading through the fluff..

My opinion is that the hard part of SOA is defining the set of services in your architecture. That is a design challenge. Spring has nothing to do with that, nor does any ESB or any SOA-ish product sold by a vendor.

Where Spring always fits well for me is in the implementation of the services. You want to use good OO principles in building these services, and for me, Spring is excellent in wiring together loosely-coupled objects to build the services.

Once you have your services defined and implemented, you can then think about how to “orchestrate” them, as SOA enthusiasts like to say, and it sounds like that’s where your different camps disagree.

As an example of orchestration via an ESB, BEA’s AquaLogic Service Bus docs show a tutorial where a loan application is received and then routed to one of two loan services based on the content of the application. Using AquaLogic, you use an admin console to declaratively create a logical service (called a “project”) that has a proxy service that decides which business service to send the application to. AquaLogic has neat little wizards to help you do this graphically, so you can fire all of your developers after they’ve built the services ;). With Mule and ServiceMix, you’d do this work declaratively via XML configuration instead of a whiz-bang GUI (Mule and ServiceMix also cost about $75k less than AquaLogic).

But of course, there’s no reason why you can’t create this integration logic using Java code. You could easily make a “LoanServiceSelector” class that has dependencies on multiple loan services, and you could code the logic for selecting a loan service in that Java class. You could then define this as a bean in your Spring container and expose it as an Axis/Xfire/Glue/etc web service, or via RMI, or via Burlap or Hessian, or via anything you’d like. It’s a service no matter how you do it. And you can wire in dependencies on loan services through Spring, and those loan services could actually be web services, or Burlap services, or local objects. Spring’s remoting package will handle that plumbing, just like a lot of ESB products seem to handle this kind of integration plumbing.

And of course, Spring isn’t needed in this case, but most of us on this forum probably feel we get a lot of value out of Spring, so we use it.

So basically, my opinion is that the real work in building an SOA is identifying and designing your services. How you then orchestrate them is the easier part.

Do a trade study on ESBs, and if you feel like you get a lot of value from a particular one in relation to the cost, then use it. Mule has some pretty good examples of using an ESB, and if you read the user email list, you can read about other problems that people are trying to solve using an ESB. If it turns out that you don’t think you get enough value out of an ESB to warrant adopting it (and learning it), then code the integration logic in normal Java code like you’ve always been able to do, and use Spring to help with the development of that integration logic.

Just to add my 2 cents.

I can understand the problems you outline in your group a vs group b argument, I've gone through the same in my own head while thinking about moving to an SOA. I'm looking to go there from a more monolithic application which is turning into a headache to manage and extend as more and more functionality is added. The advantages of having a number of independent services hosted in a service container that can be modified, redeployed, started, stopped etc. without effecting the others is becoming more and more attractive as my system grows. I'm starting to view SOA as code reuse taken to the next level above classes and packages (I'm guessing this is not a novel thought).

What I'd like to point out is that I think there's a middle ground. For example, your group A seems to equate SOA with web services. However, if you look at an ESB such as Mule or ServiceMix they provide a large number of ways to communicate with a service, including a in-vm protocol and more lightweight remoting protocols such as Springs http invoker. Those, along with a correct granularity of your services should mean there's not much of an overhead going this route. Personally, I have a remote swing client so these concerns have had to be addressed already.

In fact, I already have a poor-mans SOA going in which I deploy each service (implemented using Spring) as another web application (war) and expose the methods remotly using Springs HttpInvoker. This is currently only for services used by my swing application but the concept works very well, which is why I've been looking to a more extensive solution for all my services.

Also, I found the book Enterprise SOA: Service-Oriented Architecture Best Practices by Krafzig, Banke, and Slama a very good explanation and one of the only ones I've read that does not equate SOA with web services.

Jonny

Quote:

---

As a member in the Architecture team we where asked to roll out the "Information System high level architecture"

---

What are you building?

Is the person in your team who wants the web layer to talk via web services the service objects going to put their balls on the line and take responsibility for performance?

Maybe you could to take a look at the software architecture of a typical Spring app so you don't risk over-engineering some solution.

You can always expose services using Spring remotely without building this assumption into the foundation of your application.

We've also recently started building some non-core application modules in Spring as JMX components. This gives us some of the benefits of SOA.

Quote:

---

Originally Posted by gmatthews

What are you building?

---

We are building a classic web based information system. The project is very large and it is divided into sub domains / sub-systems / services (depends who you ask in our company...)

The 2 big argues against Spring (and in favor of SOA) is:

1) Building large systems using Spring promotes monolithic systems. The reason is simple - once you are aware that you live in a single process, you start using bad habits like static members (e.g. caching) that are publicly available to everybody... or using transient objects as parameters etc. When you use process boundaries as a way to isolate sub systems you are guaranteed that your programmers won’t use this patterns.

2) When you want to expose your system to tools like business activity monitoring / statistics and usage analysis - the ESB becomes a much elegant and integrated environment to do this. It is true that the Spring Container can do this (using AOP) and indeed some services do exist/planed like Tibco, messaging, dist.trans. etc but this is much harder to implement.

Are we talking about SOA (non-Spring) vs Spring, or SOA using Spring vs Non-SOA using Spring?

I'd disagree that those two points are not problems which need to be experienced when developing with Spring.

1. Under a Spring approach, it seems at a high level like its still an option to build modules independently but run the thing in-process. i.e. take an SOA approach but don't force use of web services to communicate between modules.

Create module-a.jar, module-b.jar, each with its own applicationContext.xml, which does <import>'s of the various other Spring .xml files within each module.

The Spring configuration which ties it all together would just load all the applicationContext.xml files. There's an example of this in the Spring doco.

2. Spring 2.0 makes it easy to export beans to JMX which can assist with monitoring (and configuration). Autoproxying also makes it pretty easy to put debug/performance monitoring interceptors across your code for monitoring.

Quote:

---

Originally Posted by robrudin

Once you have your services defined and implemented, you can then think about how to “orchestrate” them

---

Thanks for the reply; I would like to challenge you a little bit more...

It is true that orchestrating stuff is a nice idea but think about this -

How do you orchestrate this (pseudo):

for each item in list_of_items_from_sys_A do

call sys_B_get_info(item);
end

If you have 500 items - doing it in a SOA world would cause 500 cross boundary hops. What would be the impact on your system?

The SOA specialist would say at this moment - "You are doing this all wrong! it should be message oriented!"

The problem with message oriented is that it KILLS Object Oriented.

This days, its all about integration and if 80% of my use cases requires information or flow between sub-systems (or services) - what is the price we are willing to pay for using SOA??

Quote:

---

Originally Posted by gmatthews

take an SOA approach but don't force use of web services to communicate between modules.

---

This is true in theory - but think about the things that programmers can do -

If team A (module_A.jar) knows it reside in the same memory and runtime space as the code that team B (module_B.jar) they can declare a static member that team B can read/write to. This leads to monolithic systems

I can think of other examples - inheritance is a big one...

Quote:

---

If team A (module_A.jar) knows it reside in the same memory and runtime space as the code that team B (module_B.jar) they can declare a static member that team B can read/write to.

---

In practice, this would be quite easy to prevent via inspection, and using something like Lattix to check module dependencies.

Over and above manual inspection or something like Lattix, it would probably be reasonable to want to test module_B.jar against a mock version of module_A.jar, and/or compile module_B.jar against only the interfaces of module_A.jar -- in either case your scenario falls over.