While I agree with most of the categories listed, I would encourage practitioners not to neglet an SOA repository. There seems to be a misunderstanding by many that a Service registry is something that a human is going to interact with directly. It has been my experience, on several large government contracts, that people, developers, interact directly with an SOA repository to discover available services at design-time. By doing this they also discover all of the related and relevant governance policies associated with a given service component. Service registries have become commodities and are being primarily used by ESBs and the like for service discover at runtime. Tim Vibbert (SOA Chief) SOA Masters Community (www.soamasterclass.com)
On 3/28/07, Jerry Zhu <[EMAIL PROTECTED]> 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] <todd.biske%40gmail.com>> 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
