There seems to be a misunderstanding by many that a Service registry is
something that a human is going to interact with directly.
Agreed. Registries are machine-readable and repositories are
human-readable. The two need to be aggregated into a single capability.
--
email: [EMAIL PROTECTED]
________________________________
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of
Timothy Vibbert
Sent: Friday, March 30, 2007 6:58 AM
To: [email protected]
Subject: Re: [service-orientated-architecture] ESB Standard
Definition - SOA capabilities and its categorization
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
<http://www.soamasterclass.com> )
On 3/28/07, Jerry Zhu <[EMAIL PROTECTED]
<mailto:[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]
<mailto: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
<http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php>
