Apache Wink and JAX-RS

I've received a number of questions from customers on IBM and JAX-RS support. I wanted to mention to interested parties that IBM started an Apache Incubator project (Apache Wink) with HP and others on building an open source JAX-RS implementation. JAX-RS (if you aren't aware) is JSR 311 - the JCP defined standard programming model for building REST-based services. You can check out the original proposal (here) and the project site (here) and lastly, the project Wiki (more useful) (here). Lastly, we've started a "WebSphere Web Services" specific blog (here) where we will be discussing features, capabilities, and other items going forward... This post (here) talks about some of the capabilities in their first (and fairly complete) release of the incubator project that was just formalized today.

Take a look...

On Twitter?

A couple of us have an active presence on twitter if you use it. Andrew Spyker (@aspyker) and I (@burckart) are both pretty active as are some of our product managers like Savio Rodrigues (@SavioRodrigues) and Erik Kristiansen(@erikkristiansen). Another great person to follow is Billy Newport, (@billynewport), our WebSphere eXtreme Scale architect. Feel free to reach out to any of us on twitter.

Information Center for XML Feature Pack Beta Posted

In software development, it's not just about creating the runtimes and API's and install images. As a customer, information to help understand how to use the features of any product is as important or more important than the product itself. This is why we've spent so much time on creating samples for the XML Feature Pack. Today we go a big step further by releasing the XML Feature Pack Information Center.

The Feature Pack for XML Information Center is comprehensive documentation on the XML Feature Pack. The content of this documentation is live and can change as we get more information articles. If there are features you have questions on, please let me know and I'll ensure we consider updates for future updates. Also note that we have moved the Javadoc for the API to this information center.

What's going on with Communications Enabled Applications?

We have had a lot of activity on the WebSphere Communications Enabled Applications blog. I have had several blogs highlighting scenarios from retail to finance to inventory management. I even came up with another one of my non-award winning videos here describing the customer experience the CEA Feature Pack can bring to a website.

Beyond that, there has been a whole bunch of information presented and I wanted to give you all a quick summary and reference to some of those blogs.

First, Roger wrote a great and verbose cheat sheet in PDF format on how to get up and running with the CEA Feature Pack and Plants by WebSphere sample. If you are looking to try it out, his document is a great place to start.

James has written some specific details on which version of vendor systems we tested our CEA Feature Pack against. He also wrote a more in depth piece on how to configure the feature pack to work with Avaya AES.

Andy wrote some getting started and advanced usage blogs on the Web 2.0 widget capabilities in the CEA Feature Pack. To get started, he wrote a blog on embedding the telephony widgets like click to call and embedding the peer to peer cobrowsing (aka coshopping) widget. He also wrote several more advanced blogs on how to create a two way form, how to handle personalized content and actions in cobrowsing scenarios, and how to add CEA widgets to a page already using another version of dojo.

Finally, we had our first guest blogger. Dustin Amrhein tried out the feature pack for the first time this week and found good ways to easily extend the Web 2.0 widgets included. He wrote his first blog showing how you can customize the click to call widget to add the ability to select a specialist. We are looking forward to him writing several more blogs on the other scenarios he tried out.

Other XML Feature Pack Beta 3 Highlights

Yesterday I blogged about one of the major focus areas of the Beta 3 of the XML Feature Pack. In today's video demo, I show the other major items of note in Beta 3. The major features of Beta 3 are:

- Spec complete on XPath 2.0, XSLT 2.0, and XQuery
- Changes to the XML Feature Pack API to adjust for new features and results of usability studies
- Focus on development and deployment issues with full command line support to pre-compile XML artifacts for performance, ANT commands to do the same, and support for running with Java 2 Security enabled.
- As always, more samples. In addition to the end to end sample of XQuery I demoed yesterday, we have over 40 samples that show the new features of the new standards.

Here is the video that overviews these features:

Demo 6 - XML Feature Pack Beta 3 Highlights

Direct Link (HD Version)


For more information on the WAS V7.0 XML Feature Pack Beta, please go here to download the code, samples, documentation as well as see other demos.

XQuery End to End Sample for XML Feature Pack (Demo #5)

So far in the XML Feature Pack demos, I have talked about topics such as the introduction to the feature pack, specific features in how to use the feature packs, and demonstrations of XPath 2.0 and XSLT 2.0 in end to end web applications. Today I'll continue the demos building upon the same application used in previous demos - the Blog Comment Checker that mines data from blogger.com feeds (encoded in XML) and presents a web application that identifies problematic user supplied comments. I hope you'll see how different XQuery is as a language and how similar it is to concepts you might already know like SQL and JSP templating. I imagine, for some users, the learning curve of XQuery won't be near as steep as other XML processing languages.

Demo 5 - End to End XQuery 1.0 (Part 1)

Direct Link (HD Version)

Demo 5 - End to End XQuery 1.0 (Part 2)

Direct Link (HD Version)

Download Stats Extreme Makeover - The Value of XSLT 2.0 and XQuery 1.0

On Friday, I had the opportunity to use XSLT 2.0 and XQuery 1.0 in a way that proved the value of the new standards.

For our Beta programs, we get a weekly report of how many downloads have occurred. Over time we have asked for more and more breakdowns of the data (how many were from IBM'ers vs. non-IBM'ers, how many were from non gmail/hotmail/etc email addresses, how many for code vs. how many for documentation, how many unique users have downloaded, etc.). We use these reports to gauge the interest in our betas and the effectiveness of our beta programs.

Currently the process for doing these reports is:

1. Load a webpage somewhere on the intranet that returns in either HTML or space and newline separated text the download records (and I don't have the time nor contacts to change this "service").
2. Import these download records into Excel
3. Write VBScript that processes the rows into summary tables, but not all summaries have VBScript written for them due to the fact that VBScript can get quite complicated.
4. Read the summary tables and hand compute some summaries and transpose them into emails and presentations to beta teams.

This process can take a few hours and is error prone.

I asked for the raw data for the service as I knew there had to be an easier way.

First I started with the HTML as its pretty much XML and I figured I could just write some simple XQuery summaries. This failed as HTML isn't XML (if its not XHTML). Don't get me started on that rant (in this case, we had things like width=-1 with no quotes)! So I restarted with the text file version of the data.

XSLT 2.0 has a new function - unparsed-text() that lets you load from text files. This allows you to load any data into XSLT 2.0, but only as a string. As the XSLT 2.0 specification shows the real power of this function is magnified by XPath 2.0's support of regular expressions. Combining the unparsed-text() with regex tokenize() with newline as the separator allowed me to for-each across every line in the file. Adding another new XSLT 2.0 function into the mix - analyze-string() with a regular expression that did capturing of each of the fields allowed me to transform each line into a well formed XML element with sub-elements for each of the fields (download element with elements for filename, email address, etc). Ah, now I have data in a well formed structured XML format. Life is good.

Once I had this transformation of the input data, I returned to the task of creating the summaries. With XQuery, any query I want is just moments away. To prove the point, I decided to write a simple query that would break down the downloads for IBM'ers and non-IBM'ers separately. I would also group each unique user and list all the downloads that user had done with summaries at all levels of how many code vs. how many documentation downloads had occured. I want to put this in XML format, so others could query my summaries or I could put the summaries into HTML or load back into Excel (if you really really want to).

It took me approximately 30 minutes to create all of the above queries. The code is approximately 20 lines long and is well designed into re-usable functions that could be customized later. The code is easy for most of my peer Java developers to understand as XQuery looks alot like an imperative language with SQL like queries mixed into templating of output.

My next step is to move this to a web application (what I did so far was prototyped it with sample data) that connects directly to the service. The web application could easily offer up web forms that allowed the user to specify search criteria supported by the back end service (date range for example) along with what XQuery/summary view was required.

There are still some items that can't be automated and need human intervention. As an example, the process of deciding what constitutes an IBM'er is complex as some IBM'ers have "ibm.com" email address and some do not. Also, IBM could be "IBM, International Business Machines, or mistyped". It would take a bit of time to create some services that approximate what a human eye could spot manually. Adding a human facing pop-up that allowed visual inspection of the automated data analysis steps would be valuable. Also, I admit that I didn't create the charts and graphs - just the raw data that could be loaded into Excel to create charts and graphs.

But in the end I have converted a manual error prone data processing scenario into an automated approach (for data query and summaries) that creates all the same valuable raw data for reports with the potential to add more reports much more quickly. All of this was made possible using well documented W3C standards that have all the needed features (some new with XPath/XSLT 2.0 and XQuery 1.0) that make this scenario possible.

Specification complete on XPath 2.0, XSLT 2.0, XQuery 1.0 - Beta 3 of XML Feature Pack Released

I'm happy to announce another update of the XML Feature Pack. The first beta focused on XPath 2.0. The second beta focused on XSLT 2.0. This third beta rounds out the specs with support for XQuery 1.0.

Once we're not in beta, we'll post final numbers on the W3C website on the XML Query Test Suite conformance. Currently we're at 96.8% on minimal conformance and we have support for the optional full axis and serialization features. As for XPath 2.0, and XSLT 2.0, we consider this beta release to support all of the specifications with minor restrictions as listed in the getting started guide. This means that we now have support for all for the W3C recommended standards for Querying, Transforming, and Accessing XML data (except the less popular XQuery/X).

We have expanded the XML Feature Pack API to handle feedback from usability studies and to handle new features required by the standards.

We have focused on items that make the feature pack easier to use. We have made changes to allow the feature pack runtime to run under Java 2 Security, without requiring an application to enable any more security than minimally needed. We have expanded the options for the command line tools for pre-compiling xml artifacts. We have also added ANT tasks for integrating this pre-compilation support into your build scripts.

With the full standards support, updated API, and runtime and development time improvements, this feature pack release should be quite useful. In the next few days, I'll post some videos to demonstrate the new capabilities on YouTube. In the meantime, you can download the feature pack beta and join the web forums to ask questions.

Another reason for DataPower SOA appliances - XML Threat Protection

I've gotten a few questions on recent XML security buzz. On today's blog post by Rich Salz (lead architect of our appliances) discussed how XML threat protection is a required tool when exposing important services to untrusted sources. He talked about this due to the recent press interest in "XML Exploits" which was started by some XML fuzzing work by Codenomicon.

I wanted to post about it here to make sure this wasn't an unknown concept to our customers. Rich talks about "defense in depth", which is what most of our WebSphere customers are doing today. To quote Keys Botzum (one of our lead security consultants for WebSphere, "Anyone that is exposing services to untrusted sources absolutely needs to be running a XML firewall, like DataPower)". In my world, defense in depth means putting a WebSphere DataPower XML Security Gateway XS40 in front of any services that could be called by untrusted sources. Also, given the performance characteristics of the DataPower devices (basically no latency impact), you likely want to do this on all services (as sometimes hacks aren't intention and sometimes hacks come from internal sources).

If you haven't heard of XML firewalls or XML threat protection, think about network firewalls. Network firewalls are great for protecting us from threats that can be detected at the network level (like the recent Twitter and FaceBook distributed denial of service attacks), but they don't help you with threats that are in the payloads of messages themselves. XML Firewalls help you with such application level threats by turning away bad messages before they enter your enterprise applications.

If you have any questions on the concept, feel free to pop over to Rich's blog and ask.

Interviews of WebSphere architects

Recently we have made a set of informal videos interviewing various WebSphere architects about the numerous advantages of WebSphere Application Server in the areas of developer and management efficiency, application innovation, and performance. These are focused on the difference between WebSphere and JBoss but also cover in detail many of the WebSphere Application Server strategical focus areas.

There are two playlists which can help you view all the videos. This playlist of WebSphere vs JBoss Developer Discussions walks through the specifics around how development is getting better and easier. This playlist covers WebSphere vs JBoss Operations discussions and covers more of the systems management side of the product.

Here is one of the videos (you'll note I didn't include one of mine ;-) ) on developer efficiency.