See inline... On 02 Apr 2007 08:20:39 -0700, Jerry Zhu <[EMAIL PROTECTED]> wrote: > > My summerizing Anne's message about SOA capabilities > organized as a hierarchy. So it is a SOA Capability > Reference Model? > > Capability Domain (CD) > Capability Type (CT) > Capabilities > > CD provide high level view of SOA capabilities needed > to support functions in a SOA infrastructure. CDs are > comprised of CTs that further categorize and define > the capabilities in each domain. CT group similar > capabilities in support of the domain. Each CT > includes one or more capabilities that provide the > "building blocks" that collectively deliver the > required functions to the SOA infrastructure. The > capabilities can be encapsulated into infrastructure > servcies/components to fulfil certain functions.
One important thing to keep in mind is that products frequently do not correspond one-to-one with capability types. Often a product addresses multiple capability types, but rarely does it fully implement all the required capabilities in a capability type. As I said, a large organization is likely to have multiple platforms, mediation, and management systems. It may also use multiple registries. > Anne mentioned three CDs: Service Runtime, Service > Governance, and Service Development. Anne further > specified CTs in Service Runtime Domain as below: > > Service Runtime > Service platform > Service mediation > Service management > Service Registry > > Anne, and all of us, still needs to provide content in > other two domains. And as is clear from your questions, it would also be helpful to break down the runtime capability types into their constituent capabilities. > SOA capabilities are SOA infrastructure capabilities > to be configured not coded. We all want to minimize > coding efforts so we need to know what to buy and what > to code. As a general rule, I recommend buying generic technology rather than building it, but even if you elect to build it yourself, the required capabilities of the infrastructure are still the same. My model attempts to define the capabilities required in a SOA runtime infrastructure. An important concept of the model is the clean separation of concerns between business functionality and infrastructure functionality. This is not so much an issue of what to buy versus what to build -- it's an issue of what to implement in a business service versus what to externalize to the infrastructure. Anything that is not directly related to processing your business algorithms can be construed as infrastructure. Any aspect of this infrastructure functionality that is generic can potentially be externalized to the infrastructure and implemented as infrastructure services. (i.e., applying SOA principles to infrastructure functionality) Once infrastructure functionality is externalized into services, it can be configured declaratively and invoked automatically by mediators on behalf of a service or service interaction. I refer to this concept as the Infrastructure Services Model (ISM). > Benefits of having a clear picture of SOA > capabilities are many and I leave it to the group to > elaborate. One thing is that customers would be able > to look at their business capablities to undestand SOA > capablities needed and ask vendors to what degree > their products meet their needs in terms of SOA > technologies rather than having vendors dictate their > SOA capability needs. Exactly! Before designing an infrastructure -- and certainly before buying products--you should understand what you need. This capability model helps you understand what you need. > > Now in responding to Anne's message: > > - Anne gave four CTs in Service Runtime Domain. I > think that two more are needed. They are Messaging > Backbone (transport data as messages in secure and > reliable fashion) and Cross Protocol Communication > that can be done in three ways: protocol bridging, MOM > bridging, and Direct Protocol Handling. I contend that you do not need a messaging backbone. There is no requirement to rely on any specific messaging protocol. The middleware that a service can communicate with is a function of its service platform. There is no requirement that all services must communicate using the same middleware, nor is there a requirement that all messages must be carried by a common carrier. There is also no need to call out a specific "cross protocol communication" capability. Protocol transformation is no more critical to the environment than security mediation. It's just another form of mediation. The mediation systems are responsible for managing whatever mediation might be required. That's the whole point. An endpoint can converse using whatever protocol or middleware it needs to. At runtime, the infrastructure automatically routes the message through whatever mediators are required to deliver the message properly. The instructions regarding "proper delivery" are specified declaratively in policies (or you might call them configuration files). Policies define all aspects of mediation requirements, including routing, transformation, persistence, caching, reliability, transactions, security, auditing, logging, or whatever infrastructure function is required. Mediators rely on infrastructure services in the ISM to implement the required infrastructure functionality. > - Services not being a part of the infrastructure, I > disagree. What about integration services: > Transformation Service, Content Based Routing Service, > and application adapter? do we code them or we buy and > configure them? I should have been more clear. I meant that business function services are not part of the infrastructure. Services that implement infrastructure functionality are clearly part of the infrastructure (the ISM), but in this model they are encapsulated under the Mediation capability. (Note that an application adapter is a platform capability rather than a mediator capability. It is the mechanism used to expose functionality as a service.) > - Are mediator and interceptor the same thing? how > are they implemented? Are they something we buy and > configure? If so, they would be placed somewhere in > SOA capability (reference model)? An interceptor is a form of mediator. Mediators can be implemented as handlers/modules in a message processing pipeline, as a proxy for the service, as a central hub, or as a central access point (e.g., in the DMZ). Your infrastructure should give you the flexibility to deploy mediators in the most appropriate way to address the mediation requirements. > Apparently, the questions in this thread are far from > being addressed. I am sure more questions will emerge > as we are moving along. > > Best to all, > > Jerry Zhu > > > --- Anne Thomas Manes <[EMAIL PROTECTED]> 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/ > > > > > > > > > > __________________________________________________________ > It's here! Your new message! > Get new email alerts with the free Yahoo! Toolbar. > http://tools.search.yahoo.com/toolbar/features/mail/ > > >
