At your service!

The last session of the architecture class was totally devoted to Service Oriented Architectures.
When you think about the fact that this style is predominantly popular these days in the enterprise application area, something sounds quite not right. The idea in this architectural style is to compose a system using services only and services are units of an atomic process which don't have any interdependencies. An application controller will orchestrate these services and perform and enterprise level task. The strange thing is the shape of this pattern, if we can draw the module dependencies, it would look like a central system which is connected to all these other little boxes around it, no box is connected to any other box, like a fish bone diagram maybe. However most modern applications today, if drawn on paper, would look like these layers of inter connected boxes. Will this enterprise architecture change in the future? It might get much more complex with more complex enterprise needs, just like what has happened to desktop applications. They once used to look like fish bones. And this spiral of architectural styles continues on as we progress in time and need to solve much more complex information related problems. Considering the Vitruvian Triad, SOA is currently providing the "Form" for the required "Function", in the near future, "Fabric" will force some changes into it. This has probably happened to building architectures too, they started with specific forms to support functionality and as time passed, some of them changed to provide better quality (fabric), speaking of fabric, I think aesthetics can be considered a subset of fabric too, it is related to quality anyway, a very subjective quality.

The holy grail of SOA is to be able to create any needed system just by composing the already existing components, hmm.... seems very idealistic, and probably true, but in a very larger scale which we might not reach for a long time, isn't this what has already happened in a smaller scale, we create programs only by composing already existing classes sometimes, or even create programs by composing already existing assembly instructions for the CPU. Its just the fact that our atomic significant unit has to be a service, an enterprise level service. Not so soon.

We are currently experimenting with an idea to be able to provide a controller layer for the service orchestration and choreography on top of a work flow engine to handle the state and tasks, this would be a portal with a service bus embedded in it. Laying a form generator and a report generator tool on top of this cake would make a very delicious application builder that is more like a dream come true for most enterprises at the moment. (kind of like chocolate cheese cake with strawberries ... )

Sweeter than SugarCube...

Customer Relationships Management (CRM) has been a hot requirement for the e-business application domains quite for some time now and the number of the clients of Fanafzar looking for CRM systems is increasing everyday.

Most of these clients require the back office CRM features which will be used by the employees, most probably on the local intranet, however they have a few scenarios where the customer will directly interact with the system, usually through a self service portal. Examples for this customer interactions would be online help desks that are integrated with the internal enterprise CRM system.

Being a firm which mostly promotes the open source solutions, we had initiated an integration systems research project code named SugarCube. In this solution the Joomla CMS is integrated with the SugarCRM system. All the back office requirements are provided by SugarCRM and the front end poral is based on Joomla. However, the scenarios which require interactions and communications between these two systems will be designed and the communication protocol between the two is web services using SOAP. The fact that sugarCRM has implemented most of its UI in terms of web services in addition to normal web forms has made this integration quite feasible. The SugarCRM server will be based on the company intranet and it will communicate with the Joomla server on the company internet web server.

The next step for this integration project is using a work flow engine to manage the business processes needed and provide the flexibility for modification of these processes for the enterprise. We've studied JBPM, but some proof of concept prototypes would be necessary before any further design decisions. JBPM being a java based engine would need some web service based wrappers around it to be able to talk to other service providing sub systems, which are mostly PHP based.

Code name was SugarCube since the integration was planned for the XoopsCube portal initially. XoopsCube has got a far better architecture and design structure compared to xoops or joomla open source portal but for practicality, Joomla has been selected for the current project.

SugarCube is coming out of research phase an being implemented for an ISP client these days.

Hope we don't drop it in tea !

The glue that binds it all ....

There are some very nice discussions regarding the psychology of design, thinking methods and definitions and types of architecture in the "Art of Software Architecture" book. Although the author has used the word "Art" in the title, there are very interesting points in the book indicating why the process of design and architecture should not necessarily be an art form. The term here is a follow up to a series of similar names from the publisher. Art usually stems from the inside of the subject and might not necessarily conform to any external constraints, although there are many different definitions for art. Systematic design needs to reduce the uncertainty of the creative thinking process by employing existing patterns which resemble previously thought creative processes turned into defined entities. Architectural styles have been described in this book with this aim.

Three elements have been discussed for architecture, which are know as the Vitruvian triad, since they were proposed by Vitruvius. These are Function, Form and Fabric. In the case of software, function refers to the requirements, form is the actual design and fabric will be the quality.

Other nice to read topics from the book are the concept of complexity and techniques for managing it in software design.

This book is part of the books I've listed for the new class that I'm teaching for the IT department of the National Petroleum Company.

Reposition them to new positions they've never had ...

I was talking to a friend of mine who works in the financial sector in Wall Street, they do financial analysis and forecasting, so I asked him whether they use any software tools for their tasks and he said no since if there is a software, then that means there is something that everyone can do. In their case they wrote specific code themselves for their needs.

This is really important and true. It reminds me of the discussion that exists usually in the profession community regarding the use of a language like VB or C. VB programmers have some features ready to be used which makes life sometimes easier, but on the other hand, this means everybody can use those features. With C, you have to do a lot yourself, but maybe you can do something that others haven't done yet. Business applications can be created using .net language, easily but at the same time this is what lots of companies are doing and you can't be the cutting edge really on this platform, however with C, you can come up with some features that haven't been thought of and that gives you the cutting edge. Does Google use any of the popular web development platforms for its core engine technology? I am almost certain the answer is no.

Se lets try to generalize now. With any tool, you can perform some tasks, but so can anyone else. By knowing a process, you can do something, which others might not be able to, because they have to follow the process exactly like you did, which is not always easy and possible. An example, you buy microwave pizza (an entity) and put it in the microwave and serve it to your friends. The next week you are the guest and your friend serves microwave pizza. How different are the tastes going to be? In a parallel world, you Make a pizza yourself (a process) and eat your friend's microwave pizza, I bet you that you'll be their host forever. (or maybe the reverse !)

Now one more level back, what does it mean to know a process? Well if we know C instead of VB, do we know a process? What about Assembly?
Here goes a definition: "A process is how we arrange some entities in time"
When I can sort 10 numbers (sorting process), I know how to arrange them in time so that at the end they will end up sorted. I am not going to create a new entity. Entities are not created in the world, they all exist, its just how we arrange them in time that makes new things, or at least we think that we are making new things. A new chemical substance is just a re-arrangement of the molecules of other chemical substances. How different is a blank CD compared to a CD which contains a sophisticated scientific software? Anything but re-arrangement of bits on the CD?

Now the second question is : "What can be re-arranged?"

If we are going to create things, we know that we have to re-arrange things. What is the basic element of re-arrangement that we have? Well when you create objects using Lego blocks , your basic elements are the Lego blocks. You things that you can create are confined to the possibilities for arranging these lego blocks. If you you only two simple ones, you can create two artifacts, one when the red is over the yellow and the other one, yellow is over red. This is by far how creative you can be and if you are among 100 other people, that is what almost everyone can do. (Conclusive point : don't try to find out the most talented person by giving them only two lego blocks!)
Even if you have many lego blocks, then you are still confined. (This is why I hated Legos growing up since you couldn't create really cool cars or planes with them.)
You can draw with thin brushes or with thick brushes, on a fixed size paper, can you be more creative with thin brushes or thick ones?
The less granular our tool is, the more possibilities for re-arrangement, and the more possibilities for creativity and less similarity between different people.

C is less granular than VB, Assembly is less granular than C, so it is obvious how each one of these tools can provide the possibilities for new creations.

Conclusion, if you want to be able to do noble things, if you want to be surfing in the forefront waves and be an absolute avantgarde , then you have to rely on good processes, meaning you have to be able to do things in time that others can't follow, meaning you have to select the basic elements as small as possible compared to the context that you are working in so that there is lots of possibilities for re-arrangement and you using your knowledge and skills, can come up with wonderful new solutions.

"So should you use VB or C for your next project if you want to be avantgarde?"
The important thing is the context which you are going to work on. If your goal is an artifact which is made of elements and these elements can be UI elements and some simple Objects, then VB (having ready many basic elements) is going to be the lego blocks that you will use to create that, however if the monster that you want to create is made out of elements that are maybe specific arrangements of data in memory or specific configurations in instruction calls for high efficiency, then your legos should be called C. But of course the possibilities for novel ideas with the less granular tools are more so you won't lose anything by selecting C.

Last word, I am not implying that everybody needs to be on the cutting edge, some have to be, others are just experts that are great in a field, not necessarily unique. There is a nice article here about the differences between an Expert and a Genius.

GameE

I've been lucky enough to get to know two talented coders who have had quite some experiences with OGRE and have lots of shared interests. Yaser and Farzam. We've been thinking about starting out a new project which is an open source game engine. It is in initial studies stage at the moment.
The code name for the engine is GameE. It will not be tailored for any specific genre.
The brainstorming sessions have been on general engine requirements, high level architecture, configuration management issues and things are pretty fun already.

Spiral out

We have faced many paradigm shifts in software systems development. Starting from analysis and design and toward the actual coding methods. There seems to be a recurring pattern generated in each paradigm. We turn a process into a declarable entity. We make procedural or data abstractions. By doing this, problem understanding and solution definition becomes easier for us. By doing this, we are scaling the system, usually in space and downscaling time. By describing a process as an entity, we are ignoring the time it takes for that process to run and look at it as something with state in an instant of time. (a function name, instead of the procedure that it defines)

These paradigms started with pure machine code (specifying the lowest level procedures), followed by assembly (abstracting several machine code procedures into a macro command, an entity with name, callable), high level languages (abstracting assembly commands into a high level command, every entity covers more tasks, has shorten time even more), structured programming(embracing procedural abstractions in the form of functions, to turn a collection of high level commands into an entity), object oriented (several behaviors and state are placed in to an entity - object - and it represents a span of time and also has scaled in size even more), component based design (where the scale is even larger than before).

Recently there has been a lot of talk around Service Oriented Architecture and most recently Data Oriented Architecture which are trying to be the next paradigms for software development. Clearly what is happening is again scaling in size and reducing the sense of time for these systems. Converting some processes in to a declarable entity that doesn't show time in its definition.

If we look at it from the outside it seems like a spiral moving in time, repeating the same kind of pattern but in larger scales and for larger problems.

Now how come we have been able to shrink the time factors so much and still feel the same time is going by when we work with a software system? Well, clearly Moore's law has been the helping factor.

Refactoring

It has been a few days that I have looked back at the topic of rafactoring and it has kept me thinking. Well first of all Martin Fowler's Refactoring book is great.
I've been thinking about the range that refactoring can be applied ... whether there can be any limits to code refactoring ... how will the most refactored code look like after several refactoring rules performed on it ... how well can this be done automatically ... and so on.

This has been something that has been happening constantly and is happening for the game project.