If you are exposing your some of services by Spring Remoting’s Http Invoker, most probably you come to the point where you wanted to have some authentication & authorization over your exposed services.
Spring Security is the magic to this…….. Following are great two articles, by which you can easily manage this stuff.
Goodluck!
Hardware Security Module or HSM is intensively used by financial institution and bank which intend to communicate with other financial institution like VISA, MASTERCARD etc.
Working with real HSM device is not only challenging but required most expensive budget since HSM devices are highly expensive. So, there are some good guys who spend their precious time and build HSM simulators by which you can have similar experience of HSM. We can easily work with simulators while in development then switch to real HSM device in production environment.
.Net based HSM Simulator
Java Based HSM Simulator
In the next post, I will be publishing the real HSM integration code, with any simulator or real device.
The holy grail for rest api is an auto-generated, always up-to-date, stylish documentation that promotes your site/product api. What are the tools available now ?
Well documented
less documented… but strangely easy to use.
Working in a Java shop, I’m looking for a solution at least working for spring-mvc rest services.
SpringDoclet is a Javadoc doclet that generates documentation on Spring Framwork artifacts in a project. The detection of Spring artifacts is based on the presence of Spring annotations on Java classes and methods.
SpringDoclet currently detects and documents the following types of Spring artifacts:
- Components – classes annotated with@Component,@Controller,@Repository, and@Service
- RequestMappings – classes and methods annotated with @RequestMapping
SpringDoclet writes its output in HTML format into a file named spring-summary.html. The location of the file is determined by the Javadoc “-d” option, with the same defaulting rules as the standard doclet.
sample
RESTdoclet
Benefits
Enables the creation of an enterprise REST service documentation web portal, providing a central port of call for service consumers
Enables automatic generation of documentation from underlying service source code, thus ensuring the documentation is always up to date
Features
Displays Spring-annotated service operations, types and associated Javadoc
Out of the box supports for Spring 3 RESTful services using Javadoc
Java 5/6 support. Java 7 coming soon
Customisable interactive web documentation application
Simple integration with Maven build processes
No custom annotations required – supports Spring 3 REST annotations out of the box
Further details on the RESTdoclet wiki.
WsDoc is a documentation generator for Spring MVC REST services. Multi modules/war and unified report.
sample
Wadl is the wsdl of rest api… but don’t appear to gain in adoption. It’s may dedicated to wsdl nostalgic 
Here are some home made solution for self documenting spring based applications.
Sample1 | Sample2
Swagger is a specification and complete framework implementation for describing, producing, consuming, and visualizing RESTful web services.
The overarching goal of Swagger is to enable client and documentation systems to update at the same pace as the server. The documentation of methods, parameters and models are tightly integrated into the server code, allowing APIs to always stay in sync. With Swagger, deploying managing, and using powerful APIs has never been easier.
As a specification, Swagger is language-agnostic. But since a spec without a usable implementation has limited immediate value, Wordnik has released Swagger implementations in Scala, Java, and HTML5. Client generators are currently available for Scala, Java, Javascript, Ruby, PHP, and Actionscript 3. More client support is underway.
sample | sample 2 | springmvc
I/O Docs is a tool created by Mashery that is very similar to Swagger. Written in JavaScript, the source is available on github (same for swagger), which means that you can taylor it to your own needs, as well as look-and-feel.
sample
Customizing it, is also possible.
Apiary : REST API documentation. Reimagined.
It takes more than a simple HTML page to thrill your API users. The right tools take weeks of development. Weeks that apiary.io saves.
Enunciate is an engine for dramatically enhancing your Java Web service API. (@javax.ws.rs.Path)
It’s simple. You develop your Web service API using standard Java technologies and attach Enunciate to your build process. Suddenly, your Web service API is boasting some pretty impressive features:
- Full HTML documentation of your services, scraped from your JavaDocs.
- Client-side libraries (e.g. Java, .NET, iPhone, Ruby, Flex, AJAX, GWT, etc.) for developers who want to interface with your API.
- Interface Definition Documents (e.g. WSDL, XML-Schema, etc.)
- …
Solutions exists… picking the right one will be harder.
For internal use the doclet approach is perhaps enough. From my point of view swagger looks more promising (specification, multi platform implementation, easy “try it” for end-users,…). I think IODocs will bring too much ‘new’ dependencies for “the Enterprise” (node.js,redis,…).
To go further on this topic, take a look at this presentation maintainable-api-docs-and-other-rainbow-colored-unicorns or this talk
Other remarkable tools ? Don’t be afraid to submit them in the comment !
Originally Published at http://mestachs.wordpress.com/2012/08/06/rest-api-documentation/
Node.js is extremely popular in recent days but I did get time to met with him. Today, while browsing randomly I saw an article “Top 5 Technologies at Startups” and found one of them is Node.js
So I decided to explore it right now and in next fifteen minutes I have setup node.js, write hello world http app and using it in browser. The nature of node.js is pretty awesome in context of development & performance. In today’s mobile apps era it become so obvious for mobile app developers to have back-end applications to process and store data. While with traditional approach, developing a full blown back-end application, it can takes up to months yet you have very short time to bring your idea into the market otherwise you are simply OUT!.
So if you want to kick start with node.js, its pretty straight forward & easy.
helloworld.js contents
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');
Node.js Resources
Some Real World Inspiring application build with Nodejs’s Express Framework
Enjoys with Node 
Nginx has been known and quit popular for its simplest and fastest speed. Nginx has been used as reverse proxy and load balancing purpose. Using Nginx over apache httpd has number of advantages, we will discuss them later.
So, starting with nginx with single tomcat instance is fairly simple
location / {
proxy_pass http://localhost:8080;
proxy_set_header X-Real-IP $remote_addr;
}
In the example below from their site, you will see that specific port 80 traffic is being sent to a singleservlet container running on port 8080.
Note that if you want to run multiple backend servlet containers ( for load balancing, scaling, etc… ) you should look at the Upstream Fair Module that will send traffic to the least-busy backend server. It is not shipped by defaul w/nginx.
server {
listen 80;
server_name localhost;
location / {
proxy_pass http://localhost:8080;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
}
location ~ \.faces$ {
proxy_pass http://localhost:8080;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
}
location ~ \.php$ {
proxy_pass http://localhost:8050;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
}
}
There is attached sample nginx.conf file with this post.nginx
Tip 1 Use a good JDBC Profiler
A JDBC profiler should be used as part of the development, QA process to catch potential performance issues and in production to help trouble shoot live performance issues.
In Development and QA
In Production
Tip 2 Understand Transaction Flush Mode
Hibernate does not flush every add or update transaction to the database. Rather Hibernate collects them and waits for the right time to flush them all t the database. And the right time is defined by the Transaction Flush mode. There are four Flush mode,
Why we need transaction Flush mode?
Default Flush Mode introduces Performance Problem during Bulk Operations
We had a page that creates a new campaign based on an existing campaign template via a deep copying . A campaign object could contain possibly hundreds of other objects. A typical flow is like the following,
A typical copy operation takes 30 minutes. This clearly indicates a performance issue. After further investigation, we traced the problem back to hefty performance cost introduced by database transaction flush.
For each select statement like retrieving the next level campaign objects, Hibernate does a database flush and as the number of objects loaded in the session increases, the time to determine the “dirty” objects increases dramatically. And there is absolute NO need to do database flush, since we are NOT making any changes to existing objects, only creating new ones.
The solution is to switch the default flush mode to COMMIT. This cuts the execution time from 30 minutes to 3 seconds.
So next time if an operation takes abnormal long time to execute and it is not being held up by the database itself, check Hibernate transaction flush mode carefully. Typically I use either MANUEL or COMMIT for any type of bulk operations or read-only operations.
Tip 3 Use Batch Operations
This article was written by Kris Buytaert (www.krisbuytaert.be/blog).
After years of working in Java-based environments, there are a number of things that I like to implement together with the teams I`m working with – the application doesn’t matter much, whether it’s plain java, Tomcat, JBoss, etc, these deployment strategies will help your ops and dev teams build more managable services.
PACKAGING
The first step is to have the native operating system packages as build artifacts rolling out of your continuous integration server – No .ear, .war or .jar files: I want to have rpms or debs. With things like fpm or the maven rpm plugin this should not be an extra hassle, and the advantages you get from doing this are priceless.
What advantages? Most native package systems support dependency resolution, file verification, and upgrades (or downgrades). These are things you would have to implement yourself or cobble together from multiple tools. As a bonus, your fellow sysadmins are likely already comfortable with the native package tool used on your systems, so why not do it?
PROXIED, NOT RUNNING AS ROOT
Shaken, not stirred
Just like any other daemon, for security reasons, I prefer to run run Tomcat or JBoss as its own user, rather than as root. In most cases, however, only root can bind to ports below 1024, so you need to put a proxy in front. This is a convenient requirement because proxying (with something like Apache) can be used to terminate SSL connections, give improved logging (access logs, etc), and provides the ability to run multiple java application server instances on the same infrastructure.
SERVICE MANAGEMENT
Lots of Java application servers have a semi functional shell script that allows you to start the service. Often, these services don’t daemonize in a clean way, so that’s why I prefer to use the Java Service wrapper from Tanuki to manage most Java based services. With a small config file, you get a clean way to stop and start java as a service and even the possibility to add some more monitoring to it.
However, there are some problems the Java Service wrapper leaves unsolved. For example, after launching the service, the wrapper can return back with a successful exit code while your service is not ready yet. The application server might be ready, but your applications themselves are still starting up. If you are monitoring these applications (e.g for High Availability), you really only want to treat them as ‘active’ when the application is ready, so you don’t want your wrapper script to return, “OK,” before the application has been deployed and ready. Otherwise, you end up with false positives or nodes that failover before the application has ever started. It’s pretty easy to create a ping-pong service flapping scenario on a cluster this way.
ONE APPLICATION PER HOST
I prefer to deploy one application per host even though you can easily deploy multiple applications within a single Java VM. With one-per-host, management becomes much easier. Given the availability and popularity of good virtualization, the overhead of launching multiple Linux VM’s for different applications is so low that there are more benefits than disadvantages.
CONFIGURATION
What about configuration of the application? Where should remote API urls, database settings, and other tunables go? A good approach is to create a standard location for all your applications, like /etc/$vendor/app/, where you place the appropriate configuration files. Volatile application configuration must be outside the artifact that comes out the build (.ear , .jar, .war, .rpm). The content of these files should be managed by a configuration management tool such as puppet, chef, or cfengine. The developers should be given a basic training so they can provide the systems team with the appropriate configuration templates.
LOGS
Logs are pretty important too, and very easy to neglect. There are plenty of alternative tools around to log from a Java application: Log4j, Logback, etc .. Use them and make sure that they are configured to log to syslog, then they can be collected centrally and parsed by tools much easier than if they were spread all over the filesystem.
MONITORING
You also want your application to have some ways to monitor it besides just checking if it is running – it is usually insufficient to simply check if a tcp server is listening. A nice solution is to have a simple plain text page with a list of critical services and whether they are OK or not (true/false), for example:
someService: true otherService: false This benefits humans as well as machines. Tools like mon, heartbeat or loadbalancers can just grep for “false” in the file. If the file contains false, it reports a failure and fails over. This page should live on a standard location for all your applications, maybe a pattern like this http://host / servicename/health.html and an example “http://10.0.129.10:8080/mrs-controller/health.html”. The page should be accessible as soon as the app is deployed.
This true/false health report should not be a static HTML file; it should be a dynamically generated page. Text means that you can also use curl, wget, or any command-line tool or browser to check the status of your service.
The ‘health.html’ page should report honestly about health, executing any code necessary to compute ‘health’ before yielding a result. For example, if your app is a simple calculator, it should verify health by doing tests internally like adding up some numbers before sharing ‘myCalculator:true’ in the health report.
The ‘health.html’ page should report honestly about health, executing any code necessary to compute ‘health’ before yielding a result. For example, if your app is a simple calculator, then before reporting health it should put two and two together and get four.
This kind of approach could also be used to provide you with metrics you can’t learn from the JVM, such as number of concurrent users or other valid application metadata for measurement and trending purposes.
CONCLUSION
If you can’t convince your developers, then maybe more data can help: Check out Martin Jackson’s (presentation on java deployments)[http://www.slideshare.net/actionjackx/automated-java-deployments-with-rpm]
With good strategies in packaging, deployment, logging, and monitoring, you are in a good position to have an easily manageable, reproducible, and scalable environment. You’ll give your developers the opportunity to focus on writing the application, they can use the same setup on their local development boxes (e.g. by using vagrant) as you are using on production.
By the way, I will be giving a talk titled DevOps: The past and future are here. It’s just not evenly distributed (yet). at this year’s LISA in Boston!
FURTHER READING
Powered by WordPress. Designed by 