Friday, April 04, 2014

Towards a deeper integration: A Web language

When I wrote the article "How to solve the integration problem", in which I assimilate web development to a general integration problem, I was not fully conscious of how true it was. Web development is becoming increasingly a problem of integration of different technologies, languages paradigms and applications. Consciously or unconsciously web developers view web applications as a problem of integration. as essentially the development and integration of two or three independent applications: one in the browser, other in the server and maybe another in the database, with a dozen configurations that glue these things together.

That implicitly precludes the effort in the search for a higher paradigm that can be found by a deeper integration. That leaves essentially unresolved the problem of creating a true Web framework: A Web language. A framework in which the fundamental building block has data navigation presentation and storage and whatever other thing necessary inside itself. This building block that has all the components integrated, may be composed to build true web applications.

The situation is similar to the time when there were only batch systems.  There was no unification of input, processing and output. the programmer created a job  in a set of punched cards. The output of he job was sent to a printer. There were no interactive input-output. there were a input program, a processing program and a printing program. The applications ran essentially in the same way as a stateless web service  work.

Then, interaction was added. both input and output streams were intermixed. state was added. Each programming component may alternate repeated input and output interactions. When there were previously only batch processes, then there were development environments, shells, games etc. 

The building block for console applications had a higher level than the one of previous batch developments. The programmer managed abstractions in terms of the problem not in terms of the phase in the process in which the batch was executing for the hardware needs. That was because a new composable piece was found: the IO procedure, that combined input and output. The IO calls were a product on this revolution. that was a true revolution since it was an inversion of control where the program was in control of the flow. And a new kind of application was born: the interactive console application.

But essentially the IO procedure was the combination of small batch programs: the OS and library calls.  We don´t think on these small pieces as programs. we are so accustomed to work with pieces at a higher level that we do not even consider that. 

Can we do the same for the Web?. One may say that this new de-inversion of control will produce problems of scalability, state handling etc. All this is true. But they are the very same problem that the Operating systems had when switched from batch to interactive applications:  the batch systems did not leave state behind. They were fine and reliable. But people though that batch systems were not enough.

Can we do the same for the Web?. Unlike console applications. In Web applications the user must be in control, not the program. But the programmer must feel that he is in control of the flow.

That is not only possible, but highly desirable. If the fused building block is composable, we would have the Rosetta Stone of integration, a new unified language upon which to talk at a higher level with the machines for building web applications and since web applications are a particular kind of application integration, we can extend it to any kind of integration problem, as I mentioned in the article above.

Furthermore, if the building block and the composition make use of well known ideas then the task of making that language understandable becomes far more easy.

And now the marketing part. Excuse the bombastic tone, required in any marketing activity:

In the article mentioned above, I claim that MFlow do it. It is a Web language.  The MFlow building blocks are the widgets and the flow elements, (flowlets). A widget is an applicative or monadic piece of code with  a parser of request parameters and a writer of HTML code. It combines the creation of rendering, request parsing, processing and session management among other in a single atomic composable element. In the other side, a flowlet manage reusable and composable flows of pages, with state management.

People that know how to program monadic parsers will find natural how the MFlow monadic widgets works. People that know how to use formlets will find natural how applicative widgets behave.  If an user know how to create imperative code, he can create page navigations.

And the deep fusion of elements will give the opportunity to create easier solutions to known problems.

Soon I will add composable caching directives to MFlow, where a widget can express its own HTTP caching needs to the page, and I will show an example that uses this for caching javascript programs generated in the server by the haskell code to navigate a dataset without repeated accesses to the server.

Stay tuned.

Monday, March 03, 2014

Single page apps with better than HTML5 storage using MFlow

See this article without the extra newlines introduced automatically by  blogger

http://mflowdemo.herokuapp.com/noscript/wiki/caching

In the latest version of MFlow, the autorefreshed widgets (the ones that use autRefresh, appendUpdate and prependUpdate) can be cached. The advantage is that there are no spurious round-trips to the server to get fragments of pages  that already have been sent. 

The goal is to avoid to  access the server except whenever a heavy front-end framework would have the need to do it: when there are something new to get from the server.

While JavaScript frameworks rely on heavy Javascript programming using the lattest HTML5 API storage facilities, MFlow relies on  HTML fragments, retrieved using GET queries. They are stored in the browser HTTP cache.  The HTTP caching  works for you, The amount of programming is reduced drastically in relation with JavaScript frameworks. and the effect is compatible with all browsers.

See for example this  piece:

 showProducts= autoRefresh $
do  absLink IPad << b "See Ipad models"
            showModel IPad
<|> do  absLink IPod << b "See Ipad models"
            showModel IPod
     

Shows initially two links to two products. Since it is autoRefreshed, the fragment refresh itself when one of the links is pressed. When the user press the first of the links, by the definition of the Monad instance (see this) the code that follows it is executed, so the rendering of the model appears. 

When the other link is pressed, the rendering of the second model appears, and the first collapses. (see the links section of the wiki) .  

When the first link is pressed again, since the former was a GET request, if it is cached by the appropriate directives, there will not be a call again to the server. The fragment will be read from the browser's HTTP cache.

That is how  MFlow can perform the caching that the Javascript frameworks do with heavy HTML5 API programming

MFlow has the setHttpHeader  call that, as the name tells, set the HTTP header directives. 

setHttpHeader :: MonadState (MFlowState view) m
            => ByteString -- ^ name
           -> ByteString -- ^ value
           -> m ()

It is session-wide, so if you can put it at the beginning of the session. You can change it afterwards whereever you like. 

For example, this site now has a directive:

       setHttpHeader "Cache-Control" "public, max-age=300"
This caching permits the options on the cascade menu on the demo to be filled without invoking repeated roundtrips to the server.

http://mflowdemo.herokuapp.com

More fine control on HTTP caching will be developed. A component-based framework like this can mix pieces with different inherent caching needs: A widget that show private information inside a general container widget with less restrictive policy must respect the more restrictive directive automatically. 

Saturday, February 22, 2014

Parsec-like expressions to read web service parameters and generate the response

A haskell formlet is the combination of a parameter parser plus a writer to generate HTTP output

I use this similarity to create parsec-like combinators that use the formlet monad in MFlow (the View monad)  to parse the web service parameters and to generate the output.


This service below implements a service that sum or multiply two Int-egers.

main = runNavigation "apiparser" . step . asks $ do rest "sum" ; disp $ (+) <$> wint "t1" <*> wint "t2" <|> do rest "prod" ; disp $ (*) <$> wint "t1" <*> wint "t2" <?> do -- blaze Html h1 << "ERROR. API usage:" h3 << "http://server/api/sum?t1=[Int]&t2=[Int]" h3 << "http://server/api/prod?t1=[Int]&t2=[Int]" where asks w= ask $ w >> stop
See a more complete explanation and working examples here:
http://mflowdemo.herokuapp.com/noscript/wiki/webservices
By the way:
The blogger editing system is the ugliest and unfriendly thing invented by mankind. It is not worth being a Google product. The feedback link does not work.

Friday, January 17, 2014

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

Sunday, December 22, 2013

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.

Friday, November 15, 2013

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