You will find on this website publications about informations technologies. The content is available in french and english.

dimanche, 16 mars 2008

This website's implementation

My needs during the setup of my personnal website on which you browse right now are the followings :

  • Allow me to carry my publications in french and english
  • Have a blog style for the interactivity and organization
  • Host my CV
  • Allow me to carry longer documents outside the blog in order to have a better lisibility by a larger screen size
  • Be easy to administrate and use
  • Be implemented in Java to facilitate the modifications (it is a language that I know very well)
  • Have a cool design

I get to the following software components selection :

  • Server under Ubuntu linux for the softness and strength of this distribution
  • Blojsom for the blog tool. It needs some modifications to integrate two publications languages. Its goal is to be simple, it save posts in files, it allows me to modify post with a simple text editor (jedit). I also add the Xilizeplugin to Jedit that allow me to write articles in a simple language and then transform it in HTML with a simple click.
  • Sitemesh for the HTML documents decoration with the same page design
  • Apache in front with a redirection towards Tomcat that host the previous components.
  • subversion for the source and posts sharing between my differents machine
  • Awstats for the web stats and Munin for the server monitoring
  • Mon.itor.us for the external monitoring of the server
  • Leaves design found on the Open Source Web Design site and integrate in a Blojsom template wrote in Velocity.

The machine that host the whole of the site is one of my forme desktop PC reconverted in a silent server. This machine has thus the strict minimum components :

  • CPU Athlon thunderbird at 800 Mhz.
  • 768MO of RAM.
  • 200 Go hard disk.
  • A big silent Zalman fan with a potentiometer for reducing speed to the minimum during winter and increase it during summer.
  • A CD player.
  • A fanless power supply Antec Phantom.
  • There are NO graphic card, sound card, keyboard, mouse, monitor, etc. All the administration is made remotely with SSH.

The whole is connected on my router that exhibit the 80 port on the DMZ itself connected on the freebox modem. The Free ISP give me an upload rate of 100ko/s largerly sufficent for my present needs.

Posted at 5:08 PM in en/Technologies/

dimanche, 7 octobre 2007

Architectural assets

Peter Eeles published on the Rational Edge eZine an excellent article concerning the “assets” which the software systems architect uses trough his job. I find this article extremely interesting because it formalizes well these assets which one uses implicitly. This formalization provides a good base to structure our realization and stock of knowledge. The central point of this article is the description of each metamodel element.
Which are thus these assets that composes this capital ?

  • Patterns: architecture, design and programming
  • Architectural styles
  • Reference architectures
  • Technical frameworks (an implementation of J2EE) and application frameworks (software package like SAP or Siebel)
  • Existing applications
  • Components library

Can one identify other assets? for my part I would add the “example or reference implementation” asset which one can possibly classify like an example of implementation of a reference architecture (for example the “Sun‘s Pet Store”: http://java.sun.com/developer/releases/petstore/ or “Oracle‘s Virtual Mall Shopping”: http://www.oracle.com/technology/sample_code/tech/java/j2ee/vsm13/index.html ).

The granularity and completeness characteristics identified by Peter Eeles to categorize these assets are interesting. These axes are located nevertheless at the model level. If one instancize this model and leads to a set of architecture components, an important characteristic for these components in the broad sense (pattern, software component, architectural style) is the maturity and the experience feedback we can have with respect to a component in particular.

Finally, I think a formalization effort is always welcome to structure a field knowledge. When this formalization is shared by all is even more appreciable, so the interest to see the OMG proposing a specification on all of these reusable assets from the information system.
Besides, like says Peter Eeles, in order to work on the life cycle of this assets base : how to create them? how to re-use them? how to set up an organization and a culture of re-use and sharing. Here, we attain the central characteristic of knowledge job like our: tha architect capacity to set in music in a creative way its knowledge and experience, in short its competence. To conclude this post, I would add that this is this creative part, always too few to my taste, which makes our job interesting.

Technorati Tags:

Posted at 11:28 AM in en/Architecture/

dimanche, 10 juin 2007

SOA essential concepts

The implementation of a Service-Oriented Architecture, SOA to use the buzzword, is now frequent. Theses implementations leads to healthy thought about it. After a first phase of spreading and clarification about what is SOA, some acceptance is setting up. So, we now find the principles that guide that architecture, the expected benefits, a method (in french...) and of course the vendors products that will help the implementation (the verb “help” is important because theses tools are not magic).

Layered architecture

That architecture first leads to ask real background questions about business formalisation and put system architecture in frontline and that is salutary.

What is also interesting in my opinion is the paradigm change at work with this architecture. I'm interested in the abstraction level of the concepts that we use and the SOA clearly give a high place abstraction level very noticeable. What are the concepts that we can consider as essential for SOA ? :

  • The concepts that form a process : activity, transition, synchronization. These concepts are important because they put emphasis on the process design at a macro level with possibility to implement those process directly. It goes along with the come back of the functional languages, we can say that the function goes ahead the data that was put too much in the frontline with the object approach.
  • The event : fundamental concept for a dynamic modelization worthy of this name and largerly sub utilized by UML.
  • The composition : the object approach essentially give to this notion a structural vision. A more dynamic approach is given by the architectural style "Pipe-and-Filter".
  • The service : the service is the unitary element of this architecture because it is the interface of the underlying unitary system (and if possible, implemented with an object approach).
  • The data : it seems evident but this very large concept has evolved to such an extent that I permit myself to flow it as a fundamental concept. The web and the XML language are greatly involved in theses evolutions. The Adam Bosworth's article concerning the background changes at work in data structures is an excellent vision for that.

Hence, these five concepts form, in my opinion, the foundations of SOA Architectures. You will find some transversal concepts but that stay for me secondary and less structuring (service registry, rules engine, service management and monitoring, etc.). Nevertheless, a very important principle occuring during implementation, so that does not help to modelize, is the standard respectness (XML, WS-* or web with REST architecture, etc.).

This post was inspired by the one from Gregor Hope on SOA patterns, I agree with him on the first three concept but, to my mind, the declarative approach does not make any paradigm change because it is in place for a long time (SQL is the most famous exemple).

Technorati Tags:

Posted at 3:27 PM in en/Architecture/

dimanche, 27 mai 2007

Language expressiveness and competitive advantage



RailsConf is over and Martin Fowler posts his feedback. The general tendency is here, the expressiveness power of dynamic languages, gives them a more and more significant spread. As Martin Fowler says that more than 40% of their business in United-states use the Ruby platform. There is of course a bias from the Thoughtworks, the compagny Mr Fowler works for, positionning on this technology but I think that this tendency is well confirmed.
The Java platform has clearly a playing card and Sun has well understood that. On the technical side with the integration of the JSR-223 to Java 6 et JRuby as well as the promotion side with Sun‘s sponsoring for RailsConf.



The release of JRuby in a general availability will surely give a kick-off to a more lively interest. As a notice, Groovy has some leg up in terms of implementation. From a more general manner, the Java execution platform can become an infrastructure foundation and the host environment for another languages. The Java platform fullness is preserved but with an opening towards tools more adapted to specific tasks (Ruby and Rails for the web development for example, a small wink to Gilles who started with this technology for his project).

The expressiveness power is for me one of the main competitive advantages of programming languages. With this comparison, the dynamic languages are clearly winners. Nevertheless, beware to these metrics that can gives to Domain-Specific-Language an important expressivity measure but with a lack of softness. Hence the interest in metaprogramming techniques from these dynamic languages that permit the best of both worlds.

The predominence of advanced programming languages, like dynamic languages, in the evolution scale is on the march even if this evolution stays slow.

Technorati Tags:

Posted at 7:09 PM in en/Technologies/

mercredi, 28 février 2007

10 design principles and SOA

Following my publication about generic design principles, I stumbled upon this article from Stefan Tilkov on InfoQ about 10 principles of SOA.
For each principle of SOA, here is my parallels :

  • “Explicit boundaries” : every service should be auto-sufficient and not depend on a shared context. In brief, it is the principle of state reducing.
  • “Shared Contract and Schema, not Class“ : Minimize the structural dependencies, here by using XML document.
  • “Policy-driven“ : This principle describe the agreement between a provider and a consumer, from a functional point of view as well as a technical one. I did not describe this notion, especially the technical one, as this a SOA foundation principle : the accommodation to heterogeneous technical environment.
  • “Autonomous” : here I would say rather protection des variations.
  • “Wire formats, not Programming Language APIs“, “Document-oriented“, “Loosely coupled“, “Standards-compliant“, “Vendor independent” : all these principles deals with minimizing dependencies with : the use of standard format and protocol (XML, http), evolutive data format, use of standard and not using proprietary features.
  • “Metadata-driven” : use of registry and if possible self-description of services by their naming.

Technorati Tags:

Posted at 11:53 PM in en/Architecture/

10 design principles

I just published an article about generic software system's design principles. I tried through this article to summarize some principles, ones well-known like encapsulation, another too often forgotten like variations protection. I hope this principles will be useful for you as they are for me.

Article's table of contents:

Technorati Tags:

Posted at 11:18 PM in en/Architecture/

mardi, 28 novembre 2006

Languages war

A typical controversy subject, the programming language choice can somewhat appears as secondary. Yet, a language always brings its paradigms that will influence programmers whom use it. The most common programming paradigm in IT business applications are imperative programming and object-orientd programming. Functional programming stay confined to very restricted domain (research, geeks, etc.). The most known and old one, Lisp, did not really make a breakthrough. Nevertheless, Paul Graham talk about his success with Lisp.

The functional paradigm make a breakthrough recently

This breakthrough has its origin in :

  • The success of languages that integrate a functional approach. That‘s not the language itself which is popular but the possibility that are associated. Ruby is popular thanks to the fabulous web framework Rails, Javascript thanks to the Ajax phenomenon.
  • The functional approach‘s ease for parallel execution processing. Google and his implementation of the famous Map and Reduce is a perfect example (even if it is implemented in C++ and I will come back later on this point). With the generalization of multi-processorsmachines, this subject will become more and more major.

The Java language weakness

These spotlights pointing functional programming show up the weakness of the flagship language of these last years : Java. Although having several matured programming paradigms – namely imperative, object-oriented, generic from the 5.0 version and multi-platform – Java is cruelly missing the functional paradigm. The concurrent programming paradigm is fulfilled with the superb library integrated to the platform from the version 1.4 : java.util.concurrent. At last, Java is quite conservative concerning the typing discipline with a strong and static typing.
As a summary, the Java language weakness are (and I speak of the language and not of the platform..) :

  • static and strong typing are too conservative : Bruce Tate wrote an excellent article describing the different binding mechanisms (binding mechanism deals with link between a declaration and an implementation, often through a type) implemented in every programming language and he points the finger at the "common" Java frameworks like Spring and Hibernate. He describes theses frameworks as a replacement for mechanisms natively found in dynamic languages (on-the-fly byte-code generation, dynamic proxy, classes decoration). I want to show the famous picture from Dr Larson, that summarize very well the hearth of the matter :
  • no functional paradigm : a Java function is always linked to a type and is not a first-order object. It is not possible, in Java, to pass another function to a function without using a type (The closure concept does not exists). Steve Yegge, always present, has signed a brilliant post on this subject : Execution in the kingdom of nouns.

The Java platform power

The Java platform and not the language itself, is still one of the most powerful execution platform. The Java ecosystem is one of the richer at this time with a very high number of external librairies. The advanced platform characteristics with Java EE are mandatory for high-demand environment (clustering, distributed transaction, security, messaging, web services, etc.). The Java platform stay adaptable even if the processus can be lengthy and restrictive. The JSR-223 is just aiming at defining the interaction interfaces with a dynamic language (often called script language) while the JSR-241 define a language that merge the characteristics of Ruby, Python and Smalltalk (quite ambitious !). At the same time, projects like JRuby, sponsored by Syn, or Groovy, aim at using the Java Virtual Machine as an execution container for this languages.

The competitors

Java is currently sustaining a strong push from more advanced languages. This push is due to their inner capability but also from theirs platforms. Theses competitors are named Ruby, Javascript or Groovy. I leave aside Smalltalk , Python and Lisp which are missing the small "flash" that can make them really popular. I also leave aside the 8512 minus 7 other programming languages that human being has spawned…

Ruby

Ruby is the start of-the-moment, notably thanks to a web framework named Ruby on Rails, which known how to exploit all the Ruby dynamic language possibilities and also be very pragmatic (configuration by convention, code generation, common directory structure). Sun has hired the two main JRuby project developers aiming at offering a Ruby interpreter written in Java and allowing an interaction between these two languages. Grails can be considered like an example of how a dynamic language and an older “host” language can interact.

Groovy

Groovy's strength is his proximity with the Java syntax and his already deep integration with the JVM. The JSR-241 deals with the groovy's standardization. The Rails equivalent is also available for Groovy and is named Grails.

Javascript

Javascript is an advanced language despite the "web gadget" a priori and is coming back on the foreground thanks to the Ajax phenomenon.

Forget the programming language and concentrate on design

This programming languages inventory is for me an introduction to the essential activity : Design. The languages and the different paradigms must be considered as an intellectual tool and not as a simple way to implement a processing. Whatever implementation you choose you will succeed to surpass, with more or less readiness, the language weakness. So, you can implement a functional approach with Java by giving interfaced objects, do meta-programming with reflection and on-the-fly byte-code generation (this is what do Hibernate for example), do late binding with Spring.

The most obvious example is still the Google‘s search engine‘s implementation that use techniques from the functional paradigm to address their problem (parallel execution processing on a large amount of data). The implementation is done with...C++, a language far away from the functional paradigm. Another quite well known example, the implementation of the X windowing system was designed in an object oriented manner but implemented with the non object C language.

I predict a handsome future for the dynamic languages, it is in the logical way of the language evolution towards a more and more expressiveness power. Which one will carry off ? ...difficult to say. I think Ruby has good assets and enjoy the (light…) Sun‘s support. Javascript and Groovy have a very close syntax with Java and can be outsiders. Wait and see.

I intentionnaly omit C# from this comparison because it is very close to Java and then is not relevant to this comparison. Also, it makes me avoid to get in the traditionnal Java vs .Net war.

Technorati Tags:

Posted at 8:33 PM in en/Technologies/

mercredi, 1 novembre 2006

REST : a scalable architecture

During architecture definition, we have to choose what will be the differents concepts and principes.
They can be evaluated in a qualitative manner with differents aspects, but a “validating” major aspect is the scalability, that‘s to say : does the built system can handle an important load without major redesign ?
Scalability with computer can be get notably with a non exponential use of resources as one goes along the load increase. The reducing of the system generated states is one of the answer to this problem. That‘s why the functional languages are interesting, but it will be the subject of another post.

So considerated, the REST (Representational State Transfer) architectural style answer quite well to this challenge. This architectural style is the web one. This style is based on the stateless protocol HTTP that offer four "verbs" GET, POST, PUT and DELETE on resources Theses verbs are very close to the CRUD well known in database. Each one represent a particular action that modify or not the system state. Then :

  • GET : this action is idempotent et does not modify the system state. It is similar to a data read.
  • POST : modify the system state and is not idempotent, example: adding an item to a basket or the validation of the basket. These datas aren‘t part of the URI.
  • PUT : create or modify a particular resource but is idempotent.
  • DELETE : delete a resource.

REST was initialy proposed by Roy Thomas Fielding as his PhD's thesis .
So REST is an architectural style that is simple and very robust, validated by the web experience and that can be combined to the power of the XML language. This post was inspired to me by those of Eliotte Rusty-Harold that ask some questions of practical interest very interesting about REST and the use of the HTTP protocol.

The REST style is effectively simple, but is it sufficient to build complex interactions and avoid to move a major part of the applicative logic onto the client ?
A very interesting example is given by this article that provide a REST translation of a mail service, this example illustrate all the importance of correct resources identification. The parallel with the object approach is also decided concerning the resource representation.

Some links to go forward on REST :

Technorati Tags:

Posted at 10:54 PM in en/Architecture/
portage salarial freelance