--- Michael Poulin <[EMAIL PROTECTED]> wrote: > Jerry, > "a good service oriented business model" eliminates > modifications in normal life. Just for last 6 months > my team had to implement 3 new industry regulations. > Unfortunately, we have to be agiled with > Compliance...
I believe industry regulation life cycle (five to ten years?) is longer than SDLC (six months to two years?). Probably new regularions are already there before your design bengins. Regardless, if your design follow Open/close principle (model business in right way), change can be contained (no modification but extension). Agile can be thrown out of the window. Does new industry regulation impact business model? if yes, in what way? Business model and business rules can be used in ways that contain change. Hence expected change is not modification. > > Statement "one message schema per interface" is > questionable: how many schemas do you have in the > interface if you use "include" operation? I think > that finally you get one but aggregated from many. > If you add/remove operation, the interface changes > (while service may stay the same). Strongly saying, > if the aggregate message schema changes, the > interface changes as well. The idea is not one or two message schemas but close to modification once interface and message schema are published. Open/close principle must follow to have high quality low cost solutions. > > However my question was about different thing: when > I extend schema and re-publish the service interface > at the same end-point, I can have both old and new > consumers use it. If I change interface by > adding/removing operations I have to have separate > end-points for each operation combination. Plus, old > consumers have to change their 'code' to access new > end-point(s). So, which way is better from the > consumer perspectives? What about adding new interfaces to the same endpoint? Old consumers do not know new interfaces. New ones can use both old and new interfaces. Every one is happy. Or a different solution. Create a second endpoint polymorphic to the first one with more functions (or more interfaces). When old consumer call first endpoint and he is routed to the the second endpoint without knowing it. The first endpoint is eliminated. Jerry > - Michael > > ----- Original Message ---- > From: Jerry Zhu <[EMAIL PROTECTED]> > To: [email protected] > Sent: Tuesday, October 23, 2007 9:21:37 PM > Subject: Re: [service-orientated-architecture] > operation granularity dilemma > > 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] com> 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 > > > > > > > > > > <!-- #ygrp-mkp{ border:1px solid > #d8d8d8;font-family:Arial;margin:14px > 0px;padding:0px 14px;} #ygrp-mkp hr{ border:1px > solid #d8d8d8;} #ygrp-mkp #hd{ > color:#628c2a;font-size:85%;font-weight:bold;line-height:122%;margin:10px > 0px;} #ygrp-mkp #ads{ margin-bottom:10px;} #ygrp-mkp > .ad{ padding:0 0;} #ygrp-mkp .ad a{ > color:#0000ff;text-decoration:none;} --> <!-- > #ygrp-sponsor #ygrp-lc{ font-family:Arial;} > #ygrp-sponsor #ygrp-lc #hd{ margin:10px > 0px;font-weight:bold;font-size:78%;line-height:122%;} > #ygrp-sponsor #ygrp-lc .ad{ > margin-bottom:10px;padding:0 0;} --> <!-- > #ygrp-mlmsg {font-size:13px;font-family:arial, > helvetica, clean, sans-serif;} #ygrp-mlmsg table > {font-size:inherit;font:100%;} #ygrp-mlmsg select, > input, textarea {font:99% arial, helvetica, clean, > sans-serif;} #ygrp-mlmsg pre, code {font:115% > monospace;} #ygrp-mlmsg * {line-height:1.22em;} > #ygrp-text{ font-family:Georgia; } #ygrp-text p{ > margin:0 0 1em 0;} #ygrp-tpmsgs{ > font-family:Arial; clear:both;} #ygrp-vitnav{ > padding-top:10px;font-family:Verdana;font-size:77%;margin:0;} > #ygrp-vitnav a{ padding:0 1px;} #ygrp-actbar{ > clear:both;margin:25px > 0;white-space:nowrap;color:#666;text-align:right;} > #ygrp-actbar .left{ float:left;white-space:nowrap;} > .bld{font-weight:bold;} #ygrp-grft{ > font-family:Verdana;font-size:77%;padding:15px 0;} > #ygrp-ft{ > font-family:verdana;font-size:77%;border-top:1px > solid #666; padding:5px 0; } #ygrp-mlmsg #logo{ > padding-bottom:10px;} #ygrp-vital{ > background-color:#e0ecee;margin-bottom:20px;padding:2px > 0 8px 8px;} #ygrp-vital #vithd{ > font-size:77%;font-family:Verdana;font-weight:bold;color:#333;text-transform:uppercase;} > #ygrp-vital ul{ padding:0;margin:2px 0;} #ygrp-vital > ul li{ list-style-type:none;clear:both;border:1px > solid #e0ecee; } #ygrp-vital ul li .ct{ > font-weight:bold;color:#ff7900;float:right;width:2em;text-align:right;padding-right:.5em;} > #ygrp-vital ul li .cat{ font-weight:bold;} > #ygrp-vital a{ text-decoration:none;} #ygrp-vital > a:hover{ text-decoration:underline;} #ygrp-sponsor > #hd{ color:#999;font-size:77%;} #ygrp-sponsor #ov{ > padding:6px > 13px;background-color:#e0ecee;margin-bottom:20px;} > #ygrp-sponsor #ov ul{ padding:0 0 0 8px;margin:0;} > #ygrp-sponsor #ov li{ > list-style-type:square;padding:6px 0;font-size:77%;} > #ygrp-sponsor #ov li a{ > text-decoration:none;font-size:130%;} #ygrp-sponsor > #nc{ > background-color:#eee;margin-bottom:20px;padding:0 > 8px;} #ygrp-sponsor .ad{ padding:8px 0;} > #ygrp-sponsor .ad #hd1{ > font-family:Arial;font-weight:bold;color:#628c2a;font-size:100%;line-height:122%;} === message truncated ===
