Friday, July 23, 2010

EJB 3.1

Today i'm going to talk about something interested and that is EJB3.1, after so many years in development sun has finally provided easy to use spec in EJB world in new enhanced EJB 3.1. I can see some similarity between EJB 3.1 spec and Spring Framework. lets check some feature from EJB 3.1

EJB 3.1 builds on the ease-of-use enhancements in EJB 3.0 by providing many new ways to improve developer productivity. Chief among these are the ability to implement session beans using only a bean class and the ability to package enterprise bean classes directly in a .war file, without the need for an ejb-jar file.

No business Interface (optional)
Singleton Bean
App callback
Annotation (exists in 3.0 spec)
No need of Eejb-Jar file

lets go and discuss above points.


No Interface


For example, the following session bean exposes a no-interface view:

@Stateless
public class HelloBean {

public String sayHello() {
String message = propertiesBean.getProperty("hello.message");
return message;
}

}
As is the case for a local view, the client of a no-interface view always acquires an EJB reference -- either through injection or JNDI lookup. The only difference is that the Java type of the EJB reference is the bean class type rather than the type of a local interface. This is shown in the following bean client:

@EJB
private HelloBean helloBean;

...

String msg = helloBean.sayHello();
Note that even though there is no interface, the client cannot use the new() operator to explicitly instantiate the bean class. That's because all bean invocations are made through a special EJB reference, or proxy, provided by the container. This allows the container to provide all the additional bean services such as pooling, container-managed transactions, and concurrency management.

Singleton

A singleton is a new kind of session bean that is guaranteed to be instantiated once for an application in a particular Java Virtual Machine (JVM)*. A singleton is defined using the @Singleton annotation, as shown in the following code example:

@Singleton
public class PropertiesBean {

private Properties props;
private int accessCount = 0;

public String getProperty(String name) { ... }

public int getAccessCount() { ... }

}
Because it's just another flavor of session bean, a singleton can define the same local and remote client views as stateless and stateful beans. Clients access singletons in the same way as they access stateless and stateful beans, that is, through an EJB reference. For example, a client can access the above PropertiesBean singleton as follows:

@EJB
private PropertiesBean propsBean;

...

String msg = propsBean.getProperty("hello.message");
Here, the container ensures that all invocations to all PropertiesBean references in the same JVM are serviced by the same instance of the PropertiesBean. By default, the container enforces the same threading guarantee as for other component types. Specifically, no more than one invocation is allowed to access a particular bean instance at any one time. For singletons, that means blocking any concurrent invocations. However, this is just the default concurrency behavior. There are additional concurrency options that allow more efficient concurrent access to the singleton instance.

Application Call Back

Here is an example that shows part of a singleton that includes a @Startup annotation as well as @PostConstruct and @PreDestroy methods:

@Singleton
@Startup
public class PropertiesBean {

@PostConstruct
private void startup() { ... }

@PreDestroy
private void shutdown() { ... }
...
}

No ejb-jar file


The EJB 3.1 specification addresses this problem by removing the restriction that enterprise bean classes must be packaged in an ejb-jar file. You now have the option of placing EJB classes directly in the .war file, using the same packaging guidelines that apply to web application classes. This means that you can place EJB classes under the WEB-INF/classes directory or in a .jar file within the WEB-INF/lib directory. The EJB deployment descriptor is also optional. If it's needed, you can package it as a WEB-INF/ejb-jar.xml file.

JERSEY

Sun offers a reference implementation for JAX-RS code-named Jersey. Jersey uses a HTTP web server called Grizzly, and the Servlet Grizzly Servlet (com.sun.jersey.spi.container.servlet.ServletContainer) handles the requests to Grizzly. You can develop production-quality JAX-RS applications today using Jersey, which implements all the APIs and provides all the necessary annotations for creating RESTful web services in Java quickly and easily. Beyond the set of annotations and features defined by JAX-RS, Jersey provides additional features through its own APIs, such as the Jersey Client API.

You can download Jersey separately or acquire it as a bundle with NetBeans 6.5 and GlassFish V3.

Developing RESTful Web Services Using JAX-RS
The classes and interfaces you use for creating RESTful web services with JAX-RS are available in the following packages:
javax.ws.rs
javax.ws.rs.core
javax.ws.rs.ext

I'm going to provide link to previous post for Jersey example and will write about Sprint rest template in my next post...

Jersey Example

Sunday, July 11, 2010

REST Framework implementation

I'm going to write a series of framework that can be used for REST implementation. I have looked different JAX RS vendors such as Jersey, RESTEasy and Restlet JAX-RS. but if you look at client side support, the JAX RS specification does not include a client side API and different JAX RS vendors have proceeded to create their own API's for the same. which means the framework one selects for the client and service ends do not have to be the same. For example, one could have a RESTful service running using Restlet while having a client developed in RESTEasy that consumes the same. In most cases, one will typically be satisfied with using the same client framework as one is using for the service development in order to be consistent and potentially be able to re-use artifacts in both areas if the framework permits the same. i have listed few options take a look at them.


Jersey - A JAX RS reference implementation from Oracle/Sun.
Spring 3.0 - Spring provides a RestTemplate, quite like the JmsTemplate and HibernateTemplate in its support of REST clients.
CXF - An apache project that is a merger of XFire and Celtix. Provides a JAX RS implementation and JAX WS as well.
RESTEasy - A JAX RS reference implementation by JBoss.
Restlet - A new upcoming framework that has support for Client Side REST calls
Apache Wink - A JAX RS implementation that has a client and server side api that has had a 1.0 release just recently
Apache HTTPClient or Http Components - Direct use of HTTP API - Down and dirty.

Im my next post i'll be talking about JERSEY and might present small example of that.

Thursday, July 1, 2010

Era of Open Source

Open Source framework, tools over the last few years have defined new era of technologies, from frameworks to infrastructure in my experience, the vast majority of enterprises are very comfortable with open source. Of course, my experience is naturally biased toward those companies who are comfortable paying for services and support around open source, and especially those who are replacing non-functional proprietary software with open source software.
I know 5-10 years ago a lot of the companies using open source would have been very hesitant to rely so heavily on open source, but so many people do now that the market seems to have really changed.

I do think going forward will see lots of companies will move toward using open source, you already have big companies Google, Facebook and Amazon using open source like Hadoop, Puppet etc...I just red article that Adobe has released Puppet Recipes for Hadoop...open source community keep growing day by day...