On the importance of avoiding success... to have enduring success; The J2EE case

There was a time -at the beginning- in which Java was an interesting language.  It was possible to download the libraries at run time. It was a C++ for internet.  There were things like ObjectSpace Voyager, that fifteen years ago embraced cloud computing (agent computing at that time) with movable code across the internet.

But shortly after, Java  was hijacked by  maniacs of databases and database-centric developments. That crap called J2EE was born, with their Cobol-istic names and their unnecessary complications of dependency injection, their clustering by manual configuration and by their infinite chains of beans repeating essentially the same code, in endless communications by RMI to the host next to it in the LAN to read a simple register of the database. That poor copy of Microsoft DNA has dominated java development in the enterprise until today.   In the meantime, other standard for web programming, web services and so on,  big, complicated and with lack of innovation  have been developed under the Java platform.

All these business problems that J2EE tried to solve, could have been solved with ObjectSpace Vogager with a tenth of the code and with a fraction of the infrastructure necessary under that J2EE gold fever, but the businessmen and the innovators where in the hands of Software development departments, and both could not communicate. The software departments seek power and size, and that means bloated code, a lot of subcontracted people, buzzwords and a platform with which any mediocrity could call himself a "guru" or an "architect", and legions of configurators, maintainers, prescriptors and so on. And that was generously given by J2EE.

I´m developing clustering and fail-over functionalities for MFlow using cloud haskell. And immediately I remembered that precious gem that was ObjectSpace Voyager. It was an agent-based java platform that was unbelievably powerful... except that  it did not worshiped SQL databases.  And  these are the few references that I got.  I notices that his creator, Graham Glass, resigned as CEO and  chief developer of the company at the peak of the popularity when the short-term oriented people in his company voted to join the B2B bandwagon -that was in fashion at that time- instead of continuing ObjectSpace as a company devoted to develop a general network business platform. The company went bankrupt the next year.

The rest is history. Sun created the J2EE crap. BEA-Weblogic made a lot of money selling his crap J2EE Application server to software departments willing to eat money and resources from the rest of the company, SUN did the same with their overpriced servers.... And finally all of this went where it belonged from the beginning: to the One that J2EE and development deparments worshipped: the SQL database. Oracle took over.

Oracle will go to death.  And that will be the end of that nightmarish cultic gnostic religion.

Let's start again, but learning the lessons from the past

How Haskell can solve the integration problem

Will show how long running tasks, Web apps, workflows, EAI Orchestration and BPM applications share the same underlying problem: The "integration problem", that only haskell can solve with more simplicity, generality and maintainability

Creating a single application in the imperative style is easy and intuitive, because the programmer is in control of the sequence of things to do. But when it comes the time to integrate two or more autonomous entities that send events at any time in its own sequence then is when the programmer is not in control, so a different programming model is necessary. Such problem happens when trying to integrate the users with backoffice applications via web applications, but also when it is necessary to integrate two or more backoffice applications, company departments, web sites, web services etc.

The standard model that solves this inversion of control problem has various names but esenstially is the same architecture with different names: finite state machine, state-transition system, a state machine system or a event handling model. That is the architecture of the main web frameworks, Enterprise Application Integration (EAI) frameworks, Orchestration frameworks, Workflow frameworks, Service Oriented Architecture (SOA) frameworks and Business Process Management (BPM) frameworks, that solve respectively, the individual above mentioned integration problems.

See the tutorial at

https://www.fpcomplete.com/user/agocorona/how-haskell-can-solve-the-integration-problem

With a practical example.

10+ things that you can do with MFlow and you can't with your Web framework

1. Create test, integrate and install your logic without concern for layout. Edit your forms, widgets, style and content at run time.
2. Convert your application from single page to multiple page and back with little code modifications
3. Make forms that change their questions depending on your answers.
4. Make a cascade menu with dynamic options programmatically in a single procedure
5. Make an element of a page to refresh itself by adding a single statement
6. Make an element to push its content with a simple modifier
7. Press back as many times as you like by default
8. Write a payment flow with some pages and seamlessly drop it whenever you need it
9. Write an active page element with his own server code, JS, CSS in a single procedure and seamlessly drop it whenever you need it
10. Write your routes and control logic as in a console application. No spaguetty callback code
11. Transparently store and retrieve session data for as long as you wish
12. Make all of this without writing a single line of javaScript code. Although you can add it.
13. Make all of this in a type safe way. If your app compiles, it works.
14. Make (almost) all of this work with or without javascript activated.
15. Make all of this in an architecture that is horizontally scalable (although not implemented such scalabiltiy yet)

Quick Start : Basics for understanding and using MFlow

Quick Start 2 : how to modify an application to add dynamic effects: implicit ajax, push etc.

MFlow site:  http://mflowdemo.herokuapp.com

Learning from the Haskell compiler

Haskell programming is naturally one level of abstraction above other languages either functional or not. It is not the functional paradigm. It is the type inference and, specially, the category theoretical grounds in which the language is based, for which functional and imperative paradigms are particular cases.

The extra level of abstraction means that you are one level up in the tree of possibilities. For example, you can define the very meaning of a sequence of statements in a Monad Instance. That, in other languages is fixed.

That means that you have a extra level of things to learn and explore. For example I created a DSL for web applications time ago and still I´m learning my own language. Sometimes my programs type check, but they do not perform what I was expecting, But it does other interesting thing. The code was a product of my own misunderstanding or my lack of concentration, but the type checker say: its valid, let´s run it. Then I check it again and voila, when I examine the program I discover a new usage of the same elements I defined that I never though previously possible.

Sometimes the error messages tell me new instances of things that I would never though about. Some of them seem crazy, but after a second though, I find that is not as crazy as it seems but, sometimes I´m not willing to accept yet another extra level of abstraction that my compiler is suggesting as result of an error.

For beginners this flood of information is confusing,as well as for expert programmers they just want their job done, but thanks in part to this interaction I´m here talking about abstract web combinators when what I initially needed from Haskell was the fsstest way to see "hello world" in a web browser.

More composable elements for single page development: witerate and dField

witerate,  is a new primitive that permits to iterate the presentation of data and/or input fields and widgets within an web page that does not change. The placeholders are created with dField.  Both are widget modifiers: The latter gets a widget and create a placeholder in the page that is updated via ajax. The content of the update is the rendering of the widget at each iteration. The former gets a widget which contains dField elements and permit the iteration. Whenever a link or a form within the witerate widget is activated, the result is the placeholders filled with the new  html content.  This content can be data, a input field, a link or a widget. No navigation happens.

This permits even faster updates than autoRefresh.  since the latter refresh the whole widget and it does not permits modifications of the layout at runtime. When edTemplate or template is used on top of witerate, the result is editable at runtime, and the span placeholders generated, that are updated via ajax can be relocated within the layout of the template.

Additionally, contrary to some javascript frameworks, the pages generated with this mechanism are searchable by web crawlers.

This example below, taken from the runtime templates example, shows how template, witerate and dField work together. The example iterates the presentation of a list of results fby displaying four of them each time. The list can be navigated forward and backward. (see the example  running and the full source code here).

These are two pages of the example with the templates beind edited at runtime. The first present results and the second is an input form managed the same way. Since the pages are not refreshed, this permits very fast input and presentation of results.

The full post explaining everything is here:

http://mflowdemo.herokuapp.com/noscript/wiki/singlepage.html

See the page and the full source code here

About client-side frameworks

Before any consideration about either client-side or server side framworks are good for one or other user case, you, as a programmer has to answer a simple question: is the Web browser a good development, integration, test and exploitation platform? My response is: No.

I love JavaScript. I programmed AJAX applications using hidden frames 13 ago, before this technology had a name. I regularly used client side technologies for editing documents, for example, Google Docs. But what makes great Google docs is the server integration of many client and server side developments.  

You finally must integrate different aspects of your applications: user data, different client-side applications , snippets to compose workflows and you have to decide where you integrate all of this.  Either you integrate it in the server of in the client.  if you do it in the client, you hardly will do multi-user stuff. you will not have a type safe, fast, multi-threaded environment under your control. You are restricted to the single threaded, single user javaScript environment. if you use some framework above that you still are restricted to the limitations of the JavaScript virtual machine and development environment. 

There are lots of client side frameworks that promise a declarative extension of HTML, but if you look at AngularJS, you will see a lot of JavaScript code, with all the big complexities of big server side frameworks, but, looking at the examples, these frameworks are devoted to present server data, in which they add little  additional advantages, except perhaps less server-client traffic. A server side framework can do it as well with adequate use of AJAX, (see this)

To summarize you have the problems of two tier architectures, the thick client problem aggravated with less power of the sandboxed environment of the web browser. Until you load all the client framework, the first page display can experiment delays. Although this could not be a problem in intranet environment where two tiered architectures have been good for a limited number of users, that is specially critical in applications with a casual usage pattern, such are all Web applications.  The dynamic HTML is not searchable. You must see how Twitter had to revert to the server side.

You may think that a server with application logic and a MVC event driven logic in the middle tier, can solve the problem, but, simple speaking, the business applications are not stateless. Neither you can store the state in the client allways. Have you seen a flowchart?, a user requirement document? all of them are filled with steps. Specially in a corporate environment, where it is necessary to integrate different software elements, departments, databases etc, much of the integration of different modules with the corresponding interfaces must be trough an stateful application that present different interfaces.

The question is not either client or server side. Both parts must believe that they are the center of the development. the user too. When you are programming in the client, you must think client centric. when you are in the server, you have to feel server centric. The intelligent way is  make everyone: The user, the front-end programmer, the back-end programmer, the integrator, to feel that they are the center of the development.

And the development process in which each one works at the highest level of productivity and abstraction is when you can package server and javascript functionalities that work together in easily pluggable, self contained widgets for the user interface. With these widgets, let the application programmer to compose single-page applications and finally with these single-page applications, integrate them in stateful workflows that accomplish the whole user case.  That is the aim of MFlow.

Change the content & layout of an active page with WYSIWYG at runtime?

It is possible modify the layout of the active components at run-time. This means that no longer is necessary to code a layout for a formulary,  or for the arrangement of different widgets. 

Just create them without layout, and later the people in charge of the layout and styles will arrange the layout and the texts when the application is already tested. Then the layout never pollutes the code, and it may be decoupled also in time. 

The layout can be edited in a more powerful editor and inserted again and so on. As long as the designer do not modify the tags of forms and links created by the application, everithing goes fine. It can insert wathever content, formatting, apply styles etc.

The validation errors in the formularies must be presented via Javascript however. The example uses a simple javascript alert to present an error when the message entered in the form field exceed a certain length

http://mflowdemo.herokuapp.com/noscript/templates/runtimetemplates

The example list the names entered in a input form, but at the same time it permits the edition of the three pages: The first page has links. There is a page with a form for entering a new name and the content of a list of results.It uses edTemplate and edTemplateList, two new primitives for template edition.

Log in as edituser/edituser to edit the pages using the login option. Log out to see the resulting layout. The edited layour has additional information about how it works.