WSDL Architectural Patterns

While working with Webservices, we all invariably encounter WSDLs. As Software architect and Designer I have noticed four distinct types of WSDLs.
1. A business entity do various operations

2. A business entity do one operation

3. One operation for various entities

4. Various operations for various business entities

Each pattern has its own pros and cons. Except option 3, all are widely used. Salesforce Enterprise WSDL follows option 2 while Oracle AIA is big fan of option 2. Lots of home grown applications in enterprises uses option 2.

For detailed list of operations in webservice refer: http://architecture-soa-bpm-eai.blogspot.com/2011/02/operations-in-service-interface-v-50.html

Varity of Type Definition in a Web Service

In most of WSDLs of enterprise class one finds very simple definitions of types.

But this approach has one serious flaw, if source like to change (generally add) type system, service has to change. To manage changes at source system, multiple versions of a service crop up in enterprise environment. But the good part of this approach is that one looking at types in WSDL can understand the types easily and least documentation is required for attribute/parameters.

To overcome the changing number of attributes/parameters and containing changes in source and target systems only (not in the system which facilitates exposure of functionality as service – web service) one can follow one of the following approaches:

Approaches 2 and 3 have their own set of challenges. Understanding of types is not intitutive and needs documentation with greater details.