I normally break things down into: Service Platforms Service Mediation Service Management
Looks very similar to Anne's model, doesn't it... I prefer to differentiate between policy enforcement, which I view as a mediation concept, from service management, which includes both policy management, as well as service lifecycle management (which is where the passive monitoring, metric analytics, etc.) comes into play. Service Registry/Repository is the tricky one to place in all of this. I'm still on the fence as to whether it is simply the information store that backs service management, or if all the of above 3 sit on top of a service metadata layer. -tb On Mar 28, 2007, at 2:15 PM, Jerry Zhu wrote: > I like the idea do understand the problem before a > solution. The problem is to determine the SOA > capabilities needed. The solution is the products mix > that covers maximally the capabilities with lowest > cost. The SOA capabilities are to be configured not to > be coded when searching for SOA middle ware > products(infrastructure components? ). > > The difficulty is that do we have a good > classification and its comprehensive list of these SOA > capabilities - capabilities that are unique to SOA? > Load ballancing and firewall, for example albeit > important to be considered, are capablities outside of > SOA. > > Anne classified four types of SOA capabilities: > > Service platforms: build, run (composite) services, > lagecy systems encapsulation etc. > > Service mediation: Anne mainly mentioned policy > enforcement here > > Service management: visibility to the environment, > monitor trafic/activities, detect anormally and take > actions etc. > > Regiestry: enable information exchange among services > and infrastructure components. > > To me, service management includes service mediation. > Intercept messages and enforce policies is detecting > and taking actions. > > Todd added network & security (environment to use one > word) SOA capablity category. > > To help with understanding the problem before a > solution, can we have some concensus here the SOA > capability categories and capbilities in each? > > I see four: > > Service platform > Service management > Service network/security > Service Registry > > Once we agree the categories, we can list individual > capabilities under each category. > > Best > > Jerry > > --- Todd Biske <[EMAIL PROTECTED]> wrote: > > What customers should be saying is, "I need these > capabilities, and I want this group to be >> responsible for them." The latter is key, because >> it helps differentiate between activities that are > may still be considered programming efforts, such as >> orchestration/choreography, from those >> that are configuration efforts, such as routing. >> Every organization will have a different set of > capabilities that are important, and different > operational models. Take that information >> and now go talk to your vendors to decide whether > you need an application server, a message bus, an EAI > tool, an ESB, a WSM product, a network appliance, >> pixie dust, a roving band of trolls, or whatever it >> takes. Unfortunately, that doesn't bode well for > vendor marketing. > > > > > ______________________________________________________________________ > ______________ > The fish are biting. > Get more visitors on your site using Yahoo! Search Marketing. > http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php > > > > Yahoo! Groups Links > > > [EMAIL PROTECTED] >
