SOA Governance in SwitchYard breaks down into two distinct categories:
Design-Time Governance - the ability to define, store, share, and manage artifacts related to services that are consumed and provided throughout the lifecycle of an application.
Runtime Governance - providing visibility, control, and policy enforcement capabilities for services at runtime.
Support for SOA Governance is an ongoing process within the project. We have started with a basic set of capabilities that have broad impact on service development and runtime execution. These features will evolve over future releases to incorporate higher-level capabilities (e.g. BAM).
The model for design-time governance in SwitchYard revolves around the concept of a service artifact module. A service artifact module collects a group of related artifacts (e.g. WSDLs, Java interfaces, XML schema) and packages them in a single archive. The archive itself is nothing more than a JAR file, but it represents the intersection point for the following actors within design-time governance:
Development : an artifact module is imported into the development environment as a Maven dependency. This allows the developer to create service consumers and/or providers based on the artifacts and also test these services within the development environment.
Repository : artifacts are imported into the repository and exported as an artifact module. Access control, versioning, notification, discovery, and other repository-layer features are handled here.
Runtime : the artifact module is deployed into the runtime as a distinct deployment entity. This allows multiple services/applications to share the same service artifacts and provides a direct link to artifacts under management in the repository and those deployed in a runtime.
For additional information and an example of using SwitchYard's design-time governance support with Guvnor NG, read the article on Repository Integration.
There are two different flavors of runtime governance in SwitchYard. The first, is policy definition and enforcement. See the Policy chapter for additional information on that subject. The second flavor is the collection and exposure of runtime metrics for services. On the surface, this support is quite basic. For each service exported from an application, SwitchYard tracks the following details:
Invocations - Success
Invocations - Failed
Invocations - Total
Min Response Time
Max Response Time
Avg Response Time
Total Response Time
In addition to service-level metrics, SwitchYard also collects and exposes metrics related to service references - or the services invoked by a particular service. This can be particularly valuable when a composite service, such as a BPEL process or a complex routing pipeline, invokes many services during it's execution. Reference-level metrics allow the operations team to "drill down" into a service and identify how much time the service is taking itself vs. other services that it's calling.
Service and reference metrics are available via the admin console and CLI at the moment. In the future, JMX and REST will be supported as an access method for the core admin layer containing these metrics.