New York Java Consultant

RESTful architecture and JAX-RS lead to distributed architectures. Roy Fielding's dissertation talks about a layered, client-server architecture. The JAX-RS Spec provides a great way to develop the server-side components, but doesn't describe how to develop the client-side components needed for a layered architecture. Note, I'm not talking about the browser as a client; rather, I'm describing Java-to-Remote-Resource communication. JAX-RS doesn't specify how a client API should be built. However, the various JAX-RS implementations does provide a client API. The client also seems to be the #1 requested feature for the next JAX-RS spec.

Before I get into the specifics of each client, I'll take the liberty to categorize different types/levels of RESTful clients I've seen that come bundled with JAX-RS projects:

This entry is part of my ongoing comparisons of JAX-RS frameworks. My next entry will include snippets collected from blogs and sample applications on how each of the four JAX-RS frameworks implements much needed RESTful client. I'll throw in some implementations of URLConnection and HTTPClient code as well.

The four current JAX-RS implementations provide Spring integration, even JBoss's RESTEasy. Each JAX-RS implementation has its own Servlet adapter implementation. The spring integration comes in the form of extending the default Servlet and plugging in a Spring Application Context. Beans are then created with some XML and potentially Spring component scanning.

There are really fantastic Spring/JAX-RS capabilities through out the four implementations, but I think that CXF takes my vote for "Best Spring integration in a JAX-RS product." The one request I'd have is to integrate with Spring MVC's Handler Mapping (find a Spring bean that corresponds with to the URL) and HandlerAdapter (given the current instance - controller/@controller/service/resource/servlet/action, figure out how to send the request and response to it). I'm not sure how hard it would be to implement, but if it were simple to do, it would add some pretty interesting functionality.

If I'm missing something, please let me know! I'm in the process of choosing a JAX-RS vendor, and Spring integration is at the top of my list.

JAX-RS Vendor Comparison

I'd like to evaluate the four products that I know of that support JAX-RS:

I'm interested in comparing the following aspects of the JAX-RS implementations that extend beyond "pure" JAX-RS:

I'll give some background on what I need, to both expose my biases and my needs. We have a large website -- let's call it NationalPark.com. There is a large section devoted to functionality that's self contained and sufficiently different from the rest of the site -- let's call it RestArea. The functionality of RestArea is reused in a handful of deployments: a couple on NationalPark.com and a few other deployments on other sites. NationalPark.com and the other websites are all developed on the Spring/Hibernate stak. We are rethinking the underlying functionalty of RestArea, and want to enrich the user experience of RestArea. We also want to separate RestArea deployment from the rest of NationalPark.com so that problems in RestArea don't spill over into the rest of NationalPark.com. A SOA/SaaS model will give us all of those features, but will also let us have more deployment options across the rest of our websites... We can deploy RestArea into one manageable environment across all of our websites, or we can deploy RestArea once per unique function. Did I mention that there will be somewhere between a million and two million users of the RestArea across our websites?

I plan on doing more research on these aspects and I'll be posting some blog updates over the next few days. I posted an entry about Spring Integration. I'll follow it up with Client API comparisons next week. Eventually, all of this research can hopefully be used for a comprehensive comparison article.

Any input you have on comparing JAX-RS products would be greatly appreciated!

Is it possible to somehow use JAX-RS in WebSphere?

This introduction to REST explicitly simplifies REST as

It's definitely a pretty good description of describing REST principles to REST-less newbies, but I think I'll supplement them with the formal principles as dictated by Roy Fielding. As an aside, among his other accomplishments Roy Fielding has "co-founded the Apache HTTP Server Project and [is] on the board of directors of The Apache Software Foundation." He was also on the standards committee for URIs, HTTP and HTML. He literally wrote the book on REST in his PhD dissertation: Architectural Styles and the Design of Network-based Software Architectures

From Chapter 6.1: Standardizing the Web

Here's part of the introduction

From the closing remarks of Chapter 5: Representational State Transfer (REST)

REST comes down to the following principles (quoted from Chapter 5: Deriving REST):

I hope I didn't leave anything out important...

Web-based systems have to perform increasingly complex functionality, a lot of which is client-side, but a hefty portion of it requires complex server-side development. That complex web development is becoming reliant on implementing RESTful architectural principles, similar to those found in Ruby on Rails. A new wave of RESTful development is aimed at the Entprise in the guise of RESTful Web Services. Development of RESTful Enterprise systems is becoming increasingly simpler for both the Enterprise Services and the Web camps through frameworks such as Grails, JAX-RS, WCF, ADO.Net Data Services and a new batch of statically-typed RESTful MVC technologies built on enterprisey technologies. The non-scripting frameworks definitely do have some catch up work, but they're all coming along nicely. The non-scripting REST environments have a disadvantage of not having language features that make development scripting environemts faster, but there are also plenty of examples of good engineering that has been ported over from the scriptng solutions to their non-scripting counterparts.

It doesn't seem like REST made it into the Enterprise in a big way yet, but the developments of the Big Boys' RESTful frameworks is likely to engender Enterprise interest over the coming months and years.

I've come across quite a few interesting features in various RESTful frameworks. I've also thought up some potentially interesting features in the development that may or may not exist yet that will probably prove useful in an enterprise; I may be playing the role of Astronaut Architect, so please feel free to flame any of my ideas that you find lame.

order.customer=239852

<order><customer>239852</customer></order>

@Path("/customerservice/")
@ProduceMime("application/xml")
public class CustomerService {

  public CustomerService() {
  }

  @GET
  public Customers getCustomers() {
    ......
  }

  ...
}

  <order total="...">
   <customer id="http://mycompany.com/customers/239852" />
   <items>
     <item id="http://mycompany.com/catalog/tables/49863"
       quantity="1"/>
     <item id="http://mycompany.com/catalog/chairs/28352"
       quantity="4"/>
   </items>
  </order>
  

  <order url="..." total="...">
   <customer id="http://mycompany.com/customers/239852.xml" />
   <items>
    <item id="http://mycompany.com/catalog/tables/49863.xml"
      quantity="1"/>
    <item id="http://mycompany.com/catalog/chairs/28352.xml"
      quantity="4"/>
   </items>
  </order>
  

I've put up quite a few ideas in this article about what I'd like out of a RESTful development infrastructure. Some are ideas that have been implemented, and some may not even be easily implementable.

If you have any other ideas about a RESTful environment, or some other comment about the ideas here, please let me know. The ideas that I'm most interesting in fleshing out are the Domain Addressability and Object REpresentation Mapping (ORM) ideas. The Cachable Client idea isn't that far behind, and integrates with the ORM idea. Again, feel free to flame, I don't generally moderate the comments.

I've had quite an interesting couple of weeks trying to wrap my head around REST, and the Java-sphere's various implementations of RESTful infrastructure. I'm going to use this entry to keep a bookmark of Resources I found useful in understanding not only Java's RESTful infrastructure but also the infrastructure of other ecosystems

I'm going to put some more thoughts about what I'd like to get out of a RESTful environment. I've been building large-scale content websites for the last three years, and I have quite a web development toolkit. Let's see which way my toolkit expands.

What's your opinion on who really "gets" REST from a development perspective (in the Java world)? Grails REST? JSR 311 - Jax-RS? Restlets?

JBosser Bill Burke (who's working on JSR 311) at one point said that:

I'm interested in REST from a perspective of building AJAXy Websites, and JSR 311 (Java API for RESTful Web Services) seems like the wrong paradigm for that type of development. Does anyone out there have any pointers for me in terms of a development platform that easily allows RESTful development?

I've heard a bit here and a bit there. I'm pretty interested in the RESTful changes that the Spring @MVC framework and even the cessation of Support for Java 1.4.

Unofficial Spring 3.0 announcement

I used the @MVC framework on my last project, which did have a lot asynchronous client-side work, could have benefited from this type of "@MVC completion." I'm pretty excited about this. I'm hoping to give a talk on this subject in October. I'm happy that the Spring Source guys have been so accommodating to my schedule by releasing the 3.0 GA in September .

Unofficial Spring 3.0 REST Support

I'm not 100% sure of what the @MVC changes are going to be, but the one thing that keeps on coming up is the support for automated URI to parameter translation. For example:

@Controller 
public ContentController{
  @RequestMapping("/content/${id}/show")
  public String show(
    @UriParam("id") Number id) {
    ...
  )
}

@MVC know that a RESTful url like

/content/19350/show

this Jira defect titled "Comprehensive REST Support" gives a good overview of the potential enhancements:

Spring @MVC and JAX-RS/JSR 311

I learned a lot about JSR 311 from JBosser/Red Hatter Bill Burke's blogs on the subject and from comments on one of my blog entries that first covered @MVC. There definitely are a lot of similarities between the two approaches to REST through annotations (Hence the "@REST" title). I'm going to write up with a comparison in the near future. I think I'll add in Restlets and possibly even Qi4j's REST implementation

I've been working quite a bit with Tiles 2 and Spring 2.5 lately for a pretty big website. The Tiles framework allows you to break up a page into smaller components (a.k.a a tile) each of which can have their own view (in our case JSPs) and their own "controller" called a ViewPreparer. The entry point from the web, in our case, is a Spring 2.5 annotation driven controller (@Controller for short). We've set up those @Controllers' to use "layout" tiles as views. Those "layout" tiles in turn use other tiles for componentized widgetry. You can read about some of the details of integrating @Controllers with Tiles (and the benefits therein) in Craig Walls' great blog entry on the subject.

We've set up some widgitized components to use ViewPreparers, so we decided to use component scanning magic to auto-magically import beans into our application context... At first, we made these ViewPreparers @Service objects, which created them in our "root" applicationContext. I like to keep DispatcherServlet related instances in the DispatcherServlet applicationContext, so I used the configurable context scanning to include the ViewPreparers only in the appropriate context:

 <context:component-scan base-package="com.mycomany">
   <context:include-filter type="regex" expression=".*ViewPreparer"/>
   <context:include-filter type="annotation" 
     expression="org.springframework.stereotype.Controller"/>

   <context:exclude-filter type="annotation"
      expression="org.springframework.stereotype.Component"/>
   <context:exclude-filter type="annotation" 
     expression="org.springframework.stereotype.Service"/>
 </context:component-scan>

While that regex is pretty useful, it forced me to keep my class names to have a prefix of ViewPreparer. My next attempt to make it a bit nicer was to create my own annotation for defining ViewPreparers:

@Target( { ElementType.TYPE })
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Component
public @interface ViewPreparer
{
    /**
     * The value may indicate a suggestion for a logical component name, to be
     * turned into a Spring bean in case of an autodetected component.
     *
     * @return the suggested component name, if any
     */
    String value() default "";
}

Which I apply to my ViewPrepers:

@ViewPreparer
public class WidgetViewPreparer extends ViewPreparerSupport {

    private WidgetService widgetService;

    @Autowired
    public WidgetViewPreparer(WidgetService widgetService) {
        this.widgetService = widgetService;
    }

    @Override
    public void execute(TilesRequestContext tilesContext, 
       AttributeContext attributeContext) throws PreparerException {
         // perform fancy widgetry logic
    }
}

My auto-scanning now looks like

 <context:component-scan base-package="com.mycomany">
   <context:include-filter type="annotation" 
     expression="com.mycompany.stereotype.ViewPreparer"/>
   <context:include-filter type="annotation" 
     expression="org.springframework.stereotype.Controller"/>

   <context:exclude-filter type="annotation"
      expression="org.springframework.stereotype.Component"/>
   <context:exclude-filter type="annotation" 
     expression="org.springframework.stereotype.Service"/>
 </context:component-scan>

My custom annotation definitely felt like it was a better approach than the regex... To take it a step further, wouldn't it be nice to have @ViewPreparers that had annotation symantics similar to Spring @Controllers?

I'm on a project that's using the latest and greatest of a specific technology, specifically Spring. As with any bleeding edge technology, most of the time things work out great, but things can go awry when you start getting into edge cases. In our case, we ran into a case where we had a slick new @Service object that had a @Transactional method... The combination of the processing of the two annotations simply didn't work. Everything works just fine if the @Service annotation is removed and the bean is set in XML. One of our developers even put in a Forum post about this (which I guess is still being researched by the spring guys).

Overall, new technologies provide a whole bunch of shinny new toys to play with... Just be careful not to cut yourself.

Indeed.com added another cool job search tool: Search by Salary. You can just add in the dollar amount in the search term, and Indeed gives you the jobs that match. Here's a search for $120K jobs in NY.

Enjoy.

ETL has three steps:

I need to take a set of XML documents and save them to a database. I thought about using Groovy for my current requirements. I decided against it because of the complex requirements (multiple types of files/tables and complex transformations) and the team that will be maintaining this code (Java/Spring/Hibernate hard core developers).

I had access to complex Hibernate mappings, so the Load technology is a pretty straight forward choice. I had lots of success with Dom4J as XML Extract technology, and others seemed to be comfortable with that selection as well.

The only thing that's left is the Transform technology. I'm pretty comfortable with Spring core and Spring MVC. They both need to take a String representation of a potentially nested variable name and figure out how to convert that String to a setter. They both need to take a String representation of a value and transform it to the correct type. Spring uses the DataBinder class to do this.

The core of what I'm doing is:

  Document document = new XPPPacketReader().read(file);

  // this is more-or-less a Map
  MutablePropertyValues values = new MutablePropertyValues();

  // read in via XPath into the Map
  for (Map.Entry configuration : this.configurations) {
    String variableName = configuration.getKey();
    String xpath = configuration.getValue();
    values.addPropertyValue(variableName, document.valueOf(xpath));
  }

  // look at the document to figure out what kind of object we need
  // usually, it will involve some logic centered around 
  // document.getRootElement().getName()
  Object content = getObjectCreator.createObject(document); 

  // bind the data - 
     // convert String variable names to setters,
     // convert String values to the appropriate types.
  new DataBinder(content).bind(values);

BTW, I'm using XPP Packet Reader for Dom4J. It solves some character encoding issues that we've run across.

The code basically does the following:

This approach handled the the most basic cases where there is a one-to-one mapping from xpath to nested variable that is a primitive or String value. Most of the transformations will likely be satisfied with this approach. The other, more complex situations have to be handled via application code and some customizations to DataBinder. DataBinder allows you to set custom PropertyEditors for complex conversion and dynamic collection management. I still have to see if this will work for my needs, but so far, so good.

Try this code:

Calendar midnight = new GregorianCalendar(2008, 10, 2, 0, 0, 0);
Calendar c = new GregorianCalendar(2008, 10, 2, 0, 0, 0);
c.set(Calendar.MILLISECOND, 0);
for (int i = 0; i < 25; ++i) {
  System.err.println(c.getTime() + ": " + c.get(Calendar.HOUR_OF_DAY));
  System.err.println("Hours since Midnight: "
      + (c.getTime().getTime() - midnight.getTime().getTime())
      / 1000.0 / 3600.0);

  c.set(Calendar.MINUTE, 0);
  System.err.println(c.getTime() + ": " + c.get(Calendar.HOUR_OF_DAY));
  System.err.println("Hours since Midnight: "
      + (c.getTime().getTime() - midnight.getTime().getTime())
      / 1000.0 / 3600.0);
  System.err.println();

  c.add(Calendar.HOUR_OF_DAY, 1);
}

November 2, 2008 is a cut off date for DST. c.set(Calendar.MINUTE, 0) is supposed to be a no-op, but it isn't... Run the code, and see the bug.

Credit goes to Panos Papamichael for finding this bug