PRABATH'S TECH BLOG

Select different backend pools based on the HTTP Headers in Nginx

prabathmail@yahoo.com (prabath ariyarathna) — Tue, 21 Mar 2017 09:46:00 +0530

Some scenarios we need to select different backend pools based on some attributes in the request.
Nginx has that capability to selecting different backend pools based on the request header value.

To accomplish this in Nginx you can use the following code in your configuration.

upstream gold {
     server 127.0.0.1:8080;
     server 127.0.0.1:8081;
     server 127.0.0.1:8082;
}

upstream platinum {
     server 127.0.0.1:8083;
     server 127.0.0.1:8084;
     server 127.0.0.1:8085;
}

upstream silver {
     server 127.0.0.1:8086;
     server 127.0.0.1:8087;
}

# map to different upstream backends based on header
map $customer_type $pool {
     default "gold";
     platinum "platinum";
     silver "silver";
}

server {
     listen 80;
     server_name localhost;
     location / {
          proxy_pass http://$pool;

          #standard proxy settings
          proxy_set_header X-Real-IP $remote_addr;
          proxy_redirect off;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          proxy_set_header Host $http_host;
          proxy_redirect off;
          proxy_set_header X-Forwarded-Proto $scheme;
          proxy_set_header X-NginX-Proxy true;
          proxy_connect_timeout 600;
          proxy_send_timeout 600;
          proxy_read_timeout 600;
          send_timeout 600;
}

You can test this setup by sending request with custom http header customer_type.

Ex:- customer_type = gold

This will load balance only among the 8080, 8081 and 8082.

Why Container based deployment is preferred for the Microservices?

prabathmail@yahoo.com (prabath ariyarathna) — Mon, 23 Jan 2017 13:51:00 +0530

When it comes to Microservices architecture, the deployment of Microservices plays a critical role and has the following key requirements.

Ability to deploy/un-deploy independently from other Microservices.
Developers never need to coordinate the deployment of changes that are local to their service. These kinds of changes can be deployed as soon as they have been tested. The UI team can, for example, perform A|B testing and rapidly iterate on UI changes. The Microservices Architecture pattern makes continuous deployment possible.

Must be able to scale at each Microservices level (a given service may get more traffic than other services).

Monolithic applications are difficult to scale individual portions of the application. If one service is memory intensive and another CPU intensive, the server must be provisioned with enough memory and CPU to handle the baseline load for each service. This can get expensive if each server needs high amount of CPU and RAM, and is exacerbated if load balancing is used to scale the application horizontally. Finally, and more subtlety, the engineering team structure will often start to mirror the application architecture over time.

We can overcome this by using Microservices. Any service can be individually scaled based on its resource requirements. Rather than having to run large servers with lots of CPU and RAM, Microservices can be deployed on smaller hosts containing only those resources required by that service.

For example, you can deploy a CPU-intensive image processing service on EC2 Compute Optimized instances and deploy an in-memory database service on EC2 Memory-optimized instances.

Building and deploying Microservices quickly.

One of the key drawback of the monolithic application is the difficult to scale. As explained in above section, it needs to mirror the whole application to scale. With the micro services architecture we can scale the specific services since we are deploying services in the isolated environment. Nowadays dynamically scaling the application is very famous every iSaaS has that capability(eg:- Elastic load balancing). With that approach we need to quickly launch the application in the isolated environment.

Following are the basic deployment patterns which we can commonly see in the industry.

Multiple service instances per host - deploy multiple service instances on a host

Service instance per host - deploy a single service instance on each host

Service instance per VM - a specialization of the Service Instance per Host pattern where the host is a VM

Service instance per Container - a specialization of the Service Instance per Host pattern where the host is a container

Container or VM?

As of today there is a significant trend in the industry to move towards containers from VMs for deploying software applications. The main reasons for this are the flexibility and low cost that containers provide compared to VMs. Google has used container technology for many years with Borg & Omega container cluster management platforms for running Google applications at scale. More importantly Google has contributed to container space by implementing cgroups and participating in libcontainer project. Google may have gained a huge gain in performance, resource utilization and overall efficiency using containers during past years. Very recently Microsoft who did not had an operating system level virtualization on Windows platform took immediate actions to implement native support for containers on Windows Server.

I found nice comparison between the VMS and Containers in the internet which comparing House and the Apartments.

Houses (the VMs) are fully self-contained and offer protection from unwanted guests. They also each possess their own infrastructure – plumbing, heating, electrical, etc. Furthermore, in the vast majority of cases houses are all going to have at a minimum a bedroom, living area, bathroom, and kitchen. I’ve yet to ever find a “studio house” – even if I buy the smallest house I may end up buying more than I need because that’s just how houses are built.

Apartments (the containers) also offer protection from unwanted guests, but they are built around shared infrastructure. The apartment building (Docker Host) shares plumbing, heating, electrical, etc. Additionally apartments are offered in all kinds of different sizes – studio to multi-bedroom penthouse. You’re only renting exactly what you need. Finally, just like houses, apartments have front.

There are design level differences between these two concepts. Containers are sharing the underlying resources while providing the isolate environment and it only provides the resources which need to run the application but VMS are different. It first start the OS and then start your application. Like or not it's providing default set of unwanted services which consume the resources.

Before move into the actual comparison, lets see how we can deploy micro services instance in any environment. Environment can be single or multi host in the single VM or it can be the multiple container in the single VM, single container in the single VM or dedicated environment. It is not just starting application on the VM or deploy application in the web container. We should have automated way to manage it. As the example AWS provide nice VM management capability for any deployments. If we use VM for the deployment we are normally build the VM with required application component and using this VM we can spawn any number of different instances.

Similar to AWS VM management, we need some container management platform for the container as well, because when we need scale the specific service we cannot manually monitor the environment and start new instance. It should be automated. As the example we can use Kubunertees. It is extending Docker's capabilities by allowing to manage a cluster of Linux containers as a single system, managing and running Docker containers across multiple hosts, offering co-location of containers, service discovery, and replication control.

Both VM and containers are designed to provide an isolated environment. Additionally, in both cases that environment is represented as a binary artifact that can be moved between hosts. There may be other similarities but those are the major differences as i see.

In a VM-centered world, the unit of abstraction is a monolithic VM that stores not only application code, but often it's stateful data. A VM takes everything that used to sit on a physical server and just packs it into a single binary so it can be moved around. But it is still the same thing. With containers, the abstraction is the application; or more accurately a service that helps to make up the application.

When we scale up the instances this is very useful because we use VMs means we need to spawn another VM instance. It will take some times to start(OS boot time, Application boot time) but with the Docker like container deployment we can start new container instance within few milliseconds(Application boot time).

Other important factor is patching the existing services. Since we cannot develop the code without any issue. Definitely we need to patch the code. Patching the code in microservices environment is little bit tricky because we may have more than 100 of instances to patch. So If we get the VM deployment, we need to make the new VM image by adding new patches and use it for the deployment. It is not an easy task because there can be more than 100 micro services and we need to maintain different type of VM images but with the Docker like container based deployment is not an issue. We can configure docker image to get these patched from configured place. We can achieve similar requirement by puput script in the VM environment but Docker has that capability out of the box. Therefore the total config and software update propagation time would be much faster with the container approach.

A heavier car may need more fuel for reaching higher speeds than a car of the same spec with less weight. Sports car manufacturers always adhere to this concept and use light weight material such as aluminum and carbon fiber for improving fuel efficiency. The same theory may apply to software systems. The heavier the software components, the higher the computation power they need. Traditional virtual machines use a dedicated operating system instance for providing an isolated environment for software applications. This operating system instance needs additional memory, disk and processing power in addition to the computation power which needed by the applications. Linux containers solved this problem by reducing the weight of the isolated unit of execution by sharing the host operating system kernel with hundreds of containers. The following diagram illustrates a sample scenario of how much resources containers would save compared to virtual machines

We cannot say Container based deployment is the best for the Micro services for every deployment it is based on the different constrained . So we need carefully select one or both as the hybrid way based on our requirement.

Reference :- http://microservices.io

http://blog.docker.com

How Disruptor can use for improve the Performance of the interdependen Filters/Handlers?

prabathmail@yahoo.com (prabath ariyarathna) — Wed, 18 Jan 2017 10:13:00 +0530

In the typical filter or handler pattern we have set of data and filters/handlers. We are filtering the available data set using available filters.

These filters may have some dependencies(In business case this could be the sequence dependency or data dependency) like filter 2 depends on filter 1 and some filters does not have dependency with others. With the existing approach, some time consuming filters are designed to use several threads to process the received records parallely to improve the performance.

However we are executing each filter one after another. Even Though we are using multiple threads for high time consuming filters, we need to wait until all the record finish to execute the next filter. Sometimes we need to populate some data from database for filters but with the existing architecture we need to wait until the relevant filter is executed.

We can improve this by using non blocking approach as much as possible. Following diagram shows the proposed architecture.

According to the diagram, we are publishing routes to the Disruptor(Disruptor is simple ring buffer but it has so many performance improvement like cache padding) and we have multiple handler which are running on different threads. Each handler are belong to different filters. We can add more handlers to the same filter based on the requirement. Major advantage is, we can process simultaneously across the all routes. Cases like dependency between the handlers could handle in the implementation level. With this approach, we don't need to wait until all the routes are filtered by the single routes. Other advantage is, we can add separate handlers for populate data for future use.

Disruptors are normally consuming more resources and it is depended on the waiting strategies which we can use for the handlers. So we need to decide on what kind of Disruptor configuration patterns we can use for the application. It can be single disruptor, single disruptor for the user, multiple disruptor based on the configuration or we can configure some Disruption for selected filters(Handlers) and different one for other handlers.

Application Monitoring

prabathmail@yahoo.com (prabath ariyarathna) — Mon, 21 Nov 2016 20:01:00 +0530

In the software world, application monitoring is critical for the administrators as well as for the maintenance(Application support) teams. Obviously monitoring is very useful for the administrators. They need to monitor the realtime behavior of the application to give uninterrupted service to the end users, but monitoring is even important to the support teams to track down the issues of the applications.

Doing support is the most important phase of the software development life cycle after delivering the product. End Users reported different kind of issues and support engineers need some informations which are related to the application behaviour to solve the issues. Some issues are domain related and we can simply recreate the issues in our local environment. Fixing the issue is not a big deal if we could reproduce the same behavior in our local setup but some issues are not easy to replicate in the local environment because those aren’t continuously happening in the production setup. So Identifying the exact root cause is the challenge. Concurrency issues, Thread spinning issue and memory issues are in the top of the order. Software developer should have proper plan to report the status of the application with required details when application has some issues. Putting log messages with the proper details and proper place are the most important but same cases like high CPU usage, developer need some more information like thread dump to track the issue. Support engineers or developers may be identified the issue by looking at the logs, thread dump or heap dumps, but application specific information need for some cases. Proper monitoring mechanism can fulfil that requirement. There are different type of monitoring application available in the industry for different purposes but all these applications are developed as the general purpose applications. Application developer need to implement application specific monitoring mechanism for achieving that requirement.

Note:- Proper Monitoring mechanism can be get as the marketing factor because client can incorporate JMX APis with their existing monitoring dashboards seamlessly or we can provide our own monitoring dashboard to the customers.

JMX(Java management extension)

The JMX technology provides the tools for building distributed, Web-based, modular and dynamic solutions for managing and monitoring devices, applications, and service-driven network. Starting with the J2SE platform 5.0, JMX technology is included in the Java SE platform. JMX is the recommended way to monitor and manage java applications. As an example, administrator can stop or start the application or dynamically can change the configurations. Monitoring and management are the basic usage of the JMX. JMX can be used for design the full modularize applications which can enable and disable the modules at any time via the JMX, but main intention of this article is for discussing management and monitoring capabilities of the JMX.

JMX architecture.

Three main layers can be identified in the JMX architecture.

Prob Level

The level closed to the application is called the instrumentation layer or prob layer. This level consists of four approaches for instrumenting application and system resources to be manageable (i.e., making them managed beans, or MBeans), as well as a model for sending and receiving notifications. This level is the most important level for the developers because this level prepares resources to be manageable. We can identify main two categories when we consider about the instrumentation level.

Application resources( Eg:- Connection pool, Thread pool, .. etc)

An application resources that need to be manageable through the JMX must provide the metadata about a resource’s features are known as its management interface. Management applications may interact with the resources via management interface.

Instrumentation strategy.

There are four instrumentation approaches defined by JMX that we can use to describe the management interface of a resource: standard, dynamic, model, and open

2. Agent Level

The agent level of the JMX architecture is made up of the MBean server and the JMX agent services. The MBean server has two purposes: it serves as a registry of MBeans and as a communications broker between MBeans and management applications (and other JMX agents). The JMX agent services provide additional functionality that is mandated by the JMX specification, such as scheduling and dynamic loading.

3. Remote management Level

Top level of the JMX architecture is called the distributed services level. This level contains the middleware that connects JMX agents to applications that manage them (management applications). This middleware is broken into two categories: protocol adaptors and connectors.

Point A to Point B by Air

prabathmail@yahoo.com (prabath ariyarathna) — Wed, 2 Nov 2016 23:03:00 +0530

As a company or individually, you may need to deliver your goods from one place to another place. The most important thing is selecting the suited shipment mode for your logistics. Following are the major modes of shipments.

1. Ground

Land or "ground" shipping can be done by train or truck.In order to take air and sea shipments, ground transportion is required to take the cargo from its place of origin to the airport or seaport .it is not always possible to establish a production facility near ports due to limited coastlines of countries.

2. Air

Cargo is transported by air in specialized cargo aircraft or in the luggage compartments of passenger aircraft

3. Ship

Shipping is done by commercial ships. Merchant shipping is the lifeblood of the world economy, carrying 90% of international trade with 102,194 commercial ships worldwide

4. Intermodal

Intermodal freight transport refers to shipments that involve more than one mode.

Each of these modes have different pros and cons. We need to select best suited mode based on our requirement, because shipping cost can be directly affected to the business.However I will only discuss about the Air transport mode in this post.

If we consider in the cost wise definitely Air transport mode is not cost effective but it has some advantage which most of the modern business need. I have listed below few of those.

1. The fastest shipping method

When your goods need to be moved quickly, air freight is the best solution compared to sea freight or ground transport.

2. Highly reliable arrival and departure times

The arrival and departure times of flights are highly reliable, as airlines tend to be very on top of their schedules. Even missing a flight wouldn’t cause much delay as there are usually flights departing every hour.

3. Send your cargo almost anywhere

Many airlines have a large network of destinations that cover almost the entire world. This means that you can send the shipment to nearly every destination.

4. Low insurance premium means large savings

As the transportation time for air cargo is comparatively short, the insurance premium is much lower. Even if air freight can be expensive, this brings about savings in terms of lower insurance costs.

5. High level of security and reduced risk of theft and damage

6. Less need of warehousing and fewer items in stock

With the quicker transit times of air freight, local warehouse requirement is much lesser because stock aren't needed to keep for longer. Customs clearance, cargo inspection and cargo handlers are more efficient, as most of cargos are cleared within a matter of hours.

7. Less packaging required

Normally, air shipments require less heavy packing than for ocean shipments. So it saves both time and money to spend for additional packing.

8. Follow the status of cargo

Many companies offer the opportunity to track cargo using web applications, which means arrival and departure of cargos can be closely monitored by staying at any where in the world.

Let’s think some company or individual selected Air cargo as the transportation mode for shipments, there are several parties who involved within the process. Airways are the major party who own the carriers. We can find three major type of carriers in the Air cargo arena.

Passenger aircraft use spare volume in the airplane's baggage hold (the "belly") that is not being used for passenger luggage - a common practice used by passenger airlines, who additionally transport cargo on scheduled passenger flights. - this practice is known as Belly Cargo. Cargo can also be transported in the passenger cabin as hand-carry by an “on-board courier”.

Cargo aircraft are dedicated for the job - they carry freight on the main deck and in the belly by means of nose-loading or side loading.

Combi aircraft carries cargo on the main deck behind the passengers’ area with side loading and in the belly.

Passenger aircrafts are the famous transport medium for the Air cargo because we cannot find Cargo aircrafts commonly for the each and every destinations. However main business of the Passenger airways is not the cargo handling because their main focus is the passenger handling. So Cargo is considered as the secondary business. One of the main reason for this is, marketing is easier with passenger transportation. As examples, marketing on the passenger seats can be done based on the facilities like business class , economy class , free wifi and meals but this cannot be done for cargo.

Passenger Airlines are not putting their full effort on the cargo business since this is secondary business for them. Hence most of the services are outsourced to the several parties.

Following diagram explains few of them briefly.

According to the above diagram you can see merchants are not directly dealing with the Airways. There are two main parties in between merchant and the airway. Each and every party has separate responsibilities.

Merchants.

Merchants are the clients in the cargo industry. As an example we can get the Seagate(Hard disk manufacturer) and 3M(provides cutting edge health and safety products). They are producing products in their Singapore factories and need to ship products to different destinations(eg:- Sri lanka) based on the requirements via Air cargo. As I explained earlier since this is secondary business for the Airways, they are not putting enough staff members for this service. So most of the required things such as documentation is done by third parties. So merchants are directly dealing with the logistic providers(Forwarders) for these purposes.

Forwarders.(3PL)

Normally 3PLs work in this scenario is deliver the goods to the required destinations but other than that they are providing various of services in the logistic context like warehousing, local distributing.

Most of the largest 3PLs are multinational companies and they are based in many countries, if not they have some partner 3PLs. Common practice is Merchant send the request to the 3PL for sending their goods to the single or multiple destinations. Most of the large scale merchants are using multiple 3PLs for delivering their goods. Most of the time 3PLs are responsible for preparing the required documents for the goods, because most of the times different parties need different documents to proceed freight. Other than this, they are doing re packaging if required. Next step is handover the goods to the ground handling agents.

According to the diagram, Forwarders are playing two different roles in two(Origin and destination) sides. In destination side their responsibility is delivering the goods to the consumers . Consumers could be the company or shopping mall or individual

Ground handling agents

First Of All let see why we need ground handling agents.

Passenger airlines has several destinations(Singapore Airlines has 63 international destinations) So maintaining different cargo office in each and every destination is not a possible task. Since this is common issue for the each and every Airways, every airport has ground handling agents. Most of the time those are owned by the national carrier of the country. So their responsibility is handling cargo behalf of the Airways. SATS is the main ground handling agent in the Changi airport and it is owned by Singapore airline. It is providing cargo handling to the Singapore airline as well as the other airlines. There can be multiple ground handling agent in big airports.

How to monitor the Thread CPU usage in the WSO2 Products?

prabathmail@yahoo.com (prabath ariyarathna) — Fri, 20 May 2016 08:09:00 +0530

1. Download JConsole topthreads Plugin.

2. Add following entries to the PRODUCT_HOME/bin/wso2server.sh
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=PORT \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \
-Djava.rmi.server.hostname=IP_ADDRESS \
Define your IP_ADDRESS address and PORT (port should be not used anywhere in that instance)

3. Run the JConsole using following command.
jconsole -pluginpath PATH_TO_JAR/topthreads-1.1.jar

4. Copy "JMXServerManager JMX Service URL" from the wso2carbon logs after restart the Wso2 Server (Eg:- service:jmx:rmi://localhost:11111/jndi/rmi://localhost:9999/jmxrmi) to the Remote process with the username and password.

5. Under Top Threads tab you can monitor the thread CPU usage.

Enable SecureVault Support for jndi.properties - WSO2 ESB - MB 3.0

prabathmail@yahoo.com (prabath ariyarathna) — Tue, 5 Apr 2016 22:35:00 +0530

We cannot use cipertool to automate encryption process for the selected elements in the jndi.properties file, because we can only specify Xpath notation here, but still we can use the manual process.

Sample [ESB_home]/repository/conf/jndi.properties file

# register some connection factories
# connectionfactory.[jndiname] = [ConnectionURL]
connectionfactory.QueueConnectionFactory = amqp://admin:admin@clientID/carbon?brokerlist
='tcp://localhost:5672'

# register some queues in JNDI using the form
# queue.[jndiName] = [physicalName]
queue.MyQueue = example.MyQueue

# register some topics in JNDI using the form
# topic.[jndiName] = [physicalName]
topic.MyTopic = example.MyTopic

1. Enable secure valut in the ESB
sh ciphertool.sh -Dconfigure

2. Go to the [ESB_home]/bin and execute the following command to generate the encrypted value for the clear text password.

sh ciphertool.sh

3. It will prompt following console for input value. Answer: wso2carbon

[Please Enter Primary KeyStore Password of Carbon Server : ]

4. Then it will appear second console for following input value.
(Answer: According to our property file, the plain text is "amqp://admin:admin@clientID/carbon?brokerlist='tcp://localhost:5672'".)

Encryption is done Successfully

Encrypted value is :cpw74SGeBNgAVpryqj5/xshSyW5BDW9d1UW0xMZDxVeoa6xS6CFtU
+ESoR9jRjyA1JRHutZ4SfzfSgSzy2GQJ/2jQIw70IeT5EQEAR8XLGaqlsE5IlNoe9dhyLiPXEPRGq4k/BgU
QDYiBg0nU7wRsR8YXrvf+ak8ulX2yGv0Sf8=

5. Open the cipher-text.properties file, which is under [ESB_home]/repository/conf/security and add the following entry.

connectionfactory.QueueConnectionFactory=cpw74SGeBNgAVpryqj5/xshSyW5BDW9d1UW0xMZ
DxVeoa6RjyA1JRHutZ4SfzfSgSzy2GQJ/2jQIw70IeT5EQEAR8XLGaqlsE5IlNoe9dhyLiPXEPRGq4k/BgUQD
YiBg0nU7wRsR8YXrvf+ak8ulX2yGv0Sf8=

6. Open the [ESB_home]/repository/conf/jndi.properties file and update the key/value of connectionfactory field.

connectionfactory.QueueConnectionFactory=secretAlias:connectionfactory.QueueConnectionFactory

How SSL Tunneling working in the WSO2 ESB

prabathmail@yahoo.com (prabath ariyarathna) — Thu, 5 Nov 2015 12:05:00 +0530

This blog post assumes that the user who reads has some basic understanding of SSL tunneling and the basic message flow of the ESB. If you are not familiar with the concepts of the SSL tunneling you can refer my previous blog post about the SSL tunneling and you can get detail idea about the message flow from this article.
I will give brief introduction about the targetHandler for understand concepts easily. As you may already know TargetHandler(TH) is responsible for handling requests and responses for the backend side. It is maintaining status (REQUEST_READY, RESPONSE_READY .. ,etc) based on the events which fired by the IOReactor and executing relevant methods. As the example if a response which is coming from the backend side hits to the ESB, IOReactor fire the responseRecived method in the targetHandler side. Followings are the basic methods contain in the target handler and their responsibilities.

Connect: - This is executed when new outgoing connection needed.

RequestReady:- This is executed by the IOReactor when new outgoing HTTP request headers are coming. Inside this method we are writing http Headers to the relevant backend.

OutputReady:- Responsible for writing request body to the specified backend service.

ResponseRecived:- This is executed when backend response headers are coming to the ESB.

OutputReady:- Responsible for reading the backend response body.

Let me explain tunneling process step by step.

If proxy server is configured in the ESB, once request comes to the target handler side, it creates connection with the proxy server because all request need to go via the proxy server.
Once request headers comes to the TH side(inside the requestReady method), those headers need to send to the actual backend side, but still we don't have connectivity between the actual backend and the ESB.
In this point we need to start initializing the tunneling in between ESB and the actual backend service. As I explained in the previous article. For initialize the tunneling, we need to first send the CONNECT request to the proxy server side. If you checked the TH requestReady code you can see the how CONNECT request is sending to the proxy server.
Proxy server establishing the connection with the backend service Once CONNECT request hits.
Base on the CONNECT request which has send from the TH requestReady methods, Proxy server responses with the 200 range status code.
This will initially hits to the TH responseRecive method. So it will upgrade the existing connection to secure one by initiating a TLS handshake on that channel. Internally existing IOSession upgrades into the SSLIOSession by using IOSession informations.
Since everything is now relayed to the backend server, it's as if the TLS exchange was done directly with backend secure service.
Now the tunnel between the ESB and backend secure service has been initialized. we need to send actual request to the backend secure service. For that we need to trigger the target handler execution again. Under responseRecive method you can see executing
conn.resetInput(); conn.requestOutput(); to execute the requestReady and outputReady methods for sending actual request to the backend.

How to setup SSL handling in the ESB?

First you need to setup proxy server.
Install Squid as described here.
Configure for the ESB side.
In /repository/conf/axis2/axis2.xml, add the following parameters to the transportSender configuration for PassThroughHttpSender,PassThroughHttpSSLSender, HttpCoreNIOSender, and HttpCoreNIOSSLSender:
```
<parameter name="http.proxyHost" locked="false">hostIP</parameter>
<parameter name="http.proxyPort" locked="false">portNumber</parameter>
```
where hostIP and portNumber specify the IP address and port number of the proxy server.Uncomment the following parameter in the PassThroughHttpSSLSender and HttpCoreNIOSSLSender configurations and change the value to "AllowAll".
```
<parameter name="HostnameVerifier">AllowAll</parameter>
```
For example, if the host and port of proxy server is localhost:8080, your transportSender configurations for PassThroughHttPSender and PassThroughHttpSSLSender would look like this:

What is SSL Tunneling?

prabathmail@yahoo.com (prabath ariyarathna) — Thu, 5 Nov 2015 00:27:00 +0530

You want to be able to access some restricted destinations and/or ports with some applications from your computer but you are on a restricted network (corporate) - Even using a Torrent client.

How to overcome this limitation?
What if backend service is secure one?
We can use SSL tunneling for overcome above issue.

What is the SSL tunneling?

SSL tunneling is when an Internal client application requests a web object using HTTPS on port 8080 through the proxy server.

An example of this is when you are using online shopping. The internet connection to the target relevant e-commerce website is tunneled to by you through proxy server. The key word here is through. The client communicates with the target web server directly after the initial connection has been established by proxy server, by means of communication within the SSL tunnel that has been created after SSL negotiation has taken place.

How it's working?

The client makes a tunneling request: CONNECT server-host-name:port HTTP/1.1 (or HTTP/1.0). The port number is optional and is usually 443. The client application will automatically send the CONNECT request to the proxy server first for every HTTPS request if the forward proxy is configured in the browser.
```
CONNECT www.example.com:443 HTTP/1.1
Host: www.example.com:443
```
RFC 2616 treats CONNECT as a way to establish a simple tunnel. There is more about it in RFC 2817, although the rest of RFC 2817 (upgrades to TLS within a non-proxy HTTP connection) is rarely used.
The proxy accepts the connection on its port 8080, receives the request, and connects to the destination server on the port requested by the client.
The proxy replies to the client that a connection is established with the 200 OK response.
After this, the connection between the client and the proxy server is kept open. The proxy server relays everything on the client-proxy connection to and from proxy-backend. The client upgrades its active (proxy-backend) connection to an SSL/TLS connection, by initiating a TLS handshake on that channel.
Since everything is now relayed to the backend server, it's as if the TLS exchange was done directly with www.example.com:443.
The proxy server doesn't play any role in the handshake. The TLS handshake effectively happens directly between the client and the backend server.
After the secure handshake is completed, the proxy sends and receives encrypted data to be decrypted at the client or at the destination server.
If the client or the destination server requests a closure on either port, the proxy server closes both connections (ports 443 and 8080) and resumes its normal activity.

How to write a Synapse Handler for the WSO2 ESB ?

prabathmail@yahoo.com (prabath ariyarathna) — Sun, 4 Oct 2015 19:25:00 +0530

Synapse handler is new feature which come with the ESB 4.9.0. It provide abstract handler implementation to the users. User can create their own concrete handlers which is executing in the synapse layer. Main intention of this blog post is to explain how to write synapse handler and explain basic theoretical background.

1. What is the handler?

Handlers are basically talking with the chain of responsibility pattern. Chain of responsibility allows a number of classes to attempt to handle a request independently of any other object along the chain. Once the request is handled, it completes it's journey through the chain.

The Handler defines the interface which required to handle the request and concreteHandlers handle request in a specific manner that they are responsible for.

2. What is Synapse handler?

Synapse handler is providing abstract handle implementation which executes in the following four scenarios.

1. Request in flow

This is executing when request is hitting to the synapse engine.

public boolean handleRequestInFlow(MessageContext synCtx);

2. request out flow

This is executing when request goes out from the synapse engine.

public boolean handleRequestOutFlow(MessageContext synCtx);

3. Response in flow

This is executing when response is hitting to the synapse engine.

public boolean handleResponseInFlow(MessageContext synCtx);

4. Response out flow

This is executing when response goes out from the synapse engine.

public boolean handleResponseOutFlow(MessageContext synCtx);

Following diagram shows the basic component structure of the ESB and how above mentioned scenarios are executing in the request and response flow.

3. How to write concrete Synapse handler?

You can implement concrete handler by implementing SynapseHandler(org.apache.synapse.SynapseHandler) interface or can extends AbstractSynapseHandler(org.apache.synapse.AbstractSynapseHandler) class.

public class TestHandler extends AbstractSynapseHandler {

private static final Log log = LogFactory.getLog(TestHandler.class);

@Override

public boolean handleRequestInFlow(MessageContext synCtx) {

log.info("Request In Flow");

return true;

}

@Override

public boolean handleRequestOutFlow(MessageContext synCtx) {

log.info("Request Out Flow");

return true;

}

@Override

public boolean handleResponseInFlow(MessageContext synCtx) {

log.info("Response In Flow");

return true;

}

@Override

public boolean handleResponseOutFlow(MessageContext synCtx) {

log.info("Response Out Flow");

return true;

}

4. Configuration

You need to add following configuration item to the synapse-handler.xml(repository/conf) file to enable deployed handler.

<handlers>

</handlers>

5. Deployment

Handler can be deployed as a OSGI bundle or jar file to the ESB.

How Schedule failover message processor helps for the guaranteed delivery ?

prabathmail@yahoo.com (prabath ariyarathna) — Sun, 13 Sep 2015 10:14:00 +0530

Before we talk about the failover message forwarding processor, it’s better to understand the big picture of the concepts and use cases. The Scheduled Failover Message Forwarding Processor is part of the bigger picture of the message store and message processor.

Message Store Message Processor.

WSO2 ESB’s Message-stores and Message-processors are used to store incoming messages and then deliver them to a particular backend with added Quality of Services (QoS), such as throttling and guaranteed delivery. The basic advantage of the MSMP is that it allows you to send messages reliably to a backend service. These messages can be stored in a different reliable storage such as JMS, JDBC message stores. The MSMP powered by three basic components:

1. Store Mediator.
The Store mediator is the synapse mediator and can be used to store messages in the message store.

2. Message Store.
A message store is storage in the ESB for messages. The WSO2 ESB comes with four types of message store implementations - In Memory, JMS, JDBC and RabitMQ Message Stores. Users also have the option to create a Custom Message Store with their own message store implementation. For more information, refer to the section Message Stores section.

3. Message Processor.
The Message Processor is used for consuming messages from the message store and sending it to the defined endpoint. Currently we have Forward and Sample Message Processor implementations; the ESB provides the facility to add custom message processors as well. Other than forwarding messages to the endpoint, the message processor provides other new features, which can be helpful to guaranteed delivery such as throttling, message retries when endpoint is not available, etc.
For more information, please refer to the Message Processor.

How to achieve guaranteed delivery?
Guaranteed message delivery means once message comes to the ecosystem, it needs to be delivered to the defined endpoint without losing it while processing. We can identify a few areas which should be considered when we talking about the guaranteed delivery in message processor scenario:

1. Store message
Message store unavailability is the only scenario that we can identify for message loss when the store mediator trying to store a message in the message store. This can be happen due to reasons such as network failures, a message store crash or a system shutdown for maintenance. This kind of situation can overcome by different approaches.

Configure message store cluster

We can configure a message store cluster as a one solution for this. This lets us avoid the single point of failure.

Defining failover message store.

This allows the message store to store messages in the failover message store if the original message store is not available. ESB 4.9.0 has introduced a new feature allowing you to define a failover message store. Full details of failover message store will be discussed under a different section.

2. Retrieve message from message store.
We need to decide on when we need to remove message from the store after retrieving the message processor from the message store, because otherwise the message can be lost in some cases. The ESB has a mechanism to signal to message store to remove the messages after a message successfully sent to the endpoint. The ESB will not remove the message from the message store if the message cannot be successfully sent to the endpoint.

3. Send message to the define endpoint.
This scenario is technically part of the ‘forwarding message to the endpoint’ scenario. As we discussed under the “Retrieve message from the message store” section, messages are removed from the message store, if only after messages are sent successfully to the endpoint. Message processors provide a retry mechanism to retry to send messages if the endpoint is not available. Even though retry mechanism does not provide guaranteed delivery, it helps successfully send off messages to the endpoint.

The message processor does have more functionality which can be used to tune the processor to improve guaranteed delivery; however, that’s outside the scope of this blog post. You can find more information about the message processor from here.

Failover Message store and Schedule failover message processor scenario.

As discussed in the earlier section, the Failover Message Store is using as a solution for message store failures. The store mediator forwards messages to the failover message store if the original message store fails.

Initially we need to define failover message store first. It can be any type of message store that are available in the ESB. No special configuration is needed to specifically define the failover message store - when you define the original message store, you can simply select failover message store for the failure situations. When a failure situation happens, all incoming messages are forwarded into the failover message store by the store mediator.

The next problem is how can we move messages which were forwarded to the failover message store to the original message store when it becomes available again. This is where the Failover Message Processor comes in. It’s the same as the Scheduled Message Forward Processor, except where the Message Forward Processor sends messages to the endpoints, this on forwards messages to the message store.

The following example explains how to setup a complete message processor scenario with the failover configurations.

1. Create failover message store.
You don't need to specify any special configuration here. Keep in mind that in-memory message store is used for this example, but we cannot use in-memory message stores for the cluster setups since we cannot share in-memory stores among the cluster nodes.

  <messageStore name="failover"/>

2. Create original message store for storing messages.
A JMS message store is used for this example. For enabling guaranteed delivery on the producer side (configure failover message store), you need to enable “Producer Guaranteed Delivery” property and need to specify the failover message store located under the “Show Guaranteed Delivery Parameters” section.

 <messageStore  
     class="org.apache.synapse.message.store.impl.jms.JmsStore" name="Orginal">  
     <parameter name="store.failover.message.store.name">failover</parameter>  
     <parameter name="store.producer.guaranteed.delivery.enable">true</parameter>  
     <parameter name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</parameter>  
     <parameter name="java.naming.provider.url">tcp://localhost:61616</parameter>  
     <parameter name="store.jms.JMSSpecVersion">1.1</parameter>  
   </messageStore>

3. Create Proxy Service to send messages to the original message store using store mediator.

 <proxy name="Proxy1" transports="https http" startOnLoad="true" trace="disable">    
  <target>  
    <inSequence>  
     <property name="FORCE_SC_ACCEPTED" value="true" scope="axis2"/>  
     <property name="OUT_ONLY" value="true"/>  
     <log level="full"/>  
     <store messageStore="Orginal"/>  
    </inSequence>  
  </target>  
 </proxy>

4. Define endpoint for the schedule forward message processor.
SimpleStockquate service is used as a backend service.

 <endpoint name="SimpleStockQuoteService">  
  <address uri="http://127.0.0.1:9000/services/SimpleStockQuoteService"/>  
 </endpoint>

5. Add schedule forward message processor to forward messages to the previously defined endpoint.
This link contain more information about the schedule forward message processor.

 <messageProcessor  
     class="org.apache.synapse.message.processor.impl.forwarder.ScheduledMessageForwardingProcessor"  
     messageStore="Orginal" name="ForwardMessageProcessor" targetEndpoint="SimpleStockQuoteService">  
     <parameter name="client.retry.interval">1000</parameter>  
     <parameter name="throttle">false</parameter>  
     <parameter name="max.delivery.attempts">4</parameter>  
     <parameter name="member.count">1</parameter>  
     <parameter name="max.delivery.drop">Disabled</parameter>  
     <parameter name="interval">1000</parameter>  
     <parameter name="is.active">true</parameter>  
     <parameter name="target.endpoint">SimpleStockQuoteService</parameter>  
   </messageProcessor>

6. Add schedule failover message processor for forwarding failover messages from failover message store to the original message store.
When you are defining a failover message processor, you need to fill two mandatory parameters which are very important for the failover scenario.

Source message store.
Target message store.

Failover message processor sends messages from the failover store to the original store when it is available in the failover scenario. In this configuration, the source message store should be the failover message store and target message store should be the original message store.

 <messageProcessor  
     class="org.apache.synapse.message.processor.impl.failover.FailoverScheduledMessageForwardingProcessor"  
     messageStore="failover" name="FailoverMessageProcessor">  
     <parameter name="client.retry.interval">60000</parameter>  
     <parameter name="throttle">false</parameter>  
     <parameter name="max.delivery.attempts">1000</parameter>  
     <parameter name="member.count">1</parameter>  
     <parameter name="max.delivery.drop">Disabled</parameter>  
     <parameter name="interval">1000</parameter>  
     <parameter name="is.active">true</parameter>  
     <parameter name="message.target.store.name">Orginal</parameter>  
   </messageProcessor>

Other than above mandatory parameters, we have a few other optional parameters under the “Additional Parameter” section.

7. Send Request to the Proxy Service
Navigate to /samples/axis2client directory, and execute the following command to invoke the proxy service.

 ant stockquote -Daddurl=http://localhost:8280/services/Proxy1 -Dmode=placeorder

Note a message similar to the following example printed in the Axis2 Server console.

 SimpleStockQuoteService :: Accepted order for : 7482 stocks of IBM at $ 169.27205579038733

Parameter Name	Description
Forwarding interval (`interval`)	Interval in milliseconds in which processor consumes messages.
Retry interval (`client.retry.interval`)	Message retry interval in milliseconds.
Maximum delivery attempts (`max.delivery.attempts`)	Maximum redelivery attempts before deactivating the processor. This is used when the backend server is inactive and the ESB tries to resend the message.
Drop message after maximum delivery attempts (max.delivery.drop)	If this parameter is set to `Enabled`, the message will be dropped from the message store after the maximum number of delivery attempts are made, and the message processor will remain activated. This parameter would have no effect when no value is specified for the Maximum Delivery Attempts parameter. The Maximum Delivery Attempts parameter can be used when the backend is inactive and the message is resent. If this parameter is disabled, the undeliverable message will not be dropped and the message processor will be deactivated.
Fault sequence name (`message.processor.fault.sequence`)	The name of the sequence where the fault message should be sent to in case of a SOAP fault.
Deactivate sequence name (`message.processor.deactivate.sequence`)	The deactivate sequence that will be executed when the processor is deactivated automatically. Automatic deactivation occurs when the maximum delivery attempts is exceeded and the Drop message after maximum delivery attempts parameter is disabled.
Quartz configuration file path (`quartz.conf`)	The Quartz configuration file path. This properties file contains the Quartz configuration parameters for fine tuning the Quartz engine. More details of the configuration can be found at http://quartz-scheduler.org/documentation/quartz-2.x/configuration/ConfigMain.
Cron Expression (`cronExpression`)	The cron expression to be used to configure the retry pattern.
Task Count (Cluster Mode)	The required number of worker nodes when you need to run the processor in more than 1 worker node. Specifying this will not guarantee that the processor will run on each worker node. There can be instances where the processor will not run in some workers nodes.

To test the failover scenario, you can shutdown the JMS broker(original message store) and send few messages to the proxy service. These messages are not sent to the backend since original message store is not available. You can see those messages are stored in the failover message store. If you check the ESB log, you can see the failover message processor is trying to forward messages to original message store periodically. Once the original message store is available, the failover processor send those messages to the original store and forward message processor send that to the backend service.

Illegal key size or default parameters

prabathmail@yahoo.com (prabath ariyarathna) — Wed, 9 Sep 2015 21:02:00 +0530

When you run the pre-defined security scenarios in the WSO2 ESB most probably you already faced the Illegal key size or default parameters exception

org.apache.axis2.AxisFault: Error in encryption
   at org.apache.rampart.handler.RampartSender.invoke(RampartSender.java:76)
   at org.apache.axis2.engine.Phase.invokeHandler(Phase.java:340)
   at org.apache.axis2.engine.Phase.invoke(Phase.java:313)
   at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:261)
   at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:426)
   at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:398)
   at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:224)
   at org.apache.axis2.client.OperationClient.execute(OperationClient.java:149)
   at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:554)
   at org.apache.axis2.client.ServiceClient.sendReceive(ServiceClient.java:530)
   at SecurityClient.runSecurityClient(SecurityClient.java:111)
   at SecurityClient.main(SecurityClient.java:33)
Caused by: org.apache.rampart.RampartException: Error in encryption
   at org.apache.rampart.builder.SymmetricBindingBuilder.doSignBeforeEncrypt(SymmetricBindingBuilder.java:765)
   at org.apache.rampart.builder.SymmetricBindingBuilder.build(SymmetricBindingBuilder.java:86)
   at org.apache.rampart.MessageBuilder.build(MessageBuilder.java:144)
   at org.apache.rampart.handler.RampartSender.invoke(RampartSender.java:65)
   ... 11 more
Caused by: org.apache.ws.security.WSSecurityException: Cannot encrypt data; nested exception is:
   org.apache.xml.security.encryption.XMLEncryptionException: Illegal key size or default parameters
Original Exception was java.security.InvalidKeyException: Illegal key size or default parameters
   at org.apache.ws.security.message.WSSecEncrypt.doEncryption(WSSecEncrypt.java:608)
   at org.apache.ws.security.message.WSSecEncrypt.doEncryption(WSSecEncrypt.java:461)
   at org.apache.ws.security.message.WSSecEncrypt.encryptForExternalRef(WSSecEncrypt.java:388)
   at org.apache.rampart.builder.SymmetricBindingBuilder.doSignBeforeEncrypt(SymmetricBindingBuilder.java:755)
   ... 14 more

Reason for this issue could be not installed JCE file to your JRE. First you can check after install JCE file on your JRE. To confirm JCE file installed correctly, you can find following Java source.

public class JCETest {

    public static void main(String args[]) {
        int maxKeyLen = 0;
        try {
            maxKeyLen = Cipher.getMaxAllowedKeyLength("AES");
        } catch (NoSuchAlgorithmException e) {
            Assert.fail();
        }

        Assert.assertEquals(2147483647, maxKeyLen);
        System.out.println(maxKeyLen);
    }
}

AES key size should be equal to the 2147483647 if JCE files has been installed sucessfully.

How to preserving HTTP headers in WSO2 ESB 4.9.0 ?

prabathmail@yahoo.com (prabath ariyarathna) — Wed, 9 Sep 2015 19:17:00 +0530

Preserving HTTP headers are important when executing backend services via applications/middleware. This is because most of the time certain important headers are removed or modified by the applications/middleware which run the communication.

The previous version of our WSO2 ESB, version 4.8.1, only supported “server” and “user agent” header fields to preserve with, but with the new ESB 4.9.0, we’ve introduced a new new property (http.headers.preserve) for the passthru (repository/conf/passthru-http.properties) and Nhttp(repository/conf/nhttp.properties) transporters to preserve more HTTP headers.

Passthru transporter – support header fields


Location
Keep-Alive
Content-Length
Content-Type
Date
Server
User-Agent
Host

Nhttp transport – support headers


Server
User-Agent
Date

You can specify header fields which should be preserved in a comma-separated list, as shown below.

http.headers.preserve = Location, Date, Server

Note that properties(http.user.agent.preserve, http.server.preserve), which were used in ESB 4.8.1 for preserving headers, also works in ESB 4.9.0 - we’ve kept that for the backward compatibility.

How to enable proxy service security in ESB 4.9.0?

prabathmail@yahoo.com (prabath ariyarathna) — Wed, 9 Sep 2015 14:49:00 +0530

Security is one of the major concern when we developing API base integrations or application developments. WSO2 supports WS Security, WS-Policy and WS-Security Policy specifications. These specifications define a behavior model for web services. Proxy service security requirements are different from each others.

WSO2 ESB providing pre-define commonly used twenty security scenarios to choose based on the security requirements. This functionality is provided by the security management feature which is bundled by default in service management feature in ESB. This configuration can be done via the web console until ESB 4.8.1 release, but this has been removed from the ESB 4.9.0. Even though this feature isn't provided by the ESB web console itself same functionality can be achieved by the new WSO2 Dev Studio. WSO2 always motivate to use dev studio to prepare required artifacts to the ESB rather than the web console. Better way to explain this scenario is by example. Following example provides guides to the way you need to enable security for the proxy service in newly released ESB 4.9.0.

Note: Understanding the actual security requirement is the first step you need to follow before starting the implementation of the secure proxy service. In this example, I'm selecting basic auth as the security scenario.

1. As the first step, we need to create proxy service to secure. I'm going to create simple proxy service which front the SimpleStockQuate service.

Create ESB config project from the Developer Studio dashboard.
Create Proxy service which named SimpleProxy.

2. We need to define security policy file to enable security for the proxy service. Registry resource project needs to create for storing policy file.

Create Registry resource artifact(SecurityPolicy - Resource type should be WS-Policy)

Select design view of the SecurityPolicy.xml file. You can see all pre-defined security scenarios listed in this view. In this example, I'm selecting UserNameToken scenario. Under this scenario, we need to select user rolls which allow to access the service. This option allow you to select rolls inline and select available rolls from the ESB.

3. Now we have both proxy service and security policy file. Next step is to enable security using defined policy file. Proxy service properties has separate section for the security. It contains two properties which required for enabling security.

Security Enabled – This property should be True for enabling security

Service Policy – You need to select defined security policy file as a value of this field.

4. Now Security configurations has been finished. Next step is to create CAR file to deploy into the ESB. We have two options to deploy artifacts into the EBS.

Export artifacts as a CAR file from Developer Studio and upload file to the ESB as a carbon application.

Configure ESB as a server inside the Developer Studio and deploy directly.

We are going to use first option in this example. Since we need to export both ESB config and registry project to the single car file, we need to add “Composite Application Project” to the Dev Studio and need to associate previous setup applications (ESB Config , Registry resource). You can export CAR file easily by selecting “Export Composite Application Project” option from the menu which pop up for the right click.

5. WO2 ESB providing very simple way to install car file by just select and upload way.

You can find this option(“Carbon Applications") in the bottom of the right-hand side menu.

When you click on the Service List menu you can see the deployed proxy service(“SimpleProxy”)

with enable security.

6. You can simple Test this proxy service by “Try this service” feature which provided by th ESB itself. You have to fill the userName and password fields before sending the request.

Likewise, you can try other predefined scenarios or your own security implementation with the custom policy.

No snappyjava in java.library.path Exception when running WSO2 Message Broker 2.2.0 in MAC OS

prabathmail@yahoo.com (prabath ariyarathna) — Thu, 16 Jul 2015 10:48:00 +0530

You can see the following exception when you running WSO2 MB 2.2.0 top of the MAC OS.

java.lang.reflect.InvocationTargetException

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:606)

at org.xerial.snappy.SnappyLoader.loadNativeLibrary(SnappyLoader.java:317)

at org.xerial.snappy.SnappyLoader.load(SnappyLoader.java:219)

at org.xerial.snappy.Snappy.(Snappy.java:44)

at org.apache.cassandra.io.compress.SnappyCompressor.create(SnappyCompressor.java:45)

at org.apache.cassandra.io.compress.SnappyCompressor.isAvailable(SnappyCompressor.java:55)

at org.apache.cassandra.io.compress.SnappyCompressor.(SnappyCompressor.java:37)

at org.apache.cassandra.config.CFMetaData.(CFMetaData.java:82)

at org.apache.cassandra.config.KSMetaData.systemKeyspace(KSMetaData.java:81)

at org.apache.cassandra.config.DatabaseDescriptor.loadYaml(DatabaseDescriptor.java:491)

at org.apache.cassandra.config.DatabaseDescriptor.(DatabaseDescriptor.java:132)

at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:216)

at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:447)

at org.wso2.carbon.cassandra.server.CassandraServerController$1.run(CassandraServerController.java:67)

at java.lang.Thread.run(Thread.java:745)

Caused by: java.lang.UnsatisfiedLinkError: no snappyjava in java.library.path

at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1886)

at java.lang.Runtime.loadLibrary0(Runtime.java:849)

at java.lang.System.loadLibrary(System.java:1088)

at org.xerial.snappy.SnappyNativeLoader.loadLibrary(SnappyNativeLoader.java:52)

Solution.

Clone the https://github.com/xerial/snappy-java repository to you machine.
Run "make" command inside the cloned directory.
Copy "target/snappy-1.1.1-Mac-x86_64/libsnappyjava.jnilib" file in to the MB home directory. This will fix the issue.

MQ Telemetry Transport Protocol for IOT

prabathmail@yahoo.com (prabath ariyarathna) — Fri, 2 Jan 2015 00:02:00 +0530

MQTT protocol is a lightweight, open and simple network protocol for the device communications. It is based on the principle of publishing messages and subscribing to topics, or "pub/sub". The protocol runs over TCP/IP, or over other network protocols that provide ordered, lossless, bi-directional connections. It was designed for the low-bandwidth, high latency networks in the late 1990s/early 2000s and its support to connect over thousands of clients to a single server. This characteristic is a suite for the devices which has very limited processing powers and limited memory, such as sensors, mobile devices, monitoring devices. Since It provides a common interface for everything, new sensors or devices can integrate very easily with the system.

Message in MQTT is published on topics. These topics are treated as a hierarchy separate using slash(/) as a separator like in the file system.Clients can receive messages by creating subscriptions. A subscription may be to an explicit topic, in which case only messages in that topic will be received, or it may include wildcards.

Eg:- sensors/COMPUTER_NAME/temperature/HARDDRIVE_NAME

Two wildcards are available, + or #.

+ can be used as a wildcard for a single level of hierarchy.

sensors/+/temperature/+

# can be used as a wildcard for all remaining levels of hierarchy.

sensors/#

MQTT defines three levels of quality of service(QoS). This QoS define how messages are travel through the protocol. As an example, we can get a parcel sending through the normal mail or courier service. Courier service assures the delivery but normal mail not providing it.

QoS 0 - At most once delivery: With this setting, messages are delivered according to the best effort of the underlying network.

QoS 1 - At least Once Delivery: For this level of service, the MQTT client or the server would attempt to deliver the message at-least once.But there can be a duplicate message.

QoS 2 - Exactly once delivery: This is the highest level of Quality of Service. Additional protocol flows ensure that duplicate messages are not delivered to the receiving application.

MQTT Server/Broker

https://github.com/mqtt/mqtt.github.io/wiki/servers

MQTT Clients

https://github.com/mqtt/mqtt.github.io/wiki/libraries

Basic HTTP Authentication for REST Web Service

prabathmail@yahoo.com (prabath ariyarathna) — Tue, 19 Aug 2014 13:39:00 +0530

Basic HTTP authentication solve following security problems.

Get username and password from http request
Fetch the applicable method security details
Verify if user is authorized to access the API
Return valid error codes in case of invalid access

In this tutorial, we show you how to develop a simple RESTfull web service application with HTTP basic authentication using Cuubez framwork.

Technologies and Tools used in this article:

cuubez 1.1.1
JDK 1.6
Tomcat 6.0
Maven 3.0.3
Intellij IDEA 13.1.1

Note: If you want to know what and how REST works, just search on Google, ton of available resources.

1. Directory Structure

This is the final web project structure of this tutorial.

2. Standard Web Project

Create a standard Maven web project structure.

 mvn archetype:generate -DgroupId=com.cuubez -DartifactId=basic_authentication -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false

Note: To support IntelliJ IDEA, use Maven command :

mvn idea:idea

3. Project Dependencies

Cuubez is published in Maven repository. To develop cuubez REST application , just declares “cuubez-core” in Maven pom.xml.

File : pom.xml

 <dependency>  
   <groupId>com.cuubez</groupId>  
   <artifactId>cuubez-core</artifactId>  
   <version>1.1.1</version>  
  </dependency>

4. REST Service

Simple REST service with basic HTTP authentication annotations.

@PermitAll: Specifies that all security roles are allowed to invoke the specified method(s)
@RolesAllowed: Specifies the list of roles permitted to access method(s)
@DenyAll: Specifies that no security roles are allowed to invoke the specified method(s)

 @Path("/users/{userId}")  
 @Produces(MediaType.APPLICATION_JSON)  
 public class UserResource {  
   private static Log log = LogFactory.getLog(UserResource.class);  
   @PermitAll  
   @GET  
   @Produces(MediaType.APPLICATION_JSON)  
   public Response userGet(@HeaderParam(value = "name") String name, @PathParam(value = "userId") String id, @QueryParam(value = "age") Double age) {  
     User user = new User(id, age, name);  
     return Response.ok().entity(user).build();  
   }  
   @RolesAllowed("ADMIN")  
   @Consumes(MediaType.APPLICATION_JSON)  
   @POST  
   public void userPost(User user) {  
     log.info("POST = [" + user + "]");  
   }  
   @DenyAll  
   @PUT  
   @Consumes({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})  
   public void userPut(User user) {  
     log.info("PUT = [" + user + "]");  
   }  
 }

5. Authentication filter

The security interceptor is build by implementing com.cuubez.core.Interceptor.RequestInterceptor interface. This interface has one method which need to implement.

 @Provider  
 public class AuthenticationFilter implements RequestInterceptor {  
   private final InterceptorResponseContext ACCESS_FORBIDDEN = new InterceptorResponseContext("No access", HttpServletResponse.SC_FORBIDDEN);  
   public InterceptorResponseContext process(InterceptorRequestContext interceptorRequestContext) {  
     if (interceptorRequestContext.isAnnotationContain(DenyAll.class)) {  
       return ACCESS_FORBIDDEN; //Return access denied to user  
     } else if (interceptorRequestContext.isAnnotationContain(PermitAll.class)) {  
       return null; //Return null to continue request processing  
     } else if (interceptorRequestContext.isAnnotationContain(RolesAllowed.class)) {  
       //get encoded user name and password  
       String encodedUserName = interceptorRequestContext.getHeader("userName");  
       String encodedPassword = interceptorRequestContext.getHeader("password");  
       //decode user name and password  
       String decodedUserName = new String(Base64.decodeBase64(encodedUserName.getBytes()));  
       String decodedPassword = new String(Base64.decodeBase64(encodedPassword.getBytes()));  
       //get allowed user roles  
       String[] allowedRoles = ((RolesAllowed) interceptorRequestContext.getAnnotation(RolesAllowed.class)).value();  
       //Access userAccessor to retrieve user details(UserAccessor is not providing by framework, developer need to implement it according their requirement)  
       UserAccessor userAccessor = new UserAccessor();  
       String role = userAccessor.getUserRole(decodedUserName, decodedPassword);  
       if(isAllow(allowedRoles, role)) {  
         return null;  
       } else {  
         return ACCESS_FORBIDDEN;  
       }  
     }  
     return null;  
   }  
   private boolean isAllow(final String[] allowedRoles, final String userRole) {  
     for (String allRole : allowedRoles) {  
       if (allRole.equals(userRole)) {  
         return true;  
       }  
     }  
     return false;  
   }  
 }

This interceptor mechanism provide full flexibility to developer.

6. web.xml

The ContextLoaderListner context listener has to be deployed in order to create the registry for cuubez ,while the ServiceInitiator servlet is used so that incoming requests are correctly routed to the appropriate services. We have configured the specific servlet, named “cuubez”, to intercept requests under the “/rest/” path.

File : web.xml

 <web-app>  
  <display-name>Employee Example</display-name>  
   <listener>  
     <listener-class>com.cuubez.core.servlet.BootstrapContextListener</listener-class>  
   </listener>  
   <servlet-mapping>  
    <servlet-name>init</servlet-name>  
    <url-pattern>/rest/*</url-pattern>  
   </servlet-mapping>  
   <servlet>  
    <servlet-name>init</servlet-name>  
    <servlet-class>com.cuubez.core.servlet.HttpServletDispatcher</servlet-class>  
   </servlet>  
 </web-app>

7. Demo

In this example, web request from “projectURL/rest/users/{userId}” will match to “UserResource“, via @Path("/users/{userId}").

1. GET request

(GET resource annotated by @PermitAll annotation. Specifies that all security roles are allowed to invoke the specified method(s))

2. POST request

(POST request annotated by @RolesAllowed annotation. ADMIN role permitted to access method(s))

Forbidden request (Wrong encoded(Base64) user name and password passed as a header variables)

Successful request (Correct encoded(Base64) user name and password passed as a header variables)

3. PUT request

(PUT resource annotated by @DenyAll annotation. Specifies that no security roles are allowed to invoke the specified method(s))

8. Download

Download Basic Authentication Sample Application - Basic-Authentication.zip

Embedded jetty for JAXRS

prabathmail@yahoo.com (prabath ariyarathna) — Tue, 19 Aug 2014 13:30:00 +0530

In this tutorial, we show you how to develop a simple RESTfull web service application with embedded jetty server using cuubez framwork.

Technologies and Tools used in this article:

cuubez 1.1.1
JDK 1.7
Maven 3.0.3
Intellij IDEA 13.1.1

Note: If you want to know what and how REST works, just search on Google, ton of available resources.

1. Directory Structure

This is the final web project structure of this tutorial.

2. Standard Java Project

Create a standard Maven java project structure

 mvn archetype:generate -DgroupId=com.cuubez -DartifactId=cuubez-jetty -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

Note: To support IntelliJ IDEA, use Maven command :

mvn idea:idea

3. Project Dependencies

Following maven dependencies should add to the pom.xml file.

File : pom.xml

 <dependency>  
  <groupId>com.cuubez</groupId>  
  <artifactId>cuubez-core</artifactId>  
  <version>1.1.1</version>  
 </dependency>  
 <dependency>  
  <groupId>org.eclipse.jetty</groupId>  
  <artifactId>jetty-servlet</artifactId>  
  <version>8.0.4.v20111024</version>  
 </dependency>

4. REST Service

 @Path("/users/{userId}")  
 @Produces(MediaType.APPLICATION_JSON)  
 public class UserResource {  
   private static Log log = LogFactory.getLog(UserResource.class);  
   @GET  
   @Produces(MediaType.APPLICATION_JSON)  
   public Response userGet(@PathParam(value = "userId") String id, @QueryParam(value = "name") String name, @QueryParam(value = "age") int age) {  
     User user = new User(id, age, name);  
     return Response.ok().entity(user).build();  
   }  
   @Consumes(MediaType.APPLICATION_JSON)  
   @POST  
   public void userPost(User user) {  
     log.info("POST = [" + user + "]");  
   }  
   @PUT  
   @Consumes({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})  
   public void userPut(User user) {  
     log.info("PUT = [" + user + "]");  
   }  
 }

5. Embedded Jetty Implementation

 public class JettyServer {  
   public static void main(String args[]) {  
     Server server = new Server(8080);  
     ServletContextHandler handler = new ServletContextHandler(ServletContextHandler.SESSIONS);       
     server.setHandler(handler);  
     handler.setContextPath("/");  
     handler.setResourceBase(".");  
     handler.addEventListener(new BootstrapContextListener()); //cuubez bootstrap context listner  
     handler.addServlet(HttpServletDispatcher.class, "/rest/*"); //servlet filter  
     try {  
       server.start();  
       server.join();  
     } catch (Exception e) {  
       e.printStackTrace();  
     }  
   }  
 }

6. Demo

In this example, web request from projectURL/rest/users/id-1003 will match to UserResource, via @Path("/users/{userId}"). {userId} will match to parameter annotated with @PathParam and age and name will match to parameters annotated with @QueryParam

URL : http://localhost:8080/rest/users/id-1003?name=jhone&age=30

Download this example - cuubez-jetty.zip

Cuubez Rest framework sample application

prabathmail@yahoo.com (prabath ariyarathna) — Tue, 24 Jun 2014 15:00:00 +0530

In this tutorial, we show you how to develop a simple REST web application with Cuubez.

Technologies and Tools used in this article:

Cuubez 1.0.0
JDK 1.6
Tomcat 6.0
Maven 3.0.3
Intellij IDEA 13.1.1

Note If you want to know what and how REST works, just search on Google, ton of available resources.

1. Directory Structure

This is the final web project structure of this tutorial.

2. Standard Web Project

Create a standard Maven web project structure
.

 mvn archetype:generate -DgroupId=com.cuubez -DartifactId=Employee-example  
     -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false

Note To support IDEA, use Maven command :

mvn idea:idea

3. Project Dependencies

Cuubez is published in Maven repository. To develop cuubez REST application , just declares cuubez-core in Maven pom.xml.

File : pom.xml

 <dependencies>  
   <dependency>  
    <groupId>com.cuubez</groupId>  
    <artifactId>cuubez-core</artifactId>  
    <version>1.0.0</version>  
   </dependency>  
 </dependencies>

4. REST Service

Simple REST service with Cuubez

 import javax.ws.rs.GET;  
 import javax.ws.rs.Path;  
 import javax.ws.rs.PathParam;  
 import com.cuubez.example.entity.Employee;  
 @Path("/employees")  
 public class EmployeeResource {  
   @Path("/{empId}")  
   @GET  
   public Employee getEmployee(@PathParam("empId") final String empId) {  
     Employee employee = new Employee(empId, "jhon powel", "marketing", "No 321, Colombo 4", "+94775993720");  
     return employee;  
   }  
 }

5. web.xml

The ContextLoaderListner? context listener has to be deployed in order to create the registry for cuubez ,while the ServiceInitiator? servlet is used so that incoming requests are correctly routed to the appropriate services. We have configured the specific servlet, named cuubez, to intercept requests under the /rest/ path.

File : web.xml

 <web-app>  
  <display-name>Employee Example</display-name>  
   <listener>  
     <listener-class>com.cuubez.core.servlet.BootstrapContextListener</listener-class>  
   </listener>  
   <servlet-mapping>  
    <servlet-name>init</servlet-name>  
    <url-pattern>/rest/*</url-pattern>  
   </servlet-mapping>  
   <servlet>  
    <servlet-name>init</servlet-name>  
    <servlet-class>com.cuubez.core.servlet.HttpServletDispatcher</servlet-class>  
   </servlet>  
 </web-app>  

6. Demo

In this example, web request from projectURL/rest/employees will match to EmployeeResource, via @Path("/employees"). And the {empId} from projectURL/rest/employees/{empId} will match to parameter annotated with @PathParam.

URL : http://localhost:8080/employee-example-1.0.0/rest/employees/eId-0001

Download this Cuubez Employee example - Employee-example.zip

Heartbleed

prabathmail@yahoo.com (prabath ariyarathna) — Thu, 29 May 2014 15:10:00 +0530

Heartbleed is the vulnerable which is identifying in very famous TSL level security library call OpenSSL. It is widely used to implement TSL level security. Heartbleed is effecting if user using vulnerable OpenSSL instance for the client side or server side. Note that only the number of OpenSSL version are reported as an effected by vulnerability.

OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable
OpenSSL 0.9.7 branch is NOT vulnerable

CVE-2014-0160 is the official name for this vulnerability. These vulnerability names are maintain by the CVE (http://cve.mitre.org/)

What actually happened?
When Heartbleed is exploited it leads to the leak of memory information from the server to the client and from client to the server side. RFC6520 is for the transport layer security (TLS) and datagram transport layer security (DTLS). RFC6520 heartbeat extension is providing link to send heartbeat message which consisting of payload between client and server. Sender send 16 bit message and receiver should reply with the same message. The affected version of OpenSSL allocate a memory buffer for the message to be returned base on the length field in the requesting message, without regard the actual size of the message payload. Because of this failure to do proper bound checking, the message returned consist of the payload, possible followed by whatever else happened to be the allocated memory buffer.
In that case Heartbleed can send heartbeat request with smaller payload with larger length field.

Following image show how it happen.

[Ref:-Wikipedia]

Cuubez sample application

prabathmail@yahoo.com (prabath ariyarathna) — Tue, 27 May 2014 21:39:00 +0530

Step 1: Download cuubez from the Repository

The first step is to download the latest cuubez stable release from: http://www.cuubez.com/index.php/2014-05-20-11-01-54

Maven repo

<dependencies>

   <dependency>

     <groupId>com.cuubez</groupId>

     <artifactId>cuubez-core</artifactId>

     <version>1.0.0</version>

   </dependency>

</dependencies>

Step 2: Add the following libraries to your Web application

  com.thoughtworks.xstream
  commons-logging
  javax.servlet
  javassist
  javax.ws.rs
  com.google.code.gson

Step 3: Define listeners and bootstrap classes\

<web-app>

  <display-name>Employee Example</display-name>

    <listener>

        <listener-class>com.cuubez.core.servlet.BootstrapContextListener</listener-class>

    </listener>

    <servlet-mapping>

     <servlet-name>init</servlet-name>

     <url-pattern>/rest/*</url-pattern>

    </servlet-mapping>

    <servlet>

     <servlet-name>init</servlet-name>

     <servlet-class>com.cuubez.core.servlet.HttpServletDispatcher</servlet-class>

    </servlet>

</web-app>

Step 4: Create your first RESTful service

In a REST based architecture everything is a resource. A resource is accessed via a common interface based on the HTTP standard methods (e.g., POST, GET, PUT or DELETE). Every resource should support the HTTP common operations. Resources are identified by global ID's (which are typically URIs). In the first example, we will recall a RESTful Web service which returns a User object when a certain path is request with an HTTP GET:

User object :

public class User {
    
    private String id;
    private String name;
    private int age;
    

    public User(String id, String name, int age) {
        this.name = id;
        this.age = age;
        this.name = name;
    }

    public String getId() {return id;}

    public int getAge() {return age;}

    public String getName() {return name;}

    public void setId(String id) {this.id = id;}

    public void setAge(int age) {this.age = age;}

    public void setName(String name) {this.name = name;}
}

REST service class :

@Path("/users")
public class UserDetail {

    @GET
    @Path("/{userId}")   
    @Produces(MediaType.APPLICATION_JSON)
    public User getUser(@PathParam(value = "userId")String userId) {
      User user = new User(userId, "jhone", 35);
      return user;
    }
}

The @Path annotation at class level is used to specify the base URL of the Web service. Then you can assign a @Path annotation at method level to specify the single action you want to invoke.

In this example, if you need to invoke the userDetail service, you have to use the following URL: (we suppose that the web application is named cuubez.war)

http://localhost:8080/cuubez/rest/users/id11001

would return:

{
"id":"id11001",
 "name": "jhone",
 "age": 35
}

Cuubez RESTful web service framework tutorial

prabathmail@yahoo.com (prabath ariyarathna) — Mon, 22 Apr 2013 17:33:00 +0530

Cuubez|Rest 1.0 beta

Table of contents

1 RESTful web service overview

REST is an acronym for the Representational State Transfer architectural style for distributed hypermedia systems.This style was developed in parallel with HTTP/1.1 based on HTTP/1.0 design to work best on the web and it specifies uniform interface constraint. If that is applied to a web service, induces desirable properties, such as performance, scalability and modifiability which enables services to work best on the Web. In REST style, data and operations act as resources .These resources are accessed using uniform resource identifiers (URI). In order to work, REST assumes that resources are capable of being represented a pervasive standard grammar.

Basic REST principles

Application state and functionality are categorized in to resources.
Resources are addressable using standard URIs that can be used as hypermedia links.

All resources use four HTTP verbs. 1. GET 2. POST 3. DELETE 4. PUT

Resources provide information using the MIME type supported by HTTP.
The protocol is stateless.
The protocol is cacheable.

2 Cuubez|Rest framework overview

Cuubez|Rest is a project that enables development and consumption of REST style web services. The core server runtime is based on the unique way to the Cuubez. The project also introduces a client runtime which can leverage certain components of the server-side runtime. Cuubez|Rest will deliver component technology that can be easily integrated into a variety of environments. Simplicity is the major strength of the Cuubez|Rest. It can be divided in to three major sections

Cuubez core
Cuubez extensions
Cuubez client

Cuubez core contains all server side RESTful web service core components. Cuubez extensions provide all cuubez framework related extension solutions. cuubez 1.0 beta release dose not have any extension right now but under the 1.0 stable release, spring framework extension scheduled to release. Cuubez client facilitate to execute cuubez exposed RESTful web service easily.

3 Sample application

3.1 Expose Java method(with return object) as a RESTful web service

3.1.1 Server side implementation

3.1.1.1 Required libraries

cuubez-core
commons-logging
javassist
xstream

3.1.1.2 web.xml configuration
Add contextLoaderListner to web.xml. (This is mandatory configuration)

<listener>
<listener-class>com.cuubez.initiator.ContextLoaderListner</listener-class>
</listener>

Add Servlet mapping.
This can be configured with any URL patterns.In this example It configured to redirect all request to Cuubeze RESTful web service framework.

<servlet-mapping>
<servlet-name>init</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>

<servlet>
<servlet-name>init</servlet-name>
<servlet-class>com.cuubez.initiator.ServiceInitiator</servlet-class>
</servlet>

3.1.1.3 Expose Java method as a RESTful web service

@RestService annotation is used to expose Java method as a RESTful web service.

Name property : Name of the RESTful web service (name should be unique for the application .Same service name cannot be used to different services).
Path property : Path property specifying the specific location to the service.
HttpMethod property : This property specify,which HTTP method is used to expose this RESTful web service.
MediaType property : Which content type is used to communication. Cuubeze 1.0 beta 1 release only support XML as a mediaType.

@RestService(name="userDetails", path="/user", httpMethod=HttpMethod.GET, mediaType = MediaType.XML)
public List<User> getUserDetails() {

}

3.1.2 Client side implementation

Required libraries

cuubez-client
commons-logging
javassist
xstream

First need to define service url and mediaType.Cuubez 1.0 beta 1 release only support XML media type. ServiceUrl contains server address + application name+rest service specifying location(In this example it is /user) + rest service name(It is specifying as a userDetails).

String serviceUrl = "http://localhost:8080/Cuubez_web/user/userDetails";
ClientRequest request = new ClientRequest(serviceUrl, MediaType.XML);

RESTful web service is exposed via HTTP GET method hence client needs to communicate via HTTP GET method.Cuubez client library provides APIs to communicate via each of these HTTP methods. Each HTTP method has two different API methods, one for the service which has return object or primitive value and one for the services which hasn't return any object or primitives.
get(Class) API method can be used for this example because of the userDetails service return List as a return object.

get(List.class)

List<User> userDetails = request.get(List.class);

Note:- Client side User class and server side User class package should be the same.

3.2 Expose Java method(with parameters) as a RESTful web service

3.2.1 Server side implementation.

3.2.1.1 Required libraries

cuubez-core
commons-logging
javassist
xstream

3.2.1.2 web.xml configuration Add contextLoaderListner (This is mandatory configuration)

<listener-class>com.cuubez.initiator.ContextLoaderListner</listener-class>
</listener>

Add Servlet mapping. This can configured any url patter.In this example it configures to hit all request to Cuubeze RESTful web service framework.

<servlet-mapping>
<servlet-name>init</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>

<servlet>
<servlet-name>init</servlet-name>
<servlet-class>com.cuubez.initiator.ServiceInitiator</servlet-class>
</servlet>

3.2.1.3 Expose Java method as a RESTful web service @RestService annotation is used to expose Java method as a RESTful web service.

Name property : Name of the RESTful web service (name should be unique for the application .Same service name cannot be used to different services).
Path property : Path property specifying the specific location to the service.
HttpMethod property : This property specify,which HTTP method is used to expose this RESTful web service.
MediaType property : Which content type is used to communication. Cuubez 1.0 beta 1 release only support XML as a mediaType.

@RestService(name="saveUserDetails", path="/user", httpMethod=HttpMethod.POST, mediaType = MediaType.XML) public void saveUserDetails(long userId, User userDetails) { }

3.2.2 Client side implementation Required libraries

cuubez-client commons-logging javassist xstream

String serviceUrl = "http://localhost:8080/Cuubez_web/user/saveUserDetails"; ClientRequest request = new ClientRequest(serviceUrl, MediaType.XML);

saveUserDetails service need userId(long) and User object as a parameters.

Note:-All parameter objects package structure should be the same(Parameter User class package structure should same in the server side and the client side).

Long userId = 1001; User userDetails = new User(“David”, 28); request.addParameters(userId, userDetails);

addParameters API call is used to pass parameters. We need to strictly following the parameter sequence when parsing to the addParameters method and adding parameter value directly to the add parameter method is not allowed.

* Not allow

request.addParameters(1001, userDetails);

saveUserDetails service is exposed via HTTP POST method hence client need to communicate via HTTP POST method.Cuubez client library provide APIs to communicate via each of these HTTP methods. Each HTTP method has two different API methods, one for the service which has return object or primitive value and one for the services which hasn't return any object or primitives. post() API method can use for this example because of the saveUserDetails service not return any object to the outside

request.post();

JMS හි ප්‍රායෝගික යෙදීම්...

prabathmail@yahoo.com (prabath ariyarathna) — Sat, 12 Jun 2010 22:49:00 +0530

මේදවස්වල ටිකක් වැඩ වැඩි හන්දා අලුතෙන් දෙයක් ලියන්න උනේ නැතිවුන නිසා මම ලගදි කියවපු ලිපියක් අනුසාරයේන් පොඩි ලිපියක් ලියන්න හිතුනා.මේ ලිපිය ලියල තිබුනේ Java messaging Service එහෙමත් නැත්නම් JMS පිලිබදව. නමුත් මම මෙහි ලියන්න බලාපොරොත්තු වෙන්නේ JMS පිලිබදව පැහැදිලි කිරීමකට වඩා එහි යේදීමක් පිලිබදවයි.මෙ පිලිබදව විශේෂයෙන් ලියන්න හේතුවක් වුනේ මේ කියන්න යන කාරණය පිලිබදව බොහෝදෙනා යොමු නොකරණ කාරණයක් නිසා.බොහො විට සිද්දාන්තමය කරුනු පිලිබදව අවබෝදයක් තිබුනත් එහි යෙදීම් පිලිබදව ඇත්තේ අඩු අවබෝදයක්.මම පැහැදිලි කරන්න හදපු කාරණය ගැන කතාකලොත් සාමාන්‍යයෙන් යම්කිසි මෘදුකාංගයක් නිර්මාණයේදී අපි එය තුල සිදුවන සිදුවීම් සියල්ල Log එකක් තුල ලිවීම්ට සලස්වනවා.එහිදී method execution වල සිට Exception throwing දක්වා සියලුම සිදුවීම් එය තුල සටහන් කිරීම සිදුකරණු ලබනවා.සමහර විට මෙමගින් ඇතිවන වාසි පිලිබදව ඔබට ප්‍රශ්නයක් මතුවීමට පුලුවන්..ඇත්තටම මෙහිදී මෙය සිදුකරණු ලබන්නේ මෘදුකාංගය තුල සිදුවු දෙ පිලිබදව පසුව අවබෝදයක් ලබාගැනීමටයි.සමහර අවස්තාවලදී මෘදුකාංගයේ සිදුවන Error එකක් වුවද එය සිදුවුයේ කොතැනද කුමන වේලාවේදීද යන්න පිලිබදව ඉතාම පහසුවෙන් මෙම log සටහන් නිසා දැනගත හැකී.මෙය මෘදුකාංගය පවත්වා ගැනීමේදී ඉතාම ලොකු පහසුවක් වෙනවා.විශේෂයෙන් මෙම log සටහන් ක්‍රමය Web Application වලදී බහුල වශයේන් යොදාගනු ලබයි. දැන් අපි සටහනක් තමන්ගේ මෘදුකාංගයට යොදාගැනීමේ ක්‍රියාවලිය පිලිබදව ප්‍රායෝගික කොටස පිලිබදව උදාහරණයක් මගින් පැහැදිලි කරණවනම් Struts Framework එක යොදාගන කරණු ලබන Web Application එකක් සලකා බැලුවහොත් එහිදී මෙම Log ලිවීම සදහා අපට Interceptor එකක් පහසුවෙන් යොදාගත හැක. එහිදී සිදුවන්නේ Struts Action න් execute වීමට ප්‍රතම(pre-processed) මෙම request, Interceptor එකක් හරහා යැවීමයි.පහත රූපයෙන් එය නිරූපණය වේ.

මෙම Interceptor එක තුලදී එම Log එකට අදාල සියලුම තොරතුරු database එකක් තුල හෝ Log file එකක් තුල සටහන් කරගත හැකියි.මෙහිදී බහුලව භාවිතා වන්නේ Log file එකක් තුල සටහන් කර ගැනීමේ ක්‍රමයයි.මෙහිදී මෙම අවස්තාවට අදාල බොහෝ තොරතුරු log සටහනේ සටහන් කරනව.මෙම ක්‍රමයේදී ඇතිවන ප්‍රශ්නය තමයි සියලුම Action execute වීමට ප්‍රතමව මෙසේ log සටහනක ලිවීම. මෙය සෘජුවම මෙම මෘදුකාංගවල කාර්යක්ෂම තාවය කෙරෙහි බලපෑමක් සිදුකරනවා ඊට හේතුව interceptor එක වෙතට පැමිනෙන request නැවතත් ඊට අදාල action එක වෙත යොමුවන්නේ ඊට අදාල තොරතුරු මෙම log සටහන ලිවීමෙන් අනතුරුවයි.මෙම කාර්යක්ෂම තාවය අඩුවීම බොහෝවිට Web Application සදහා විශේෂයෙන් බලපානවා.එහි දල ආකාරය පහත රූපසටහනේ නිරූපණය වේ.රූප සටහනේ දැක්වෙන්නේ එක ගමන් කරන ආකාරය පිලිබදව අවබෙදයක් ගැනීමට පමණක් බව සලකන්න.මෙහිදී මෙම කාර්යක්ෂම තාවය අඩුවීමට බලපාන හේතුව මගහැරවා ගැනීමට අපට JMS යොදාගැනීමට පුලුවන්.මෙහිදී ප්‍රශ්නයට හේතුව වන්නේ (interceptor එක වෙතට පැමිනෙන request නැවතත් ඊට අදාල action එක වෙත යොමුවන්නේ ඊට අදාල තොරතුරු මෙම log සටහන ලිවීමෙන් අනතුරුවයි).මෙහිදී මෙම තත්වයෙන් මිදීමට අපට Interceptor එක ඉවත්කිරීමට හැකියාවක් නැහැ.නමුත් මෙහිදී අපිට Interceptor එක මගින් log සටහන ලිවීමේ කාර්යය කරණ අවස්තාව සදහා කුමක් හෝ පිලියමක් යෙදිය හැකියි.මෙහිදී මෙම කාර්යය වෙන කෙනෙකුට පවරා request එක කෙලින්ම Action එක වෙත යොමු කල හැකිනම් මෙම කාර්යක්ෂමතාවය පිලිබදව ප්‍රස්නයට පිලිතුරක් ලබාගත හැකියි.මෙහිදී මෙම පහත රූපයේ ආකාරයට අපට මෙ සදහා ලෙහෙසියෙන්ම පිලිතුරක් සොයාගත හැකියි.
මෙහිදී ඉහත රූපයේ ආකාරයට Interceptor එක තුල ඇති Message sender function එක යොදාගෙන අපට log එකෙහි සටහන් කිරීමට අවශ්‍ය තොරතුරු message එකක්(Interceptor එකෙහි ඇති message sender එක යොදාගෙන) මගින් Message queue එක වෙතට යොමු කර request එක පමාවකින් තොරව නියමිත Action එක තුලට යොමු කල හැක.මෙහිදී log එක write කරන තෙක් බලාසිටීමෙන් අපතේයන කාලය ඉතුරුකර ගැනීමට හැකිවෙනවා.මෙම queue එකට යොමුකල message පිලිවලින් message receiver තුලට යොමුකරනු ලැබේ.මෙම receiver එක තුල අපට log සටහන් ලිවීම සදහා අවශ්‍ය කේත සටහන් ලියාගත හැකියි.මෙම ක්‍රමය නිසා කලින් තිබු කාර්යක්ෂමතාවය පිලිබදව ගැටලුව මගහරවා ගතහැක.මීට අමතරව JMS යොදාගත හැකි අවස්තා විශාල ගණනක් දක්නට ලැබෙනවා.මම සරළ උදාහරණය මගින් ඔබට මෘදුකාංග නිර්මාණයේදී අපට මතුවන ගැටලු සදාහා අපි ඉගෙන ගන්නා සිද්දාන්තමය කරුණු යොදාගන්නා ආකාරය පිලිබදව යම්තරමක හෝ අවබෝදයක් ලැබෙන්නට ඇතැයි සිතමි.

JNode

prabathmail@yahoo.com (prabath ariyarathna) — Thu, 25 Mar 2010 19:45:00 +0530

මේක අලුත් නිවුස් එකක් නොවුනත් වැදගත් නිසා බොලොග් එකට ඇඩි කරන්න හිතුවා.මේක මෙහෙයුම් පද්ධති හදන්න පුලුවන් Assembly,C වලින් විතරද කියල හිතපු අයට හොද නිවුස් එකක් වෙයි. මොකද හැමදාම කතාකරන්නේ එක්කො ලිනක්ස් නැත්නම් වින්ඩොස් හරි මැක් හරි ගැනනෙ,ඉතින් අද වෙනමම විදිහේ මෙහෙයුම්
පද්දතියක් ගැන තමයි ඉතාම කෙටියෙන් හදුන්වල දෙන්න හදන්නේ.මෙම මෙහෙයුම් පද්දතියට කියන්නේ JNode කියල .සමහර විට අහලත් ඇති.මෙහි විශේෂත්වය තමයි මෙය පරිගණක Java භාෂාව යොදාගෙන පරීක්ෂණ මට්ටමෙන් කරගෙන යන දෙයක් වීම .පරීක්ෂණ මට්ටමෙන් කිවුවට හොද මට්ටමක තියෙනවා දැනටමත්.ඇත්තටම සම්පුර්ණයෙන්ම Java පරිගණක භාෂාව යොදාගෙන තමයි මේක කරලා තියෙන්නේ නමුත් මේ සදහා Kernal එක විදිහට Assembly Micro Kernal එකක් භාවිතා කරලා තිබෙනවා.මෙහි අතුරු මුහුණත් පහත රූපවල පෙනෙන ආකාරයට Java UI Component හි ඇති ස්වරූපය ගන්නවා.
මෙය විවෘත හා නිදහස් මෘදුකාංගයක් විදිහට තමයි මෙය සංවර්ධනය කර තිබෙන්නේ ඔබටත් මෙය සමඟ සම්බන්ධ වීමේ අවස්ථා තිබෙනවා.මෙය අත් හදා බැලීමට අවශ්‍ය නම් පහසුම ක්‍රමය වන්නේ ඔවුන් දී තිබෙන ISO image එක Virtual machine එකක් මත Run කර බැලීමයි.

Google Code Jam 2010

prabathmail@yahoo.com (prabath ariyarathna) — Tue, 2 Mar 2010 06:47:00 +0530

ගුගල් සමාගම විසින් අවුරුදු පතා සිදු කරණු ලබන අංගයක් වන ගුගල් codejam තරග මාලාවේ 2010 අවුරුද්ද සදහා වන තරගය මැයි මස ආරම්බ කිරීමට නියමිතයි.මේ සදහා register කර ගැනීම අප්‍රේල් මස 7 වෙනිදයින් ආරම්බවේ.මෙහිදී ගුගල් විසින් සපයනු ලබන සන්කීර්ණ ගැටලු සදහා පිලිතුරු පරිනණක භාෂාවකින් ලිවීමට ඔබට සිදුවනු ඇත.මෙගැන වැඩි විස්තර දැන ගැනීමට කැමතිනම් ඒ සදහා මෙතනින් පිවිසෙන්න.