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/
