Satya Komatineni's Blog

Satya Komatineni is the author of AspireJ2EE (http://www.activeintellect.com), an open source web development RAD tool for J2EE/XML. He is also the author of a public contnent managemetn/weblogging system called AKC (http://www.activeintellect.com/akc). He has published with ONJava.com, ONDotnet.com, XML Journal, Java Report, and Java Developers Journal. Currently Satya, in his capacity as CTO at Indent, Inc., is also a technical architect on a number of SBIR (Small business innovative research) phase-I awards. Satya's current research includes CMS/Blogging Systems, Universal Data Tiers, Java, C#, COM+, J2EE, XML,Relational Databases, Frameworks, SVG, Web Charting, Universal IDEs, Transformational languages (JSP, XSL, awk), and Better software architectures. Satya holds an MS in Electrical Engineering from IIT, New Delhi, 1986. The companies he has consulted with include IBM, Millipore, CSX, Ryder, Bax Global, Harland, and TNT Logistics, NA.

SOA Projections, Common Data Models, and eventually Surface Oriented Data Architectures

I admit before writing another line on this subject that I have more questions than answers and majority of my statements here should start with "I wonder ..".

Where i work there are upwards of 500 applications. In proportionate numbers are databases to support them. Services are the answer. A common API is the answer. Probably true. So I define a handful services. Some are queries and some are updates changing the state. Each service will take objects or structures as inputs and emit an object or collections of objects as output or none. Although each service is independent and stateless, the outputs of these services are corelated and taken together presents a well defined object model.

Moreover a query service has to be cogniscent of the amount of data it needs to return, say for displaying in a "paged" portal page. The same query service may also have to take in a "where clause" to constrain the data. The same query service may have to accomodate "sort" and even at times "aggregation" (such as sum, average etc). In short you need a similar (may be smaller) set of semantics provided by SQL.

My hunch is that the "collective" output of a set of related services essentially presents a well defined "Common Data Model". So in a round about way the services originating from "n" number of distinct databases presents the picture of a "unified common database" on the other side. Perhaps what do we loose if this "conceptual datamodel" is to be realized in a physical database backed by a number of "data synching" abilities offered by "Master Data Management" technologies.

Say we do. Say we go ahead and realize conceptual common data model in a physical database with proper synching procedures. Now something like a web portal can take advantage of this aggregated/conceptual database using "horizontal portlets" (ex: SQL query populated in a web page is a horizontal portlet, for such a portlet can work with any data as long as it is the output of an SQL). This is not uncommon for reporting needs today by reporting engines.

I am sure there is a middle road. But the agility of horizontal portlets, well defined data models exposed closer to the end users, query like semantics, need for joins across services are questions to SOA.

The tendency in corporations is to hide all the data as far away from the end user as possible. In what I am calling Surface Oriented Data Architectures the data is migrated or presented as close to the end user as securely as possible. For instance searching music libraries or finding buying patterns in Amazon: I see them all as essential characteristics of a "Surface Oriented Data Architecture" where data migrates to the "surface".

It serves well to remember what inspires

It serves well to remember what inspires. I repeat here a paragraph from Ivan Sutherland followed by links to read the rest.

"I, for one, am and will always remain a practicing technologist. When denied my minimum daily adult dose of technology, I get grouchy. I believe that technology is fun, especially when computers are involved, a sort of grand game or puzzle with ever so neat parts to fit together. I have turned down several lucrative administrative jobs because they would deny me that fun. If the technology you do isn’t fun for you, you may wish to seek other employment. Without the fun, none of us would go on." ..Ivan Sutherland

I came to read this paragraph prompted by James Gosling's Weblog recommending to read his essay on Technology and Courage. I shall not leave a link to the article here as I am hoping you would go there after reading James Gosling's note on it. :)

A False ceiling: What is behind that blanket of SOA?

I believe in working with my children to clean up their rooms. Time is not always on my side, however. So my 10 year old showed me the other day how nicely she had been cleaning up her room. Everything seemed in order until I have come to find she pushed everything under the bed and covered up with a blanket.

It is not an uncommon argument in an enterprise, where the thought is to hide everything behind a bus of SOA. Couple that with the hype where once upon a time CORBA solved all problems and then EJBs solved all problems. Now SOA is on the lips of many that probably have never written a line of code. It is difficult to argue with someone who is not a goldsmith that what is glittering is not necessarily gold.

I have a two story house and it looks fabulous looking up with popcorn ceilings until one day the bathroom upstairs started leaking a bit of water. I thought, "Probably replace a pipe here and a coupling there and that should fix it". Through a tiny hole I climbed up to see. I hope what is behind a SOA wall is rational.

1. I have a suspicion that SOA may play only a second fiddle (addressing transport and discovery) to the synergistic programming triangle of (Objects, XML, Databases).

2. I also feel that SOA is best looked as an "intra" system framework first and then only as an "inter-system" framework.

3. my other web log

Objects, XML, Databases: A Synergistic triangle of the Programming Circle

Three technologies, (Objects, XML, Databases) that have evolved independently seem to be flowing toward a synergistic union. An Object is about behavior. An XML is about structure. A Database is about collections. A Program is like a golden braid that weaves through these aspects.

Objects

Although objects have structure they are seen by their behaviors and defined by the functions they encapsulate hiding their structure. These behaviors are sometimes dependent on their surroundings, environments, or their containers. As a result they are less transportable.

XML

An XML is fundamentally a constrained data structure with rules governing their relationship and binding. Owing to its conceptual structure the syntax of XML is a mere convenience. Whether you define a "c" structure or a "java" class or an "xml" definition they communicate the same data with almost no loss of information. XML is eminently transportable as data tends to be self contained and eventually gets wrapped by object behaviors.

Databases

tables, columns, rows, sql are all apparent aspects of a database management system. What is more subtle to grasp is the role of collections in databases. How to store, search, retrieve, manipulate, and aggregate collections is the bread and butter of databases.

Why is it important to see them this way

Programs live as objects, get transported as XML and become dormant as databases. The more these three aspects are treated in a uniform way the simpler programs are. It is not to say that there are not differences among these three aspects to treat them totally the same. But the role of architecture is to seek and apply what is common.

References

Some relevent and some not, but more of these

Java related notes

Dotnet related notes

html/css related

July 2008

Search this blog:

Categories

Archives

July 2008
June 2008
May 2008
January 2007
August 2006
June 2006
April 2006
October 2005
August 2005
February 2005
November 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
December 2003
November 2003

Recent Entries

SOA Projections, Common Data Models, and eventually Surface Oriented Data Architectures

It serves well to remember what inspires

A False ceiling: What is behind that blanket of SOA?

Articles

Server-Side Typed Event Distributors
Event processing isn't just for GUIs and enterprise messaging systems anymore. Even an HTTP server can be seen as processing a series of events, and it can be advantageous to wire up one or more handlers to each event. Satya Komatineni shows how to build an event distribution framework and what it can do for you. Jan. 26, 2006

A Starter's Guide to the Eclipse IDE, Part 1: Installation and Projects
Installing Eclipse and working with basic Java projects.  Mar. 2, 2005

All articles by Satya Komatineni »

This work is licensed under a Creative Commons License.