Resteasy 2.3.4 Released

May 29, 2012

billburke RESTEasy Leave a comment

About 20+ issues fixed and implemented.  Some highlights:

  • Netty integration.  Thanks to Norman Maurer
  • Expanded Atom support for extension elements.  Thanks to Kurt Stam
  • O’Reilly examples implemented on top of JBoss AS7
  • Zip patch that allows you to patch JBoss AS7 with latest Resteasy release
  • Expanded support for @Form that allows prefixed/indexed @FormParam and also collections.  (Docs are clearer on this). Thanks Maarten Winkel

Follow links from main Resteasy page to get to docs, downloads, and release notes.

 

Open Source’s Talent Advantage

May 22, 2012

billburke jboss, opensource 1 Comment

Was reading an article on TheStreet.com about Why Wall Street Hates Open Source.  I think one of the things that business people often don’t know about is the talent advantage open source companies have.  Answer this question:  What are our hiring practices?  How do we hire people?

We know they can do the job

Most of the developers that come to the JBoss division of Red Hat were/are contributors to at least one of our open source projects.   Think about that for a second…Before we start paying somebody a dime, we’ve worked with our potential new employees months, sometimes years at a time.  We know what they are capable of.  We know the quality of their work.

We can hire anybody anywhere

The world is our labor market.  We can hire anybody anywhere without having to move them because we already have distributed development model.  A development model that our employee has already participated in.

Our developers have initiative and are self-motivated

Open source developers are uncommon.  Why?  It takes initiative, and lots of it.  You have to have the gumption to download the code and figure out how to build it.  Then you have to have the skills to be able to understand and dive into somebody else’s code so you can add your pet feature or fix a bug that is holding you up.  You have to go beyond the scope of your job description and learn something new.  When we hire a contributor, we know we have somebody that isn’t afraid to take initiative and drive things on their own.

Our developers already know our products

In my experience, the vast majority of our contributors are actually users of our products.  They’ve come to help, because they are missing a feature or bug that hinders the progress of the work they are being paid to do.  They know our products, but more importantly, they know what’s wrong with our products and what they don’t like about our products.

Our developers enjoy what they do

Core contributors often contribute during their free time.  People aren’t willing to give up free time if they don’t a) enjoy what they are doing, b) don’t like our products.

Our developers are part of a movement

Richard Stallman aside, open source is not socialism, yet it is a movement.  A movement most developers are proud to be part of.

Anyways, this is one of the many reasons I think Red Hat is built to last.

Write your own logging abstraction

May 22, 2012

billburke java 2 Comments

As software developers we are ingrained to believe that copying and pasting code into multiple places is a bad idea.  As everything in life, you should always question what you’re taught as there are always exception to the rule.  I think logging abstractions are is one of these exceptions.  How many of you have struggled with logging frameworks?  How many times has one project or library used a different framework or version that causes incompatibilities?  How many often do you use a maven exclude for apache commons logging, log4j, or slf4j because each dependency uses a different framework or version of that framework?  Its a pain in the ass and a bleeping mess!

HornetQ was the first project I saw where they said, “To hell with logging abstractions!”.  They wanted to reduce external dependencies and logging was at the top of their list.  They implemented their own logging abstraction that used JUL by default, but that could also delegate to log4j, slf4j, etc.  Generic findClass invocations were done to determine which logging framework was installed in the environment HornetQ was running in.

So, what I’m suggesting is that each project should cut and paste what HornetQ has done and incorporate it into their own projects.  Let each project own their own logging abstraction and reduce their dependencies.  A side effect is they’ve also reduced any potential maven transitive dependency conflicts as well.  We did this very thing in Resteasy last year.  This is one case where copy and pasting is a good thing.

Enjoy.

Creating a JBoss Modules zip

May 21, 2012

billburke jboss, RESTEasy Leave a comment

I’ve extracted some of the build files from AS7 to create a maven project that can create a modules/ directory structure for Resteasy.  I wanted this so that people can easily patch/upgrade AS7 to the latest resteasy release.  It should be fairly easy to use the project as an archetype if you want to do it for other things.

json-home format: resource discovery

May 11, 2012

billburke REST 6 Comments

Thank you Mark Little for turning me on to the JSON-Home format Internet Draft.  “application/json-home” is a format that describes resources available from a particular site as well as possible hints on how to interact with those services.

   GET / HTTP/1.1
   Host: example.org
   Accept: application/json-home

   HTTP/1.1 200 OK
   Content-Type: application/json-home
   Cache-Control: max-age=3600
   Connection: close

   {
     "resources": {
       "http://example.org/rel/widgets": {
         "href": "/widgets/"
       },
       "http://example.org/rel/widget": {
         "href-template": "/widgets/{widget_id}",
         "href-vars": {
           "widget_id": "http://example.org/param/widget"
         },
         "hints": {
           "allow": ["GET", "PUT", "DELETE", "PATCH"],
           "representations": ["application/json"],
           "accept-patch": ["application/json-patch"],
           "accept-post": ["application/xml"],
           "accept-ranges": ["bytes"]
         }
       }
     }
   }

While I like the format, my own personal opinion is that hints are not needed.  Most(99%?) non-browser clients already know how to interact with the resources.  What they are looking for, really, is the actual URL to the resource.  IMO, a separate format(s) should be defined for resource description and the link relation URL can offer up that representation if it wants to.

Another beef I have with this (and the atom link XML format too) is that the value for the relationship, rel, can be a URL.  I’d much rather define a logical name, and have a separate attribute that specifies a URL that describes the relationship.  For applications, especially intra-net based ones, URLs can change more frequently than their Internet counterparts.  A logic name attribute could remain fixed and the description URL could be more dynamic.

BTW, I’m glad that the powers-that-be at IETF are showing some love to non-browser clients. Json-home is something similar I’ve done for a few of the RESTful services I’ve written.

Mocks are a Mockery

May 1, 2012

billburke flame bait, opensource 12 Comments

There were some interesting side conversations going on in the comments of my Java EE wins over Spring blog.  In particular, a few people were arguing over the value of Mocks.  I always considered Mocks a bogus pattern.  Only time I ever use them is when I’m initially starting a project and I don’t have full implementations of a particular subsystem and I need to test that something works.  You see to me, your GIT master branch, or your SVN trunk is a sacred place.  I fully believe in the idea of continuous integration.  But to have a pure Trunk, you have to test your code, as close as possible, to the target environment it is supposed to run in.  Mocks go counter to this idea.  And give you false sense of security.

My colleague, Stan Silvert said it best:

When you DO use mocks you are testing in an environment that is biased toward a passing test. An artificial environment will always make invalid assumptions about the behavior and stability of that environment.

What you end up with is a (hard to maintain) mock library that allows your tests to pass and gives you a warm feeling that you’ve done a great job. But you are fooling yourself.

The ONLY reason to use mocks is when test execution in the real environment is unacceptably slow. This used to be the case quite often. But with frameworks like Arquillian and super-fast startup times for app servers this is no longer a frequent concern.

I’ll end with an even more radical assertion. The difference between integration testing and unit testing is purely semantic. Even the smallest, most focused unit test pulls in a lot of the environment (JVM, OS, etc). In-container testing just pulls in more of the target environment and allows you to find more errors sooner.

Test in the real environment and get results that are truly valid. Stop kidding yourself with mocks.

Personally, I’m a very paranoid person when it comes to development.  Earlier in my career I did a lot of demos and live coding in front of an audience.  When you’re in this type of environment you live by the mantra that anything that can go wrong will.  So, when rehearsing, you always mimic as much as possible what your setup will be.  I carried this paranoia to Iona (an Irish company), when I worked on Orbix there.  We had a rule, that if even one test (integration or whatever) failed, you were awarded the Guiness Penalty.  If you broke the build, you had to buy every one on the team a pint of Guiness.  IN this environment, Mocks are a waste of time, both in build CPU and in coding time as you still had to run integration testing before you committed anything (unless of course you just wanted an excuse to have a few beers).

So unless a particular integration test is ungodly slow, don’t use mocks.  Stan again, said it best:

…the days of the 2 hour in-container smoke test are over.
Since mocks no longer provide much of a speed advantage their use is outweighed by the fact that they give you a phony environment, maintenance headaches, and false confidence.

But you do touch on a truth about testing that a lot of people miss. The purpose of testing is to uncover errors. And you will uncover more errors in a real environment than you would in a mock environment.

With projects like Arquillian and fast boot up times like AS7 (1.75 seconds on my laptop), there’s no need to mock anymore.

Resteasy 2.3.3.Final Released

May 1, 2012

billburke RESTEasy 1 Comment

A bunch of bug fixes. Also added a couple new features:

  • A few people were asking for a servlet-free embedded HTTP engine.  Integration with Sun JDK’s com.sun.net.HttpServer was added.  See documentation for more details.  Support for different HTTP engines is in the works.
  • Support for some more formats of the Atom Publishing Protocol.  Thanks to contribution from Kurt Stam.

Links to release notes, downloads, and documentation are available from the main Resteasy Web Page.

Decentralized Auth with Cookies

March 19, 2012

billburke REST, security Leave a comment

Way back in June I was brainstorming about ideas for decentralized authentication.  Here’s a summary of the requirements I wanted:

  • Competely stateless servers.  Servers that host browser applications and restful services would not have to store usernames, passwords, or permission metadata (roles allowed).
  • Servers would not have to handshake with an Identity Provider (IDP).  An HTTP request should contain all the information a server needs to authenticate and authorize a client.
  • A single web request can spawn complex authenticated and authorized interactions between underlying distributed web services.  This single web request would have all the metadata needed to invoke these complex underlying interactions between distributed services.

Unifying Interactions With Cookies

The problem with the protocol discussed in my previous blog was that it relied on new headers being transmitted between the client and server.  This sort of mechanism just wouldn’t work with browser-based applications.  Why?  Well, a browser isn’t going to know how to transmit and process new headers.  The only way to get a browser to store and forward metadata is via a cookie.  Most browser-based apps already use a session cookie to authenticate users (after a log-in of course).  There’s no reason we couldn’t re-use the digital signature techniques discussed in my previous blog with cookies.  Here’s how it could work:

  1. Browser points to example.com
  2. example.com redirects browser to idp.com (the identity provider)
  3. User logins into the IDP
  4. IDP redirects back to example.com.  The forward URL has all security metadata needed for the request, digitally signed (a query parameter would have the signature).  The amazon url signing technique could be used.
  5. Example.com would authenticate and authorize based on the query parameters of the forward URL and also verify the signature.
  6. Example.com would send back a set of cookies that contained all the security metadata expressed as cookie name/value pairs.  A special digital signature cookie would be used to sign them all so that on subsequent requests, the server could verify all the information stored in these cookies.

Step #4 might be problematic as the URLs could get quite large.  Who knows if a browser barfs on absurdly long URLs.  In this cast we could do a double form-post.  IDP could response from a successful login with an HTML Form whose target is Example.com.  This form would have all hidden fields within it containing security metadata.  One particulr form parameter would have a digital signature (I think SAML HTTP bindings work like this).

One vulnerability here is the cross-site scripting hack.  Most website already have this vulnerability I believe, so using existing techniques would be best.  I’m not sure how website solve this particular problem, but the HttpOnly flag could be used with each session cookie.  Javascript apps could have their javascript dynamically generated by the server and include the necessary code to manually apply and send the appropriate cookies.  Another thing that might mitigate things, is to include a timestamp with the cookies.  The application server would check for stale timestamps and with each request reset the digitally signed cookies with a new timestamp.

Non-Browser Clients Use Cookies Too

For non-browser clients, they could use a simpler RESTful protocol to obtain a signed URL or the set of signed form parameters.  There’s also no reason they couldn’t get a set of signed cookies instead of either of these approaches.

 

 

Java EE wins over Spring

March 13, 2012

billburke java, javaee, spring 87 Comments

The past 1-2 years since the release of Java EE 6, you’ve seen a lot of articles like this latest on TSS that talk about the niceities of Java EE 6′s component model over Spring and how Spring is now legacy.  Yup legacy.  Who would have thought it?  (other than me of course ;) ) I remember internal JBoss emails 4-5 years ago arguing whether we should give up on promoting Java EE as a component model (aka on EJB) and just concede to Spring.  Now, 4-5 years later, Java EE 6 has answered the challenge and is a viable, rich, integration technology.  So what happened?

Spring always depended on Java EE

Spring was and has always been a wrapper over core middleware infrastructure: ORM, Transactions, Messaging, HTTP.  It always depended core Java EE specs like JPA, JTA, JMS, and Servlet.  So, since you couldn’t deploy a Spring app without at least one of these core technologies/specifications, Java EE stayed in users minds.  There was always the opportunity that Java EE could get its act together in component model development.  While Rod Johnson always tried to position Spring as a Java EE alternative and JBoss killer, the Spring “platform” was never a true alternative to Java EE and JBoss, and in fact, couldn’t really exist without it.  IMO, this was a huge missed opportunity for the Spring folks.

Being the anti-Romney doesn’t work in the long run

J2EE was a machine with a huge massive install base.  A machine with a massive amount of money invested into it.  Java EE was its own market.  While Rod positioned himself over and over as the alternative to Java EE did he really think that this massive machine wouldn’t respond to the challenge?  While there are a lot of radical technology enthusiasts out there, the core Java constituency is pretty much moderate.  They are slow to adopt and tend to wait to see who is going to win the war over a long time.  Spring could not replace Java EE because technology wise, they were dependent on it.  All Java EE had to do was improve its component API message to the people, outspend Spring, and win over it in the long run.

Annotations were a game changer

The first thing that happened to shake Spring was the introduction of annotations in Java 5.  Annotations were a game changer.  Annotations were the opportunity to introduce mini-DSLs and pluggable keywords into Java.  Java EE 5 grabbed this opportunity with a huge facelift and refactoring of EJB and the introduction of JPA.  Basically, this was a standardization of Hibernate and its integration into EJB.  Complex EJB 2.x XML was replaced by few new Java keywords (well, annotations).  Simplicity ruled the day.  Middleware started to look more and more like a language feature rather than something hacked together via XML.  When annotations came out, I remember the Spring folks writing multiple blogs and forum posts about how evil they were.  IMO, they were just terrified of this new technology as it made much of Spring 2.x obsolete, and, well, much of Spring more complicated than Java EE 5.

CDI closed API hole

Thank you Gavin and the Seam folks.  CDI and Java EE 5 pretty much closed the technology gap.  Not only did they fill the integration holes that Spring exposed, they innovated far beyond what Spring had and created something new.  Beyond core IoC and DI, CDI’s event model was truly innovative and cool.

App Servers got their act together

Application server started to get their act together with regards to boot time.  It started with Glassfish and ended with JBoss 7.  Both of which can boot in a matter of seconds.  The whole Spring complaint that you needed Spring to mock out and test your code because app-servers started so slow was moot.

Arquillian made a mock of mocks

The final game changer was Arquillian.  One huge advantage Spring had was a unit testing story.  They gave you the ability to mock out core services like transactions and allow you to test application code outside of the application server.  This is huge for continuation integration and automated builds as well.  Combined with the fast boot times of JBoss 7 and Glassfish, you no longer have to hope your mocks will work when you actually run it in its real environment.  Arquillian allows you to run your unit tests in a real environment with real transactions, etc.  Personally I always despised mocks because they didn’t test in the environment you were going to run in.  I thought they were pointless and to this day, I refuse to use this testing pattern.

Anyways, in retrospect, I’m glad Rod and company were able to cash out with the VMWare acquisition before Java EE was able to regain its dominance.  SpringSource pushed Java EE to innovate and for that I’m very grateful.  For Java EE, it was either evolve or die.  They evolved, now its time for Spring to die.

 

Web Sockets, a disaster in waiting?

February 28, 2012

billburke REST 10 Comments

Mark posted a really nice article to InfoQ: WebSockets vs. REST?

From what I understand of Websockets, its bascially used to set up a two-way socket connection and not really an application protocol. What worries me the most is that you’ve basically rolled back 20 years of protocol consolidation, and we’re now back to a free-for-all of everybody’s pet protocol. Not so bad if your client and server are a tightly coupled, unreusable UI application. Really bad if you’re writing a web service that is supposed to be reusable by unknown heterogenous clients. With Web Sockets, web services are not only going to have to negotiate the media type, but also the application protocol. Seems like a huge step backward to me in terms of integration.  Did we forget all the problems we had with Oracle Forms, PowerBuilder, Visual Basic and all the UI/framework specific protocols all those developer frameworks introduced?  Do we really want to go back to those days?

What about security issues?  With an anything-goes socket protocol, isn’t this a security nightmare for our operations folks?

Disclaimer:  You could say that I’m both biased and threated by the concept of Web Sockets given my involvement in REST frameworks and APIs.  But in all honesty, I’d be very happy to embrace a new protocol that is both ubiquitous and easily supportable and interoperable in many different languages and platforms.  There’s much to be said about the simple request/response text-based approach of HTTP (and REST over HTTP).  While it may not be uber-efficient, its just so easy to hack and support.

Older Entries

Follow

Get every new post delivered to your Inbox.

Join 480 other followers