SOA Design Architecture

Can i check what are the pros and cons of having a generic web service for differen开发者_如何学Ct service provider and having a separate web service for each service provider?

Is there any articles i can reference also?

---

The benefit is that it is easier to create the infrastructure portion.
The disadvantages are that you now need to write more code to separate the different messages and dispatch them to the proper module for processing. Your code will be more complex and harder to maintain.

---

having been down both roads, i would suggest you consider smaller versioned services as opposed ton one large kitchen sink service.

take the unix philosophy of doing one thing and doing it really well. put a version number on it so you can upgrade with out breaking consumers. also try to keep the code for each version separate from each other. once version 1.0 is in production, you don't want to accidentally break a contract with a consumer who may have already coded around your bug. just publish a new version and nudge your consumers to the upgraded service.

---

BostonBob speaks the truth, service granularity should be scoped to one capability, this aids maintainability in the long run as things live in only one place and are logically cohesive.

As for service operation granularity the sweet spot seems to sit between 3 -5 operations on a service contract, with 12 as the upper limit, if there are more chances are you an decompose it into two useful services.

Here are some practical examples of how to build a SOA

I would suggest you read articles by Thomas Erl and Roger Sessions, this will give you a firm handle on what SOA is all about. And how to partition the services

SOA Design Pattern

Achieving integrity in a SOA

Why your SOA should be like a VW Beetle

SOA explained for your boss