Michael, If a good service oriented business model is created in the first place, the need for modification disappears within the development life cycle. If you use user driven Agile approach, constant modification and rework is inevitable..
Regardless, message schema should be interface based or one message schema per interface. Once a interface is published, it should not be changed. new operations should be placed in new interfaces with new message schema. Old clients do not know new interfaces and new clients can use both new and old interfaces. When old clients use new interfaces the old interfaces gradually retire. Jerry --- Michael Poulin <[EMAIL PROTECTED]> wrote: > I have a common case in a service design and would > like to solicit > your opinions on the solution. > > Assume we have a function which can process data and > also store the > processing results. At first, the service > implementing the function is > proposed having 2 operations Process and Commit, > where Process is > only processing requests while Commit is processing > requests and > storing the results. Service is stateless and Commit > uses Process > internally. > > An alternative solution offers only 1 operation > Process - which can > accept a request with a "flag" of different values; > at this moment, > its are `process-only' and `process-complete'. The > former states for > the Process operation and the latter states for the > Commit operation > in the first design. > > The first design is introduced as `transparent' to > the users. At the > same time, it leads to the intensive service > modifications if more > operations related to Process would be added, like > Publish, Pass/Send, > etc. Plus, a hidden combination of Process with any > other operations > make management of the Process operation quite > complex and its SLA - > not well predictable ( because of unmanaged > `contributions' from other > operations). > > The second design operates with multiple message > schemas through the > same service operation. When new combination of > processing with > additional feature is needed, new message schema > gets issued and used > by those in need. This simplifies service updates > but increases > governance and management of consumer management > over the service > versions. In spite of more complex management, the > solution reuse and > flexibility/adaptability to the changes in the > business requirements > significantly increases. > > So, the first solution is better for developers, the > second solution > is better for business. > > So, what would be your opinion on mentioned case? > Any alternative > proposals are highly appreciated. > > - Michael > > >
