Social Icons

twitterfacebookgoogle pluslinkedinrss feed

Featured Posts

Monday, May 23, 2016

G-Reg and ESB integration scenarios for Governance


WSO2 Enterprise Service Bus (ESB) employs WSO2 Governance Registry for storing configuration elements and resources such as WSDLs, policies, service metadata, etc. By default, WSO2 ESB shipped with embedded Registry, which is entirely based on the WSO2 Governance Registry (G-Reg). Further based on the requirements, you can connect to a remotely running WSO2 Governance Registry using a remote JDBC connection which is known as a ‘JDBC registry mount’.

Other than the Registry/Repository aspect of WSO2 G-Reg, its primary use cases are Design time governance and Runtime governance with seamless lifecycle management. It is known as Governance aspect of WSO2 G-Reg. So with this governance aspect of WSO2 G-Reg, more flexibility is provided for integration with WSO2 ESB.

When integrating WSO2 ESB with WSO2 G-Reg in governance aspect, there are three options available. They are:

1). Share Registry space with both ESB and G-Reg
2). Use G-Reg to push artifacts into ESB node
3). ESB pulls artifacts from the G-Reg when needed

Let’s go through the advantages and disadvantages of each option. Here we are considering a scenario where metadata corresponds to ESB artifacts such as endpoints are stored in the G-Reg as asset types. Each asset type has their own lifecycle (Ex: ESB Endpoint RXT have it’s own Lifecycle). Then with the G-Reg lifecycle transition, synapse configurations (Ex: endpoints) will be created. Those will be the runtime configurations of ESB.


Share Registry space with both ESB and G-Reg

Embedded Registry of every WSO2 product consist of three partitions. They are local, config and governance.

Local Partition : Used to store configuration and runtime data that is local to the server.
Configuration Partition : Used to store product-specific configurations. This partition can be shared across multiple instances of the same product.
Governance Partition : Used to store configuration and data that are shared across the whole platform. This partition typically includes services, service descriptions, endpoints and data sources
How to integration should work:
When sharing registry spaces with Both ESB and G-Reg products, we are sharing governance partition only. Here governance space will be shared using JDBC. When G-Reg lifecycle transition happens on the ESB endpoint RXT, it will create the ESB synapse endpoint configuration and copy into relevant registry location using Copy Executor. Then ESB can retrieve that endpoint synapse configuration from the shared registry when required.
Mount(3).png

Advantages:
     Easy to configure
    Reduced amount of custom code implementation
Disadvantages:
     
If servers are deployed across data centers, JDBC connections will be created in between data centers(may be through WAN or Public networks).
      With the number of environments, there will be many database mounts.
      ESB registry space will be exposed via G-Reg.

Use G-Reg to push artifacts into ESB node
How to integration should work:
In this pattern, G-Reg will create synapse endpoints and push into relevant ESB setup(Ex: Dev/QA/Prod, etc) by using Remote Registry operation. After G-Reg pushing appropriate synapse configuration into ESB, APIs or Services will be able to consume.
G-Reg Push(1).png

Advantages:
      Provide more flexibility from the G-Reg side to manage ESB assets
      Can plug multiple ESB environments on the go
      Can restrict ESB API/Service invocation until G-Reg lifecycle operation is completed

ESB pull artifact from the G-Reg

How to integration should work:


In this pattern, when lifecycle transition happens, G-Reg will create synapse level endpoints in the relevant registry location.

When API or Service invocation happens, ESB will first lookup the endpoint in their own registry. If it is not available, it will pull the endpoint from G-Reg using Remote Registry operations.  Here ESB side endpoint lookup should be implemented as a custom implementation.  

ESB pull.png

Advantages: 
        User might be able to deploy ESB API/Service before G-Reg lifecycle transition happens. Disadvantages: 
        First API/Service call get delayed, until Remote API call is completed 
        First API/Service call get failed, if G-Reg lifecycle transition is not completed. 
        Less control compared to option 1 and 2

Saturday, April 16, 2016

Lifecycle Management with WSO2 Governance Registry

SOA Lifecycle management is one of the core requirements for the functionality of an Enterprise Governance suite. WSO2 Governance Registry 5.2.0 supports multiple lifecycle management capability out of the box. Also, it gives an opportunity to the asset authors to extend the out of the box lifecycle functionality by providing their own extensions, based on the organization requirements. Further, the WSO2 Governance Registry supports multiple points of extensibility. Handlers, Lifecycles and Customized asset UIs(RXT based) are the key types of extensions available.

Lifecycle: 

A lifecycle is defined with SCXML based XML element and that contains,
  • A name 
  • One or more states
  • A list of check items with role based access control 
  • One or more actions that are made available based on the items that are satisfied 

Adding a Lifecycle
To add a new lifecycle aspect, click on the Lifecycles menu item under the Govern section of the extensions tab in the admin console. It will show you a user interface where you can add your SCXML based lifecycle configuration. A sample configuration will be available for your reference at the point of creation.

Adding Lifecycle to Asset Type
The default lifecycle for a given asset type will be picked up from the RXT definition. When creating an asset, it will automatically attach lifecycle into asset instance. Lifecycle attribute should be defined in the RXT definition under the artifactType element as below.

<lifecycle>ServiceLifeCycle</lifecycle>

Multiple Lifecycle Support

There can be instances, where given asset can go through more than one lifecycle. As an example, a given service can a development lifecycle as well as a deployment lifecycle. Above service related states changes will not be able to visualize via one lifecycle and current lifecycle state should depend on the context (development or deployment) which you are looking at.

Adding Multiple Lifecycle to Asset Type
Adding multiple lifecycles to an Asset Type can be done in two primary methods.

Through Asset Definition(Available with G-Reg 5.3.0):Here, you can define multiple lifecycle names in a comma separated manner. Lifecycle name which is defined in first will be considered as the default/primary lifecycle. Here, multiple lifecycles which are specified in the asset definition(RXT configuration) will be attached to the asset when itis getting created. An example of multiple lifecycle configurations is as below,
<lifecycle>ServiceLifeCycle,SampleLifeCycle</lifecycle>

Using Lifecycle Executor
Using custom executor Java code, you can assign another lifecycle into the asset. Executors are one of the facilitators which helps to extend the WSO2 G-Reg functionality and Executors are associated with a Governance Registry life cycle. This custom lifecycle executor class needs to implement the Execution interface that is provided by WSO2 G-Reg. You can find more details from below article[Lifecycles and Aspects].

Tuesday, March 29, 2016

How to disable Registry indexing


Sometimes people complain that they have seen background DB queries executed by some WSO2 products(EX: WSO2 API Manager Gateway profile). These query executions are not harmful, and those correspond to registry indexing task that runs in the background.

It is not required to enable indexing task for APIM 1.10.0 based Gateway or Key Manager nodes. So you can disable the indexing task by setting "startIndexing" parameter as false. This "startIndexing" parameter should be configured in the registry.xml file under "indexingConfiguration" section.

Ex:
 <indexingConfiguration>  
     <startIndexing>false</startIndexing>  
     ......  
 </indexingConfiguration>  

Friday, March 18, 2016

WSO2 Governance Registry: Support for Notification

With WSO2 Governance Registry 5.x releases, now you can send rich email messages when email notification is triggered in WSO2 Governance Registry with the use of email templating support we have added. In the default implementation, administrator or any privileged user can store email templates in “/_system/governance//repository/components/org.wso2.carbon.governance/templates” collection and the template name must be same as the lower case of the event name.

For an example if you want to customize “PublisherResourceUpdated” event, template file should be as: “/_system/governance/repository/components/org.wso2.carbon.governance/templates/publisherresourceupdated.html”.

If you do not want to define event specific email templates, then you can add a template called “default.html”.

By default, $$message$$ message section in email templates will be replaced with the message generated in the event.

FAQ:
How can I plug my own template mechanism and modify the message?

You can override the default implementation by adding a new custom implementation. First, you have to create a Java project. Then you have to implement “NotificationTemplate” interface and override the “populateEmailMessage” method. There you can write your own implementation.

After that, you have to add the compiled JAR file to WSo2 Governance Registry. If it’s an OSGI bundle, please add it to :  <GREG_HOME>/repository/compoments/dropins/ folder Otherwise jar needs to be added to  <GREG_HOME>/repository/compoments/lib/ folder

Finally, you have to add the following configuration to registry.xml file.

<notificationConfiguration>
   <class>complete class name with package</class>
</notificationConfiguration>

What are the notification types available in the Store, publisher and Admin Console?

Store: StoreLifeCycleStateChanged,StoreResourceUpdated,
Publisher: PublisherResourceUpdated, PublisherLifeCycleStateChanged,     PublisherCheckListItemUnchecked, PublisherCheckListItemChecked

Admin Console: Please refer this documentation (Adding a Subscription)

Do I need to enable worklist for console subscriptions?

Yes, you have to enable Worklist configuration.(Configuration for Work List)

Does notifications visible in each application?

If you have login access to the Publisher, Store and Admin Console, then you can view notifications from each of those applications. However, some notifications may have customized to fit the context of relevant applications.