Hi, +1. To differentiate with just a messaging bus software, I'm calling it ESB2.0. It's a service infrastructure with 4 capability types you've mentioned. The main difference between ESB2.0 and vendor specific ESB products is that ESB2.0 aims to facilitate independent softwares to work together instead of providing an "all-in-one" box.
Cheers, H.Ozawa Anne Thomas Manes wrote: > Sorry to be lax in chiming in here. > > My definition of the core capabilities required in a services runtime > infrastructure is: > > - Service platform: a container or hosting system that supports the > runtime > lifecycle of a service and provides the framework that enables a > service to > access the infrastructure and communicate > - Service mediation: a mechanism that intercepts in-flight messages and > enforces policies > - Service management: a means to monitor and control services, services > infrastructure components, and message traffic > - Service registry: a means to enable information exchange among services > and service infrastructure components > > A few notes: > - I refer to this infrastructure as a managed communications > infrastructure > (MCI) -- not an "ESB". In my mind, an "ESB" is a vendor product, which > may > or may not be used to implement an MCI. It is "managed" in the same sense > that Java and .NET are managed code environments. The MCI is > responsible for > ensuring that messages are delivered properly according to a set of > defined > policies. > - The MCI refers only to the runtime infrastructure. Capabilities > required > for development and governance are not included in this model. (I have a > separate model for governance infrastructure.) > - Although registries and repositories are closely related, they serve > different purposes and should be modeled as separate capabilities. A > registry provides a single access point to find information required > by the > runtime infrastructure. It provides references to the actual information > (metadata, policy, and management information) which may be (and is > likely > to be) stored in multiple repositories. The primary role of the > registry in > the runtime infrastructure is to support information exchange among the > runtime components. Repositories are ancillary to the core runtime > capabilities. They manage information, and therefore are part of the > governance infrastructure rather than the runtime infrastructure. > - I don't consider a service to be part of the infrastructure. It is the > entity that relies on the infrastructure to communicate. > - The network is below this infrastructure. (The purpose of the > infrastructure is to abstract the network and to enable managed > communication.) > - Security is a cross-cutting concern and must be supported by all > infrastructure components. Policies dictate what type of security > measures > must be enforced, and each component is responsible for enforcing them. > - A typical runtime infrastructure will include multiple platforms and > multiple mediation systems, and may include multiple management > systems. You > may elect to set up multiple registries, but multiple registries can > create > federation issues. I view a registry as establishing the boundary of an > information domain. > - Mediation can occur anywhere along the the message path -- as an > interceptor in the service platform, as a proxy for a service > endpoint, as a > central broker, or as an access control point (e.g., in the DMZ). As I > said, > a mediator enforces policies. Policies define the rules that apply to the > message exchange. They specify rules related to routing, caching, > persistence, transactions, security, transformations, or whatever else is > required to enable the two service endpoints to communicate. Mediation > should be performed wherever it is most appropriate to perform it, > although > you want to keep the number of mediators in a message path to a minimum. > - Mediators are responsible for managing federation between security > domains.Requirements for trust, privacy, authentication, etc, are > defined as > a set of policies that apply to a specific interaction between two > parties. > For example, if the interaction requires a secure conversation, the > infrastructure should automatically manage the process through which the > participants exchange keys and establish a secure session (e.g., using > WS-Trust and WS-SecureConversation). > - The management system should be able to gather management > information from > all infrastructure components, but today we don't have pervasive > management > standards. Therefore, for the moment, you need dedicated management > agents > to collect management information. Many mediation agents also act as > management agents. > > I think these notes address all the questions raised in this thread. > > Anne > > On 31 Mar 2007 04:08:51 -0700, Stefan Tilkov <[EMAIL PROTECTED]> > wrote: >> >> On Mar 30, 2007, at 5:32 PM, Bill Barr wrote: >> >> > >> > 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. >> > >> >> The one registry I know pretty well, Systinet's UDDI registry, always >> had a user interface -- so I don't see this as a major distinction. >> In my understanding, registries store references to all kinds of >> service artifacts and some additional metadata, while repositories >> store the actual artifacts themselves. >> >> Stefan >> -- >> Stefan Tilkov, http://www.innoq.com/blog/st/ >> >> >
