timgarrett.net

I know I had you fooled into thinking this was exclusively a tech geek blog.  I don’t intend for that to be the case, and I would like to use this forum to sound off about Brett Favre and his retirement flip-flopping.  A lot of football fans have suggested that Favre should just be accepted back because a proven quarterback gives more chance than playing with the quarterback of the future.  By that logic, who would turn down a 4-time Super Bowl champion like Terry Bradshaw?  He is proven after all, and he looks pretty good for 60!

But that’s not really the point.  The point is that Favre has jerked the Packers around; not for days, weeks, or months…but YEARS.  I for one am just looking for this endless “will he stay or will he go” to end for good.

I am a big fan of EJB3, but I think certain integration realities in an enterprise environment can limit its relevance. While recently working with EJB3 stateless session beans exposed as JAX-WS web services, I ran into some issues propagating security credentials. I know that this is a fairly seamless process in a traditional Java -> EJB invocation. I had hoped that there was some magic that would provide the analagous solution of security credential propagation from a Java web application to a JAX-WS web service secured with HTTP basic auth (and SSL for the transport mechanism).

I could not dig up any details on this topic, so I came up with my own solution by assembling standard and quasi-standard components.

The end result looked like this:

1. The web application, which used form security, was adapted to use the Spring Security form-based authentication. Although this was a somewhat painful process in the Acegi Security days of configuration hell yore, the Spring Security domain-specific namespace has made it a quite simpler activity. You need a couple of filters and a very simple Spring XML file. Reference docs are here. Anyway, I set up the authentication in the web app to authenticate against the same JAAS realm I had previously used with straight container-managed security.

2. Next, I used the Spring JaxWsPortProxyFactoryBean to wire up my remote web service to appear as a simple business service interface to the web application code. This is pretty cool, because it lets you code your view and controller code completely ignorant of the fact that the model lives somewhere in the SOAP world. I leveraged the new basic authentication functionality of Spring 2.5.5’s JaxWsPortProxyFactory bean and created session-scoped instances. So, I could have an instance of the client bean for each user of the web application, and that client would have its username and password properties initialized from the Spring Security SecurityContext object in scope.

3. Next, I set up my web service (JAX-WS servlet endpoint with injected EJB resource) with Spring Security settings of its own, to include basic authentication against the same realm as the web application (if on different containers, would be different realms but the same underlying authentication store) and HTTPS transport. Then, voila, I had credentials that were equally valid in the web application and the web services.

To be fair, this was a lot of work, but code samples aren’t really necessary as most of the work was in figuring out a valid approach However, I believe the benefits will be immense in the long run.

I can always add rules later to enable anonymous callers of certain web service operations, but more often than not, I want to know who the caller is and have their experience (returned data) take that into account. That way I can take advantage of all the neat things that Spring Security offers to create fine-grained security in my services. I can do method-level security, collection-filtering security, and audit logging with ease! At the most primitive level of functionality, I can do a thumbs-up, thumbs-down decision on whether a user is even authenticated and allowed to use a web service.

I have seen some pretty primitive attitudes toward web service security–things like non-SSL transports combined with a simple authentication token that never changes. This is exactly the kind of recklessness I wanted to avoid in my services. SOA is a powerful mechanism when employed properly. One of the premises of SOA is that systems can be easily built by aggregating services. However, that is no reason for the web services to be a free-for-all for anyone who can find a “Hello, this is Axis” servlet and associated WSDL.

Stand with me and build a better web service!

I know my approach to exception handling within services are not original to me, but when I was recently looking for a concise, consolidated written explanation of it to share with a coworker, I couldn’t find one.

In a nutshell, it is:

• Throw only unchecked exceptions in your business logic; exceptions should not be used for control flow, so why force other modules in business logic to deal with hiccups?
• Use a transactional management strategy that rolls back transactions on RuntimeException
• Hide the implementation details of exceptions behind the service layer just as you would the implementation details of the code
• Define one or more checked exceptions specific to your service layer; when an error propagates up to the top service class, log it and its stacktrace and then throw a generic checked exception

An example:

public interface TestService {
    public void runTest() throws TestServiceException;
}

public class TestServiceException extends Exception {
    public TestServiceException(String message) {
        super(message);
    }
}

public class TestServiceImpl implements TestService {
    private static final Logger logger
            = Logger.getLogger(TestServiceImpl.class);

    public void runTest() throws TestServiceException {
        try {
            //integration with business logic here
            } catch(RuntimeException e) {
                logger.error(e, e);
                throw new TestServiceException(
                        e.getClass().getName()
                        + " encountered in TestService");
            }
        }
    }

This type of standardization is especially important if you have opted to generate web services or other remoting code directly from your services. In the same project I mentioned previously where the web service was required to accept a wide variety of abbreviations and spellings of state names, a remote web service would occasionally throw Oracle database statement errors back to the web service client. This is very dangerous; if combined with poor security practices and other poor coding techniques, it is likely to provide a method for remote SQL injection attacks.

Whether you have just started building web services or whether it is old hat by now, it is important to take a step back and examine how you have been doing things. Although it is initially cool to quickly generate a service and accompanying WSDL, maybe some client code for testing, and expose your business logic to remote systems, there are more important things involved, like data integrity. It doesn’t matter how quickly you can interact with remote systems if you are getting nothing but junk from the interaction. The old adage “Garbage In, Garbage Out” certainly applies.

How do you know if you are building a robust web service that delivers real value while maintaining data integrity? The answer to this can be found by examining how you handle remote input. Do you assume that everything is OK if an initial test run doesn’t throw an exception? Do you validate input? Do you throw away part of your data and continue processing in spite of it?

Building a robust web service isn’t all that complicated. Here are a few tips:

• Be specific about your inputs. Is the data element really a xsd:string or is it actually a positiveInteger? If a numeric type, are you specifying ranges? If a string type, are you specifying an enumeration of valid values?
• Fail early. The job of a web service is to enable easy integration between systems, not to try frantically to make bad data into good data. Make your interface contract clear, and leave client code no choice but to follow the rules.
• Version your web services. Don’t let your past mistakes haunt you forever. Create new namespaces and URLs for your new, more savvy web services. Then, announce an End of Life schedule for your services. Well-defined web services that communicate in clear messages are best for everyone.

Why am I on this SOAP box? Imagine a web service that accepts every possible value imaginable for a state or province. For example, Connecticut might be Connecticut, connecticut, CT, or C.T. I saw this today. Unless the purpose of your web service is to provide mailing address normalization, this is completely out of line. The S in SOAP used to stand for simple, but if you are building this kind of logic into your web services, you missed the boat.

Services should be contract-driven and should leverage rigid XSD rules and validation before ever being passed into the business logic that makes the service worth exposing remotely in the first place. Clean data gets dirty a lot faster than dirty data gets clean. So, take the steps early on to maintain clean data in your system.

I got it. It rocks. How is that for short and to the point?

I am an experienced and competent J2EE developer (with some forays into the updated JavaEE technologies). I have worked with most of the big technologies and acronyms from time to time. They are powerful, very powerful. Howevever, they are also big and cumbersome to learn. For a long time, I have taken the stance that the complexity was necessary. You get robustness, correctness, and big industry names behind your project.

Yet, when I was reading through the spec for the Java Business Integration (JBI) API this past week, I was dumbfounded by some of what I would consider unnecessary complexity. Integrating services across a business should not be that much work. Although I don’t know what specific conclusions can be reached about this fact, t is interesting that BEA and IBM, two big enterprise committee members, decided not to vote for the spec.

In a dramatic departure from my previous stances, I am going to go out on a limb and say that Ruby and Rails maybe is capable of delivering most of what Enterprise Java is actually used for and at a dramatic savings in time. I have been reading up on the framework, and I have been very impressed by the power of the conventions-based framework. I see concise, understandable code and lots of freebies. I understand and sympathize with some of the pedantic arguments against Rails. However, that those concerns don’t seem to actually exist as real issues with most real Rails projects indicates to me that most developers who think they are doing Enterprise development actually aren’t.

The features are compelling. You want persistence and you get ActiveRecord. You want MVC and you get a convention-based file/folder and class structure that outlines the distinct responsibilities of the code. You want web services and you get to choose between REST and SOAP (with the simplicity of REST being preferred). You want transactions and you get to choose between service-like transactions that can roll back database state or Object-based transactions that roll back database AND object state. Scalability is all about load balancing your server tiers.

Listen, I don’t think I am ready to be a Ruby on Rails evangelist, but I can’t help but wonder why some of the commercial projects I have worked on have not employed it.

For those who aren’t ready to throw away all their Java infrastructure, I am very impressed with the Grails framework as well.

I love the Spring Inversion of Control framework, mainly because every time I think it should do something, I find out that it does.  I came across a situation today where I needed to make use of the value of a property as the basis for a setter on a bean.  Really, what I needed was a way to copy a property from one bean to a property of another bean.   I found that I could use PropertyPathFactoryBean to create a bean with an ID of bean.propertyName and a class of PropertyPathFactoryBean.  When that bean was passed in to a setter in the destination object, the typing was seamlessly handled.

Maybe knowing a specific use case would make the power of this all the more obvious.  What I was trying to do was set a URL on a business domain bean to a URL derived by calling getURL() on a bean that implemented the Spring Resource interface.  I want to keep my domain objects free from any Spring API dependencies, and this approach allowed me to use the power of the Resource interface (and the various provided Spring implementations) without making my code dependent on Spring.  All the power, none of the baggage!

Super Tuesday is about the biggest non-issue of my week. Although the Kansas Democratic Party is holding their caucus today, that doesn’t impact me because I am one of the Other Guys. Republican? Yes, on paper. However, the only Republican candidate that I could actually see myself getting behind in this upcoming election is Ron Paul. Unfortunately, by the time the Republicans cast their votes in the Kansas caucuses, all the front runners will be pretty much set.

If you haven’t heard of Ron Paul, I can’t really blame you. He defies all the worst characteristics of both major political parties and represents the best ideals of both. What is it that both parties abhor? He believes in small government. The Republicans can’t stand that he might threaten their unconstitutional power-grabbing in the name of national security. The Democrats are terrified that he might eliminate all their precious and equally unconstitutional federal programs that rehabilitate alcoholic yaks, provide free condoms to elementary school students, and ensure that no art museum is without plenty of abstract nude paintings.

Critics would say a vote for Ron Paul is a throwaway vote. At least I could sleep with a clear conscience afterward.

I have tried starting a blog several times before, but I have never really been able to keep it up.  Maybe this is the time.  Or not.  But I am trying a few new things.  Previously, I tried the WordPress blog engine that came installed with my web hosting package.  It was pretty limited in functionality.  Of course, being the geek that I am, I thought it would be a good idea to code out my own XHTML, build my own database schema, write my own blog management interface, etc.  Okay, that was dumb.  So now I have installed the latest and greatest WordPress myself from the tarball.  Now, I am not pulling out my hair about configuration and code I can’t modify, but I am not writing my own blog engine either.  This should do nicely.