IT-eye

Recently I have been evaluating Oracle Business Rules (10.1.3.1) for one of our customers.
I started with the sample application, the Car Rental Sample and the Wine Demo, which you can find here
Working samples with simple data models and corresponding rule definitions.

The next step was to use a ‘real’ xml fact and corresponding schema. I loaded the XML schema using the Rules Author, imported the xml fact definitions and defined a ruleset containing a single and simple rule (calling println for an element value).

For the Rules client I generated the required java classes using the JAXB binding compiler and asserted my first xml fact.
I got an error from the Jess Rules engine, complaining about fact names containing dollar symbols. Fact names are equal to the class names that the JAXB compiler generates. And the compiler generates (for non-simple schemas) Java classes containing inner class definitions.


Caused by: Jess reported an error in routine Variable.Variable.
Message: Variable name cannot contain '?' or '$'


I hoped that removing the dollar symbols from the alias names would overcome this error, since removing dollar symbols from the real names is not an option. These names are automatically generated.
Unfortunately – but not surprisingly – the same error was thrown. The only thing that surprised me a bit was that the Rule Author does allow fact names containing dollar symbols.

I decided to use Apache XML beans instead of JAXB and as a consequence Java fact definitions instead of XML fact definitions. The reason is that Apache XML beans does not generate classes containing inner classes.
When running the inference engine after asserting a XML fact an error was thrown stating that the JAXB properties file was missing. So, I decided after skipping XML fact definitions also to skip asserting XML facts and to assert Java facts.

But when I asserted a Java (XMLBean) fact and run the inference engine I encounted the following error:


oracle.rules.rl.exceptions.JavaException: exception in invoked Java method
Caused by:
org.apache.xmlbeans.impl.values.XmlValueNotSupportedException: Could not get a Java Date type from a Schema complex type

It appears that XMLBeans are not applicable for the Rules engine (yet) and I decided to freeze the evaluation.

Other experiences: I started to create a WebDAV based repository using the Oracle database server Release 2. Unfortunately, the WebDAV interface appeared to be unstable, corrupting the repository. After recreating the repository several times I decided to use a file based repository.
I presume that this instability has nothing to do with Oracle Business Rules but with the XMLDB server.

Also error reporting of Oracle Business Rules is very limited. I frequently hit the following strange error message: 5}' is undefined.
My final conclusion is that the product is not really useable for non-flat xml schemas at the moment. But the potential is enormous and I can not wait to evaluate the next release!

If you enter the midtier EM website and browse to Forms -> User sessions you have the ability to monitor and trace all forms processes. By default this ability is turned off and has to be enabled by setting em_mode=1 and allow_debug to true in the formsweb.cfg and a restart. This doesn’t always work, a workaround is to go to Forms -> Configuration and click edit. Change the em_mode and allow debug here.

If you change the parameter oracle.forms.configFileName in oc4j.properties located in $ORACLE_HOME/j2ee/OC4J_BI_Forms/config to point to a different location for your formsweb.cfg the em_mode and allow_debug parameters should still be changed in the original formsweb.cfg in $ORACLE_HOME/forms/server. Oracle for some reason keeps looking for this old file.

Joe McKendrick has an interesting list of 10 companies where SOA has been successfully used in the past year: Ten companies where SOA made a difference in 2006. With a new ‘technology’ like this it’s always good to look at what works and what not, and what companies have done to make it a success.

A lot is happening regarding user interface technology. Spurred by the recent AJAX and RIA developments, many new UI frameworks are introduced. AJAX enabled JSF components can be used, or you can use JSP in combination with other frameworks like DOJO or DWR. Google WebToolkit (completely open source since this week) takes a different approach, by allowing you to code your interface completely in java, and generating all the required user interface code (html, javascript, etc). Adobe Flex is yet another option. As it’s hard to tell at this moment what will be the best user interface technology choice for the future, it’s important to keep an eye on all. Time to find out what Flex is all about.

You create Flex UIs using MXML files. A MXML file is a XML document, similar to a JSF page, which describes your user interface. Flex provides a lot of different components you can use, like buttons, datagrids, layout panels, etc. So in this sense it’s similar to JSF. Using Actionscript (Ecmascript) you can add behavior to your application. The MXML files are compiled into flash, and run in your webbrowser using a flash player. Adobe is working on a project called Apollo which will enable you to install Flex application on your computer, so you can run them without a browser.

The big benefit of Flex is that you can create very dynamic graphical interfaces. It’s all vector based, so you can draw whatever you need. One example demoed by Adobe was a car insurance claim application, where the user can graphically input the situation of a car crash. This is a good example, as it shows that users will benefit from a more graphical user interface.

Because of the vector graphics Flex will also scale on most display devices you use. We will see a lot more different screen sizes in the future, with different DPI (dots per inch), which makes it important that user interface can adapt to you screen resolution. I think this will be a big benefit for Flex.

Adobe demoed that it’s easy to synchronize user interfaces from different users, changes to data are immediately displayed, so webstore sales people can easily help customers when filling out forms for example. Flex also contains ways to handle data entry conflicts. It’s also pretty straight forward to communicate with a backend written in java (other server side technologies are also supported).

Usually when i think of Flash interfaces i see a couple of problems:

1. indexing by search engines – search engines can do some indexing of flex applications, but they won’t be able to index all your dynamic data. I think this is a big disadvantage. Right now, if you enter the title of a book in google, you will probably see a link to amazon on the first page of search results. I think this is very important for Amazon. You can’t achieve this with Flex. To solve this Adobe suggests you use a combination of Flex and html or Ajax. Current JSF implementation have the same problems with search engines though. Not a good idea to implement Amazon with JSF.
2. bookmarking and emailing urls to specific pages. I often send somebody an email to a specific page in a webstore: “have a look at this book”, or “this is a nice house”. This is hard to do with a flash application. A Flex extension exists that will allow you to create url’s that specify a specific state of a flex application. This extension, in combination with html or ajax will allow you to create bookmarkable and mailable web applications.
3. another common problem with flex interfaces is accessibility. According to Adobe this has been solved however, Flex works with most screenreaders.
4. ease of use. Many people think of web applications as crippled applications. They think that users want complex user interfaces similar to desktop applications. I think this is a mistake. The simplicity of html interfaces has made it possible for many people to use computers. Desktop applications are quite often too complex. I think it would be a mistake if every web application would function like a desktop applications. Look at what microsoft has done to office. One of the biggest improvements of the new office is it usability. In other words, the previous versions of office were difficult to use. Flex enables you to move this complexity to the web. But, it’s all up to the developer how he uses this technology. You can’t blame the technology, if the developer creates an application that is too difficult to use.

I think the current problem with Flex is that it isn’t a complete solution. Adobe suggests you use it in combination with Html or ajax. Ajax is already a complex solution, adding Flex to this only makes it more complex. I think we need a single user interface technology. Of course it could use Flex or Ajax under the covers. But this complexity should be hidden from the developers. This could be an opportunity for JSF. A developer can use JSF components without being bothered with the technology used by the component.

Some sites that use flex:

• Yahoo maps
• Google finance

Interesting links:

• Top 10 myths about adobe flex 2.0

This week the CSS3 working draft of the Advanced Layout Module passed by during a web surfing session. I think every webdeveloper which uses div-elements to define a grid layout, must agree with me that things become more complex and time-consuming when the grid-layout becomes more complex. The main reason for this is that you have to deal with a lot of floating issues and inevitable changes to indenting and text/images sizes influences your grid as well.

In the working draft an alternative way to define a grid layout is proposed: Template-based positioning. I can describe it here in my own words, but I couldn’t do it better than how it is done in the working draft:

The properties in this specification work by associating a layout policy with an element. Rather than making an element lay out its descendants in their normal order as inline text or as blocks of text with margins (the policies available in CSS level 1), these policies cause an element to define an invisible grid, in which descendant element will be placed. One policy also allows elements to be stacked similar to tabbed cards, of which only one is visible at any time.

Since layouts on the Web have to deal with different window and paper sizes, the rows and columns of the grid can be made fixed or flexible in size.

The typical use cases for these properties include:

Complex Web pages, with multiple navigation bars in fixed positions, areas for advertisements, etc.

Complex forms, where the alignment of labels and form fields may be easier with the properties of this module than with the properties for tables and margins.

GUIs, where buttons, toolbars, labels, icons, etc., are aligned in complex ways and have to stay aligned (and not wrap, for example) when the window is resized.

Tabbed dialog boxes, with only one “card” visible at any one time.

Here’s is a simple example of using template positioning for defining a three-rows grid layout:

body { display: "aa"
"bc"
"dd" }
#header { position: a }
#navigation { position: b }
#body { position: c }
#footer { position: d }
<div id="header">
<div id="navigation">
<div id="body">
<div id="footer">

In the above example you can see that the grid-layout is defined in the body element using a display attribute that defines the tabular structure of the grid. The position property is used to fill the slots with specific content.

One of the advantages, in my opinion, of template positioning is that the structure of the grid can immediately be infered from the display property. When float and clear properties are used this becomes more difficult.

Because the specification is still in its working draft stage (even the examples are still in Dutch ), I think it will take some time when the common browser vendors have implemented it so you can use the concepts in your web design. Nevertheless, the ideas in the proposal sounds great to me.