Neal Ford Pushes For Jargon
Neal Ford of Thoughtworks gave the opening keynote speech at The Server Side Java Symposium this week. His talk was mostly to urge Java developers to look at expressing programs using simplified nomenclature. He pushed jargon. He had a bunch of examples of useful jargon. For instance, the StarBucks jargon of:
"Iced decaf triple grande vanilla skim with whip latte."
In this example there is not reference to this being coffee. You are already in StarBucks so you know the context is coffee. Java developers that do not use jargon wind up with code like this:
Coffee latte = new Coffee(Size.VENTI);
Neal told the audience, "Once we establish context, additional references to the context are noise." An alternative way to express the above code is: Coffee latte = new Coffee().lowfat().nowhip().hot().strong(); Neal points out that there is no framework needed to achieve the above. Instead the example uses mutators that return this. Neal also covered domain specific languages (DSL.) He includes the use of XML as a DSL. Neal made the point that while these DSLs and the use of XML may look like a good thing from the outset, they are often prone to spin out-of-control as the DSL needs to expand to support uses over time. For instance, Neal pointed to using Groovy to implement DSLs that are more like natural language and carry more meaning when reading a command: recipe.add 1.pound.of("flour") Neal paints Sun as the drug pushers in a kid's playground. He showed a picture of a playground with the words:
The first one is free.
I found this very funny and biting at the same time.
Convincing Management That Testing is Important
After Neal's keynote I gave my talk on "Unit Testing in Java" to a full room. I suspect the TSSJS producers had me talk next to set-up the day's test and performance talks. My talk avoided the normal drill-down on how to unit test – I'm not an expert at unit testing - and highlighted the eco-system that has grown up own unit testing. My personal favorite is repurposing unit tests written by developers as functional tests, load and performance tests, and business service monitors. The idea is to let testers and IT managers reuse a software developer's expertise at building unit tests of their code. I propose adding Data Product Library (DPL) capabilities to a unit test to provide operational data at runtime. For instance, a unit test of a sign-in page of a Web site needs the id/password operational data provided by a DPL. Additionally, the unit test needs a protocol handler library to speak the native protocol (such as HTTP) to the service under test. By orchestrating a sequence of unit test calls we repurpose the unit test into a functional test. And by running the sequence in multiple concurrently running threads we repurpose the unit test into a load and performance test.
My slides are available at http://downloads.pushtotest.com/200803/TSSJS08_UnitTestingInJava.pdf
I talked about building a Quality Engineering Process (QEP) within a Java shop to provide test automation and continuous testing for an organization. The idea is to have the typical ANT build script compile an application and automatically schedule a set of tests with a QEP system. We see PushToTest customer's needing to operate tests automatically but only when the test resources are available. Like many organizations the test equipment is often not the same as their production equipment and often the test equipment is tied-up and unavailable. A QEP system delivers a scheduler, repository and dashboard for running tests. The scheduler detects when the test equipment becomes available and runs the test.
The talk elicited several questions about the most effective way to successfully get an organization to adopt QEP and unit test repurposing. My advice is to get your organization to adopt a test-first strategy. This builds the unit test creation into the development schedule and avoids the "we ran out of time to test" syndrome.
But I was hearing in these questions a tougher issue: How do I convince management that testing is important? Several attendees came up to me afterwards with an exasperated look on their faces. I recommended that they take the PushToTest 3-Day Test Automation Bootcamp
to learn our QEP methodology and get hands-on experience using soapUI, Selenium, TestGen4Web, and TestMaker. We had AMD at our last Bootcamp and the test architect brought his manager along too. By the end of the Bootcamp the manager knew the approach to testing, how much time to budget for tests, and how test automation makes testing a low-impact part of building and releasing software and services.
Description Language Debate Continues
In Mark Hansen's talk "Building RESTful Web Services with JAX-RS" an attendee asked, "Why is there pushback on REST adopting a description language?" SOAP has WSDL and Sun is promoting the Web Application Description Language (WADL) for REST. Hansen answered the question by describing two types of user.
REST is great for applications where a group needs to quickly build a user base. For example, building an on-line community, an open source community, and a social networking site. For these, scripting languages like Python, Ruby, PHP and Java in this domain are appropriate. Mark said that these applications were mostly mashups. More importantly Mark said in this domain delivering the application with bugs is acceptable. The goal is to build the user base quickly. Bugs are acceptable because the application benefits from community support and the bugs that show up are low cost to solve. Mark said you do not want to worry about data types and message service interface definitions. He told the audience that some really big sites are built that way but did not give an example.
In the other camp, Mark talked about mission critical business application where functions that blow-up are the cause of very big problems. In that camp you have a smaller number of developers that need clear interface specs, clear unit tests, clear operations plans. In this case Mark told the audience that it makes sense to use SOAP and WSDL.
Mark went on to talk about JAX-RS to build REST-style service interfaces. One interesting point Marc made was about annotations. Mark told the audience that the JAXB group, the JAX-RS group, and others at Sun need a way to express annotations externally where you can't easily recompile the code. Mark indicated there is a lot of talk about doing this and he is expecting a way.
Ruby On Rails On GlassFish On Java Looks Solid
Arun Gupta of Sun showed Ruby on Rails running on JRuby on GlassFish. He told attendees to get the JRuby on Glassfish module from the Glassfix download site. The module comes with JRuby 1.0.3, Goldspike, and Rails 1.2.6, delivered as a WAR file.
Arun recorded a screencast to show how to install and run JRuby on GlassFish
. Then you download and run Rails from the native JRuby environment. The JRuby team at Sun has been at work for the past year on this and the ROR demo looks solid. Still no official word from Sun on providing an official release and Sun support.
One-liners I heard in the hallway:
Everyone is supporting JAX-WS except for IBM.
Appcelerator and WaveMaker are doing just what jMaki already does.
Web Application Description Language (WADL) is not part of the JAX-WS JSR.
JRuby final release candidate out now, expect JRuby release at JavaOne.
Glassfish app server starts in 863 milliseconds. Less than 1 second is great.
Asynchronous Web services with callbacks are better suited for OpenESB than JAX-WS.
Amazon's REST interface to EC2 is an insult to REST in 2008.
Avoiding ESBs and Developer Disappointment in BPM Tools
Brian Slettin of Zepheria
lead a talk titled "Staying Off the Bus: SOA Strategies Without ESBs" that could have been better described as "I'm tired of waiting for vendors to give me a decent Business Process Management (BPM) platform." Over the years most of the platform vendors have tried to provide the Java development community with set of products, best practices, framework, and code to implement applications that deliver business flows. I sensed a lot of anger and disappointment at all the failed attempts, including JBI, JEMs, BPEL, SCA, and WS-*.
Metro Web Services Stack
, Senior Staff Engineer, Sun Microsystems gave a talk on the Metro Web Services Stack
. Metro is a high performance SOAP stack for Java.
Back in 2002 I found that the first generation of SOAP stacks were not scalable and I published my findings
. People would ask me the cause of the scalability problem and I told them that the marshalling/unmarshalling tasks that SOAP stacks need to perform to move in and out of the Java object environment was the biggest problem. Kohsuke's talk was a refreshing and well though-out discussion of all of the performance issues and the Metro architecture to get around the issues.
Kohsuke told the audience that Metro defers the XML binding to as late in the marshalling process as possible. XML arrives as InputStream. Their validator wraps a SOAP message in an object but avoids parsing until later. Metro databinding reads XML in SAX where parsing and validation finally happens. The output is a data binding into POJOs.
Metro provides a "handler" that uses AOP messaging techniques in SAAJ, XML read into DOM here. Then a Databinding method reads XML in SAX with a visitor walks over DOM and generates SAX events. Internally the Metro stack uses InputStream, XML stream buffer, DOM/SAAJ, and JAXB POJOs to represent the data internally. Kohsuke spent the rest of his time talking about what they have found are lighter and heavier in their demands for resources and processing time. Many times the choice that requires buffering or a non-streams approach is much slower. For example. Kohsuke told the audience that Metro does Encyrption/Decrypt, Signing/Verification in a streaming fashion, but that these require buffering. Kohsuke said that cryptography is still very costly. Additionally, he told us that Dump is streams-based but requires buffering and validation requires streaming. Kohsuke told us WS-Reliable Messaging and Secure Conversation requires buffering. WS-AtomicTransaction, no conversation however additional round-trips
Handler requires a DOM conversion and this is very expensive. Kohsuke told the audience this axion: "Pick 2 out of 'fast', 'portable', and 'easy'." There is always a trade-off. Kohsuke finished by telling the audience that they are still working on scalability. He said horizontal scalability (aka clustering) is trivial if you don't use stateful web service protocols like WS-AT, WS-RM. He also said his team is working on an AsyncProvider to do call-back based request/response.