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 ... )