by Geoffrey Slinker
v1.1 March 24, 2006
v1.0 December 7, 2004
|
Accesses: |
|
Maverick Development |
Web services do not follow an object oriented approach because the objects passed to and from a web service are stripped down to just the public fields and all behavior is lost.
I am currently developing C# web services. The first thing you notice is that any object passed to or from a web service is passed as a data only object. The behavior of the object is lost. With out behavior you are not in an object oriented world.
Most of us are very good at object oriented modeling and we think of the world in terms of "is a", "is not a", "has a", "uses a" and other object oriented markers. Since web services strip our objects down to data only objects you may feel like a fish out of water when working with web services.
Almost immediately we come up with mappers to map the data object back into a real object with behavior. Since namespaces are an issue we all come up against the same problems and resort to some kind of mapper whether it is using reflection and introspection or done by copying each field (often by passing the data only object into the constructor of the "real" object).
But this does not help in modeling the system.
Recently I have been designing a complex system that is to use web services and a service oriented architecture. To make a long story short I designed my system in a traditional object oriented fashion. I identified objects and behavior. I identified abstract types and factories. I designed the system just like I have done since 1987 when I was using C++, Object C, and Object Pascal.
After I finished the design I looked at my high level objects. I identified which objects are the ones that drive the system. Then I looked at the interfaces that these objects implement and the public methods that they have. From those I created a facade that unifies the high level ojbects and exposes the behavior. This facade is implemented in C# by inheriting from System.Web.Services.Webservice. By using the facade pattern I was able to bring to bare all of my experience with object oriented design and then leverage the well known facade pattern. Also, I find that it is very similar to doing the adapter pattern because web services and service oriented architectures deal with interfaces, binding, and transport issues and the web service that I implement wraps the existing objects so that there is a standard interface to the system.
After I had implemented the facade I recognized that this was very similar to a problem from my past where I had to wrap C++ code with C code. C code does not have any object oriented aspects. The C++ code had been designed and implemented using object oriented techniques. The C code was added later. It is very similar to adding a web service layer over C# code.
When designing a system that is to expose its functionality through a web service then design the system using traditional object oriented techniques and then make a facade that is the web service that unifies the system so that it can be called and used as a web service.