Ever asked yourself the question: “Am I (still) doing the right thing?” Well, I did!
I was triggered by someone that asked me why we are making all these changes to EDRA and why we are making all those guidelines about “how to use EDRA”. Isn’t EDRA the perfect SOA framework without all that changes, he asked. Well…. To be honest, I said, I don’t think so. Then of course the next question was: why should we use it? This made me think, are we doing the right thing?
Of course it is much easier to continue talking about SOA for a couple of months or even years, dreaming about al the good thinks SOA will bring us in the future. But he… we have to start somewhere, so why not start now!
There are tons of articles or writings about SOA on the internet, however there are only a few successful SOA implementations in real life projects (that I know off). In my opinion implementing a perfect SOA architecture cannot be done by just selecting the right framework, or tool (at least not at this moment). Implementing SOA needs a different way of thinking! For most of us, getting familiar with this “new way” of thinking takes time. To reduce this time as much as possible, adopting a framework might be the right thing to do. While using a framework, we will encounter all kind off issues that we wouldn’t have found when we only continued reading about the perfect world of SOA.
Whether to adopt a specific framework or not isn’t a decision we can make in one minute. We have to make sure that the framework meets you own architectural requirements. If some (or more) of our requirements are not covered by the framework, we have to find out how easy it is to introduce these requirements in the framework.
This is exactly what we are doing at the moment. We have our own set of requirements and we are mapping these requirements to EDRA features. Requirements that we think are important and are not available in EDRA will be implemented by our self. Of course we have to make sure that our own requirements are up to date with the latest ideas about SOA. This is why requirements are not static but can change in time, based on articles that we read or changes in technology and tools that we use.
For me, Adopting EDRA wasn’t based on its complete set of SOA features. In fact I don’t even think that Microsoft is positioning EDRA as a SOA framework. In my opinion the most important features of EDRA are: supplying a way to separate the business logic from the cross-cutting concerns (logging, authorization, etc.) and separate the business logic from the underlying transport that is used. I think these features give you a good starting point for building distributed systems. SOA features that we think are missing in EDRA (some of them I wrote about in previous posts) will be added to EDRA by our self.
One very important thing I try to keep in mind is to “abstract” the usage of EDRA away as much as possible. For me EDRA is just a piece of infrastructure that is used in our architecture. In the end it must be possible to replace EDRA by any other technology or framework that comes available without having to change all your services within the architecture (or at least as little as possible). So, it’s not only a question IF you want to use EDRA but also HOW you will use EDRA. Spending some time on writing design guidelines for services (interfaces) build against EDRA might give you more flexibility in the near future when switching to another version of EDRA or even a totally new framework or technology.
After spending a considerable amount of time thinking about the above issues, I think using EDRA as a starting point is a good thing to do (for our situation) and resources needed for introducing new (SOA) features will not be a waste of our time. By introducing some good design guidelines for our service we keep enough flexibility for changes in framework or technology in the near future.
So, in my opinion: Yes we are still doing the right thing!!