Thursday, May 31, 2007

[Pub] Concepts and Models for Typing Events for Event-Based Systems

We are happy to inform you about our new paper Concepts and Models for Typing Events for Event-Based Systems that will be presented at the DEBS’07.

Event models have a major impact on the flexibility and usability. Therefore, we introduced concepts and approaches for representing, structuring and typing event data and introduced event models of existing event-based solutions in our paper. The paper discusses concepts of organizing event models, introduces basic typing concepts for structuring event data and also introduces more advanced typing concepts such as inheritance, exheritance and dynamic type inferencing. The typing concepts are illustrated with the event-based system SARI and compared with existing event stream processing systems.

The paper can be downloaded at:

[Pub] Event-Driven Rules for Sensing and Responding to Business Situations

There has been a passionate discussion in the CEP community around the relationship and relevancy between rule and ESP/CEP engines. Please find below a paper that we wrote on this topic. The paper shows an approach for graphically modeling business rules. The approach illustrates how to separate correlation concerns from rule concerns.


The paper will be presented on the DEBS 2007.
Looking forward to you response.

[Tech] Maven and "public" Repositories

I have written already about build-automation in this BLOG, and I think I made my point clear, that I love the concept of Maven (2) and really think it is a great tool and a significant step forward in build automation.

Right, after this introduction a "but" has to follow; at least a "however": However, Maven is building upon public repositories like ibiblio and the central Maven repository from Apache, at least as long as open-source projects are involved. Now, despite of the fact that some of the repository servers apparently had some problems once in a while, there are a lot of open source projects on those servers where the pom files are questionable at best. The last example I personally figured was JMock, where the described pom settings do not work and some months ago a Springframework version with iBatis where specific iBatis versions were demanded that could not be found on public servers (whereas to the best of my knowledge also the ones available on the servers would have done).

Now usually one would say, this is the problem of the very project, and just hits the reputation of this project if the documentation or build configuration is made sloppy. Unfortunately this is not the case when Maven 2 is concerned. The reason simply is, that other projects that do depend on such a project with sloppy POMs is now running into problems, and the whole Maven build idea suffers.

I personally really would ask all developers using Maven, who provide projects with POMs "in the wild" to be careful with the POM settings, that are uploaded for public usage. I am not a hardcore Maven expert, really , but I think some guidelines/best-practices to check the validity of a Maven POM should be suggested, I would start with some initial thoughts here:
  • Check XML for well-formedness and POM File syntax
  • Check if really all dependencies declared are really needed (not just drop anything in that might be needed, and remove "historic legacy")
  • Test your pom on a clean local repository!
Any other thoughts?

Additionally I want to suggest a tool that checks public repositories for invalid POMs, if e.g. a student would like to program that as a student-project, please contact me!

Wednesday, May 23, 2007

[Arch] "Evil" XML in Dependency Injection

We had a discussion recently in this Blog about dependency injection frameworks. Benedikt introduced the new kid on the block: Guice.

Was XML the solution for virtually everything some years ago, so it is apparently the fashion of the day to criticise XML applications in various domains, also in the usage as beans-configuration in Spring. I personally cannot really follow that discussion, for me personally particularly the usage of XML in the configuration of Spring was a very powerful advantage. It is a very declarative approach, meaning, one can easily provide a set of different configurations, simple properties (like jdbc urls and the like) can be easily externalised into properties files. Hence a clean multi stage configuration is feasible.

Additionally the config file can be easily edited with a variety of XML editors and given a simple XSLT script a HTML visualisation of the connections within the Spring definition is possible.

Right, so far my plea for XML-based dependency injection configuration.

However, there are folks who prefer other types like annotation based DI, and meanwhile also Spring supports XML-less DI declaration, partly also based on auto-configuration (which I on the other hand do not like at all; it easily confused configuration imho).

Several articles and Blog entries explain how to use Spring without "evil" XML, no need to repeat it here, check out for example:
Comments anyone?

Thursday, May 10, 2007

[Misc] Web 2.5 ;-) Pipes

Ok, I confess, this is probably not a "core" SE topic, however, I was stumbling over Yahoo Pipes today, and I was fascinated. Until now I am not really sure, what I could use this service for and if at all, but yet it looks great.

I like it because the idea is fascinating: you can "program" graphically specific data-workflows: Define some input stream (RSS, XML), some preparation, filtering, ... steps and eventually generate some (RSS) output. So it is a kind of "RSS construction" kit. It is, however a very nice application, apparently mostly Javascript, fast, easy to use.

I wrote Web 2.5, because it might be the next trend to give the "end-user" more web-development skills at hand to create own small services.

Ideas anyone?

Tuesday, May 08, 2007

[Pub] XML Binding

In the current issue of I describe options to handle XML data with Java. "Traditionally" well known strategies are SAX (simple API for XML parsing) and DOM (document object model) parser. While parsers following these strategies are still used, and there are good reasons to do so, in the last years several new concepts appeared on the scene. Let's give a brief review of XML parsing history and (possible) future:

SAX (simple API for XML parsing)

SAX is the "oldest" concept and is still used directly and as a basis for other libraries like many DOM libraries. SAX follows a callback strategy: a class implements a callback interface and this class is handed over to the SAX parser. When the parser is started it "rushes through" the XML document from top to bottom and sends events (using the callback interface methods) to the class. These events are like: "Start Document", "Start Element", "characters", "End Element", ... "End Document".

SAX is very fast and needs few memory as it is not required to keep the whole document in memory; however, accessing the data can be somewhat awkward for many applications. It is actually a rather low-level interface, but might be still useful for applications where mostle "linear read" is required and highest performance is the issue. A lot of implementations are available, also as part of the Java API.

DOM (document object model)

DOM parser like dom4j oder jdom are actually libraries build on top of SAX: they read the SAX events and build a generic object tree represanting the XML document. Navigation is easy, the whole document can be accessed and also changed. Some libraries also allow the usage of query languages like XPath. Hence DOM strategies are "general purpose" parsers, but with some disadvantages that should be considered:
  • The whole document is kept in memory, i.e., much higher memory consumption than with SAX
  • Document is built from generic objects like "Document"; "Element"
  • Data access typically is limited to "String-type" access
XML Binding

The "youngest" technology is XML-binding. The general idea is similar to object relational mapping: domain objects are not "manually" transfered to XML data, but a binding between domain object and XML structure(s) is defined. Then the XML binding library takes care for serialisation to and deserialisation from XML data.

Typically the basis for the mapping is a W3C schema that describes the XML structure plus additional mapping information. Then the binding library and tools can help in generating domain classes when needen. To give an example:

This illustration shows how SAX fires events to the callback class, DOM builds a tree of generic "Element" classes containing the content of the XML document, whereas the binding framework actually creates a tree of concrete domain objects. Despite of the fact, that this is apparently more elegant than a generic tree it also has some tangible advantages like: Direct work with domain objects is possible, no intermediate layer has to be programmed. Binding is type-safe: DOM and SAX libraries are usually working only with String datatypes, whereas binding framework allow arbitrary types.

The drawback however is, that binding frameworks are more complex to understand than DOM libraries and the initial effort (creating schemas, binding definitions, code generation) is somewhat higher.

Binding Frameworks

Leading XML binding frameworks in the Java domain are Apache XMLBeans, Codehaus Castor, JIBX and JAXB from Sun. Beside these "general purpose" frameworks, there are specialised binding libraries used at Webservice framworks like Apache Axis 2 (ADB) and Codehaus XFire (Aegis). They are supposed to be simpler to understand compared to a "full-blown" binding framework like XMLBeans.

Castor has the advantage that the framework contains an O/R mapper as well as an XML binding library, hence if both things are needed in a project, Castor might be the right choice. XMLBeans on the other hand got some attention the last years, as it appears to be the most powerful library available.

XML Beans in the recent version does not only support binding, but also has "low-level" XML interfaces named Cursor and Token, that are comparable with DOM libraries. Hence it is possible to work with "different perspectives" on XML data: binding on the one hand, full XML infoset access down to whitespaces and XML coments on the other. Also XQuery and XPath are supported to query XML data. The roadmap of XMLBeans plans streaming XMLBeans to overcome the disadvantage, that full documents have to be kept in memory.

So it appears that the future of XML processing might be hybrid frameworks like XML beans, that allow to change the access strategy as it is needed for the very problem to be solved.

Thursday, May 03, 2007

[Arch] Top 10 Enterprise Java Performance Problems

As I am currently writing on another article about O/R mapping and persistence strategies (hopefully to be published soon, stay tuned) I had a discussion today with Stefan Edlich who is expert in object-databases like db4o (check out his book on db4o!) as well as in Hibernate. We had some discussions at the "persistence-event" we organised in Vienna last year (I reported about it with a longer blog article here). However, he shared some experience and recommended a very interesting blog entry about typical sources for performance problems in Java enterprise applications. I do not want to repeat the list here, but I highly recommend to check that article and maybe bring up some discussion!

Tuesday, May 01, 2007

[Arch] Software Patterns Blog

I came across the recently started software patterns blog from editors of the International Journal of Patterns (IJOP) focusing on software patterns, stable analysis and design patterns, architectural patterns, pattern languages and how to develop systems of patterns.

The objective of this blog is to foster mature discussions about issues that affect all software developers and practitioners nowadays and may be interesting as good software patterns tend to encapsulate software engineering best practices.

Examples of current software patttens blog topics are:

Pitfalls Categories Overview: The Factor of Immaturity

1. Skill and Experience: The Magical Wands!

2. Same Problem, but Multiple Patterns!: The Common Problem of Duplication

3. Choosing the Right Pattern- Real Challenges

4. Drawing a Fine Line between an Analysis Pattern and a Design Pattern

5. Keeping it Very Simple!

Patterns that are hard and difficult to understand are, most likely, harder to reuse as well

6. Pitfalls in Traditional Software Patterns