Showing posts with label SOA. Show all posts
Showing posts with label SOA. Show all posts
Sanjaya on "Right Middleware for SOA in Health Care"
Identifying the right combination of middleware products to build your SOA is key to its success.
In this article, Sanajaya Karunasena from WSO2, discusses an approach to using non-functional requirements in choosing these products, using SOA in healthcare as an example.
Effective SOA deployment using an SOA Registry-Repository
An SOA registry-repository is increasingly becoming an important infrastructure middleware solution for managing the rising complexities and meeting new requirements related to SOA.
Many different information artifacts describe a service component or relate it to other service components and information artifacts, such as:
- Multiple WSDL files may describe the various interfaces and protocol bindings of these interfaces for the service component.
- XML schema files may describe the documents exchanged by messages in the service protocol.
- Business process orchestration for the service component may be described by artifacts such as BPEL descriptions, and ebXML business process specification schemas.
- Metadata may describe the assembly structure and subcomponents of a composites ervice.
- XSLT stylesheets may be used as adapters between service components to handle impedance mismatch due to service version differences.
- WSRP descriptions may describe how service components are used by portals.
- Organizational policies, business rules, and procedures may define how service components and service information artifacts may be defined and used.
Governance is defined as the policies, rules, and regulations under which an organization functions as well as the processes that are put in place to ensure compliance with those policies, rules, and regulations.
It is required to have a point of control within the SOA infrastructure that provides governance of service components and artifacts by enforcing the organizational policies that govern them.
The need for a point of control and governance within the SOA deployment demands that service information artifacts be stored and managed in a consistent manner that allows enforcement of organizational policies.
This is precisely the role served by a registry-repository service within an SOA deployment.
The following example describes a registry-repository using a common metaphor:
- A registry-repository is like your local library.
- It has a repository that contains all types of electronic assets, much like the library book shelves contain all types of published content including books, magazines, videos, and so on.
- It has a registry that contains metadata describing the electronic artifacts, much like the library’s card catalog contains information describing the published content on its book shelves.
- The registry and repository are administered jointly. Within a library, the card catalog information and books in the shelves are administered jointly.
- Any number of registry-repositories should be able to work together to offer a unified service, much like multiple libraries can participate in a cooperative network and offer a unified service.
A registry can only store links or pointers to service information artifacts.
The actual artifacts must reside outside the registry.
A registry-repository provides an integrated solution able to store metadata such as links or pointers to artifacts, as well as the actual artifacts.
An SOA registry-repository should provide governance capabilities that enable organizations to define and enforce organizational policies governing the content and usage of the artifacts throughout their life cycles.
Since organizational policies vary, an SOA registry-repository should enable organizations to enforce custom policies for the governance of any type of service information artifact throughout its life cycle.
A registry-repository should allow business rules to be enforced at the time of publishing. It should also allow such business rules to be defined by the organization and specialized for the types of artifacts. If an artifact fails publish-time validation checking, the registry-repository should either reject the artifact, or accept it as invalid and automatically notify responsible parties.
Federated information management allows multiple registry-repositories to federate together and appear as a single, virtual registry-repository, while allowing individual organizations to retain local control over their own registry-repositories.
Governance requires enforcement of organization policies that are described in a machine-processable syntax, typically XML.
An SOA registry-repository will be used to manage and govern policies in much the same manner as other SOA artifacts.
The ebXML Registry standard supports federated policy management of access control policies expressed in the XML syntax defined by the OASIS Extensible Access Control Markup Language (XACML) standard.
A registry-repository should also support federated identity management features such as single sign-on, and integrate with identity and access management services using open standards such as Security Assertions Markup Language (SAML) and Liberty.
A registry-repository contains all service-related artifacts for service components available within an SOA deployment.
A registry-repository should provide discovery capabilities that are extensible and can accommodate the simplest to the most complex domain-specific discovery queries. Specifically, its discovery queries should not all be predefined.
Here are some examples of service artifact discovery queries expressed in plain English:
- Find all WSDL documents that use a specified namespace pattern
- Find all Service Bindings or Services that have a certain text pattern in their documentation
- Find all Service Bindings that are SOAP bindings AND use DOC Literal style AND do not use HTTP as transport
- Find all WSDLs with Service implementations that use specified implementation platform (for example, Java™ 2 Platform,Enterprise Edition or J2EE™, .Net, and so on)
- Find all WSDLs with Service implementations that use specified platform resources (such as database, Java Message Service or JMS, Java API for XML Registries or JAXR, and so on)
Cataloging of artifacts improves their discoverablity and is essential in supporting the kind of artifact-specific queries.
With cataloging information is automatically converted to metadata at the time it is published.
For example, an organization may define cataloging policies for WSDL artifacts such that when a WSDL document is published, it is cataloged in a WSDL-specific manner to generate metadata that includes information on:
- The documents imported by the WSDL document (such as other WSDL documents and XML schema documents)
- The name spaces used by the WSDL document and documents imported by it
- The name and description of the bindings, interfaces, and types used by the WSDL document
Such metadata can then be used in WSDL-specific discovery queries.
As more and more service components are reused within other service components, the task of tracking the network of dependencies between service components becomes more challenging and significant. A registry-repository should provide a set of standard relationship types, but also allow an organization to define additional relationship types based on its specific requirements.
Service components are deployed in phases. During each phase, organizational access control policies (ACPs) determine the controlled community of users which has access to the service.
A registry-repository should allow ACPs to be defined and enforced for service information artifacts. Since ACPs tend to be fairly specific to organizational needs, the registry-repository should allow for fine-grained access control policies that can accommodate specific needs.
Service components evolve over time for a variety of reasons, such as the need to fulfill new requirements. A service’s evolution may involve changes in its implementation and/or public interface.
A registry-repository should provide versioning capabilities that enable automatic version control of any type of service information artifact
When a service evolves, it is important to notify its consumers of the changes to the service.
A registry-repository should provide a change notification capability that allows interested parties, such as system administrators, to create subscriptions to events within the registry-repository that may be of interest to them.
As IT organizations evaluate which registry-repository to deploy as part of their SOA infrastructures, the choices often fall into the following categories:
1. Proprietary registry-repository
2. UDDI registry without a repository
3. UDDI registry with a proprietary repository
4. ebXML registry-repository
5. Combination of UDDI registry and ebXML registry-repository
A UDDI registry offers a subset of capabilities offered by an ebXML Registry.
In particular, it provides only a registry and no repository.
What gets published in a UDDI registry are pointers to service artifacts such as WSDL.
What gets published to the ebXML Registry are not just pointers to service artifacts, but also the actual artifact themselves.
Thus, an ebXML registry-repository can be used for governance of any type of service artifacts throughout their life cycles.
Further, at the end, the white paper also provides a Registry Standards Comparison Matrix which compares UDDI and ebXML Registry 3.0 standards in various categories.
SOA Governance - Enabling Sustainable Success with SOA
In most organizations, virtually every IT resource and process will have some level of governance associated with it in the form of policies, rules, and controls that define how a particular asset is managed and utilized, or parameters around how a certain IT function is performed.
The act of establishing and enacting these rules falls under the broad umbrella of IT governance, with the purpose being to institutionalize discipline and maturity in IT processes so as to gain greater control and economies.
SOA governance, is a subset of IT governance related to establishing policies, controls, and enforcement mechanisms—within the context of the activities and constructs associated with SOA—similar to those that exist for managing and controlling other aspects of IT.
Initially, the concept of SOA governance was applied narrowly to the development and use of Web services, for example, validating the conformance of a Web service with specific standards or managing Web services in the SOA run-time environment.
The paper defines SOA Governance in the following way:
The art and discipline of managing outcomes consistent with measurable preconditions and expectations through structured relationships, procedures, and policies applied to the organization and utilization of distributed capabilities that may be under the control of different ownership domains.
Without effective SOA governance, organizations will experience some predictable challenges:
1. A fragile and brittle SOA implementation
2. Services that cannot easily be reused because they are unknown to developers or because they were not designed with reuse in mind
3. Lack of trust and confidence in services as enterprise assets, which results in a “build it myself” mentality (further compounding the lack of reuse with redundancy and unnecessary duplication of functionality)
4. Security breaches that cannot easily be traced
5. Unpredictable performance
The first requirement of SOA governance is architecture governance.
Architecture governance is necessary to ensure that SOA as architecture evolves by design and not by accident.
A key aspect of SOA architecture governance is defining a roadmap that will guide the smooth and orderly evolution of the architecture over time.
SOA exposes standalone application functionality at a fine-grained level of granularity, thus necessitating a new form of governance—service-level lifecycle governance.
Service-level governance applies at the level of individual services and covers a wide gamut of requirements and situations.
Design-time governance is primarily an IT development function that involves the application of rules for governing the definition and creation of Web services.
Policies might include ensuring that services are technically correct and valid, and that they conform to relevant organizational and industry standards.
If an organization has an SOA governance infrastructure in place—in the form of software that facilitates the implementation of SOA governance practices—these checks can be invoked automatically when developers check services into a registry.
In addition, approval and notification workflows can be triggered by a governance-enabled registry to ensure that services pass through pre-defined review and approval steps so that they meet architectural and organizational standards for business function encapsulation, reusability, reliability, and so on.
Governance at run-time revolves around the definition and enforcement of policies for controlling the deployment, utilization, and operation of deployed services.
These run-time policies typically relate to non-functional requirements such as trust enablement, quality-of-service management,and compliance validation.
Examples of run-time governance include:
- Checking a service against a set of rules before it is deployed into production, for example, to ensure that only a certain message transport or specific schemas are used
- Securing services so that they are accessible only to authorized consumers possessing the appropriate permissions, and that data is encrypted if required
- Validating that services operate in compliance with prescribed corporate standards, in effect, to confirm that a service is not just designed to be compliant, but that its implementation is actually compliant
A more specific case of run-time governance involves service-level monitoring and reporting.
Change is inevitable and, at some point, services deployed in the run-time environment will have to be changed to adapt to new business requirements. Since the majority of services will be designed once and then modified several times over their lifespans, change-time governance—the act of managing services through the cycle of change.
The second section of the white paper describes the technologies behind SOA Governance.
At a basic level, an SOA governance system should facilitate service-level governance across the lifecycle from design-time to run-time to change-time. It should allow polices to be defined and created, and provide mechanisms for these policies to be enforced at each phase of the service lifecycle.
The main components of this system include:
- A registry, which acts as a central catalog of business services
- A repository, for storing policies and other metadata related to the governance of the services
- Policy enforcement points, which are the agents that enact the actual policy enforcement and control at design-time, run-time, and change-time
- A rules engine for managing the declaration of policies and rules and automating their enforcement
- An environment for configuring and defining policies and for managing governance workflows across the service lifecycle
A registry is usually identified as one of the first requirements of SOA adoption and registries play an important role in governance. In simple terms, a registry is a catalog or index that acts as the “system of record” for the services within an SOA. A registry is not designed to store the services themselves; rather, it indicates their location by reference.
As the place where services are made known within the SOA, a registry is also a natural management and governance point. For example, compliance requirements—such as
conformance with the WS-I Basic Profile or the use of specific namespaces and schemas— might be imposed on services before they are allowed to be published in the registry. Or, as services are registered or changed, the registry also has the ability to trigger approval and change notification workflows so that stakeholders are alerted to changes.
An SOA registry typically fulfills the following functions:
- Stores service descriptions, information about their end-points and other technical details that a consumer requires in order to invoke the service, such as protocol bindings and message formats
- Allows services to be categorized and organized
- Allows users to publish new services into the registry and to browse and search for existing services
- Maintains service history, allowing users to see when a service was published or changed
A governance repository should support the following capabilities:
- An information model or taxonomy for representing and storing organizational and regulatory policies that can be translated into rules that are enforced by the SOA governance system. It should be possible for policies and rules to be interpreted
by people or machines (and sometimes both) as appropriate.
- Audit capabilities for tracking the trail of changes and authorizations applied to assets within the repository context.
- Identity management capabilities and role-based access controls to ensure that
only appropriate parties have access to policies.
- A notification system and content validation capabilities to provide additional assurances that policies are well-formed, consistent, and properly applied.
In practice there are many benefits to combining both Registry and Repository into a single entity.
Implementing them as separate products creates the burden of duplicate data entry, sets up the need to synchronize information, and increases the risk of inconsistencies between the two.
The places where policies are actually applied and enforced—the policy enforcement points—change depending on the lifecycle stage. During design-time, the registry/repository itself is the point of enforcement. During run-time, policies are generally enforced by the underlying message transport system that connects service providers with consumers. Finally, during change-time, policies are typically enforced by the IT management system.
A rules engine is not strictly a requirement of an SOA governance system, but incorporating rules engine technology within the registry/repository enables a significant degree of flexibility and automation, while reducing the reliance on humans to perform mechanical governance tasks.
SOA Governance - Introduction
Service-oriented architectures (SOAs) promise unlimited agility and organizational flexibility with a new layer of Services that need to be carefully created and managed.
These services are standards-based, reusable, platform independent, and easy to integrate.
The promised benefits of SOA for business include
1. A substantial IT cost reduction,
2. Faster delivery on business requirements
3. Effective introduction of new and competitive business models.
In moving towards SOA, companies want to
1. Ensure continuity of business operations
2. Manage security exposure
3. Align technology implementation with business requirements
4. Manage liabilities and dependencies
5. Reduce the cost of operations
In other words, SOA is about facilitating change, about gaining and leveraging agility for competitive advantage and SOA governance is about managing change to maintain that agility and to ensure that it consistently serves business objectives and delivers return on investment (ROI).
Another way to define SOA governance is, it is the ability to ensure that all of the independent efforts (whether in the design, development, deployment, or operations of a Service) come together to meet the enterprise SOA requirements.
The failure to govern the evolving SOA can result in millions of dollars in costly service redesigns, maintenance, and project delays
Gartner, Inc says, in 2006, enterprises worldwide have spent nearly $3billion on failed and redesigned Web services projects because of poorly implemented service-oriented architectures.
Further, SOA requires a major shift in the way software is developed and deployed within enterprises. Companies will have to move from the “Develop Now, Integrate Later” view to a “Develop for Integration” paradigm. The new paradigm, technologies, and standards created to support this shift require companies to implement their SOA in a well planned, well coordinated, and effectively managed way – which raises the requirement of SOA Governance.
Following elements are required to achieve SOA Governance:
1. Enterprise SOA Policies
2. Auditing & Conformance
3. Management: Track, Review & Improve
4. Integration
Policies set the goals that you use to direct and measure success.
E.g.:
- Customer name and contact information may not be transmitted as clear text
- Each message must carry information to uniquely identify the message source, destination, timestamp, and transaction ID, to meet mandatory archiving requirements
- Messages must contain an authorization token
- Password element lengths must be at least 6 characters long and contain both numbers and letters
- Every operation message must be uniquely identified and digitally signed
- Do not use RPC Encoded web service operations
- Do not use Solicit-Response style of operations
- Do not use XML ‘anyAttribute’ wildcards
Policies should not be left to documentation. Policies should be an active part of the operations of companies. Following the policy definition stage, policies should be put to work to detect, analyze, and audit compliance.
Subscribe to:
Posts (Atom)