Chapter Template for Service-Oriented Computing Series

  • View
    892

  • Download
    0

Embed Size (px)

Text of Chapter Template for Service-Oriented Computing Series

  • 1.1. Overlord: SOA Governance from JBoss This document discusses what Overlord will provide within the context of SOA Governance. The rst section will discuss only core requirements and components. The second section will discuss the roadmap and where partners may be able to play a role.Any computer system, whether it is centralized or distributed, needs some form of governance, i.e., the act of monitoring and managing the system. Such governance may be as simple as ensuring only authorized users have access to services, or as complex as guaranteeing the system and its components maintain a level of availability or reliability in the presence of failures or increased system load. Managing distributed systems has always been a critical aspect for users, developers and administrators. As those distributed systems grew in scope and scalability, spanning multiple organizations with different infrastructures and trust boundaries, governance became more difficult but even more important.Governance deals with the processes by which a system operates. In order to have successful governance, some form of management, monitoring and administration is required for these processes. SOA governance is the discipline of creating policies and communicating and enforcing them.In order to govern a SOA infrastructure (SOI) such as an ESB, there needs to be a framework in place that allows policies and Service Level Agreements (SLAs) to be dened, enforced and audited across multiple security and identity domains. Such a framework must be able to dene policies for individual services and then either enforce them or provide means by which they can be managed and enforced by some other component within the SOA. One aspect of SOA governance that is implied by most denitions but often overlooked is the necessity to communicate such policies to users of services.Any implementation of governance provided by an SOI should be centered on the four principles of enterprise architecture: the people involved, the processes, the technology and services. A good governance implementation needs to be supported by a hierarchical organizational reporting structure. This impacts on an SOI in several ways, with the most obvious being that the different levels in the reporting structure (e.g., developers, business managers, service sponsors etc.) need different views onto the system as services are built and deployed. Unfortunately at this stage in the evolution of the Enterprise Service Bus as a SOA infrastructure, many implementations present only a single view (the developer view) and organizations must rely on ad hoc mechanisms to cover the other cases. This inevitably leads to an impedance mismatch (translation difficulties) as managers try to understand how to map low-level details onto their expectations. Within Overlord we believe strongly that all good SOIs must eventually cater for everyone involved in the SOA development and runtime within the same environment.In the following sections we shall discuss SOA and governance from the perspective of JBoss products currently and in the future. It should be realized that all of what we will outline within this document will eventually become implemented within the JBoss SOI. 1

2. 1.1 Infrastructure and tooling support Low-level infrastructure support for governance will come from JON and more native support within the ESB and other projects. Importantly our SOA Infrastructure has always made the registry (UDDI in our case) a central component, which helps drive some aspects of governance into the minds of users and developers. Furthermore, all good governance solutions need a repository for storing artifacts (e.g., service denitions) and we have development efforts in the Guvnor and DNA projects to ll that important gap.Depending upon the role of the user or component some governance tools within Overlord to be Eclipse based, whereas others will be Web based. Plus there will be some tools that will have representations in both arenas because some of the capabilities will be need to be available across different roles in a format that is natural for that role. For instance, sometimes what a sys admin needs to do is also what a developer needs to do (e.g., inspect a service contract).Managing a LAN-based distributed system can be hard enough: imagine expanding that so it covers different business domains where the developer or deployer do not control all of the underlying infrastructure and cannot work on the assumption that people are trustworthy (and possibly live on different sides of the planet!) With SOA governance there are run-time and design-time requirements: typically a runtime component executes to ensure things like Service Level Agreements (SLAs) are maintained, whereas a tooling-based governance component could be for run-time monitoring/management or design time service composition.With Overlord, you'll be able to graphically display: MTTF/MTTR information on behalf of specic nodes and services on those nodes. Also for all nodes and services that are deployed. throughput for services. time taken to process specic types of messages (e.g., how long to do transformations, how long to do transformations on behalf of user X). number of requests sent to services during the lifetime of the service/node (in general, it is always important to distinguish between services and the nodes on which they execute). number of faults (service/node) in a given duration. information about where messages are being received. information about where messages are being sent (responses as well as faults). potential dependency tracking data. This can be used to determine sources of common failure. Can also be used when deciding whether or not (and where) to migrate services, for improved availability or performance. what versions of services exist within a specic process (VM). Includes sending probe messages that can test availability and performance on request. However, this functionality is also duplicated into the design- time tooling. All of this information may be obtained periodically from a central (though more realistically a federated) data store or direct from the services themselves. However, both sys admins and developers will need to be able to connect to services (and composites) and inspect their governance criteria at2 3. will, e.g., when was the last time they violated a contract, why and under what input messages/state: the dynamic factor is incredibly important. This information needs to be made available across individual services as well as the entire SOA-P deployment.Within the Overlord project we are working on a separate and dedicated governance console that is used to receive alarms/warnings when contracts/SLAs are violated or close to being violated. Obviously the console is only one such destination for these alerts: sys admin inboxes are just as important. However, that's where the infrastructure comes into play.Traditional management tooling (e.g., via JMX) including: start/stop a service.suspend/resume a service. add/update restriction lists for services. This limits the list of receivers that a service considers valid and will process messages from. A similar list of destinations for responses will exist. This plays into the role/relationship concept because although a developer may not consider the issue of security (maybe can't, given that services could be deployed into environments that did not exist when the developer was building the service), the sys admin (or service container admin) will have to.migrate services (and potentially dependent services).inspect service contract.update service denition.attach and tune specic service parameters.Fortunately we'll get a lot of this from close integration with the JBoss Operations Network.Design time tooling from Overlord includes: dening the service denition/contract, which includes specifying what message types it allows. This is tied into the service implementation in order that the SOI can verify incoming messages against this contract for validity. Part of the contract will also include security and role information which will dene who can interact with the service (may be ne grained based on time of day, specic message type, etc.) Policies are attached at this level on a per service or per operation basis (if not dened on an operation basis, the service level policy is taken if dened).policy denition/construction, tracking and enforcement. Not just part of the development tool, but also an integral part of the underlying SOI. Policies need to be shared so that other developers can utilise them in their own service construction. Typically these will be stored in the repository.service construction from other services, i.e., composite services. This has an input on SLA and on governance enforcement. In some cases a physical instance of the service may not exist either and the infrastructure becomes responsible for imposing the abstraction of a service by directing interactions accordingly.inspecting the registry and repository during design time to locate and inspect desired services for composition within applications. Also ties into runtime management so that the user can inspect all running services. This3 4. would also tie into our graphical process ow tool, by allowing a drag-and- drop approach to application construction.service development then into service deployment. The tool will allow the user to view a list of available nodes and processes. The availability, performance etc. of those nodes will also be displayed (more tooling and infrastructure support). Then you can drag a service implementation on to the node and deploy it, either dynamically or statically. This ties into the runtime management tool that allows the user to view deployed services on nodes. Service implementation tooling: from the client perspective you go to the registry and select the right service based on requirements (