Anne, You basically talked about four components/systems in a service infrastructure: Service hosting system (I would not say platform), service mediation system, service management system, and service registry system. If this is what you meant, can you elaborate further what are subfunctions in each system and related vendor products. how the systems interact etc.
thanks jerry --- Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > Sorry for the confusion. I didn't mean to imply that > registry is responsible for reliable messaging. Registry is not involved in the message flow between > service endpoints. Service endpoints and mediation > systems are responsible for managing message flow. > > My point is that a services infrastructure comprises > many components from multiple vendors. infrastructure components include (from a functional > perspective), service platforms (which host service > endpoints), service mediation systems (which control message flow and enforce policies), and > service management systems (which monitor message > traffic and infrastructure > components and control infrastructure components). > These components must > share information about services (metadata, > policies, contracts, SLAs, > heuristics, etc). These diverse components have no > means to communicate > directly, nor do they have the means to directly > discover what other > components might be deployed in the environment. > Keep in mind that the > services infrastructure is a loosely coupled set of > cooperating components. > Registry and the UDDI protocol provides a standard > way for these diverse > systems to discover, share, and exchange > information. All systems know how > to talk to a registry via UDDI. Any system can post > information about a > service artifact in the registry, and through that, > any other component can > discover information about the artifact. Quite a few > products today rely on > UDDI to discover and exchange information about > services (XML gateways, SOA > management systems, and a few ESBs -- i.e., the > mediation systems). > > Anne > > On 2/8/07, Jerry Zhu <[EMAIL PROTECTED]> wrote: > > > > Anne, > > > > My understanding about registry in our discussion > is > > that it stores info about services (could be COM > > objects also) not services themselves. Three types > of > > info: properties/location of servicies and > regulations > > of how to use the services. > > > > What you said "information exchange among the > diverse > > set of systems used to manage communications and > > message flow at runtime" is message managing > function > > that is an entirely different issue. I think that > > Microsoft and IBM have different solutions > regarding > > reliable messaging. Do not understand you here. > > > > I guess that repositories are used to store > services > > Internet addressible referenced by a registry. A > > registry could refer to services in local and > remote > > repositories. > > > > Registry could be used design time as well as run > > time. So information in registry could be consumed > by > > both human and programs. > > > > > > Jerry > > > > --- Anne Thomas Manes <[EMAIL PROTECTED] > <atmanes%40gmail.com>> wrote: > > > > > Jerry, > > > > > > That depends on which product you buy. > > > > > > I prefer to differentiate registries from > > > repositories, although many vendors combine the > two > > into a single product. A registry's primary role > is > > > to enable information exchange among the diverse > set > > > of systems used to manage communications and > message > > flow at runtime (e.g., platforms, ESBs, > > > XML gateways, management agents, mediation > systems, > > > etc). Given that an orgainzation will almost > > certainly use multiple systems to implement a > > > services infrastructure, it's essential that > these > > > systems have a standard means to exchange > > information related to metadata, policies, access > > points, routing rules, performance, incidents, > SLAs, > > etc. A UDDI-compliant registry with it's standard > data > > model and protocol provides the means to enable > this > > information exchange. > > > > > > Note that a registry acts as an index to > > > information. The only information > > > maintained in a registry is properties (using a > > > name/value pair system called a keyedReference), > > short description fields, and pointers to more > > > information. More comprehensive information, > such as > > > schemas, WSDLs, BPEL scripts, documentation, > code, > > etc, should be maintained in a separate > repository. > > > > > > Most registry products implement the UDDI > > > specification, which defines both > > > a data model (via XML Schema) and a protocol > (via > > > WSDL and SOAP APIs) for interfacing with the > > registry. I view full support for the UDDI v3 > > > specification, including optional features, such > as > > > the subscription and value set APIs, as a > required > > feature for a registry. > > > > > > Registries that fully implement UDDI v3 include > HP > > > Systinet, webMethods Infravio, SOA Software > > Workbench, and Software AG CentraSite. BEA, > Oracle, > > > and Tibco resell/OEM the Systinet registry as > BEA > > > AquaLogic Service Registry, Oracle Registry > > (included with Oracle AS,Oracle ESB, and Oracle > > > SOA Suite), and Tibco Matrix (which is a package > > > containing Systinet Registry and AmberPoint > WSM). > > > > > > Registries/repositories that do not fully > implement > > > the UDDI v3 spec include IBM's UDDI > implementation > > (included with WAS v6 --it supports the required > > > features of UDDI v3, but not the optional > features), > > > IBM WebSphere Registry and Repository (WSRR - it > > does not support UDDI), Sun's registry/repository > > > (part of JES -- it supports the UDDI v3 inquiry > API > > > only), BEA Repository (formerly Flashline -- it > > supports the UDDI v3 inquiry API only), > > > LogicLibrary (it does not support UDDI), > Microsoft > > > Enterprise UDDI Services (included with Windows > > Server 2003 -- it supports UDDI v2), and Apache > jUDDI > > > (it supports UDDI v2). > > > > > > A growing number of registry products also > provide > > > repository features, and some products are > > stand-alone repositories (not really registries) > -- > > > although the exact set of repository features > varies > > > significantly among the products. Most > > registry/repository products provide > > > content management and maybe version control of > > various XML artifacts (e.g., WSDL, XML Schema, > > > XSLT, etc). Some repositories also support a > number > > > of governance capabilities. Some provide > lifecycle > > management of these artifacts with > > > built-in processes to manage transitions between > > > lifecycle stages. Some > > > provide automatic discovery and management of > > > relationships and dependencies > > > among artifacts. Some provide extensive > reporting > > > facilities that support > > > impact analysis, metrics management, and more. > Some > > > provide the means to > === message truncated === ____________________________________________________________________________________ We won't tell. Get more on shows you hate to love (and love to hate): Yahoo! TV's Guilty Pleasures list. http://tv.yahoo.com/collections/265
