Complete Hibernate – Beta Class at Reduced Price

Intertech has updated its Complete Hibernate class (more material – more days of training) and it is being run for the first time in August. Sign up now to get a 25% reduction in price by participating in the beta run of the class.

JAX-WS and Operation Overloading

Another great group of people this week in my classroom. The topic was Java Web Services with a little JMS thrown in. During the class this week, in the discussion of Java to XML (and back) mapping as provided by JAX-WS and JAXB, I indicated to students that while Java as a programming language supports method (or operation) overloading, it is prohitited in Web services by specification (WSDL) and the WS-I Basic Profile.

During class, we explored the JAX-WS annotations for defining Java Web services. Specifically, we looked at the @WebService annotation on the service endpoint interface (SEI) and implementation bean (SIB) as shown below.

package example;
import
javax.jws.WebService;
@WebService(endpointInterface ="example.SomeService")
public class SomeServiceImpl implements SomeService
{
public int doIt(String str) {
return 0;
}
}

package example;
import
javax.jws.WebService;
@WebService
public interface SomeService {
public
int doIt(String str);
}

When looking at JAX-WS, we also explored the operationName attribute on the @WebMethod annotation for Web service methods. A perceptive and imaginative student (thanks Pat) asked “if you could use the operationName to allow for method overloading at the Java level while preserving unique operation names in the WSDL and SOAP level?” I’ve extended the example to demonstrate below.

package example;

import javax.jws.WebMethod;
import javax.jws.WebService;

@WebService
public interface SomeService {

public int doIt(String str);
@WebMethod(operationName = "doItNow")
public int doIt(int i);
}

package example;
import javax.jws.WebService;
@WebService(endpointInterface = "example.SomeService")
public class SomeServiceImpl implements SomeService {
public int doIt(String str) {
return 0;
}
public int doIt(int i) {
return 0;
}
}

What a great question and one that sent me scrambling to my browser and text books looking for an answer.

The answer is – no, not easily. This will be somewhat dependent on the JAX-WS implementation (for example, take a look at Christophe Hamerling’s example in Apache CXF where overloaded operations and use of the @operationName works) and work-arounds could probably be negotiated (for example, don’t use document/literal wrapped style). However, when using the JAX-WS reference implementation mapping tools there is still going to be problems despite the @WebMethods operationName attribute provides a unique operation name as far as SOAP and WSDL are concerned.

The reason? The wsgen tool has problems creating the default SOAP wrapper classes for the operation inputs and outputs. When you run wsgen with the code above, you get an exception (com.sun.tools.internal.ws.processor.modeler.ModelerException: [failed to localize] Request wrapper bean names must be unique and must not clash with other generated classes.)as shown below.

So thanks again for the great question Pat. Contact Intertech if you would like to sign up for our next Complete Java Web Services class.

JAX-RS: A new Java Web service API

JAX-RS will be part of Java EE 6 which is due out in final form in September ’09. What is JAX-RS? JAX-RS is the Java API for RESTful Web Services. OK, so what is a RESTful Web service? The term REST (Representation State Transfer) dates to a 2000 doctoral dissertation by Roy Fielding – cofounder of the Apache HTTP server and coauthor of the HTTP and URI standards. REST is the software architecture (or architectural style) for distributed hypermedia (text, graphics, audio, video, etc.) systems. REST is the foundation of the World Wide Web. RESTful Web services, is the application of the REST architectural style to provide information to other systems, process, etc.

At the heart of a RESTful system is a resource. A resource is anything that has an identifier in the form of a URI. Any informational item that can be named can be a resource: stock price, customer, purchase order, calendar of events, etc. The concept of a resource is broad. Here are some examples.

http://www.intertech.com/studentDirectory/students
http://www.intertech.com/studentDirectory/students/jamesBond
http://www.intertech.com/studentDirectory/students/missMoneypenny

Resources have state and it is that state that the requester of the resource is interested. A RESTful Web service requestor or client may request to read the resource’s state. A client may request to update a resource’s state. Behind REST systems is a set of client-invoked operations on resources. While not absolutely required, most have come to accept the set of HTTP methods as the general API for REST operations on resources.

GET - Read a resource
POST - Create/add a new resource from the
HTTP request body
PUT - Update a resource from the HTTP request body
DELETE - Delete a resource

The URI query string might provide amplifying information about the operation.

http://www.intertech.com/studentDirectory/students?lastName=Bond

In a RESTful system, URIs act as nouns (identifying resources) and the HTTP method acts as a verb that specifies the operations on the resources. URIs and HTTP methods provide, while more convention than standard, a terse and uniform style for information exchange.

So Back to JAX-RS. JAX-RS allows for the construction of RESTful services in Java. Using JAX-RS, REST resources are Plain Old Java Objects. The POJOs are annotated with @Path. @Path takes one argument. The argument identifies the relative URI path to which the resource responds.

@Path("/helloworld")
public class HelloWorldResource {
...
}

The URI path is relative to the base URI of the server the resource is deployed, the context root of the WAR, and the URL pattern for an adapter servlet that routes traffic to the resources.

http://:///

So, assuming the resource above was in a MyWebApp WAR, a URL request to this HelloWorldResource might look like the following:

http://localhost:8080/MyWebApp/resources/helloworld

The @Path annotation merely dictates what request traffic is sent to the resource.

Add annotations (@GET, @POST, @PUT, @DELETE, @HEAD) to the resource methods to indicate what should be invoked for each type of HTTP request.

@Path("/helloworld")
public class HelloWorldResource {

@GET
public String sayHello() {
return "Hello
World";
}
}

Methods that are annotated with @GET, @POST, @PUT, @DELETE and @HEAD are called resource methods and allow for the RESTful service clients to retrieve, update, remove, and create new resources.

By default, the resource returns text/plain. However, the @Produces annotation can be used to specify the MIME type of response. The @Produces can annotate the resource to provide the default return type for all resource methods.

@Path("/helloworld")
@Produces("text/html")
public class
HelloWorldResource {
...
}

Resources may offer multiple MIME types for any given request.
Resources may also be sent information (as part of the HTTP request body) by the client. The @Consumes annotation works in a fashion similar to @Produces but for incoming rather than outgoing MIME types. @Consumes specifies which MIME types can be accepted or consumed by the resource.

@POST
@Consumes("text/plain")
public void respondToMessage(String message)
{
...
}

As with all Java specifications, JAX-RS must be implemented. The Jersey project is Sun’s reference implementation of JAX-RS 1.0. You can get Jersey today at https://jersey.dev.java.net. To learn more about JAX-RS and the other APIs of Java Web Services, sign up to take Intertech’s updated Complete Java Web Services class.

Spring Dependency Injection Questions

This past week, we had our “Beta” run of Intertech’s new Complete Spring Core and Complete Spring Web classes. The latest Spring (2.5.6 with mentions of Spring 3) and Spring MVC/Web Flow are taught in these classes.

I had a great group of students to help give this new class its inaugural flight. While a little on the quiet side, they had wonderful questions and some great insight at the conclusion of our class for how to improve it. I thought I would share two questions that came out this week’s class.

Question #1 (thanks Sharon) - What happens when you use for dependency injecting a property but the property is a List in the actual class? For example, what if the bean definition looked something like this…

And the class looked like this…

public class Player
{
private List teams;
public void setTeams(List teams) {
this.teams = teams;
}
}

The implementation class of the collection bean property does not have to match or property definition in the Spring configuration. Both can be used interchangeably with any type of java.util.Collection. The element wires a collection to the bean and ensures that there are no duplicates. But, as in this case, the underlying collection is still a list. So in this example, the Player bean will have a List of team Strings, but the duplicate “Yankees” will be removed.

Question #2 (thanks Kurt) - Another great question came when we looked at the @Autowire annotation that was added in Spring 2.5. This annotation can be used on any method in the class to conduct dependency injection. The question was what if the @Autowire is used on multiple methods to dependency inject the same property? For example…

public class Player {
private String name;
private Team team;
@Autowired
public void initializePlayer(Team team){
this.team =
team;
}
@Autowired
public void initializePlayerAgain(Team team){
this.team = team;
}
}

In fact, both methods will get called and a Team will get passed to both methods. While this works, we could not think of a good reason for its use.If you have interest in exploring Spring, please contact our office (651-994-8558) and ask for Dan McCabe. I think our Spring training is the most complete (pun absolutely intended!).

Java SE 7 and Java EE 6

I just returned from JavaOne. Details on Java 7 and Java EE 6 were big topics during the conference.

Java 7 is expected to be released Feb 2010. Based on last year's conference notes and milestones released this year already, many thought (including myself) that Java 7 would be released sooner. The last feature-complete milestone is scheduled for Oct 2009. I attended a few sessions that discussed what will be in Java 7. Everyone was careful to say that the final decisions hadn't been made yet, indicating there is still work being done on Java 7. Some of the things likely to be in Java 7...
1. modules (allowing you to customize the features of Java you need for your app and finally killing the classpath)
2. null check operator/conditional - "?:"
3. Strings in switches
4. multiple exception catches in the catch block (using "")
5. diamond operator to allow the generics to be more easily used.
//For example...
HashMap> map = new HashMap>();
//becomes
HashMap> map = new HashMap<>();

Things not likely to make Java 7 but at one time rumored to have a chance...
1. closures
2. SQL expression checking

Java EE 6 will actually come out sooner. Java EE 6 is due on in final form in Sept 2009. In this release, the big new features are:
1. JAX-RS (support for RESTful web services)
2. JSF 2.0
3. Asynch servlets
4. Bean validation (adding validation to JavaBeans that can be used to validate property data anytime they are used).
5. Web.xml is gone (at least it can be gone) with the use of annotations and/or web.xml fragments.
6. Web beans - essentially session beans in the WAR file.

A few other notes from the conference...

Eclipse Galileo is the next train release of Eclipse (following the previous year releases of Calisto, Europa, and Ganymede) and it will come out on June 24th. This release now includes 33-48 Eclipse projects (Ganymede included 24 projects). On Jun 26, there will be a live Webinar to learn about new features. From the talk, I wouldn't say there is any real big thing in this release that most of us would use on a regular basis.

Spring has a new project called Spring Roo (yes for kangaroo). Essentially, this is Rails or Grails but all in Java and Spring. Meta programming is here to stay folks. I hope to have more on that in a later blog posting.

Groovy and Grails at JavaOne

Hello from San Francisco! I am at JavaOne this week. Catching up on what is new, important and at issue with Java. The conference is not cheap and travel is usually one of the first things that go in reduced budgets, but if you can somehow manage it, this is the conference that all Java developers need to attend whenever possible.

The conference’s Java University started today. I attended a wonder class by Graeme Rocher on Groovy and Grails. Graeme is the project lead for Grails and head of Grails development at Spring Source.
Groovy is a programming language that has been attracting a lot of attention lately. And base on what I learned and saw today, it rightfully should. Groovy is a dynamic language inspired by a number of other such languages (most notably like Ruby, Smalltalk and Python) written specifically for the Java Virtual Machine. Its aim is to bring the “power of Ruby and Python and the elegance of the Java syntax to a JVM.” Because it is written specifically for the JVM, it is an extension to Java. Groovy provides all the power of metaprogramming but with all the benefits of Java and the JVM underneath. Although other dynamic languages like JRuby or Jython run on the JVM, they have had to be modified in order to run on the JVM. Some concessions were made in the port of Ruby and Python to the JVM. Most of the environments are an extension but a replacement of the Java API (having their own I/O and collection API for example). The goal of Groovy is simple – less code meaning faster development and hopefully easier/faster maintenance.
Grails is an MVC++ action-based web framework. Grails is to Groovy what Rails is to Ruby (more precisely Ruby on Rails). I say Grails is an MVC “plus plus” framework because it is more, way more, than just a web application framework. It also provides the entire platform for building applications from the UI to the data layer. In fact, Grails is built on Groovy (of course) as well as Spring, Spring MVC, Hibernate, Quartz (for job scheduling), SiteMesh (layout framework), Jetty and HSQLDB. Like Rails, building a CRUD (create, read, update, delete) interface can be done in minutes. But because it is also built on top of the best-of-breed Java technologies, it can also do so much more, and because it is done with Groovy, it can be done quickly with very little code.

A couple of things to consider before you start singing Kumbaya with the Grails/Groovy crowd. Grails requires a relatively up to date platform. Grails comes with its own container and even database, but most shops are going to want to run Grails on their own container. Grails requires a Web container that is at the 2.5 level (Java Servlet 2.5). Secondly, Grails is slower than Java. According to Graeme, he has seen a Java application that did ~1000 transactions a minute only perform ~750 when using Grails. The good news is that the same app using Rails did only ~150. Rails performance issues are starting to attract some attention and Grails offers the same kind of development convenience with a much better performance outlook (see http://www.infoq.com/articles/Rails-Performance or http://www.techcrunch.com/2008/05/01/twitter-said-to-be-abandoning-ruby-on-rails/ for some of the Rails issues). Lastly, Grails, while offering the promise of less code and faster development, is not a tool for novices. Under the covers of Grails and Groovy, there is a lot of Java and Java technologies. While Groovy and Grails helps abstract away many of the details and common drudgery of modern Java application development, it does not protect the developer from having to fine tune and tweak application to do the business’s bidding, especially in large scale, high performance environments. I asked Graeme if he felt developers of Grails applications needed to know Spring, Hibernate and all the underlying technologies well to be able to build a large scale performing enterprise application. He indicated that in some cases, for example Spring, developers were isolated from having to know the framework to get things to work and work well. But developers are going to have to know and understand the inner workings of other frameworks like Hibernate in order to make parts of Grails like GORM (Grail’s ORM capability) perform well. Given that Grails is built on top of Java, on top of many Java technologies like Hibernate and Spring, and on top of Groovy, this is a lot to learn and know.

Still, when you see the simplicity and speed of Groovy and Grails development, you can’t help but believe there indeed IS a better way to build Web applications. “Power to the people” with Groovy. I encourage you to take a look. More information on Groovy can be found at http://groovy.codehaus.org/. Information on Grails can be found at http://www.grails.org/.

New Spring Classes and a Special One-time Discount

For those interested in learning Spring, I have just completed two new Spring classes at Intertech: Complete Spring Core and Complete Spring Web. These two classes will be offered back-to-back in June.

In fact, we (Intertech) has a special offer. For the Beta (first public offering) of these two Intertech courses, we’re offering a 25% discount on the standard course rate. In exchange for the discount, you agree to give detailed course feedback. The courses and dates are:
Complete Spring Core Training, June 8-10
Complete Spring Web Training, June 11-12

To get this special pricing, you must register over the phone (651-994-8558 +23) and mention “BETA-RUN.” This is a onetime offer so sign up now.