Governance in the Real World

Dakshitha Ratnayake Lead Solutions Engineer WSO2

Governance in the

real world

Agenda

• Service Governance and service Registries

• Quick Intro to Wso2 Governance Registry

• How Customers Use the WSO2 Governance Registry –Managed Service Documentation

–Unification of Governance Registry And API Manager

•Quick Intro to Wso2 API Manager

–Use of Workflows and Publishing to External Gateways

Challenges with soa

• Challenges arise when creating an interconnected SOA

• If there IS a large number of services, how do you decide and prioritize which functions to expose?

• How will people discover functions that have been exposed?

• A lack of visibility and governance leaves room for: – service proliferation

– Service duplication

– regulatory compliance issues

Gartner Definition:

“ensuring and validating that assets and artifacts within the architecture are acting as expected and maintaining a certain level of quality.”

SOA governance

Characteristics of a

SOA registry

Definition: A central ‘database’ that includes artifacts for all services planned for development, in use and retired.

Characteristics:

• The registry is the driver of a catalog of services

• Searchable by service consumers and providers

• Service meta-data is updated throughout the sdlc

Wso2 G-reg is ‘more’ than

just a registry

• WSO2 Governance Registry provides enterprises with end-to-end SOA governance

• Allows to Store, manage and search any kind of enterprise asset (not limited to services):

– Services

– APIs

– Policies

– Projects

– Applications

– People

• Allows to Secure the access to assets via a fine-grained permission model

• Provides Notification support

• Supports Lifecycle management

• Includes a store and publisher with rich and enhanced user experience.

How do Our

customers use the

wso2 governance

registry

Dakshitha Ratnayake

Lead Solutions Engineer

Use case: managed

service documentation

A service candidate is identified and the user queries the Service Registry. For a new service, the candidate service is registered with minimal data in the Service Registry. As the service is matured and proceeds through the SDLC process, the Registry is updated with details as they become available.

Registry requirements

• Ability to add, change, edit, and customize service meta data

• Access based on role

• Service Lifecycle Management

• Robust keyword search

• Ability to track service pedigree (version differentiation)

• Service consumer registration

• Support for data import/export (XLS data)

G-Reg in action

Service & function trackers

Identify service & functions

XLS-based

Populate

Develop and update

Design and update

Deploy and update

Test and update

Export full service list

Export Full service list

Full service catalog

EVTS

architects

developers

testers

Devops

1

2

3 4

5

6

7

8

Use case: unification of

G-Reg and API Manager

Background:

• Initial problem: no Governance solution In Place – Service proliferation/duplication

• Later They started to use G-Reg to manage and govern various artifacts:

– Soap & Rest services

–wsdl (service contracts)

– schemas

• their Governance team Also handles WSO2 API Manager (API-M)

• API-M is used to expose SOAP and REST APIs (including integration APIs which are backed by the ESB)

wso2 api manager

Publisher

Key manager

Store

Gateway

2

2

1. Create API In APIM Publisher (Also APPLY policies and add documentation etc.)

2. Publish to API-M Gateway & Store

3. Search API and Subscribe to API

4. Key Manager Issues

Tokens 5. Invoke API with TOKen(S) 6. ENFORCE policies and

Validate tokens 7. Publish Events 8. Dispatch service Request

Service Developer

1

API Subscriber 3

4

5 6

8

7

Analytics

Actual Service

Problem

Publisher

Key manager Store

Gateway

Service Developer

1 3

3

1. Create/Register service 2. Create Corresponding API Manually in API-M Publisher 3. Publish to API-M Gateway & Store

Service Developer

2

Management Console

a

A. Add New Lifecycle state for a service

Administrator

API Subscriber

Service Consumer

{PRE-G-REG 5.x.x}

G-Reg in action

Publisher

Store

Publisher

Key manager Store

Gateway

Service Developer

1

2

3

4 5

5

1. Create service 2. Create API when ready to publish 3. Publish Service to Governance Store 4. Publish to API-M Publisher 5. Publish to API-M Gateway & Store

a

A. Add New Lifecycle state for a service

Administrator

API Subscriber

Store user

{G-REG 5.x.x}

Next Steps – Common

Store and publisher

Publisher

Store

Key manager

Gateway

Service Developer

1 2

2 1. Create service or API

in Governance Publisher

2. Publish API to Governance Store and API-M Gateway

Store user/API Subscriber

Advantages of a common

store and Publisher

Advantages:

• Have one stop place to manage all assets. – Govern all the assets from a central Publisher

– Explore all the assets from a central Store

• Complete Store and Publisher via G-Reg If separate Gateway & Key Manager exist (This is now a common requirement among many gateway vendors and customers)

• already using G-Reg, but also need to do API Management - pointless using a complete api Management Solution.

• Visualize dependencies across APIs and other asset types

Other Registry

Requirements

• Graphical views of associations and dependencies between assets within the registry

• Remove multiple resources from G-Reg in a single step

• Group/Categorize assets

• Track updates and modifications to metadata stored in the registry

• Bulk upload/Bulk delete of services

Use case: use of

Workflows and publishing

to External gateways • workflows to be plugged for subscriptions

• When a service is Promoted to a certain life-cycle state, it must be deployed in External gateways

Other

• Create new types of assets - i.e., Application asset TYPE

• manage subscription for an asset

• Multi-Tenancy support at G-REG layer to provide separation for their internal departments

G-Reg in action –

Workflow integration

Business Analyst

Architect

Create new Service Requirement

1

Start New Workflow

2

Workflow STEP 1 - Notify Architect

3

Verify Requirement & Approve/Disapprove

4

Service Developer

5 Workflow STEP 2 - Notify Developer To Start Development Terminate

Workflow

5

G-Reg in action - External

Gateways

Service Tester

1

2

Deploy Mediation Proxies, HTTP ENdPOINTs

2

Deploy APIs

Questions? ? ? ?!!

references

• http://searchsoa.techtarget.com/definition/SOA-registry

• http://wso2.com/blogs/architecture/2014/07/api-registry-and-service-registry/

• http://www.slideshare.net/wso2.org/wso2-and-agile-path

• http://www.slideshare.net/Prolifics/leveraging-governance-in-the-ibm-websphere-service-registry-and-repository-for-iib-and-datapower?qid=8f6311fc-84ea-4f46-a9ca-b29da57512ca&v=&b=&from_search=28

Thank You