In addition to my webMethods stuff, I've being doing a fair amount of .Net stuff lately. I decided to run through the new MVC framework tutorial from Microsoft just to see their new take on this old pattern. The tutorial is located here.
I must give props to folks over at the ASP.NET web site. They have done a very nice job with the content on MVC. This particular tutorial was very straightforward and explained MVC very well. If you are inclined to check it out pay particular attention to section 4 on abstraction and loose coupling. That is really good stuff. This section is written in terms of OO concepts but they apply as well to the services world. Thomas Erl explains some of the differences between OO and services here and here if you want more detail.
MVC has long been a highly regarded pattern in the user interface world. The interesting thing is this same pattern with some modification can be used in the SOA world even when GUIs are not involved. The Service Facade pattern as explained here by Thomas Erl is closely related in concept to MVC. There are differences but I think you will see the overlap and the potential of MVC in the services world.
I think one of the biggest mistakes some developers and architects make when jumping into the SOA world is to wrap existing stuff in a standards based interface and then go at it directly. While there is really nothing wrong with wrapping existing stuff in a standard based interface, invoking it directly is another issue. Spending some time with the Facade pattern and MVC can pay off in a more agile and resilient set of services. I have personally found that the associated overhead of these extra layers of abstraction are minimal and well worth the small cost.
Rob Eamon has also gone through some MVC content and has posted his thoughts on the Nerd Dinner walk through on his blog. Check that out when you get the chance.
7 comments:
With the facade pattern, are you suggesting that there should be an interface to the interface? Why define an interface that cannot be invoked directly?
Are not all service interfaces facades?
Hey Rob,
Hope all is well with you. No I don't think all interfaces are facades and in fact most are not that I have run into. What I see a lot is an existing component enabled as a service.
What that becomes is a brittle exposure into an existing service. Agility usually goes out the window. Data definitions(what little there are) are tied directly to that component. Changes to the component usually impact all of the calling services resulting in a big mess.
The facade pattern encourages abstraction of data definitions and provides a layer of buffering. It is more true in my opinion to the idea of programming to an interface. The general idea being to shield the calling applications from the underlying implementation.
It does add some overhead(but not much) and has proven for me to be very agile. I think it shares the same goal as the MVC pattern which is ultimately trying to shield the presentation layer away from the underlying ever changing business logic. This shields away the caller from the underlying implementation of the services.
It also allows for testing without the underlying actual service being developed. Much like the MVC pattern does as well.
A service interface isn't suppose to expose the underlying implementation details. The service interface is supposed to shield calling applications from the underlying implementation. It is supposed to present an abstraction of data and behavior.
If the interface doesn't hide this then it isn't a good interface definition and violates a core principle of SO--interface stands separately from implementation.
"It also allows for testing without the underlying actual service being developed."
Spot on. One can use mock services behind the interface for testing.
Oops, I meant to say mock components, not mock services.
"It is supposed to present an abstraction of data and behavior."
Yep I agree and some do. But I still like the Facade pattern. I think it provides the most interface like interface. It's kinda of a grey area (notice how I got my blog title in there :) ). It's grey to me because a service interface is not completely abstract like an interface say in Java or .Net. It's close but not quite there.
I think we are on the same page about services I just like the extra layer of abstraction the Facade layer provides.
Interesting thought on the MVC pattern applied to service implemenations. My take:
Model - The core service implementation providing the RWE.
Controller - The service interface implementation interacting with the service implementation providing a "view" to the consumer.
View - Code and document related to the "presentation" exposed to the service consumer.
Do these match your view?
Yes that is the idea. It's not a purist MVC but I think it is pretty similar in what it is trying to accomplish.
Post a Comment