by Bogdan Nedelcu
14. October 2005 08:51
In the SOA paradigm, exposing the business as a service is not a correct thing to do, services must be the boundary of the system. But some of us develop 3-tier applications where the business server is often separated if not phisically but rather logically from the user interface.
As the webservices invade our every day life I wonder if developing the business server as a webservice would have any benefits to the programmers.
There are some certain reasons why we shouldn't do this:
1. Slower connection - if you develop both the client and the server in .net, then serializing and deserializing into XML is a huge performance drawback, not to take into account the space occupied by the objects.
2. Problems with types - not everything can be serialized into XML
3. Changing the programming model - the types become somehow duplicated, they loose their logic going closer to data then objects.
However if one can wrap up it's business objects as webservices he could have the following benefits.
1. Easy testing and debugging - if a problem occurs you can trace easily the exchanged content using a standard soaptest tool.
2. Integration with InfoPath - hey, we could draw our UI in Infopath and work with just formulaires
3. (and the most important) Automated business testing.
The most important feature about exposing the business as webservices is the posibility to test the business server from a XML-capable testing tool. Send a message to the webservice and receive the result, compare it to the expected result and give a message. Sequences of test can perform complicated business logic tests. Combined with a automated build process one can have a pretty stable build released in a matter of minutes.
How can this be done if for example you're using remoting as the comunication channel, well it's not simple, you should wait for the Indigo platform which exposes the interfaces as webservices natively.
But there are some possibilities if you enter deep into the .NET core and see how they implemented the webservice ASP.NET handler. In our company we implemented such a system in order to expose an interface both as remoting object and as a webservice. This provides us a more stable build and helps the testing team to concentrate more on the human discoverable bugs.
As a project manager it gives me more confidence when I release a build, I'm more assured that all the basic functionalities work, I have a better sleep at night.
328126aa-17ff-4ef4-bdd9-0d1a0c1113aa|0|.0
Tags: