--- Michael Poulin <[EMAIL PROTECTED]> wrote: > 1. I promote the same > statement - Agile methodology is inadequate to the > distributed shared computing. >
Agile is code and fix methodology. One technique is refactoring. Modifying existing code to fit into the new requirements. Not sure if it is good for SOA project and this is not Agile methodology list. > > > 2. How do you define "Open/close principle"? > > Google search you will find on the first page. > > 3. How provider distinguish which interface is > requested if more than one is > associated with the same end-point? > I am not saying multiple interfaces per end-point is a way to go. But if so, The providers is self contained and has no knowledge of consumers. It is consumer's job to find what interface is useful. Provider documents its service in ways easy for consumers to understand. > > 4. I think a provider may not route a consumer to > the end-point which is not agreed on in the Service Contract. So, the way I prefer is having a individual > end-point per version. If a new version must replace > the old one, it requires either a graceful migration period when two end-points are known to the > consumers (preferable mechanism of the migration > must be defined in the Service Contract) or it has to be a period of un-availability (also defined in the > Service Contract) when provider and all consumers > upgrade to new version. > Why we keep versions? If newer version appeared, do we still keep old versions? If we modify current functions, do we keep or use old functions? Single end point multiple interfaces maybe a way to do. Versions are multiple interfaces? each version is a interface? Jerry > > 5. Since SOA Service follows a business concept of > service, not everything has > to be automated. > > > > > - Michael > > ----- Original Message ---- > From: Jerry Zhu <[EMAIL PROTECTED]> > To: [email protected] > Sent: Friday, October 26, 2007 1:55:24 AM > Subject: Re: [service-orientated-architecture] > operation granularity dilemma > > > > > > > > > > > > > > > > > --- Michael Poulin <[EMAIL PROTECTED] com> 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 > === message truncated ===
