Upon designing the Basar platform

The last blog entry about designing an asynchronous ecommerce platform dates back to March 2013 which is ... quite a while. As things slightly changed a bit since than (I switched departments, projects where abandonded and so on) I was unfortunately too busy to work on that topic intensively. With some fresh new ideas, encouragement gained from personal talks and some interesting hints on technology retrieved from talks at this year JavaZone, I will get into more detailed work during the upcoming weeks.

Actually, there are two things, I would like to talk about in this blog input: (1) project name change and (2) design decisions.

The first topic is short and has a short explanation as well: I changed the projects name from iServices to Basar as it - from my perspective - expresses the intention of the platform much better than the former name. But names are just sound and smoke, therefore read on for some architectural facts whereas you can find the conceptual aspects in another blog post.

For several reasons I always found the idea of having loosely coupled services formed into a larger integrated system very intriguing. Amongst others these are my arguments:

1. clear separation of concerns, even across teams
2. only a small number of global design requirements along with a larger responsibility mapped to the teams
3. perfect match of technologies applied inside components to solve local problems - no need to swing the hammer
4. easy exchangeability of features
5. easy extensibility

For some more - very good - reasons see the video of James Lewis about "Micro-Services - Java, the UNIX way held at JavaZone 2013.

But where does loosely coupling start and where does it come to an end? Is it just like throwing some guys into the ring which have never met before or is there a common foundation they all adhere to like common frameworks or concepts? .... as always: it depends on the context. Or to say it with the words of Harold Samuel: location, location, location

In this case, the desired goal to provide a mixture of SaaS and PaaS (as a combined product) along with a heavy need to decouple the single building blocks, I decided to go for the communication as common foundation. Rather than on a technical level I choose the conceptual/business level to define the common base. Therefore all services belong to service types which in turn have a defined communication protocol. If a new component wishes to add some recommendation engine features it must adhere with the requirements defined for reco engines inside the platform ... or ... for any good reason, extend the platform and provide a version 2 of the recommendation engine service type.

What we have so far is a set of textual service representations, the desire to leave components in a certain type of isolation and provide the chance to extend the platform if required. Now comes the technology challenge: what paradigm to follow and which framework to use.

As I have stated in an earlier post the platform will definitely be build on an asynchronous foundation. I believe that asynchronous information processing offers the opportunity to leverage the existing hardware at its best - well, you can still mess things up but achieving the opposite is made easy through the paradigm itself.

Another decision made on the path of technology challenge is to let the asynchronous communication be carried out through message passing along with the strong requirement that particular context knowledge must be represented through the message state only. What does that mean, does the platform not have any clue about which reality it represents? No, that's wrong. The building blocks/components have a state but that state is independent from any special context represented inside a message. The message is used to aggregate knowledge from the component which in turn is incorporated into the context of the message but the component does not hold any specific state for any specific message.

Take a recommendation engine for example. It knows about customers, products and which products to offer to which customer. When a customer message requesting a recommendation comes in, it knows - depending on the message state - which data to respond. The component has its own state but is not dependent on the message nor does it keep anything that is bound with the message. However, the message might initiate a state change but that in turn is global and visible to all upcoming messages.

To draw a picture on how I see the platform imagine a large set of chaotically ordered neurons where each neuron may be connected with an arbitrary number of other neurons. A message put into this mesh is ping-ponged between different neurons, each carrying out the task requested until - if requested - the response finally is spilled out to the calling party. Along its path it may have an impact on data or state provided through different neurons, like changing the set of recommendable products as the message told everyone that the last pair of Levi's just left the stock.

Now over to the final stept: which framework to use?

Over the last two years I became fascinated by the Akka framework and its simplicity towards implementation and application management. As it provides me with all required building blocks I decided to go after it and use it as foundation ground.

Now that I have defined the paradigm to follow, the communication methodology to use and the framework to apply: how does this may fit with the idea to have a loosely coupled system as the messages needs to be passed around ... somehow ... and the natural answer would be to use an Enterprise Service Bus? The latter would couple things again more tightly, may become a bottleneck AND is so old skool, thus I need to find another approach.

The challenge was to bring together message passing and loosely coupling along with distributed components. Somehow it is like mashing up parts of Amazons two-pizza rule together with message passing and loosely coupled components into a new approach.

The idea is to have components that accept certain messages and produce defined output - both known to the entire platform and defined on service specification level. These components register themselve on a central instance which keeps track on which service type is implemented by which service component. Additionally it knows in which cases a specific component accepts incoming messages of a certain type. If a service wishes to communicate with another service it looks up its actor reference from the central phonebook, checks which messages it accepts (eg. customer age must be 25) and starts communicating.

Having the core foundation layed out the upcoming posts will address different problems - technical as well as conceptual ones - that needs to be solved to have a consistent architecture.

Crowd Commerce - What the heck....

After a conversation with a friend of mine and some people at work, the question intrigued me, on how to extend the sales of product owners on the one hand and those of web shops owners on the other hand (see my last blog entry on that topic).

During the following days and weeks, a lot of concepts and ideas kept floating through my mind, never knowing how to canalize it in a suitable way. Some of them are so far from the edge that even pros in this field throw a squint on me. Therefore I decided to write them down and see what you people think about them.

The core idea behind it, I have already outlined in my previous post, can be summarized best by the term Crowd Commerce. It all dates back to a book I once read: The wisdom of crowds by James Surowiecki. I got intrigued by the idea that the crowd is one of the most powerful organizational forms and that the crowd is more knowingly than its highest rated member. It is nothing really new, but someone wrote it down in a noteworthy book and people became aware of it.

So, I started to ask myself the question, what would happen if product owners would mainly focus on what they are good at: obtaining products at the best price and handle the sales process. And what would happen if web shops or website owners simultaneously would focus on what they are good at: presenting and recommending products to their customers. Obviously, there would be a gap between both as the product owners miss a suitable way of presenting and selling products whereas the shop owner lacks the ability to buy products at best rates from their producer.

That automatically led me to the question on what needs to be done in order to close that gap and what would happen then? I guess that we would see lots of (small) web shops popping up, having a quite specialized product portfolio they (might) enhance with additional services like suggestions on how to use a specific product or provide construction services.

There are indeed some open questions left to answer, like the handling of delivery costs when odering products belonging to different product owners. Although they were ordered from within a single web shop the customer has to pay each product owner for shipping its product. But from my point of view, that is just a minor problem to solve.

A major topic might be to answer the question if product owners and web shop owners are really willing to give up the area the other part is responsible for: buying products and selling products. But in doing so both contribute to the crowd and therefore to crowd commerce as they do what they are best at. Depending on how their cooperation is defined, the overall crowd leverages its possibilities at its best and all participating parties will win.

As described in the previous blog entry, the iServices platform is a technical approach to translate the ideas of crowd commerce into a platform.

Stay tuned for more information....or get in contact with me, if you are interested in participating ;-)

iServices - Enabling Crowd Commerce

My last blog entry discussed the different options on how to define functional processes within the iServices application. As I have been too vague on the context the application will be implemented for, this article gives you a rough overview on the ideas, concepts and features thought of so far.

It all started with a beer and a discussion with a friend of mine about an idea for a web shop. At its core heart it was quite the same where the products would come from as the set of services surrounding the product portfolio were its unique selling point. One approach provided that we would use one of the several affiliate services and assemble the product catalog from it. This was accompanied, however, that we had to stick to the rules of such services, eg. forwarding the customer to the product owning shop for closing the ordering process (see shopping24.de for example). But that was not we were looking for, we wanted to have an independent shop where the ordering process would be transparent for the customer regarding the product owning web shop or the deliverying party.

The following days the idea intrigued me further since it seem to be an interesting approach for product owners and web shops (or alike) equally. Product owners, even small ones, could provide their catalogs along with any additional information to an arbitrarily large number of web shops/sellers, whereas web shops/sellers can select products, even those they would probably have no access to as their purchase quantity would be far to small, from a large unified catalog. For both it would be somehow a win/win situation.

In my mind, these thoughts formed the picture of a busy bazaar or hypermarket where participants trade with each other equally. Due to the concentration of supply and demand, all participating parties benefit from this setup. While thinking on how to summarize this picture at its best, the term Crowd Commerce came to my mind.

As I still was searching for a context that I could use for showing that asynchronous architectures are suitable for ecommerce systems as well, it was quite obvious that the scenario described about would be the perfect match. It was then that the idea of something like a bazaar or marketplace connecting product suppliers and sellers in n-to-m relationships for increasing sales numbers for both participants was born.

The core features of the concept are described further below, split up into different two view points: product owner view and web shop view.

Product Owners

• product owners provide their product catalog along with media, availability and other information possibly required by web shop
• they decide where the products are allowed to be incorporated into: theme shops, special shops only, all shops, shops requesting a specific compensation at maximum ....
• they receive orders from an arbitrary web shop for their products and fulfill them
• fulfilling orders might be done in their own name or with a special label of the shop that forwarded the order
• provide the platform with updates on order states as well as product availabilities
• might change the availability of a product between different web shops incorporating the product due to compensation or selling rates in order to max. the numbers

Web Shops

• select and consume products from the platform catalog if they were cleared for it by the owner
• use the platform processes to place orders for products belonging to the product
• use the infrastructure to handle payment processes

There are some more ideas and visions but it would lengthen the blog entry unnecessarily.

Defining and Handling Functional Processes

My last blog entry gave a broad overview on what I am currently after in my sparetime. One core question that plagues me for quite a while now, is on how to define functional processes within the application: incorporate the process definition into the messages or describe it explicitly within the application architecture?

Application Architecture

Describing functional processes and the depending data flow explicitly within the application architecture has two major benefits

• Known structure and data flow eases the pain of extending the application according to customer needs
• Predictable behavior due to known structure and data flow eases the pain of monitoring and managing the application in operation mode

Messages

Incorporating the functional process description into the messages being passed around has one major benefit

• Flexibility of application reconfiguration enables the application management to quickly react to changing requirements

Hence, the main question - as always in computer science - is to answer wether to have a known structure which is easy to monitor and maintain but difficult to extend or to have a highly flexible application which allows the product owner to quickly respond to customer requirements.

In a generic approach, achieving both targets is difficult (or near to impossible), but as I know about the context the application will be deployed within, there is a chance to nail down some basic structural aspects which ease the pains of the operations and support team while maintaining maximum flexibility within that borders.

Therefore the application is structured into so-called domains which handle specific topics, like orders, customers, payments or recommendations. These domains are pre-defined and receive messages dedicated to their specific topic. Within a domain, eg. order, the messages tell the processing components on how to handle them. This allows the product manager to offer max. flexibility to the customer when it comes to the specification of a certain behavior within a domain. This approach is outlined in the iServices wiki.

Finally has to be said, that the messages floating around in the system as well as the provided domain interfaces follow a functional approach instead of a technical one. This particularly refers to the way how these artifacts are designed: they try to map the functional context instead of its technical implementation.

The next blog entry will discuss a concrete application context as I have been too vague on that topic so far :-)

Designing an Asynchronous eCommerce Solution

Ever since I took some very interesting classes about parallel computing (thanks to Dr Clemens Grelck) I am interested in high-performance and low latency computations. Unfortunately, most of the topics back then were academical as the there was only limited access to parallel computers and affordable multi-core (desktop) processors were far from being available.

But nowadays things look a bit different ...

As I am always in search for interesting problems in the ecommerce domain, I recently found myself asking the question: why do most of our products process inbound shop requests in a sequential manner? While executing these calls, precious resources are being blocked since the application awaits a response to its query. So, is there a serious reason not to switch from synch to async non-blocking communication and - beside that - apply some of my previously academical knowledge in a beloved field?

In order to answer that question, I started a little open-source project called iServices which is available on GitHub and actually serves as repo for my own proof-of-concept implementation and further ideas on that topic.

At its core the platform is based on AKKA and provides an ecommerce specific runtime on top it (well, actually it is ecommerce driven, but we will see where the road leads to ;-)). It makes use of functional interfaces and functional messages being passed around. The whole platform is stateless and thus highly scalable to serve large numbers of parallel messages.

One of the major reasons to switch the underlying communication model is to enhance the use of available hardware resources which in turn reduces operational costs compared to sync'ed solutions when it comes to constantly rising number of requests. As the retail market always is in search of ways to save money and increase the margin, this project is a try to proof that the demand can be supported by such an architecture.

But each coin has two sides .... getting a sync'ed application mastered by the developers as well as the application management is much easier than the same applied to an asynchronous solution. The reasons are complex communication structures and information flow behavior that sometimes might seem arbitrary.

The next blog entry will discuss whether to let the platform define functional processes or provide these to the messages and let the platform just react on that.

Writing Accounting Logs

While designing an order processing application which is used as some sort of an backend for different web shops, our business department formulated the requirement to have sufficient information extracted from the exposed services which helps them to do accounting towards the application users. These users identify themselves by providing a unique key as part of the HTTP header. 

As the application is developed in a mid-size team and it is required to have the accounting information exposed for all services, it is hard to ensure that all service implementations stick to that requirement - well, a review could help, but after all we are humans :-)

Therefore we decided to work on a more generic approach which is independent from any specifc service implementation but can be easily activated with a minimum amount of code. The first idea was to use an interceptor which is added to the relevant service classes.

Although the interceptor approach worked as expected, the available information were not sufficient to do accounting: there is no way to access the request payload and headers from the interceptor implementation. Injecting a WebServiceContext using the resource annotation works for the service instance which is currently executed but not for the interceptor called prior the service method execution.

It was then we came up with the approach to implement a soap handler which extracts all relevant accounting information and exports them as required. The implementation looks similar as follows:

 public class SOAPLoggingHandler implements SOAPHandler<SOAPMessageContext> {  
      /**  
       * @see javax.xml.ws.handler.Handler#close(javax.xml.ws.handler.MessageContext)  
       */  
      public void close(MessageContext ctx) {  
      }  
      /**  
       * @see javax.xml.ws.handler.Handler#handleFault(javax.xml.ws.handler.MessageContext)  
       */  
      public boolean handleFault(SOAPMessageContext ctx) {  
           return false;  
      }  
      /**  
       * @see javax.xml.ws.handler.Handler#handleMessage(javax.xml.ws.handler.MessageContext)  
       */  
      public boolean handleMessage(SOAPMessageContext ctx) {            
           boolean outboundMessage = (Boolean)ctx.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);  
           if(!outboundMessage) {  
                // extract relevant information here and write them to log  
           }                 
           return false;  
      }  
      /**  
       * @see javax.xml.ws.handler.soap.SOAPHandler#getHeaders()  
       */  
      public Set<QName> getHeaders() {  
           return null;  
      }  
 }  

Next, the handler must be registered with the application. Therefore a file named, eg. handlers.xml, is created and added to the classpath having the following contents:

 <?xml version="1.0" encoding="UTF-8"?>   
 <jws:handler-chains xmlns:jws="http://java.sun.com/xml/ns/javaee">   
      <jws:handler-chain>   
           <jws:handler>  
                <jws:handler-class>com.mnxfst.logging.SOAPLoggingHandler</jws:handler-class>   
           </jws:handler>   
      </jws:handler-chain>   
 </jws:handler-chains>  

Last but not least, the handler needs to be added to a web service implementation:

 @WebService  
 @HandlerChain ( file = "handlers.xml" )  
 public class TestWS {  
      @WebMethod  
      public boolean returnTrue() {  
      }  
 }  

Depending on the business needs the required information can be extracted from the root source of a SOAP request.

Moving away from ecommerce, next stop: everywhere commerce

Starting to work at my current employer back in 2006 I was wondering why the images and product information for online presentation were technically separated from those being used for the printed catalog. There were some more things like that which let it become obvious that there is a clear differentiation between online and offline commerce. During the years the different channels were merged together more and more but somehow the barrier was kept up between the two worlds - as it is or were the case for the majority of similar companies out there. The last two years were, from my point of view, some quite exciting ones. We had a project running which had the task to define a first-class ecommerce platform for tomorrow business. Although we started with a primary focus on the (classical) ecommerce layer, it became quite clear that the specified platform had much more potential than just to enhance the existing web shop business. With the emergence of this platform the remaining barriers keeping the different channels aside are about to be removed. The deep integration of a point of sales (POS) application with a mobile app as well as a classical web shop or the call center organisation became possible. While working on the project, I came across an article published in June 2012 by Jochen Krisch on excitingecommerce.de where he wrote about the failure of multi-channel strategies. Having our project in mind, which clearly allows to fully integrate different channels in every thinkable way, I asked myself two questions:

1. Are we wrong in trying to create an integration platform for all available and future channels or
2. What do others do wrong in leveraging their availabilities?

The first question I swept away from my mind as I for myself expect the platform to be the future for commerce on different channels. That led me to the second question and a german saying: if everyone jumps from the bridge it does not necessarily mean that it is the right way to go. Reminded of my first days at work, I wondered if business isn't about selling products ... no matter how? If the latter is true:

• Why should a product description in one channel be a totally different from that on another channel (keeping aside the different presentation technologies)?
• Why should the checkout process be handled in a technically different way from that on another channel?
• Why should a customer identifying itself at the checkout (in an real world shop) not receive any special offers in another channel or be credited with money as being a steady (channel independent) customer?
• Why should the underlying software platform be a different one for all channels?
• Why not force to integrate all channels naturally by using the same technologies enabling the business to create competitive offers?

Maybe the failing companies did not have any good ideas on how to integrate their different channels. Maybe they even did not have the right software platform to do so. I believe that in order to be successful on integrating different channels it is heavily required to have both: the right software platform as well as good busines strategies. Additionally, the right devices need to be available in a critical mass. If these requirements are met, multi-channel can work and it will work.

Writing presentations with impress.js

Yap, it was not a mistake, I intentionally titled this article 'Writing presentations...' instead of 'Designing presentations...'. As impress.js let's you create CSS3 / HTML5 based presentations and there is no sophisticated editor available so far, it is more about writing the slides than designing them.

To be fair enough, there are some quite promising editors, like impressionist, arising on the horizon but it is more about showing future capabilities. But as the developers made good progress so far, I expect the tools to be practically useful in short time. And there is no need to do a pros and cons discussion about this or that tool here right now.

I came to using impress.js in somewhat like an unexpected manner. When I was about create a presentation for my submitted talk at JavaZone 2012 I had a discussion with my boss on reusing existing slides from another presentation he held about the same topic. During the creation of that set of presentation slides, he had asked me to insert some more flexible effects beside just switching from slide to slide. For example, he wanted to zoom into a particular part of a diagram and show more information on that detail. After having a short fight with Microsoft Powerpoint, I managed to give him something which came close to his wish, although I must admit that I was quite unhappy with the result.

So, when we talked about those slides, he gave me a hint on impress.js. He told me, that it looks quite promising concerning more flexible effects ... but - and here comes the drawback - it also looks as if it is much more work to accomplish desired results. Since I really dislike old-fashioned boring Powerpoint slides, I decided to give it a try and downloaded the impress.js package.

When I started the intro presentation that comes along with the framework, I was stunned as it was the first time for me to see something dynamic in the browser which is not powered by some Adobe flash plugin. It was then when I decided to write the next presentation using impress.js. As I am a quite lazy guy and tried to avoid learning some new CSS3/HTML5 features, I tried out several visual editors like impressionist. But as I wrote above, those were promising but not quite useful for a larger presentation. That was the reason why I put the impress.js framework back to its dark directory somewhere on my HDD. Again, it was my boss who brought me back to the framework as he asked me, if I made any progress so far... :-)

I reopened the text editor and Google Chrome some weeks after downloading impress.js and started to write my presentation. At first it took me quite a while just for setting up the two starting slides but as more slides were created, the faster I became in writing them :-)

I must admit that there are probably a lot more effects available and not being used in my presentation and probably my HTML/CSS is not the best seen ever, but the results are a good fit for me ... and hopefully for my audience as well :-) Beside that, writing the slides by hand helps to understand the basic ideas of this technology and leverage all possibilities available.

For trying out impress.js by yourself, simply visit the projects github page, download the project as ZIP file, extract its contents and open the index.html page with a current Chrome version. As the HTML code contains a very good inline documentation, read its content and you will be able to make the first steps quickly. Enjoy it :-)

JAVA SE 7 has been released, what about JAVA SE 8

Simon Ritter gave a talk about the further development of the JAVA platform at JavaZone 2011 in Oslo. In this blog entry I will try to recap the main aspects of his presentation titled Moving Java Forward: Java SE 7 has been released, what about Java SE 8? and give some additional information where it seems feasible.

Review in the History of Java

JAVA has been started as a project at SUN led by James Gosling back in 1992. The outcome was a compact basis for writing applets which slowly evolved into one of the most widely used programming platforms.

In 1998 the platform made a first major step away from being only a programming and execution environment for applets and swing applications. Back then SUN released version 1.1.2 - named JAVA 2.

Then came 2004 and the announcement of JAVA 5 which finally paved the way into the enterprise platform market. A large set of bitterly missed features were added like generics or annotations.

The next major release (JAVA 6) opened the JVM for scripting languages and provided some management and monitoring features.

On 28th of July 2011 Oracle announced the latest version so far: JAVA 7. It contains features like:

* Parts of Project Coin (strings in switch statements, underscores in binary int literals)
* NIO.2 (I/O improvement towards enhanced platform independence)
* Fork/Join Framework (flexible and reusable synchronization barriers)

Oracle acquired SUN - mission changed?

Since Oracle acquired SUN in January 2010, a lot of rumors and news were spread: positive and negative ones. Unfortunately, this as well as the fact that employees needed to re-position themselves within the new context led to a smaller break in the development of the language. But fortunately Oracle seems to have an open ear to the community and its customers and finally identified four major aspects to follow:

* grow the developer base
* grow the platform adoption
* increase the platform competitiveness
* adapt to change


Beside that, they decided not to have the different stacks (JAVA SE, JAVA EE and JAVA ME) maintained separately but to combine all efforts in one committee in order to reflect that there is just one language.

Although the company committed itself to the adoption of new ideas, this does not imply that they support the incorporation of all suggestions made by users. The overall goal concerning the implementation of language enhancements and new features is code readability. In his talk, Simon Ritter made a nice side blow towards Perl.

Up to now it sounds like if Oracle is trying to get in charge on decisions made whether a feature will be added to the next release or not. But, as Simon Ritter argued in his talk, Oracle will stick to the java community process. However, they will slightly change it to meet the fusion of the three different language stacks: JAVA SE, JAVA EE and JAVA ME. In the end there is one committee which reflects the fact that there is only one language.

Besides work concerning the language itself there is an ongoing process covering the consolidation of the two runtime environments living within the same company: Hotspot and JRockit, where Hotspot is used as source enhanced by JRockit features.

JAVA SE 7 is out, what’s up to JAVA SE 8

So far I have just talked about the history and what happened when Oracle acquired SUN last year. Now I will give some hints on what’s coming next for JAVA 8, which is planned to be released in October 2012.

Maybe I am wrong but from what I have heard and read so far, I would say that JAVA 8 promotes in large parts features that will enhance the multi-core support and bring new language features supporting the programming model required for these types of hardware architectures.

Lambda expressions in parallel collections
A good point to start from is the sorting of collections. Actually it can be done in a serialized way by simply stepping through its contents using a simple for-loop. In JAVA 8 there will be parallel collections having a special filter method the progammer has to provide a predicate to. Filtering will be done with the best hardware utilization as possible. Beside that the collections will have a map function to filter out those attributes the caller is really interested in.

Since JAVA 8 will bring lambda expressions to the platform, these can be used for the filtering purpose as well like:

cars.filter( #{Car c -> c.seats == 2} ).map( #{Car c -> c.age} ).max();
(returns the max. age of all cars having just two seats)

Think about how much code you need to implement this feature using inner classes.

Single Abstract Method Classes
The concept of single abstract method (SAM) classes will make it easier to write inner classes having only one single method. Actually Runnable#run or Comparator#compare are examples of SAMs.

Today we write the following:

car.dummyMethod( new Runnable() { public void run(System.out.println(c.seats));});

Using lambda expressions combined with SAM, we can do the same thing as follows:

car.dummyMethod ( #{Car c -> System.out.println(c.seats)} );

But we will need to follow a set of rules to leverage SAM classes and lambda expressions at their best:

1. Lambda expressions are applicable only in a context where they could be converted into SAM types (eg Runnable, Comparator, Callable, EventHandler):
Object test = #{ 123 } is not allowed
2. Lambda expressions must not have any break or continue statements. Their return type is inferred from the overall set of return statements within the expression.
3. The variable this has the same value as it would have outside the statement.
4. Variables accessed from lambda expressions must not be modified (should be final).

Extension methods
The main idea behind extension methods is the evolvement of APIs without breaking the backwards compatibility. Neal Gafter has written a nice blog entry about this: http://gafter.blogspot.com/2007/11/closures-prototype-update-and-extension.html
At the core of if it, an interface which is extended after it has been made publicly available provides a static standard implementation of the new method(s). All classes implementing the interface and do not provide code for the new method will the standard implementation automatically.

Value classes
Writing DTOs or value classes is one of the most time consuming tasks producing nothing else than classes having some attributes with their associated getter and setter methods. The concept of value classes tries to provide a simple solution where those attributes accessed via getter and setter methods are marked with a special keyword property, ie:

class Node { Node property parent; Node property leftChild; Node propert rightChild; }

Collection literals
Collection literals will solve a common problem when filling lists, sets or maps on creation with pre-defined data. Today this works a follows:

List digits = Collections.unmodifiableList(Arrays.asList([1,2,3]);

The new approach simplifies this:

List digits = [1,2,3];
Map namedDigits = { 1 : “one”, 2 : “two”, 3 : “three” };

module-info.java
I am trying to write a good introduction to this the fourth time right now thus I am just showing the layout of the named file proposed in Simon Ritters talk:

module com.mnxfst.product @ 1.0 {
requires jdom @ 1.0;
requires rome @ 1.0;
class org.openjdk.aggregator.Main;
}

The goal is not just to get rid of the classpath option but also to give the runtime environment sufficient information on how to run the named application correctly. Therefore only those library versions will be used that the developer named in module-info.

Profiles and Modules
The idea behind profiles and modules is to have a single language platform where you choose appropriate components from to support a certain context, eg. enterprise or mobile. In JAVA 8 this is promoted through Project Jigsaw.

Conclusion

Although most of the things I wrote about the upcoming JAVA 8 release are not quite new, I love to see how precise they got by now. Therefore I would like to dedicate the last paragraph to an evaluation of the listed topics:

Oracle acquired Sun
I hope that Oracle will stick to the JAVA community process and keep the platform as free and accessible as possible.

Lambda expressions
Although lambda expressions look a bit different from the java code we currently know, I expect them to improve the language a lot. Not only that they reduce the lines of written code but also make it more readable.

Single Abstract Methods
The same that applies to lambda expressions is also valid for SAMs: they will reduce the written code and make the remaining lines more readable.

Value Classes
In the age of code generators and other neat little helpers, I do not see a real use case for value classes beside the fact that they definitely will reduce the written code. Although I am a bit skeptical, I can say for sure that I will use them if they are available since it spares me to execute the code generator.

Collection Literals
On first sight I was a bit excited about this feature since it makes it really easy to create and fill a collection, list or map on creation. But then they reminded me about the problems I had with the auto (un)boxing feature that moved in with JAVA 5 (int i = list.get(0) might exit with a NPE).
Unfortunately I expect to see the same problems again thus this feature - although really nice and time saving - is not what I was waiting for.

module-info
Since Simon Ritter did not talk too exhaustivly about this feature I am not sure how it will work in practice. Let’s assume an application requires commons-logging 1.0 and a component used by the application requires commons-logging 2.0, how will this work without any troubles? If you’ve got any suggestions or information, please let me know since I am eager to learn about it.
After all I think this is a nice enhancement cleaning up the classpath a bit.

Profiles and Modules
Personally, I have never understood why there are three different type of JAVA specs: SE, EE and ME. Providing a common platform which can be extended concerning its installation footprint according to a specific profile seems to be reasonable. Therefore I must say that I am excited about this.

Getting Primeface and JSF EL to work on Google App Engine

Lately I decided to use the Google cloud infrastructure as runtime foundation for a new project. At least two reasons led to a positive decision towards Google's App Engine: (1) a very strict but straight development paradigm and (2) the availability of a free quota.

Since I need to get some presentable results quickly and did not want to spend precious time learning a new ui framework, I chose to try out the availability of JSF 2.0 on GAE in interaction with Primefaces. Fortunately I stumbled across an article by Derek Berube on how to setup Primefaces in a GAE environment.

Unfortunately I ran into two small but annoying errors that kept me away from making any progress for a while. The first one appeared everytime I requested a JSF page:

java.lang.UnsupportedOperationException
at javax.faces.context.FacesContext.getCurrentPhaseId(FacesContext.java:660)
at javax.faces.event.ExceptionQueuedEventContext.(ExceptionQueuedEventContext.java:158)
at javax.faces.event.ExceptionQueuedEventContext.(ExceptionQueuedEventContext.java:106)

I could get rid of it by replacing the recommended Mojarra version 2.0.4 by 2.0.3.

The second problem is associated with SUNs implementation of the expression language. So, I replaced it by the JBoss implementation but had to make changes to get it working, since it breaks the law of not spawning any threads. Therefore I copied the modified contents of org.jboss.el.util.ReferenceCache
into the source folder of my project.

Finally I got my project using Primefaces 2.2.1 and JBoss-EL 2.0.1 working.

Concurrency and Performance (Intro)

In my last blog articles, which are unfortunately more than 4 months old, I wrote about an application I developed during my spare time. Lately I began
to migrate mshop from Spring 3 to JEE 6 for some reasons I may talk about in an upcoming article.

During the refactoring, I came across certain concurrency and performance topics which puzzled me for some time. In parallel a colleague of mine established a company interal workshop series about current software development topics. Since I do think that concurrency and performance are two fundamental topics in software engineering, I offered to prepare a little series about these subjects. As these presentations contain no company secrets, I decided to present them at this place as well. If you have got any ideas or topics you would like to read about, do not hesitate to contact me.

In order to make you aware of the subjects to come, I will present you a typical concurrency situation producing invalid data. Let's assume we have two actors A and B where both share a common bank account BA they try to withdraw money from. To map this into a software I used a very naive approach and modeled a bank account implementation as follows:

/**
* Provides an unsafe bank account implementation
*/
public class UnsafeBankAccount {

private int amount = 0;

/**
* Initializes the account
* @param initialAmount
*/
public UnsafeBankAccount(int initialAmount) {
this.amount = initialAmount;
}

/**
* Withdraws a named amount of money from the account. In
* case the withdrawal is allowed the method returns true
* otherwise false
* @param a
* @return
*/
public boolean withdrawMoney(int a) {

if(a < amount) {
amount = amount - a;
return true;
}

return false;
}

/**
* Returns the current amount of money stored
* in this account
* @return
*/
public int getAmount() {
return amount;
}

}

In a single-threaded environment this implementation would cause no trouble since it is accessed in a sequential manner. If you tend to use the UnsafeBankAccount in a multi-threaded setting, you might observe inconsistent states between the results of UnsafeBankAccount#withdrawMoney and UnsafeBankAccount#getAmount.

Assume the following situation: the actors A and B share a common bank account BA they wish to withdraw money from. At first each checks the current state of the account calling UnsafeBankAccount#getAmount and then decide to withdraw a certain amount of money without overchecking the account. What could happen is:

• The initial amount of BA is $100


• A checks the account and sees that the account holds $100


• A orders to withdraw $30 from the account


• While the software validates the condition of the if-clause in UnsafeBankAccount#withdrawMoney to true the scheduler interrupts the computation and hands over the control to the thread of B


• B checks the account as well and also sees that the account holds $100


• B orders to withdraw $80 from the account


• The execution thread handling the order of B as well validates the if-clause in UnsafeBankAccount#withdrawMoney to true, recalculates the current state of the account and returns true


• Now the execution thread handling the order of A also recalculates the current state of the account and returns true as well


• If any of the customers checks BA, they will see that the account is overchecked by $10

A different situation could be:

• The initial amount of BA is $100


• A orders to withdraw $30 from the account


• Before UnsafeBankAccount#withdrawMoney has the chance to update the variable amount, the scheduler interrupts the current thread


• Now B checks the current account state by calling UnsafeBankAccount#getAmount and sees that the account still holds $100

To ensure that the bank account works as expected in both cases, we need to ensure that (1) the amount variable is always in a consistent state and (2) each call returning the amount sees the most current value.
The magic element in this case is the synchronized modifier which will be used to guard the reading and writing accesses to amount. This leads to the following modification:

/**
* Provides a thread-safe implementation of a bank account
*/
public class ThreadSafeBankAccount {

private Integer amount = null;

/**
* Initializes the account
* @param intialAmount
*/
public ThreadSafeBankAccount(int intialAmount) {
this.amount = Integer.valueOf(intialAmount);
}

/**
* Withdraws a named amount of money from the account. In
* case the withdrawal is allowed the method returns true
* otherwise false
* @param a
* @return
*/
public boolean withdrawMoney(int a) {

synchronized(amount) {
if(a < amount) {
amount = amount - a;
return true;
}

return false;
}
}

/**
* Returns the current amount of money stored
* in this account
* @return
*/
public int getAmount() {
synchronized(amount) {
return amount;
}
}

}

The implementation above ensures that no read or write access takes place while another thread reads or writes the amount variable. Depending on the use case mapped by the implementation, the synchronisation used in the getter method could be omitted, eg. the caller does not wish to retrieve the latest and most current value.

mShop - Screenshots

It's been a while (again) since I provided you with information about the current state of affairs concerning the mshop implementation. Today I would like to present some screenshots and detailed information about how I implemented the features I presented in my last post (eg. object class hierarchy definition and alike).

Creating attribute types

Object class definitions within the application consist of an unique name and a set of attributes. Each ettribute has its own value type like STRING, INTEGER or TIMESTAMP. Assigning these atomic values types directly would strip down the possibility to have a differentiated handling per attribute. Take an object class person having attributes firstname and lastname both of type STRING for example. When an user approves the order of an instance of type person the application could not handle the values of firstname and lastname in different ways but as every STRING in the context. The reason is that attribute names are just free text values having no impact on the processing.

In order to remove that limitation, mshop introduces own attribute types where each type is assigned a concrete value type like STRING or INTEGER. Take the example above. We would create an attribute type FIRSTNAME of value type STRING and maybe a type BIRTHDAY of value type TIMESTAMP. This gives the user the option to modify the handling of approved instances according the attribute types, eg combining the values of types FIRSTNAME and LASTNAME to a value givenName that is provided to a ldap server.




Creating object class orders

The driving force behind mshop are user defined object classes which serve as blueprints for concrete object instances (eg. class com.mnxfst.blog.Person is the defining type for instance Christian Kreutzfeldt). Therefore you need to define classes before your users are able to order instances of those types.

Creating an object class requires you to provide some more detailed information and must be carried out with a certain amount of care since it is the foundation of the later running system.

The definition dialog has three different tabs. The first tab lets you provide common information about the class like its name, if it is an abstract class, the activation date or the set of attributes.





The second tab lets you specify detailed information on how certain object class instances will behave in the approval workflow. You can define for each configuration (attribute value setting) the required audit level (how many people must approve the order) and what kind of operations are allowed for specific value settings.

The attached screenshot shows a configuration where object instances of the ordered type which are referencing the city of Hamburg and the specific street Kehrwieder need to be approved by two people for the operations create, update and delete.

These settings alone do not configure the concrete workflow path afterwards but represent the building bricks for it. In case an user orders an instance of type Person the application checks the attribute value settings and matches them against the associated workflow configuration in order to look up the required audit level.



The third tab finally lets you define approvers for ordered object class instances. Compared to the second tab, this one behaves nearly the same but adds another field: priority level. The audit level defines on which approval level the named user is provided with an workflow item for a specific order. The priority level gives you the opportunity to define proxy rules in case a named approver does not answer within a defined timespan.



Approving object class order

After having fully specified an object class, it needs to be approved by at least one object class approver. The object class approver opens the dialog displayed below and chooses to view all open/unanswered object class orders. In order to have the chance to validate the object class configuration he is allowed to browse through all the settings the originator made. The handling and behavior is quite straight forward and needs only little description.



Order object class instance

In case an object class has been approved its available to all users which are allowed to order instances of that type. The screenshot down below shows a set of classes the user can choose from.



The next step shows a set of available parent classes the user can choose from to define a hierarchy.



The third step lets the user specify values for the assigned attributes. The last step finally sends the object class instance order into the workflow process.



Approve order object class instance

The final view I would like to present today is the dialog for approving object class instance orders. Each approver is presented a list of all orders that he is allowed to approve / reject. By selecting a single workflow item he is able to see all required order details like common information (audit level, priority level, object class name and alike) and the attribute value settings.





Actually most of the dialogs do not look very fancy and colorful but I will try to improve on that until the first release of the application.

mShop - The object classes

It's been a while since I wrote my last post about the mshop application. Today I would like to present the
data structure which is visible to the application user and offers him the ability to model his problem domain
as best as possible.

As I have stated in my last article, most applications leave you with a rather inflexible data structure which
requires you either to adopt your problem domain to the software system or modify the software system in its
core parts to support your problem domain. Neither way is an acceptable solution to your problem.

When I started to design the mshop application, I had in mind that establishing a kind of a centralized order process
within a company must adhere to the fact that the users are not willing to use one service for ordering objects
of type A (like user accounts) and another service for ordering objects of type B (like computers or other office
supplies). Beside that the whole workflow based approval process needs to be independent from the concrete object
types handled by the system.

Therefore I tried to define a very generic data structure and a highly flexible approval engine. Both elements
will be presented more detailed in the following paragraphs.

Data structure


The data structure basically follows the object oriented design techniques used for software component specification. The following types are provided

• attributes


• attribute types (like integer, date ...)


• classes


• objects (as class instances)

A class is composed of an arbitrary number of attributes which have a specific type which could be a

• INTEGER


• DECIMAL


• STRING


• TIMESTAMP


• BOOLEAN


• BLOB


• OBJECT_REFERENCE


• CUSTOM_TABLE_REFERENCE

Most of these types are self-explanatory except OBJECT_REFERENCE and CUSTOM_TABLE_REFERENCE. An attribute
of type OBJECT_REFERENCE is allowed not to hold a value but a reference to another object (eg. a user references
another user to model the supervisor relationship). This gives the user the maximum power to model complex relationships.

The other special type (CUSTOM_TABLE_REFERENCE) has been implemented but is not in use. The idea behind this attribute type is the ability to reference objects or values that are completely unknown to the application and must not be modeled
within the domain. Actually this is just an extension point that might be used in the future.

When an attribute is assigned to a class, the user needs to specify some attribute values of this relationship

• NAME - name of the attribute (eg. firstname, lastname, email, ...)


• DESCRIPTION


• MIN_TIMES - defines how many values must be assigned to this at minimum (used for list modeling)


• MAX_TIMES - defines how many values can be assigned to this at maximum (used for list modeling)


• REQUIRED - a value for this attribute must be provided


• VISIBILITY - defines the visibility of this attribute (public, protected, private - read more down below)


• ATTRIBUTE_TYPE - defines the attribute type (eg. INTEGER, DECIMAL, STRING, ...)

The VISIBILITY of an attribute defines the scope within the attribute is visible to any accessor. If the attribute
is marked to be PRIVATE only the class or instance is allowed to read and write values from / to it. If the attribute is
marked to be PROTECTED the class or instance and all ancestors and its instances of the defining class are allowed
to read and write values from / to it. If the attribute is marked to be PUBLIC all classes and instances are allowed to
read and write values from / to it.

Although there are no limitations concerning the depth of a class hierarchy and the number of attributes within it, the user
must be aware that each new level has an impact on the overall performance of the current hierarchy.

After having defined the classes the application allows to create instances (objects) from these blueprints. Therefore the application reads the class definition (including all ancestors) and provides the user with a dialog that requires him to provide values for all attributes visible to him.

Approval engine

The job of the approval engine is to analyze incoming object orders using a XPath like expression language and forward them to a suitable set of approvers (might be a single one as well). If a required number of users have approved the order it will be either forwarded for final processing (like creating user accounts or ordering printers) or - if required - forwarded to another set of approvers (two men rule). This depends on approval information provided for the underlying class.

Each class can have one or a whole set of approval information where each element defines how entities must be handled that apply to the given path expressions:

• OBJECT_CLASS - defines the class that this element provides approval information for


• AUDIT_LEVEL - defines the audit level (1..n, two men rule)


• DISABLED - the element will not be used by the approval engine


• ORDER_CREATE_ALLOWED - if an object applies to the given path expressions, it might be created


• ORDER_UPDATE_ALLOWED - if an object applies to the given path expressions, it might be updated


• ORDER_DELETE_ALLOWED - if an object applies to the given path expressions, it might be deleted


• PATH_EXPRESSIONS - set of strings holding path expressions. if any object positively evaluates against all of these expressions, the options mentioned above will be applied

The approval engine reads the type of an incoming object order and fetches all approval information entities for that type. All path expressions of each entity are evaluated against the object. If any of them fits, the rules defined by the associated approval information entity will be used by the engine on how to further process the object order (eg. which audit level it requires, if an object might be
created at all).

Now the engine finally needs to identify all possible approvers for the ordered object. Therefore a quite similar information entity is used. If differs from the one above only by adding the following attribute

• PRIORITY_LEVEL
  

The PRIORITY_LEVEL is used by the approval engine in case the current set of approvers did not respond within a given timespan. Now the engine needs to forward the order element to a second/third/fourth ... round of approvers where the priority level identifies the specific round when an approver enters the ring.

Before the engine forwards an order to an approver it uses the path expression set to evaluate if the ordered object can be handled by a specific approver. If the path expressions are all valid, the engine checks if the operation (create, update, delete) might be carried out the by approver at all.

Conclusion

Although I just provided you with only a small view, I guess you got a good hint on how flexible the application's data structure is. In the upcoming articles I will talk a bit about the license model of mshop and provide you with some screenshots and more information about key features.

mShop - an introduction

Today I would like to start a little series of articles about a personal software project called mShop. The mShop application is a response to a discussion I had with some friends a while ago about the handling of internal orders for office supplies and other items you need to carry out your daily work, eg. printer paper, pencils, desktop computers, user accounts or permissions. The key question was if there are any professional tools to comply with the following requirements:

• define products having arbirary attributes during runtime


• flexible delegation of responsibilites concerning the approval of product orders


• automatic delegation of approved order items into sub-systems for further processing, eg. unix server for user account creation.


• being cheap within boundaries

We came to the conclusion that there are indeed sophisticated tools like ActiveEntry or one might use an existing open source shopping platform and modify it according to his needs. BUT, the solutions are either expensive, limited in their feature set or require the owner to use their inflexible data structures.

That finally let to my decision to specify and implement an application that is compatible with the features mentioned above. According to my nick mnxfst I took the first char (m) of it and added the postfix shop.

To keep the articles short, I split them up into a series where each entry concentrates on a different key feature of mShop. The next article will discuss the definition of objects users might order via the web shop.

FetchType.EAGER - Cannot simultaneously fetch multiple bags

I just came across a quite interesting problem that might give you a hint on how hibernate internally works. Assume you have the following object association:

• A references B


• A has a one-to-many relationship with C and the fetch type is set to FetchType.EAGER


• B has a one-to-many relationship with D and the fetch type is set to FetchType.EAGER

If you try to initialize hibernate using such a layout, you will receive an error message saying something like cannot simultaneously fetch multiple bags.

Since my mappings were okay until I added a test case for B and the relationships of B were correct on first sight, I started to search for a possible reason. I came across different solutions, among them I found this one from Eyal Lupu. It did not directly solve my problem, but let me analyze the code from a different point of view.

Eyal writes, that it is not allowed to have two mapped lists in one entity being marked with FetchType.EAGER because the sql statements generated would lead to an incorrect loading of the desired entity. If you look at my example above, there is just one list per entity to be loaded eagerly, so why does it fail? The solution to that problem is the first statement of my example: A references B.

If you refer from one to another entity without further fetch type definition, hibernate will always apply FetchType.EAGER. That again leads to a join operation between the relations that contain A and B. Since the relationships between A - C and B - D are also marked to be loaded eagerly, they will be incorporated into the sql statement creation as well. Guess what operation will be used to compute the entities of the relationship: JOIN. And that leads us back to Eyals posting.

Eyal suggests to add an @IndexColumn annotation which replaces the bag semantics with list semantics that gives hibernate a hint on how to handle elements of that type. Another solution - and that's the one I chose - is to mark the connection between A and B as begin fetched lazy. In case you need the relationship between A and B being resolved on entity loading, a third solution would be to mark one or both of the one-to-many relationships as being fetched lazy.

Next to the FetchType.EAGER problem it is a good idea to have some of the relationships mentioned in the example above marked as being loaded lazy. Loading all associated objects eagerly and having a relationship that for example represent a chain of ancestors would leave you with a large set of objects loaded although you need just only one.

Object change tracking

Assume you have the task to write an audit proof software that could be easily resetted into a previous, fully
operable state for all objects managed by the application. I am going to describe the approach how I solved the
issue for my assignment.

The reason for resetting a software system into a previous state is for example the ability to trace back
changes made at a specific time by a know or unknown user. Usually features like this are implemented through a
logging component having a more or less high resolution. Unfortunately the information captured only give a very
limited view on the context the changes were made in. Writing all required information into a single log entry
would be a quick but brute force solution and would let appear the log to be unreadable to auditors.

A second aspect - and that's the driving force beside the traceability of changes in my project - is the
possibility to have an automatic replay of all changes made to objects between two defined timestamps and the
provisioning of these modifications into attached sub-systems. These tasks cannot be achieved through a simple
logging mechanism since next to the data directly involded into certain actions, transitively affected information
within the context of these objects are required as well. Therefore a more complex and more complete solution
must be found which still is managable on all system levels - from abstract ui level to low database level.

A very common approach for recording changes within datasets is to save delta information representing the
transition between two states instead of creating a copy of the original state adding the changes made by the
process. The latter would lead in my case where I comprehend the whole object context as dataset to a redundant
enlargement of the whole database.

To avoid redundant information and an explosion of managed data objects, I decided to follow the idea of saving
only delta information covering the named dataset.

Within in my project, I do have to manage a lot of objects which are linked among each other and where changing a
linked objects attribute value could lead automatically to a semantic change of the originating object. Since the
changed object could be linked by n other objects, a complete and stable approach in saving the state
transition would be the storage of the changed object as well as all linking objects. This would not be as many
data as writing a whole copy of the objects context but it produces unecessary redundant information.

I decided to follow a much easier and quite simple way to solve this problem. Whenever an object changes, itself
and its ancestors can be identified for any time through the unique object id and a version stamp. All
links between objects are designed such that they reference the unique object id as well as the version stamp.

If someone changes an object, a new version is created whereas all existing links point to the version controlled
ancestor. Other objects that will be linked with the changed one in the future only see the most current version.
This leads to an overall consistent state.

But this concept is too basic to intercept all requirements. Sometimes changes to object attribute values are of
such a minor state that they would have no influence on the link semantics at all. Therefore it must be possible
to mark changes in such way that no version is created but the most current one is modified.

There is indeed the other hand extreme as well. Sometimes changes made to objects have such an impact that they
must be expanded to all linked objects too. In this case all links to former versions are upgraded to the most
current one.

Portlet Development With Spring 3.0

Portlet Development With Spring 3.0

Some weeks ago I started planning a dedicated online community backed by a Liferay portal instance. Up to now I spent most of my time defining use case scenarios, evaluating software tools and convincing people from my idea. Lately I began to write smaller portlets that provide basic features which are not included in Liferay and by the way give me a deeper insight into portlet development using Liferay.

I will write more about that platform in one of the upcoming posts but for now I would like to report about my odyssey collecting information on how to develop JSR 286 portlets supported by the Spring 3.0 framework in a Liferay environment.

If you want to develop portlet for any version of the Liferay portlet, you might use the ext environment provided by the Liferay team. Although I appreciate the help to develop applications for their portal, I definately don't want to learn how to use a proprietary development environment but use my knowledge about standard portlet development and get onto the road quickly.

I searched a while until I came across some expedient documentation about how to integrate Spring 3 and standard portlets (JSR 168 and 286). The Spring framework provides you with a dispatcher portlet that maps incoming portlet requests to registered handlers.

After having assembled all required information, I started developing my first Liferay portlet. The following steps are the ones I carried out (abbreviated):

The first step creates a directory layout as follows:


/myPortlet
/myPortlet/src/
/myPortlet/src/main
/myPortlet/src/main/java
/myPortlet/src/main/java/sourceCodeGoesHere
/myPortlet/src/main/webapp/
/myPortlet/src/main/webapp/WEB-INF/
/myPortlet/src/main/webapp/WEB-INF/classes/


The next step is to add configuration files required by Liferay:


/myPortlet/src/main/webapp/WEB-INF/liferay-display.xml
/myPortlet/src/main/webapp/WEB-INF/liferay-portlet.xml
/myPortlet/src/main/webapp/WEB-INF/portlet.xml
/myPortlet/src/main/webapp/WEB-INF/web.xml


• The liferay-display.xml configuration file defines the category the user can find the tool in when adding a new applicaton to a portal page (see Google for more information).


• If you want to control the access to the portlet, you need to modify liferay-portlet.xml which holds the names of the role that are allowed to use the portlet (see Google for more information).


• The file portlet.xml contains the core definition of you portlet: display name, class, init parameters and alike. Normally you would provide the name of your custom portlet class but since we are using Spring, we must tell the portlet container to forward all incoming portlet requests to the Spring dispatcher portlet. Additionally we need to give the path of the Spring context configuration file.:
  
<portlet-app>
.
.
<portlet-name>mySamplePortlet</portlet-name>
<display-name>My Sample Portlet</display-name>
<portlet-class>org.springframework.web.portlet.DispatcherPortlet</portlet-class>
<init-param>
<name>contextConfigLocation</name>
<value>/WEB-INF/classes/my-sample-portlet-context.xml</value>
</init-param>
.
.
</portlet-app>

  


• At last we have the web.xml file. Internally the Spring framework handles the whole custom portlet as web application with the dispatcher portlet as entry gate. Thus the web.xml configures the custom portal application like in any other Spring application: it needs a path to the Spring context definition file, names a set of listeners and defines how to handle incoming requests (-> ViewRendererServlet).
  
<web-app ...>
.
.
<context-param>
<param-name>webAppRootKey</param-name>
<param-value>mySamplePortletportlet</param-value>
</context-param>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/classes/my-sample-portlet-context.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.util.WebAppRootListener</listener-class>
</listener>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<servlet>
<servlet-name>ViewRendererServlet</servlet-name>
<servlet-class>org.springframework.web.servlet.ViewRendererServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>ViewRendererServlet</servlet-name>
<url-pattern>/WEB-INF/servlet/view</url-pattern>
</servlet-mapping>
.
.
</web-app>

  

Now I need to implement a controller for handling incoming requests. Since I am mapping incoming requests to a common Spring MVC application, the implementation of a request controller takes the same steps as for a standalone web application. See Google for extended information on how to implement Spring MVC controllers, define request, action or render mappings and how to identify incoming request parameters.

I omit the source code and continue with the definition of the Spring context. As defined in the web.xml and the portlet.xml I create a new file in /WEB-INF/classes/ named my-sample-portlet-context.xml. In order to the get application running the following beans must be defined at minimum:


<bean id="mySamplePortletViewController" class="com.me.MySamplePortletViewController">
<property name="debugMode" value="true"/>
</bean>

<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="cache" value="false" />
<property name="viewClass" value="org.springframework.web.servlet.view.JstlView" />
<property name="prefix" value="/" />
<property name="suffix" value=".jsp" />
</bean>

<bean class="org.springframework.web.portlet.mvc.annotation.DefaultAnnotationHandlerMapping">
<property name="interceptors">
<bean class="org.springframework.web.portlet.handler.ParameterMappingInterceptor"/>
</property>
</bean>


The first bean names the controller which should receive incoming requests (as defined by the RequestMapping annotations in the source code). The second bean defines the type of view used for displaying contents to the user. In this case I use JSP backed by JSTL. The last bean is the one that handles the mappings defined in the source code of the controller implementation. The provided interceptor implementation makes sure that the incoming request parameters are mapped correctly to method parameters.

Finally you need to create and implement the file (JSP) referenced in the controller source code as destination used for displaying information to the user. That's all. ... well not everything ... there are some pitfalls I stumpled upon that I would like to write about so that you are not going to make the same mistakes as I did.

RequestMappings
The JSR 168 standard only knew about request mappings, whereas JSR 286 portlets differentiate incoming requests by the phase they originate from and which purpose they serve:

• Action Request (Annotation: ActionMapping)


• Render Request (Annotation: RenderMapping)


• Even Request (Annotation: EventMapping)


• Resource Request (Annotation: ResourceMapping)

If you want to learn about these types, please check out Google for further information. I urgently advise you to use these specialised annotations although Spring lets you use the generalized RequestMapping annotation. First of all it helps to make the source code more readable, second: you know which method handles which request type, confusions excluded!

RenderMapping requires String result
As mentioned above, after processing an incoming request, the portlet controller sends the response to a defined view page. The name of that page is provided by the result of the method that handles render requests -> the method must return a string.
If it returns 'view', the user will be redirected to 'view.jsp'.

Unit testing
If you want to test your portlet controller, check out the test cases for the Spring framework itself. Since the usage of init methods is quite common, you should be aware that the init method of your controller is executed before the setUp method within a JUnit test case. So, if you plan to access data in your init method which is created by the setUp method, you need to explicitly call the init method in your test method.

Thoughts on Google Wave

Lately I received an invitation to Google Wave from a colleague at the otto group (btw, thanks for that, David).

First I thought, that Wave is another way of spending my precious time. Some people say, that Google just tries to revolutionize the communication tool market with its Google Wave application and are curios if that will work given the set of existing communication tools with their broad feature set. Beside that some point out that the feature of adding arbitrary content at any location within a wave could discourage non-digital natives from using the new technology.

I fully agree that Google tries again to revolutionize a market, but I disagree with the implicated estimation that Google just adds another communication tool. Although Wave is still in beta mode, it is already visible what the driving force behind the scene is. Google does not provide us with another isolated publishing pipe like Twitter or alike but enhances our way of information exchange by combining different communication channels into an integrated application.

From my point of view, one of the main problems with today's communication tools is the fact that some of them are very famous but none of them really maps the real life way of conversation into the digital world. That again leaves us with sometimes fragmented conversations that are unnecessarily protracted because the exchanged textual informations (for the case of an email) do not fully explain the intentions of the participants. In real life we tend to support such situations with additional material from different sources, eg. maps or photos, to clarify our statements.

Google actually tries to solve what I expressed in my last statement: support a conversation with information from a variety of sources. Make no mistake about the hype Google created around Wave, the application is still under development and has more the feeling of a very active research project than an enterprise enabled communication tool. But if you strip down the initial character of its current state (by 17/12/2009) you must realize that Google heralds a new era of compelling messaging experience as for example Mozilla also tries do achieve with its Raindrop project.

Finally neither the Google nor the Mozilla approach will help us today to avoid the face-off with situations like Frank Schirrmacher wrote about: he complained that his head cannot follow the constant flow of information anymore (see www.spiegel.de, german only). But on the other hand they help us to steer into the right direction. A very tiny but important step is the traceability of a Waves conversation history which does not only help the non-digital natives to find out when a certain piece of information was inserted into a conversation and by whom.

Hourglass display with Richfaces

Hourglass display with Richfaces

Yesterday we started with a preliminary application test to be prepared for the final integration test next month.
Since the web based application works on large datasets which could sometimes lead to extended response times at
frontend level, one of the first things the users asked for, were a hourglass or something alike to show that the
server is still processing the request.

Since the application is based on Richfaces I searched for any feature that could help me and discovered the status tag.

The first thing I wanted to try out, was to display a message simply informing the user that the current request is still in processing mode. In order to do so, only two things needs to be done:

• Define the message display behaviour using the status tag


• Bind the status handler to a control that sends an ajax request to the backend


<a4j:status id="testStatus" startText="Request processing started" stopText="Request processing ended"/>
<a4j:commandButton action=".." value=".." status="testStatus"/>


The next time the user clicks on the command button a message will appear and inform him about the processing state.

Well, that kind of behaviour gives your users a slight hint on what the system is currently doing, but hey, an overlay graphic displaying a hourglass or alike is much cooler, isn't it. Therefore I continued to search for an appropriate solution to that
problem and finally found one written by Markus Kühle (in german only). Compared to my little example above, the main concept does not change. A status handler is defined as well as the binding with the command button. In order to create an overlay message, we need to work with cascade style sheets:


* html body { margin: 0; overflow-y: hidden; padding: 0; }

#globalStatusDiv {
position: relative;
left: 50%;
top: 200px;
width: 100px;

text-align: center;
margin-left: -50px;
height: 25px;
line-height: 25px;
background-color: #FFF;
padding: 2px 15px 2px 10px;
color: #000;
font-family: Verdana,Arial,Helvetica,sans-serif;
font-size: 14px;
font-weight: bold;
z-index: 10000;
}

#globalStatusDiv img {
vertical-align: middle;
}


Next, we must define a div which contains the information to be displayed and bind it to a status tag:


<link href="/css/status.css" rel="stylesheet" />
<div id="globalStatusDiv" style="display:none;">
<img src="/images/working.gif"/> %<h:outputText value="#{generalMsg.general_loading_message}"/>
</div>
<a4j:status id="globalWaitStatus" forceId="true" layout="none"
onstart="jQuery('#globalStatusDiv').fadeIn('fast')"
onstop="jQuery('#globalStatusDiv').fadeOut('slow')" />


The binding with a command button does not differ from the simple example above:


<a4j:commandButton action=".." value=".." status="globalWaitStatus"/>


How to convince people of good ideas

Although I originally planned / promised to write about caching strategies and method interception in spring
applications, I decided to insert a different topic that concerns me since I gave a presentation the other day.
The main goal of that event was to show the current implementation state to the upcoming users.

The initiator of that project defined the platform in a very broad manner and with a scope that overlapped
more than one company. In doing so an integrated management process could be achieved for handling user/object
associations which would unify existing concepts that are alike for all expected participators - that implicates
that all of them currently hold and maintain individual applications for handling their own isolated process.
It's needless to mention that the unification of theses processes would lead to an economization even for
future applications. This affects the support for such a process as well as the application administration and maintenance.

Up to here the idea sounds very promising and reasonable. That's maybe why we were commissioned to implement
that piece of software. Unfortunately the project was altered within the scope of the number of participants and
thus in its importance. By reducing the scope to currently one / two partners, the whole idea was definitely
crippled. Although it's crucial to mention that the implication of such a project is the requirement for an even
bigger project that has the goal of unifying the required meta data and management concepts. On the other hand
even that project would lead to a unified concept on a more abstract level.

The question I ask myself now, is how to convince the people in charge of broadening the scope to the one formerly
defined and turn the project into an overall success? I appreciate all comments on that issue.