This document outlines the work currently planned for Phase 1 of the SOA Governance initiative (Project Overlord).
The following diagram provides a high level view of the components that will be used, enhanced or developed to deliver the required capabilities. The following sections will provide a brief description of each of these areas, with more detail being added during the course of the work.
Questions regarding the overall SOA Governance work, or topics that span multiple components, should be posted to the Overlord User Forum. Any questions related to the specific components should be directed to the responsible project (identified in the relevant sections below).
Testable Architecture Tooling
Testable Architecture is a methodology aimed at improving the quality of software/service development by introducing validation of artifacts between different phases of the lifecycle.
Capabilities will include:
- Defining interaction based requirements using scenarios
- Specifying an overall architecture using a BPMN2 choreography, and testing the requirements against that choreography
- Generating BPMN2 process models from the choreography to represent service design artifacts
- Generating SwitchYard services (WS-BPEL or Java) from the BPMN2 choreography and/or process models
- Simulating scenarios against BPMN2 and WS-BPEL process definitions
Project: Currently no top level project. Individual components will be hosted under the GitHub Governance organization.
The SOA Repository effort will focus on the following four areas:
S-RAMP (SOA Repository And Model Protocol) is a new standard being finalised within an OASIS working group. This will provide a standard SOA based model representation that supports extensibility to include other relevant artifacts, and an Atom binding. The project source code is hosted in the S-RAMP Repository on GitHub. Issues should be recorded using the jboss.org JIRA system under the SRAMP project.
Service/Artifact Viewer UI
This can be considered a 'S-RAMP Explorer'. It will provide users with a web application to enable them to search and navigate the S-RAMP compliant repository, and where they have appropriate access privileges, apply updates and create/upload components.
IDE Integration (Upload/Download)
Where appropriate, provide integration with the Eclipse IDE to allow users to upload and download relevant artifacts.
The Governance Workflow will be used to implement the governance processes used by an organization to progress service artifacts through a lifecycle into production. The specific nature of the workflow, and the lifecycle phases through which the service artifacts will progress, will be fully customisable to enable an organization to adopt their own governance processes.
Out of the box workflows will be provided to deal with
- validation of artifacts and dependencies
- artifact promotion based on sign-off
- signing artifacts before production deployment
- deployment into the target environment (direct or via JON as examples)
Service Execution Environment (Clustered)
The Service Execution Environment will be responsible for collecting performance metrics associated with the services deployed into its environment. The initial execution environment supported will be SwitchYard.
The diagram shows two possible configurations that will be supported - with and without JON/RHQ. Where JON/RHQ is available, the service execution environment will provide an agent to enable the service metric information to be collected. Where JON/RHQ is not used, this metric information will be directly obtained, possibly via a RESTful service.
As well as colating service performance metrics, the runtime environment will provide the ability to enforce a range of runtime policies (to be defined).
Business Activity Monitoring
Project: Currently no top level project. Individual components will be hosted under the GitHub Governance organization, and issues should be recorded using the GitHub issue management system, associated with the relevant repository.
The Business Activity Monitoring module will provide the ability to analyse activity events in realtime. For the initial phase, the scope of this capabilitiy will be restricted to dealing with SLA policies.
SLA Policy Engine
The SLA Policy engine will used a CEP Engine (Drools Fusion) to monitor the service performance and availability information to ensure they are within permitted thresholds. If any deviations are detected, these will be raised as alerts.
When an alert is raised, this will be available to the UI (described below) but will also be optionally distributed to other external systems (to be defined).
Business Activity Monitor and Alert UI
This web application will provide users with visibility of business & service activity and any alerts (or warnings) that occur.