You should establish a standard deployment process as part of your governance program. Deployment represents a lifecycle state change and should be managed carefully. The deployment process should include:
- verify that the service complies with corporate policies - configure the service - configure runtime policy enforcement (mediators) - instrument the service for management - verify that the service configuration complies with corporate policies - register the service and its policies - verify that the service registration complies with corporate policies - deploy the service package This process employs the service platform, mediation systems, management systems, and the registry. Lifecycle management governance tools (e.g., repositories) often provide tools that facilitate and/or automate the process. I strongly recommend that you also employ automatic runtime detection capabilities that can detect rogue services that are not properly managed. (Supplied by most SOA management solutions.) Anne On 2/14/07, Jerry Zhu <[EMAIL PROTECTED]> wrote:
Thanks Anne, how is service deployment addressed? Jerry --- Anne Thomas Manes <[EMAIL PROTECTED] <atmanes%40gmail.com>> wrote: > Jerry, > > These are functional components that don't > correspond 1:1 to product > categories. Most organizations will use a variety of > products to implement > these functional capabilities. > > Service platforms: tools and frameworks for building > and running services; > includes platforms that support new development, > legacy encapsulation, and > composite services/orchestration (e.g., .NET, Java > EE servers, Axis/Axis2, > ESBs, etc.) > > Service mediation: agents (policy enforcement > points) that intercept > messages and enforce policies (e.g., security, > filtering, validation, > logging, auditing, routing, transformation, etc) and > mediate between > dissimilar systems (e.g., credential mapping, > capability mediation, and > protocol transformation). PEPs may be deployed > anywhere along the message > path, e.g., within a platform (as a handler or > filter) or as a proxy. > Platforms typically provide some mediation > capabilities, but it's helpful to > have centralized management of PEPs (see service > management), therefore I > generally recommend using a SOA management system > (e.g., Actional, > AmberPoint, SOA Software). XML gateways (e.g., > DataPower, Reactivity, Layer > 7, Forum, and Vordel) provide hardware-accelerated > mediation systems. Most > ESBs make for a poor mediation system because they > rarely support security > and capability mediation. Pure-play mediation > systems include Apache Synapse > and SOA Software Network Director (formerly Blue > Titan). > > Service management: monitoring of message traffic > and monitoring, > configuration, and control of services and SOA > infrastructure components. > Provides visibility into the environment for both > operations and business > activity monitoring. Responsible for configuring > services and mediation > agents. Detects anomolies and takes corrective > action. Primary solutions are > SOA management systems: Actional, AmberPoint, SOA > Software. To a lesser > degree HP SOA Manager. IBM ITCAM and CA WSDM support > the ops monitoring > capability, but not the configuration and control > capability. > > Registry: enables information exchange among the > other infrastructure > components. > > On 2/12/07, Jerry Zhu <[EMAIL PROTECTED] <jerryyz%40yahoo.com>> wrote: > > > > 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] <atmanes%40gmail.com> > <atmanes%40gmail.com>> 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] <jerryyz%40yahoo.com> > <jerryyz%40yahoo.com>> 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> > <atmanes%40gmail.com> > > > <atmanes%40gmail.com>> wrote: > > > > > > > > > Jerry, > === message truncated === __________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/
