Recent SOA questions/thoughts

We've had some interesting SOA desing questions lately. Here's a quick rundown with my thoughts...
  • Is it a good idea to wrap DB calls in a web service?
Some argue that this is a waste for internal applications. That these services don't provide any business value - query results are simply regurgitated back to the caller.

While I agree that these calls don't add much business value, the benefit lies in abstracting the DB calls from the caller. In simplest terms, wrapping access means that callers need not concern themselves with managing database connections. Additional changes/enhancements to the schema can now be handled in a single place rather than mandated enhancements to DB clients - even the DB implementation, location, and authentication updates are transparent to users. To me, services like this - services that simplify interactions - are a big part of what SOA is all about.
  • As SOA systems evolve/extend, is it a better idea to plug in new functionality or extend existing components? For instance, let's say there is an SOA application whose flow consists of calling component A followed by component B (A -> B). New functionality needs to be added to the system. You can either modify one of the existing components to add the new capabilities (A' -> B) or you can create a new component and plug it in (A -> C -> B).
If the new capability is functionally similar to either A or B, this may muddy the waters. Regardless of the situation, I favor the plug in approach. Again, I feel this is one of the big benefits of SOA - the ability to add functionality to a system without changing and retesting existing code. It feels simpler and cleaner. Smaller, highly specialized components are easier to debug and maintain than larger components. They're also more likely to be reused. I feel pretty strongly about this.
  • One of the things I still struggle with is when is it better to code your SOA interactions through a business process vs "regular" web service code.
My current thinking is that if all you doing is calling services and mapping values, then a business process approach is acceptable. I'd still rather code these interactions in something other than BPEL, but it may only be because I'm more comfortable with that approach. I've just started to code a rather large business process in BPEL and I'm finding it to be OK. The big benefit comes in the ability to visualize the process via BPN. This makes it easy to review the flow with business users.

Comments

Post a Comment

Popular posts from this blog

I Believe...

A recent reorg at my company left me with a new manager - and a different approach to software development than my team had been previously following.  Our new approach is one that I don’t necessarily agree with, but it led me to think about - and reevaluate -  those tenets of software development that I think are important and that I believe lead to increased quality and productivity. This post will consist of fairly high level discussions about how to organize code, teams, and projects - but contain very little actual code. Many of these ideas will not be my own.  They are mostly ideas I’ve learned from others and their willingness to share their experiences with me.  They are, however, ideas that I’ve practiced and hardened as I’ve worked to build my own ideal environment for delivering value through software . Many of these ideas I now take for granted as commonplace (even though they aren’t).  I felt a need to document them anyway - so people can understand what to expect (a
Read more

Performance Tuning JCAPS - Part 2

It's been close to 2 months since my first Performance Tuning JCAPS post. Since then, we've noticed our servers running out of TCP connections under heavy load. Researching this problem, we learned that the JCAPS' JMS server makes heavy use of TCP in implementing Request/Reply queues . We approached Sun for guidance and they assured us that they've had success implementing high throughput applications using the JMS request reply solution... but how? It appears a multi-step solution is needed. First, running out of TCP connections in a scenario like ours is a JCAPS bug addressed in an ESR (110348) and rolled into JCAPS 5.1.3 Update Release 3 . We installed this update and noticed a marked improvement. Running my simple 75 user simulated test, transactions took 2521 ms to round trip (compared to the previous time of 20128ms). While this is great improvement, an average of 2.5 seconds is still really slow for this simple transaction. We reported our findings to Su
Read more

FRail :include

I really like developing with Rails, but I've been frustrated the last few days by some things Rails should do quite easily, yet doesn't. I've already written here and here about some of my struggles with Rails :include clause. Here's one more... Let's say you have a has-and-belongs-to-many relationship. If you :include this relationship in a find query, Rails will automatically create the join clause including the lookup table! That's cool. Unfortunately, it looks as if only the :include clause provides this piece of functionality. Why isn't the same functionality provided via the :join clause or through a general purpose module? This doesn't make any sense to me! I'm working on a database application where I don't need to display a lot of data, but the data displayed is heavily filtered by it's connections to other information in the database. I need to join a lot of tables to perform the filtering operation and using :include
Read more