With this post I’d like to start a collection of articles about an custom module I always wanted to see in Delivery Server as a standard feature. A feature which should ease the development of web applications using XML (DynaMents) and XSL(T) for the presentation layer, Java (Open API and more) as implementation language for the business layer, and the Delivery Server Content Repository as well as relational Databases as the data layer. Nearly 10 years ago a first attempt was made called the “Application Framework Module”, but it never reached a level of productivity that customers started to use it. I thought it’s time for a second try.
Motivation
Before I dive into details of the new application framework I first would like to talk about my motivation. Why do I think that Web Application Development and Delivery Server belongs together?
- I think it’s a common understanding that today’s internet websites, intranets, and extranets getting more and more interactive which requires applications and application integrations developed in Java.
- In many cases content flow is driven by results of applications e.g. based on a user input and validations an error or success page is shown.
- Validating user input can be realized using DynaMents. But the larger form requests get the more difficult and complicated it becomes with DynaMents. A Java routine does a much better and more efficient job.
- A framework can provide many standard features which will reduce redundant work e.g. validation of requests can be declarative instead of programming it again and again.
- I identified many situations where Java programming based on the Open API was much faster than using many DynaMents and I believe that one Iolet Call will be more performant than 20 Attribute-DynaMents.
I know that it was/is an advantage that Delivery Server offers a non-programming way to fulfill many requirements but that doesn’t mean that it’s the better solution from a technical perspective. So, that should be enough thoughts about my motivation and I like to start with the introduction of my WBF-Framework for Delivery Server.
Introduction of the WBF-Framework
The whole WBF-Framework is implemented based on the Open API of Delivery Server 11.0. A MVC pattern is used to ensure a clear separation of concerns.
The Controller
As entry point to the Delivery Server a Weblet called “wbf” is used. This weblet receives all requests which require an action. So it’s the controller of the framework. Following tasks are fulfilled by this weblet:
- Initially read all application settings required for the validation and execution of requests.
- Receive HTTP requests and analyze all request parameters (POST/GET) and the request URI for the project, application, and action needed.
- Call the validation of all relevant parameters of the identified action and return error codes if validation fails.
- Call the execution of the identified action if validation was successful and return all necessary data for the presentation.
- Forward or redirect the request to the defined result page and provide all response data as XML in request or session attributes.
The Model
Within the action the required data of the model can be read from or written to data repositories. Using the Open API the User and Content objects of Delivery Server are accessible. But there is no restriction to stick to Delivery Server Repositories. The whole world of Java is available to use other data sources like RDBMS, LDAP, and more even in combination with Delivery Server objects. The Action object of the WBF Framework provides request, response and error objects to handle all typical task like validation, access to all request parameters, and writing all results to the response.
The View
The presentation layers is completely based on Delivery Server’s xml/xsl(t) features. Every action response is automatically transformed to XML and provided in the defined scope (request, session). XML contents retrieve the response xml using Attribute-DynaMents and op=”xml”. And then it’s an easy task to render html or json, or whatever text format with XSL(T) stylesheets and templates. All originally sent request parameters are automatically returned and error codes from the validation/execution of actions are also available in a standardized way.
Configuration
The whole configuration of the WBF-Framework is done within a Delivery Server content using content attributes. Following settings are maintained:
- Names of all possible url parameters like project name, application name, …
- Default values for all controller parameters
- IP Address Security Patterns
- Applications and their actions with all action forwards, validation rules, class paths, …
- Authorization information based on Delivery Server Roles and User groups
This configuration data is only read if an hot-deployment is done or the Delivery Server gets restarted and stays in memory for the rest of time.
Debug Mode
In order to reduce development time an optional debug mode comes with the WBF-Framework which allows you to access following information of the last request:
- HTTP request parameters
- HTTP header fields
- Session attributes which live the whole session (called persistent session attributes)
- Session attributes which live only till next request (called transient session attributes)
- User attributes of the session user
- Identified request controller data (web module name, application name, action name, project name, referer page)
- Action forward definition (xml/html and xsl via forward or redirect or action redirect)
- Request log (WBF-Framework specific log entries of the last request dependent on activated log categories)
This helps a lot. If you for example need to know the attribute name of a action response value, you can just find it under “Session (persistent)” and copy it to your attribute DynaMent.
That’s it for the first part. The next article will start with an concrete example and explain step by step the functionality of the WBF-Framework.
Interesting. You call out likely performance gains of native Java vs DynaMents. In your opinion if the contents a very cachable, do you lose out an by going heavier with iolets on overall performance? Any load tests, benchmarks, or anecdotal evidence to support this? Is your framework available to you and your clients or in some other fashion as well?
This seems to be the inverse of what I think some would be curious to see a framework perhaps open the door to JSP, FreeMarker, or JSR 223 style scripting as an alternative to XML/XSL. What are your thoughts on the value of this. Given the Content & Cache API you should be able to replicate at least some of the existing caches for pages rendered from alternative template engines. No? Do you see value in a blending this with your framework?
Hi Tim, thanks for your feedback. First, if I talk about performance improvements, I mean features which are not really cacheable. Of course, pages with DynaMents, which can be cached do not need performance improvements. But for instance a form validation requires lots of Attribute-DynaMents which can be handle with one Iolet much better. I haven’t yet done load and performance tests with my framework yet, but will do that in the near future. Right now I have not yet thought about the source code concerning being open source. Still thinking about possible business models for it.
I designed the the framework in a way that most of Delivery is still used. The major difference is that any request first goes through the framework and then initiates the xml/xsl rendering transferring all results to xchg weblet. But it’s open for other rendering engines as well. There are 5 action forward types right now, but there can be more for e.g. json response, freemarker rendering, etc. I used in an earlier stage freemarker as rendering engine but found it much easier later to stick with DS’s xml/xsl rendering and it integrates better with MS content. Freemarker is now used for generating xml, xsl, html content out of the framework adminstration app in order to avoid repeating work. Combining other rendering engines with content and cache api sounds interesting to me but we should come back to that, when I feel that this framework gets to a 1.0 version. Right now I am happy to reuse as much DS know-how as possible. I see so many task, which can be implemented step-by-step using this framework e.g. URL-Shortcuts, Authorization, …
If you like we can dive into this a bit deeper in a screen session. Just let me know.
Best
Bernfried