Soa governance ebook download

Through practical examples, it explains the relationship between business requirements, business process design, and service architecture.

By tying the SOA implementation directly to business value, it reveals the key to ongoing success and funding.

It shows how you can transform requirements and vision into solid, repeatable, and value-added architectures. I heartily recommend it. In his first book, Succeeding with SOA, Paul Brown explained that if enterprise goals are to be met, business processes and information systems must be designed together as parts of a total architecture. In this second book, Implementing SOA , he guides you through the entire process of designing and developing a successful total architecture at both project and enterprise levels.

Drawing on his own extensive experience, he provides best practices for creating services and leveraging them to create robust and flexible SOA solutions. Writing for senior IT developers, strategists, and enterprise architects, the authors cover everything from concepts to implementation, requirements to tools.

Marks and Bell provide practical guidance across the entire SOA life cycle-from business imperatives and motivations to the post-deployment business and technical metrics to consider. With this book, Marks and Bell demonstrate a unique ability to take the complex dynamics of SOA, and through an eloquent set of metaphors, models, and principles, provide an understandable and insightful how-to manual for both technical and business executives.

The book uses a concise and practical approach to take you through all the steps necessary to create, run, and analyze your own Network Simulations. This book is ideal for anyone wishing to quickly get to grips with Network Simulation whether you're an expert in networks or just a beginner. Among the issues it addresses: introducing a services discipline. A complete, comprehensive methodology and framework for adopting and managing a successful service oriented architecture environment Achieving Service-Oriented Architecture helps to set up an SOA Architecture Practice defining the policies, procedures, and standards that apply not just to IT developers but to the entire corporation as it relates to business applications.

Are all architecture decisions documented and signed off on? Is a layered mediation architecture in place? Do you have a formal enterprise architecture? How is the IT governance related or aligned with the SOA, enterprise architecture, and your organizations governance? Supply chain as a service: the next big thing? Defining, designing, creating, and implementing a process to solve a challenge or meet an objective is the most valuable role Development standards should cover in some detail the end-to-end software development lifecycle including all the different assets that should be produced throughout the different phases of the lifecycle.

These standards should cover key development issues such as source code management for example, the use of tools such as subversion and configuration management for example, the use of trunk, tags, and branches folders, and all the guidelines to commit code and manage the line of development. SOA design standards : This document describes the service taxonomy and a pattern language that the designers should adhere to when producing designs for SOA Services.

AIA serves as an excellent example as to what should be addressed by the design standards. For example, naming conventions for JDeveloper would include conventions for applications and projects, composites, mediators, and BPEL components. These standards also cover programming guidelines and best practices. SOA metadata standards : It provides the standards and constraints that a designer and developer must adhere to when creating schemas and other XML artifacts.

For example, namespaces, element naming standards, and schema data models should be covered in the metadata standards. SOA templates : All the SOA deliverables defined in the governance framework should have a corresponding document template. Document templates are very important because they define the content and scope that is expected of an SOA deliverable. Having document templates available means that the project can focus on delivering content and not defining it.

Note that these standards will be dependent on how the runtime deployment framework is implemented. SOA error and exception handling standards : It defines guidelines that should be followed when implementing error and exception handling into the SOA services.

Note that these standards will be dependent on how the runtime exception handling framework is implemented. Security standards : It defines guidelines that should be considered when defining and applying security policies into the SOA services.

Note that these standards will be dependent on how the runtime security framework is implemented. Monitoring and SLA standards : It defines guidelines on the implementation of sensors and business activity, monitoring dashboards into composites and proxy services.

These standards become particularly important at runtime as they enhance the search and monitoring capabilities of SOA instances once a service becomes operational. These artifacts are created to support the implementation of Runtime Governance. Deployment framework : Creating a framework of components that standardize the way code is promoted to different environments is extremely important, not only from a configuration management perspective but also from a project point of view.

These external systems are expressed in the form of URLs that will change from environment to environment and should therefore not be hardcoded into applications.

Promoting code using tools such as JDeveloper or Eclipse is highly unreliable and not recommended as this approach requires a high degree of manual intervention that can introduce human error. A runtime deployment framework should standardize and centralize the way code is promoted between all environments. Exception handling framework : One of the key success factors of an SOA implementation is the ability of the business as usual team BAU or the operations team to be able to support the solution once it has gone into production.

Although this depends on many factors for example, infrastructure, networks, storage, external systems, and so on , it is essential that errors are reported to the appropriate teams quickly and efficiently in order to minimize the risk of disruption to a business.

The team running productions systems must be able to conduct root cause analysis and search for errors and logs in order to rapidly diagnose errors. An exception handling framework is a set of runtime component that are built with the sole purpose of standardizing the way exceptions of all types for example, business faults, systems faults, remote faults, binding faults, composite and BPEL faults, among others within the SOA Suite 11g or OSB 11g stack are handled, reported and diagnosed.

Continuous integration framework : Ensuring that the code stored in the code repositories is always working and testable is one of the golden rules of continuous integration. Having such components in a governance framework means that projects delivering SOA will have to align to the practices and guidelines specified, resulting in better-quality solutions and a faster delivery.

Testing teams are not necessarily subject matter experts in the Oracle stack and, therefore, it is imperative that they are able to utilize standardized solutions to test the web services. There are several tools available that can help automate the testing of SOA services. Some of the most popular ones are:. SoapUI : It is a Java functional testing tool that allows creating and executing automated functional, regression, compliance, and loading tests against web services.

SoapUI supports several protocols and technologies. Test Suite : It provides an automated test suite framework for creating and running repeatable tests on an SOA composite application. Using some of these tools can be complex and time-consuming if not done properly. For this reason, the framework should also provide facilities and scripts that take away most of the complexity of using the tools, allowing the tester to focus on test execution and not on the tool configuration.

Provisioning framework : This often-forgotten component of a framework is, without doubt, one of the main reasons why projects fail to deliver on time and to budget.

Manually installing and configuring an Oracle Fusion Middleware application such as Oracle SOA Suite 11g can be very complex and can take several days. Furthermore, all installations are manually executed, increasing the chance of human error. Furthermore, ideally the installation should be easily reproducible for creating further environments with identical topologies.

Human error and configuration problems can be the cause of severe delays when testing code, as it becomes extremely difficult to identify the root cause of issues. To avoid such issues and the many others that can result in a poor infrastructure configuration management, a framework should be constructed to automate software installation. Oracle FM provides several features and APIs that makes this task feasible, and the benefits of having such a component framework in a governance framework can be considerable.

This phase consists of the implementation of the Oracle SOA Governance solution in combination with the defined design-time and runtime Governance processes and standards. The result of this phase should allow projects to make full use of the SOA Governance framework in order to successfully implement the SOA solutions.

Design-time Governance can be defined as the combination of processes, tools,and people needed to support the analysis, design, and build phases of an SOA implementation. During this phase, as the name suggests, the requirements for the project or project iteration are elaborated. Requirements are meant to capture, in plain English, what the business expects from a particular solution a system, a business process or even a single SOA service. Clearly, without properly documented requirements one should never proceed to other phases of the project.

Unfortunately, as obvious as this may sound, many projects end up doing exactly this. Once all the functional and non-functional requirements have been identified, they must be validated, clearly documented, made unambiguous, actionable, measurable, testable, and traceable.

Once this has been completed, the process of identifying candidate services to support the required functionality can commence. Service discovery : This crucial phase of an SOA Asset lifecycle consists of identifying the SOA capabilities that are required in order to deliver a particular requirement, or set of requirements.

Service cataloging : During service discovery all defined capabilities should be classified and mapped to the existing SOA Assets where possible. This process is defined as service cataloging.

For example, if a new capability is needed and there isn't an existing asset that could be used or extended, then a new potential service is identified and should classified as a proposed service.

This process is repeated many times during this phase, meaning that the list of services will grow. A normalization exercise should then take place in order to avoid duplication of services and inconsistencies. The SOA Governance framework should provide templates for service catalog and capability analysis to capture the outcome of this phase. The use of templates can dramatically improve the outcome and quality of this phase as the scope and expectations in terms of content and detail are known upfront.

The output of the analysis phase will include a list of candidate services that will deliver a particular and traceable set of business requirements. The design phase translates these proposed services into actual service designs that are suitable and fit-for-purpose and that deliver the desired business functionality.

Functional contract : A functional contract is a document asset that defines the functionality that the service should deliver and the desired non-functional requirements such as service ownership, service-level agreements SLAs , and service operational requirements such as service availability.

Technical contract : The technical contract defines signature data elements that are needed in order to consume the service , protocols for example, what binding will be used such as SOAP binding over HTTP and policies for example, message security or MTOM for sending attachments.

A technical contract is usually defined during detail design and is reflected in the design document as well as in the WSDL and schema of the service. Service detail design : Contains a component and sequence diagram that describes the static and dynamic views of the service. The dynamic view shows how the information flows between the composites, what manipulation takes place to the data for example, transformation and what orchestration is required for example, in BPEL.

A detail design should also cover the definition of the technical contract that encompasses definition of data mappings, WSDL and schemas definition, and unit test scripts. Service versioning : Versioning is a critical and fundamental activity required when designing services. Having the correct versioning strategy in place is critical for the success of an SOA implementation.

Service versioning is not to be confused with version control. The latter, also referred to as revision control or source control, is a discipline for managing code throughout the asset lifecycle. For example, a service at Version 1. Whereas the service version has a direct impact on the consumers of the service, consumers are unaware of the several code revisions the asset went through. The following diagram illustrates the different Assets within a service that can be versioned:.

Regardless of what asset is being versioned it is fundamental to consider the following principles:. Minor versions : A minor version usually represents a change to a service that is backward-and-forward compatible. Minor versions are usually represented with decimals. For example, in an XSD of Version 2. Backward compatibility means that newer clients must be able to consume older services without change.

Forward-compatibility means that older clients must be able to consume newer services. Major versions are usually represented with digits. Terms of service : A contract that formalizes the terms and conditions under which a service is provided and consumed.

This will convey how clients and service providers deal with versions. For example, a term of service that communicates only three versions of a service that will be available—preview, current, and prior—and that clients are expected to move from prior to either current or preview within 1 year of the current service becoming prior. SOA Governance framework artifacts such as architectural principles, reference architectures, and most notably design standards are critical to enforcing the quality of the design phase.

During this phase, services are constructed and unit-tested as per the service design. Ensuring that standards such as programming standards, exception handling frameworks, deployment frameworks, and continuous integration frameworks are adopted during the build and unit test phase are crucial to obtain the expected quality of code and to streamline the build and unit test phase.

Runtime governance can be defined as the combination of processes, tools, and people needed to support the deployment, testing, and production support phases of an SOA implementation project. This phase covers the promotion of code between the different environments of the project for example, development, system integration test, user acceptance test, and so on. Service deployment is achieved by executing the predefined processes and techniques that are required for deployment SOA Assets between environments.

A deployment framework should ideally be employed during this stage, to automatically compile and promote services between environments without having to worry about manually changing the settings, such as environment specific endpoints or internal service dependencies. The testing phase can be divided into different stages depending on the objectives of the tests being executed. In a typical project the testing phase consists of:.

System test : Targeted at testing the integrity of the system in isolation. System integration test : Focused on testing that all of the systems in context can in fact interoperate with each other to deliver the required functionality.

User acceptance test : Business-driven test for business users to assert that the system delivers the desired business functionality. Performance testing : The non-functional requirements to ensure that the system can handle the amount of usage that is expected once the system goes live. In the SOA Asset lifecycle, the three main activities that take place during each testing stage are:. Service monitoring : This stage of the lifecycle spans across different stages of the project and its purpose is to ensure that all the services and core infrastructure components are fully operational and performing satisfactorily.

This stage is also responsible for identifying any errors or issues that may arise as part of the monitoring process.

Service testing : Utilizes available testing tools in order to ensure that the developed services are deployed into the SOA infrastructure, and that they fully address the business and technical requirements. Although this phase is really an extension of the service implementation phase, it is separated from it as the required tasks are executed by separate teams whose main responsibility is to apply bug fixes to the code and optimize system configuration settings.

It is during the test phase of an SOA project that the effectiveness, quality, and robustness of the SOA Governance framework become obvious. Should all the design-time and runtime components of an SOA Governance framework be successfully delivered, and the design-time standards properly enforced during development phases, then the tasks of monitoring and testing the services should be fairly straightforward and the complexity of this stage should be kept to a minimum.

This is because the complexity of such tasks should have been hidden by the framework, and the project should be following a script and not trying to reinvent the wheel. Furthermore, monitoring and troubleshooting tasks should be fairly straightforward, if features such as composite sensors and e-mail notifications were taken into consideration during design-time. Once a service is promoted into a production environment, it officially enters the support phase. The support phase is most definitely not the end of the service lifecycle, however; in fact, far from it.

For example, BAM dashboards should be employed where it is appropriate to monitor the efficiency of processes. Activities such as service testing, service monitoring, and service improvement should remain active during the operational lifetime of service.

Once a service has served its purpose and has been deprecated or is no longer needed, then the following activity should take place:.