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

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/

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/

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/

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