Social Icons

twitterfacebookgoogle pluslinkedinrss feed Online Resume

Featured Posts

Friday, September 09, 2016

Java - String intern() Method

String Intern method returns an individual representation for the given String object. When the intern() method get invoked on a String object, it will look up the other interned strings, and if a String object exists in the memory with the same content, it will return the existing reference. Otherwise, it will return a new reference.

Example usage of String intern:

Think about a web application with a caching layer. If cache got missed, it would go to the Database. When the application is running with the high level of concurrency, we should not send all the request to the database. Such a situation we can check whether, multiple calls coming to the same reference by checking String intern.

Code: 

String name1 = "Value";
String name2 = "Value";
String name3 = new String("Value");
String name4 = new String("Value").intern();

if ( name1 == name2 ){
    System.out.println("name1 and name2 are same");
}
if ( name1 == name3 ){
    System.out.println("name1 and name3 are same" );
}
if ( name1 == name4 ){
    System.out.println("name1 and name4 are same" );
}
if ( name3 == name4 ){
    System.out.println("name1 and name4 are same" );
}

output:

name1 and name2 are same
name1 and name4 are same



You can see that name1, name2 and name4, objects have the same reference and name3 reference is different.

Wednesday, August 24, 2016

Service Discovery with WSO2 Governance Registry


This blog post explains about the service discovery capability of WSO2 Governance Registry. If you have heard about UDDI and WS-Discovery, we used those technologies to discover Services during 2009-2013 time.

What is UDDI:


UDDI stands for Universal Description, Discovery, and Integration. It is seen with SOAP and WSDL as one of the three foundation standards of web services. It uses Web Service Definition Language(WSDL) to describe the services.

What is WS-Discovery:


WS-Discovery is a standard protocol for dynamically discovering service endpoints. Using WS-Discovery, service providers multicast and advertise their endpoints with others.

Since most of the modern services are REST based, above two approaches are considered as dead nowadays. Both UDDI and WS-Discovery target for SOAP based services and they are very bulky. In addition to that, industry is moving from Service Registry concept to Asset Store(Governance Center), and people tend to use REST API and Discovery clients.

How Discovery Client works


So, here I am going to explain how to write discovery client in WSO2 Governance Registry(WSO2 G-Reg) to discover services which are deployed in the WSO2 Enterprise Service Bus(WSO2 ESB). This service discovery client will connect to ESB server and find the services which are deployed there and catalog those into the G-Reg server. In addition to service metadata(endpoint, name, namespace, etc.), discovery client will import the WSDLs and XSDs as well.

Configure Service Discovery Client:


Sample service discovery client implementation can be found from the below GitHub repo(Discovery Client).

1). Download WSO2 Governance Registry and WSO2 Enterprise Service Bus product and unzip it.

2). By default, both servers are running on 9443 port, so you have to change one of the server ports. Here I am changing port offset of the ESB server.

Open the carbon.xml file located in <ESB_HOME>/repository/conf/carbon.xml and find the “Offset” element and change its value as follows: <Offset>1</Offset>

3). Copy <ESB_HOME>/repository/components/plugins/org.wso2.carbon.service.mgt.stub_4.x.x.jar to <GREG_HOME>/repository/components/dropins.

4). Download or clone ESB service discovery client project and build it.

5). Copy build jar file into <GREG_HOME>/repository/components/dropins directory.

6). Then open the registry.xml file located in <GREG_HOME>/repository/conf/registry.xml and register service discovery client as a Task. This task should be added under “tasks” element.

<task name="ServiceDiscovery" class="com.chandana.governance.discovery.services.ServiceDiscoveryTask">
            <trigger cron="0/100 * * * * ?"/>
            <property key="userName" value="admin" />
            <property key="password" value="admin" />
            <property key="serverUrl" value="https://localhost:9444/services/"/>
            <property key="version" value="1.0.0" />
        </task>

7). Change the userName, password, serverUrl and defaultVersion according to your setup.

8). Now Start ESB server first and then start the G-Reg server. 

So, you can see “
# of service created :...” message in G-Reg console once server has discovered a service from the ESB server and mean time related WSDL and XSD has got imported into G-Reg. Above services are cataloged under “SOAP Service” asset type.

Wednesday, August 10, 2016

Maven Compiler Plugin

The Maven Compiler Plugin is used to compile the java source code of your project. The default compiler is javac and is used to compile Java sources. By modifying pom.xml file, you can customize the default behavior of Maven Compiler Plugin. 

Using Maven Compiler Plugin, you can compile the source code of a certain project to a different version of JVM than what you are currently using. EX: compile using JDK 1.8 and target JVM is 1.7. Default source setting is JDK 1.5, and the default target setting is JDK 1.5

Example configuration is as below:


<build>
    <plugins>
        <plugin>
           <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.5.1</version>
            <configuration>
                <source>1.7</source>
                <target>1.7</target>
            </configuration>
        </plugin>
    </plugins>
</build>

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