Anders Norås' blog

Using Type Definition Assemblies to ensure efficient SOAs

A common argument against SOAs is that using web services has an unacceptable performance overhead. Even though studies show that ASP.NET web services have decent performance compared to remoting, performance worries are often justifiable when the architecture dictates that everything should be a service. Performance wise, web services don’t stand a chance compared to tightly coupled, direct method invocations.
Many developers chose performance over flexibility when they’re facing performance trade offs.
To ensure efficient service oriented architectures, common functionality must be accessible through multiple interfaces. The first step towards achieving this is to delegate the actual implementation of a service to a business component instead of having the business logic in the web service itself. This enables you to make tight calls to your business components within the service boundary while still thinking in terms of services. However, in doing this you introduce a new aspect into your architecture. When service invocations don’t necessarily come through a web service endpoint, how does one keep a mutual understanding of type definitions between the different businesses objects?
For example; how can you ensure that all business objects have a common understanding of what an order is? Web services and their clients use the XSD schema information embedded within the WSDL contract to establish this understanding, but the WSDL doesn’t apply to direct method calls nor would it be efficient to use XSD schemas to share type information between middle tier business objects. To enforce type fidelity across multiple business objects in multiple application domains you can create a type definition assembly with classes defining the various types used by business objects and web services alike. This assembly can be referenced in all business objects which use the custom types. This type definition assembly can even be used by clients to provide a richer programming experience than then shallow types WSDL.exe generates. Attentive readers might have concerns about the web services being too tightly coupled when the same assembly is referenced both in the service and in the client. If you share this concern, you still have the option to use WSDL.exe to generate client types representing the various types defined in the XSD schema.

Separate type definitions, used in conjunction with service agents and façades, make it easy to make it transparent whether you’re using a web service or a business object directly. For more information on type definition assemblies and SOAs read Jeffrey Hasan’s excellent book Expert Service-Oriented Architectures.