Data Access Considerations Regarding SOA

In the Data Access Handbook, there's a chapter on service oriented architecture. In this podcast Rob provides a number of considerations regarding SOA (Service Oriented Architecture) that changes data access strategies. This podcast last for 5:37.

You may listen to this podcast here: http://blogs.datadirect.com/media/RobSteward_SOADataAccessStrategies.mp3

Rob Steward:

So Mike, I think what's particular to data access as in service oriented architecture reference to data access, there's some very specific things that we've seen in the real world, so SOA's been around really as an idea for about eight or ten years. What we've really seen is that in the last three to four years is real world implementation starting to roll out, and so what we share in the book is: What is it that we've seen people do that they could do better if they were to change a few things with their data access code within service oriented architectures?

So one of the things that I'll talk about right now is one of the tenets of service oriented architecture is reuse of components, so really when companies do service oriented architectures they're doing it to make themselves more agile in terms of the business, so that's the main thing that you're after with SOA. So another tenet of SOA that goes along with it is you want to capture best practices. So a big thing with SOA is you build your service, or build your services, you are capturing best practices. So for example, if I build a service that takes some item out of my inventory, then I want to build that service in a way that every application's going to use it -- that's why we build the thing, so they can be reused -- but when I do it, I do it in the best possible way. That way every application that uses that service is going to inherit that best coding that I did within that inventory service. So what that means, if you think about that from a data access point of view, is that the data access code that was in that service to remove that item from the inventory, if it's written well then all the applications that use it will have good data access practices just by the fact that they're using that service.

Now, what generally happens in companies that I've seen implement service oriented architecture is that they have some architects who understand services, understand service oriented architecture, understand how to implement it, they talk about governance, they talk about all the things that go around managing services, but what these guys are not is experts in data access. So what I've seen in many places is people will write a service -- let's take that example again, the inventory service -- and they write within it some data access code, and that data access code may not be the best. It may not be the best way to do it: it may be slow or maybe it's OK. What I see more often is that for the first application that needs that service, they write the service, it works fine for them, that application has 50 users, right, and it works fine for them, but again, the tenets of service oriented architecture is another application is going to come along and it's going to use that service, so this service that one team wrote to begin with, that services 50 users within an application, all of a sudden here comes the second application. Now we've got 100 users, and now a third application, and we've got 200 users, and before you know it you've got 500 or 1,000 users on this service that was originally working fine when only 50 people were using it, but once it got to 500, it was working way too slow. Now, this is something that I've seen happen over and over and over. Services get rolled out, they work fine, but as you start to scale up your service oriented architecture and you get more people using them, the scalability just isn't there.

So here's my tip for that: I mentioned earlier that you typically have the services architects when you do SOA. What you also need is data access, the data architect involved as well, so you've got people who know what is the best way to access this data. Make sure they're involved in your planning for your services. Even when you have an application that's only got a few users and you're writing a service for it, remember service oriented architecture is designed such so that more applications can come along after you and use that service, so make sure that you design those services and use all your knowledge of data access and use the things that we talk about in the book to make each service a much better performing service and much more scalable. Again, I've seen this over and over in the last few years where it rolled out, it was fine, but as soon as you started adding users to it you found out, "Oh, you know what, we really have to go back and rewrite that data access code because there's a much better way to do it and make it more scalable."