How do you use ibatis in a service oriented architecture efficienty?

We have several services, each of which should ideally operate independently of each other. The primary use of the services is to support our webapp. We are searching for the best way to use ibatis with those services.

Our first approach, was to have one project with the SqlSessionFactory and have all service implementations use that project for data access. This means that project depends on all of the services (we had to seperate service and impl to eliminate circl开发者_如何学运维e dependency) for the data objects, and it contains all of the sql maps. The advantage would be one instance of SqlSessionFactory anytime, and one config to manage. Though if one service is used like for junits, or some other utility, all sql maps are loaded regardless, and all services are a dependency.

Another approach would be to have each service have it's own ibatis config and instance of SqlSessionFactory. This would avoid the need for the mecca of dependences on the data access project, but means several instances of SqlFactory on the webapp.

I like the second approach, though I see good and bad in both.

What would you do? What you add or take away from my argument?

Please Help!!!

---

Although I think that the strength of your first argument points to the weakness of SOA in general, I think that if you are doing SOA, it defeats the whole purpose to then make all of the services interdependent on each other.

If you are doing SOA, you are accepting the tradeoff of more inefficient resource usage for the sake of decoupling and isolation of the components.

---

Honestly, keep it simple until you find a performance bottleneck or your application grows too large. That is, unless you expect services to be independently updated on their own schedules.

Where I work, there is common code that is shared among all applications. It all comes from the same source, but is independently built into each application. This probably isn't the best solution, but at least it makes it easy to modify common code with out worrying about a separate app being deployed. And it allows common code to change as more applications are introduced, with out effecting previously deployed apps.

---

If both solutions can apply, you probably have all of your services run on the same JVM. In my opinion, you should think of running the components in separate JVMs. A true Service Component Architecture is one where you have several components (EJBs for instance) that run in a clustered environment and talk to each other in a loosely coupled manned (through JMS for instance, or Webservices or RMI, etc). Each component is independent and possibly runs in a remote server.

In this case, I would use of course the second approach. But if your application doesn't need this decoupling, you should use the first approach, since it's more memory efficient.

It's after all, a question of what your application really needs.