Handy JDeveloper utility: the Http Analyzer

One of the useful little tools included with JDeveloper is the Http Analyzer, accessible via the View -> Http Analyzer menu option.

The Http Analyzer acts very similar to a network packet sniffer, allowing you to capture and inspect HTTP request and response pairs sent between a web client and web server.

One example where you would use the Http Analyzer is when developing ADF Faces applications in JDeveloper, where the Http Analyzer is sniffing the information flowing between your browser and the active FacesServlet in the Embedded OC4J. You can also use it between any web client request on your machine and any web server anywhere assuming you can normally connect to the service via your browser/local-machine.

There are other Http Analyzers out there, but given with JDeveloper its free and you don't have to download and install yet another tool.

Starting the Http Analyzer

I'll describe a typical scenario in developing an ADF Faces application and using the Http Analyzer to help describe how it's used.

I have an ADF Faces web application that is currently running in JDeveloper and displayed in my local browser at the following URL:

http://127.0.0.1:8988/HttpAnalyzerDemo/faces/editEvents.jspx

http://127.0.0.1:8988 is the port number the Embedded OC4J is currently listening on from my localhost. Accessing this sub-URL directly in my browser displays the Welcome page for the running Embedded OC4J server. The Embedded OC4J port number can be changed via the Tools -> Embedded OC4J Server Preferences menu option, selecting the Global -> Startup dialog options, then the HTTP field.

Next we open the Http Analyzer window via the View -> Http Analyzer menu option:

In order for the Http Analyzer to work we need to start a listener process, by selecting the Start Http Analyzer button (the green arrow button) in the Http Analyzer window. By default this will start the listener on your localhost's hostname on port 8098. These default settings can be changed via selecting the New Listener button in the Http Analyzer window:

In this example you can see the Http Analyzer listener process will be listening at the following URL: http://acute:8098 .... where acute is my localhost name. In turn the listener options configure any request to this URL will be redirected to the Target URL: http://127.0.0.1:8988

As this is the URL of my running Embedded OC4J server from previous, any access to the Http Analyzer listener at http://acute:8098 will be redirected to the Embedded OC4J URL at http://127.0.0.1:8988

Note when you run the Analyzer you may see a warning message. I'm still not sure why this message displays as the Analyzer appears to work regardless.

Now with the Http Analyzer listener running, if I change my original URL in my browser to use the Http Analyzer instead and load the page:

http://acute:8098/HttpAnalyzerDemo/faces/editEvents.jspx

....I see two effects. First the ADF Faces web-page is correctly displayed in the browser from this alternative URL, and secondly the Http Analyzer window is now showing my first Http request-response as requested by my browser, and served via the FacesServlet running in my Embedded OC4J.

Using the Http Analyzer

This layout in the Http Analyzer is by default the history view. As you interact with your application through the browser, a number of request/responses in chronological order will display in the Http Analyzer history view.

The history view reveals a number of interesting elements:

• Call Time - the total time of the request/response in milliseconds
• Method - the type of Http request/response method
  
• Url - the specific URL that was requested
• Query - dunno
• Cookie - any cookies passed between the client to the server
• Status - the Http error code
  
• Set-Cookie - any cookies set by the server and passed to the client
• Type - type of request, for example Html, Images etc
• Size - the size of the response in bytes

From here you may select a specific request/response and switch the Http Analyzer into the data view. You do this by double clicking on one of the entries in the history view, or selecting the Data tab at the bottom of the Http Analyzer window.

The data view is divided vertically into 2 areas, on the left hand-side the request sent from the client to the server, and on the right hand-side the response from server to the client.

If for both areas the Show Headers checkbox is also checked, the window is further divided horizontally showing on top the Http header information passed between the client and server on each request/response, and on the bottom the actual data body of the Http request or response between the client and server respectively.

Further to this the data represented on the client or server side can be represented differently visually by selecting the View dropdown on each side. Its options include:

• Content - displays a visual representation of the data packet passed in the request/response -- for a Html page it will show a visual representation of the Html components, or for images the actual image itself.
• Raw - displays the pure data flowing backwards and forwards as text
• Hex - shows the data as hex values

Personally I find the Content and Hex views less useful than the Raw option when viewing a Html request/response. However the Raw option doesn't wrap in the Http Analyzer window making it poorly readable, and I typically copy & paste the Raw text data into my favourite text editor with wrapping turned on to read the response.

Interesting things to do with Http Analyzer

So why is the Http Analyzer useful? Some uses include:

1. Recording a history of request/responses to detect and replicate bugs
2. Analyzing the time taken for a request/response on a particular page
3. Analyzing the size of a page and its effect on client's with slow internet connections
4. Inspecting and detecting issues with the Http request/response headers
5. Estimating the bandwidth required for a popular page requested by your application
6. Detecting unusual error conditions returned by the server beyond 404 Page not found
7. Analyzing issues where the client POST request is terminated 1/2 way

.... also, and not discussed here, the Http Analyzer can be used for debugging Web Service calls, and actually modifying the Soap packet.

I'd be curious to know what uses others have found for the Http Analyzer. I've seen some particularly tricky debugging made simple by this tool.

Further documentation

The Http Analyzer documentation is not well indexed in Oracle's JDeveloper online documentation. Rather than searching for entries under the online Index help option, instead under the help Search option, search for "Analyzer" to find more documentation, including the "About the Http Analyzer" help page.

Other JSF component vendors

If you've been playing around with Oracle's ADF Faces for a while you'll probably become curious at some stage about what other JavaServer Faces (JSF) component sets are available out there. The AJAX JSF Component Feature Matrix site gives a good comparison of the other component sets that are available and the vendors or open source efforts behind them.

You'll note that ADF Faces is listed as project Trinidad. I guess as Oracle's and the Apache project diverge the matrix may end up having a separate list for both, but for now it's all under Trinidad.

One of the nice things you'll note about ADF Faces is that the component set is comparable to other's solutions. Oracle's JDev 10.1.3 ADF Faces release nearly 1.5 years ago put them way ahead in the JSF game. Here's hoping the next major release of JDeveloper will see them leap ahead again.

Just a small caveat that not all the component sets are compatible. For example ICEFaces and ADF Faces components will not work on the same page as ICEFaces requires its own ICEFaces specific treeroot view tag, which doesn't support ADF Faces components. However in this specific case you are free to use either component set on separate pages (though the look & feel of your application would be a little crazy). If you are thinking of using components from 2 vendors ensure to do some research to see if they can work together.

The future of JSF continued

For those who are interested in the future of JSF, and by inference ADF Faces and JDeveloper, the debate continues on the upcoming JavaServer Faces 2.0 spec beyond Ed Burn's original blog post. More links to the JSF 2.0 debate across several sites can be found from the JSR draft. You'll note Oracle's staff are watching some of the threads with Adam Winer from Oracle giving input on TheServerSide.com thread.

Why is this interesting? So far in the 1 and a bit years I've been working with JSF through ADF Faces, I can't say I've been immediately aware when there has been a limitation in ADF Faces or alternatively a limitation caused by the JSF spec itself imposed upon ADF Faces. The boundaries appear blurred. Now seeing the 2.0 proposals, a couple of AU$0.01 have dropped and I now realise why some features haven't been well implemented (such as page templates), and where Oracle has excelled (such as themes/skinning, extra components that others wish were in the base spec), among other concepts.

AUSOUG/OAUG Australia 2007 Call for papers

Of course if you love cold weather, warm beer, and think the Queen is a hottie, the UKOUG 2007 conference is the Oracle event to present at this year, during the bleak and horrible weather experienced by the Northern Hemisphere in December. Yeeeeeeeeeees-sir-e, I believe due to global warming even Oracle's own Open World San Fransisco conference is advising delegates to bring snow shoes and a double wind proof jacket this year.

Mind you, if you think global warming should actually entitle you to warm weather at an Oracle conference, you enjoy a cold beer or 2, you like to present in a country that fence-sits by having a monarch and being a (near) republic, why not head south this year to sunny, lovely, balmy & dry (did I mention dry?) Australia, for the 2007 conference in November? (Besides the fact it's a 16 hr flight from anywhere of course, including New Zealand).

This year the Australian Oracle User Group (AUSOUG) and Oracle Applications User Group is running with its two Australian city Oracle conference series again:

• Perth 20th/21st November
• Melbourne 26th/27th November

And remarkably given the hard work by the AUSOUG staff the call for papers is already out, with a deadline of the 4th June.

So if you like presenting up close and personal with local members, rather than the hordes at the Northern Hemisphere events, why not consider Australia's fair shores for a bit of, um, well, you can tax deduct it too can't you? And bring the family. Or avoid your pending deadlines I guess.

Hope to see you there, or here as the case might be.

(PS. With apologies to our UKOUG and OOW colleagues. I'm sure it won't be all that bad at your events too - I wish I could come ;)

Part 2: Demystifying ADF Faces black magic - component behavioural interfaces

In part 1 of this post we looked at how to categorise components, in particular looking at their base JSF classes. In part 2, we'll look at the concept of component behavioural interfaces.

The JSF specification states that JSF components (or more specifically their classes) can implement one or more behavioural (Java) interfaces, or in other words standard behaviour functionality. There are effectively only 5 types within the JSF spec. Knowing this you can surmise the functionality of each component; if something works for 1 component with a specific behavioural interface, it should work for the rest:

• StateHolder – describes a component that has state and must be saved between requests, or in other words, multiple request-responses of a single user session. UIComponent implements StateHolder, thus by default all JSF components implement this behaviour.
• ValueHolder – a component that can access data from a data model tier and also maintain a local value. Both UIInput and UIOutput implement this interface.
• ActionSource – allows the component to fire an action event via a registered ActionListener calling a backing bean method, upon a submit to the mid tier. This is used by submit UICommand buttons and similar controls (such as the ADF Faces menu components).
• EditableValueHolder – an extension of ValueHolder allowing validation and raising value-change events via a ValueChangeListener.
• NamingContainer – requires each component and child component to have a unique ID.

Notably it's the ActionSource and EditableValueHolder behavioural interfaces along with the JSF lifecycle that give JSF its events based model similar to Swing, not too dissimilar to Oracle Forms trigger-event model, and totally abstracted from the traditional (and complex?) HTTP request-response programmatic approach. The user clicks on a button.... an ActionListener captures the event and fires off a backing bean method to do some work specified by the programmer. Couldn't be easier than that!

Oracle has taken the behavioural interfaces further, and implemented 2 additional behavioural interfaces:

• CollectionComponent - any component such as UIXTable that pages across records and is useful when screen real-estate is limited or you want to stop the user querying all records in 1 hit. It starts at a particular index in a row set, and includes the number of records to show on each page.
• DialogSource - any component that opens a ADF Faces dialog, and in turn needs to be notified when the dialog closes. An extension of ActionSource and notably used on UIXCommand controls. Includes listeners for passing values to and from the dialog.
  

Again in summary it can be seen that JSF or ADF Faces components are ultimately served by a set of Java classes that plug into the JSF framework. Understanding the classes, how they help categorise the components, including their functionality, and showing similarities, can help your understanding of the plumbings of the JSF components.

Part 1: Demystifying ADF Faces black magic - component categorisation

JDeveloper's JSF design editor makes including all sorts of JSF and ADF Faces components, by drag and drop via the Component Palette, or pure tag coding in the code editor a breeze. What the Component Palette doesn't easily convey is that JSF components can be categorised in a number of different ways and are serviced by a number of Java classes. In fact the whole game looks like black magic unless you bury your head under the magician's table cloth to see how the plumbings work.

Understanding the categorisation and class structure can grow your overall understanding of the JSF framework, including the interaction of its components, the JSF lifecycle, and possibly make debugging an exercise in "ah, that's why that's called" rather than "where the heck am I?", "why did it call that?" and "what voodoo is this?"

Components can be categorised in 2 manners within JSF:

1. Standard UI Components
2. Behavioural interfaces

For this "part # 1" post we'll consider the 1st category, and will consider the 2nd category for a later post "part # 2."

The JSF specification defines a number of User Interface (UI) component classes that the majority of standard JSF UI components derive their functionality from. At runtime the JSF UI tags interact with instances of these classes through the attributes the programmer utilises on the JSF UI tags.


All components in JSF inherit from the UIComponentBase which in itself extends UIComponent. At runtime the UIViewRoot contains all the UIComponent instances that make up your JSF web page, essentially a tree of components, and indirectly maintains their state between HTTP request-responses for a particular user session.

Why 2 classes?: UIComponent and UIComponentBase? UIComponent defines all the methods that any subclass component should have, while UIComponentBase takes this further and provides methods and implementations of certain methods that JSF component developers can make use of as a convenience factor to save some coding. For the majority of programmers we wont be doing this, so the other standard JSF UI components that extend UIComponent are what we'll discuss here:

• UIViewRoot - each JSF web page is represented by a tree of UIComponents (with the subclasses as defined in this bullet point list), that at design time you coded in a .jspx file. The UIViewRoot is central to the JSF lifecycle and its associated phases. The JSF servlet for each session takes care of instantiating the UIViewRoot and its subcomponents, applying any values changes if submitted by the user, as well the state management of components between requests, data validation, data conversions and other work. All these steps commonly referred to as the JSF lifecycle are a separate discussion to this post. However the basic understanding that each web page per user session is represented by a UIViewRoot which can be accessed by the programmer is a worthwhile consideration.
• UIData - simplistically a table control containing one or more UIColumn components. The UIColumn components and subcomponents are rendered a number of times dependent on the number of rows stored within the UIData's DataModel instance. Put another way, the UIData control is a for-loop construct that for every row in the relating DataModel, will display one set of UIColumn component and subcomponents.
• UIColumn - in conjunction with the UIData component, a UIColumn represents a single column within the UIData table component. For the UIData DataModel that represents a number of rows, the UIColumn is bound to one item within each row, and the UIColumn is displayed for each row. This means a DataModel with four rows will result in a single UIColumn rendered four times.
• UIForm - very similar to the HTML form tag, a UIForm component represents a collection of child components that upon submit via a UICommand component, any input control values also submitted to the mid-tier. In other words submittable components must be placed within a UIForm within the overall UIViewRoot.
• UICommand - a component within a UIForm that when selected by the user forces a submit of the page to the mid-tier, such as a button, hyperlink or menu item. In addition behind the scenes within the JSF world may trigger a backing bean method or other code to perform an action.
• UIPanel - components that are responsible for laying out other components. These can be very simple from laying subcomponents on a horizontal or vertical plane, to placing the components in relative positions (top, bottom, left, right etc), to complex components that possibly represent menus with predefined graphical elements. Panel controls make heavy use of facets to lay the subcomponents out.
• UIOutput - any component that holds and displays a value. An output component is read only so inherently the user cannot modify the value.
• UIInput - is an extension of UIOutput. It holds and displays values, but also allows the user to modify the value which is submitted to the JSF mid-tier for processing, including validation, conversion and storing in the model tier. Unlike the UIOutput tag, the UIInput tag is inherently editable by the user, or in other words not read-only.
• UISelectBoolean - a type of UIInput control that allows either a true or false value, ultimately rendered as a checkbox or on/off button.
• UISelectOne - a type of UIInput control that displays a list of values, be it a poplist or multi-item list, where the user may select zero or one value and at most one value only.
• UISelectMany - a type of UIInput control that displays a list of values, allowing the user to select zero, one or multiple values.
• UIGraphic - a read only component that displays an image to the user.
• UIMessage - a component designed to show any error message(s) for a specified component. You see this in the web-world often when you fill out a form, press submit, and the page redisplays showing error message under each component where you didn't meet a specific validation rule.
• UIMessages - displays all error messages regardless of components in one spot. Again this is commonly seen in the web-world where after filling out a form, a stack of errors is shown at the top of the webpage telling you what you've done wrong.
• UISelectItem - a child of an UISelectOne or UISelectMany, represents an individual choice of the select controls.
• UISelectItems - a child of a UISelectOne or UISelectMany, which derives zero, one or many choices for the select controls. Specifically this control must reference through its value an array or Collection of UISelectItem instances, or a Map.
• UIParameter - a subcomponent for a parent component, that adds any parameter values (name-value pairs) that the parent component needs to complete its execution, just like calling a procedural method requiring parameters.

All the above component types are defined under the JSF spec v1.1 and are available to any JSF implementation, thus why they are a "standard" set. JDev 10.1.3.x uses the JSF v1.1 implementation.

What about ADF Faces though? Isn't ADF Faces Oracle's extension of JSF? Well yes it is.

An inspection of Oracle ADF Faces components reveals a couple of interesting things.

All the classes stored within oracle.adf.view.faces start with the prefix UIX, such as UIXInput and UIXMenu.

Why? Well this shows the roots of ADF Faces and why Oracle is considered experts in the JSF component writer community. UIX harks back to earlier versions of JDeveloper and stood for User Interface for Xml, specifically a web component technology. Web component technology huh? .... doesn't this sound familiar?

When JSF came along Oracle saw a strong match between UIX and JSF, and given the standardized nature of JSF, a good opportunity to upgrade their existing component technology to an industry wide initiative that others could adopt rather than a proprietary technology with the Oracle branding. In fact Oracle has been a key contributor to the JSF spec and their finger prints can be found in a number of JSF areas (among others, check out Adam Winer's work). And their recent-ish donation of the ADF Faces code to Apache under the codename Trinidad shows Oracle is willing to put their money where there mouth is when openly supporting open-source initiatives.

In developing UIX Oracle had learnt a significant amount about web component technology, so much so that in delivering ADF Faces, it can be seen that the ADF Faces heavily extends the base JSF component set with a whole range of extra goodies, ah, components that Oracle deemed necessary. And who are we to argue because a) Oracle is developing these for its own web-enabled applications such as EBS 12, and b) thank goodness we don't have to write these components ourselves.

This leads onto the 2nd revelation when looking at ADF Faces: Beyond the standard components which Oracle has implemented themselves, there are a large amount of additional ADF Faces component types and associated classes. In fact there are so many that the following class diagram really can't be shown without shrinking it right down (and apologies on my part I can't make this more readable):


There are just too many components to list; however we'll list a few of the key additional ADF Faces components over that supplied in JSF:

• UIXHierachy - base class for any component representing a tree hierarchy, such as menus, trees, tree-tables etc.
• UIXMenuHierarchy - deriving UIXHierarchy, the set of menu components that display menus with different levels of command options.
• UIXTree - also deriving UIXHierarchy, a component that visually represents a tree on the web page.
• UIXChoose - any component that presents a diagram to the user that they can choose an option from (such as a calendar control), rather than a poplist type approach.
• UIXCommand - similar to the UICommand component in JSF, except also includes support for ADF Faces dialog framework.

Within Oracle's JDev doco is a discussion of how their component tags differ from the JSF spec. While this doesn't mention the component classes directly, it isn't too hard to extrapolate the changes between the component classes:

So in summary we can see that be it JSF or ADF Faces components, or any other JSF component set for that matter, the mechanics of the components are ultimately served by a set of Java classes that plug into the JSF framework. As such how component behave and what they do is not black magic, and given a better understanding of the JSF component framework, your success as a JSF programmer will be increased.

In part 2 of this post, we'll look at the concept of behavioural interfaces and what they provide to each component set.

Geeking it up with data visualisation

Okay, call me a sick puppy, but I was researching data visualisation techniques the other day, and stumbled across the following graph facility. Make sure you type in a name to watch the display change.

And just to show I wasn't looking up my 12 week year old daughter's name, this was the original digg post that led me there. The graph facility appears to be the work of Martin Wattenberg, a data visualisation expert at IBM. Officially "wow".

Bar graphs are now sooooooooo 2006. Oracle, any chance we might see some of this sort of stuff in EBS 12?

Oracle Aussie & APAC Unbreakable Linux action - media reports regards Oracle's local success & failures

For the Aussie and APAC readers, it appears Derek Williams, the chairman and exec VP for Oracle Asia Pacific (APAC) and Japan, and Brian Mitchell, senior VP for Oracle APAC, have the ear of some local reporters, as there were a number of posts regards local Oracle activity today, including the success/failure of Unbreakable Linux in the local market.

I can't quite work out if the reports are a source of a media release, or which news service has syndicated who, however the reports are none the less are interesting because they're local.

• Aus stockbrocker picks Oracle Linux support - ZDNet Australia's Steven Deare

The following are referring posts that link back to ZDNet's articles but include some minor further discussion:

• Oracle Unix adopters labelled 'idiots' - builderau.com.au
• Oracle yet to tip Red Hat - builderau.com.au

There's also one other report regards APAC Oracle activity:

• Oracle sees strong growth in Asia Pacific Region - iTnews.com.au

Does anybody else have an online source of local Aussie and APAC Oracle activity?