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.
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.
Posts
No comments:
Post a Comment