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

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

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

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

Phrased differently, if I have a jar file that contains an interface and the domain objects that support that interface, can I access one of its implementations that is sitting on a remote machine using a dynamic proxy. The protocol can be SOAP or EJB or just a plain homegrown over http for that matter.

Stated differently, if I were to implement a service layer using plain java interfaces and implementations, can I break that layer apart at deployment time with out involving any compile time changes. Such an option will give me the ability to multi-tier an application with very little fan fare. Programmers need even not know about SOAP or EJB etc.

For instance WSIF (web services invocation framework) seem to advertise a functionality that is similar in intent. But someone expereienced with WSIT comment on whether all you need is interfaces and domain objects? Also WSDL seem to be necessary for WSIF to work. Can it work with out any xml artifacts and assume a certain SOAP implementation and provide a dynamic proxy for it.

I am hoping someone out there looked into this before and I would like to hear from them. Either you can post the answer here or if you don't have an account, could you email me your opinion? My email is "satya at activeintellect.com".

Thanks in advance for considering this.

"I fix myself an Omelete, sir,
Of fluffy clouds, and sky
...
I sew myself a warm cloak, sir,
of hope and daffodils."

Unlike this fanciful dilemma of "Poor Angus" of Shel Silverstein, in large IT corporations HTML prototypes can play a much more significant role. They can aid faster development times. They can secure budgets. They can encourage good architecture. They can directly lead to a number of development artifacts such as data models, and business services. I think prototypes offer another important aspect to the modern development process along with the Extreme Programming and RUP.

HTML applications are conducive to prototyping ..

There is a lot of web based IT work these days. It involves creating web sites that contain web forms, paged tables, and pretty boxes. Because of the inherent architecture of html applications, these applications are more conducive to prototyping. It is not difficult to imagine a fairly complete working prototype using just html, css, and some javascript. The nice thing about these prototypes are their lower requirements on skills and their higher reliance on imagination, experimentation, and feedback. Although it should be easier to find people that can do html, css, and javascript, it should be taken in to account that it takes a different personality to create timely and good prototypes. There is no short cut to creativity whether prototyping with HTML or programming in Java.

It is very easy to overlook HTML expertise in a web project

"I am a java or dotnet programmer and hence HTML is not that important...I need to get a certification in java or I need to get a certification in asp.net to get hired into the frenzy of the web ..." These are not uncommon plans among programmers. This is somewhat skewed, yet is well pursued by programmers and corporations that hire them.

Programmer thinks that he knows the Java programming language inside out. He knows all the OO Patterns. She knows the rose diagrams. He/she knows the EJBs. HTML is quite simple.

An interviewer thinks that if one can master the more complex programming languages, how hard can web design be!! Everyone seem to be doing web design these days, aren't they?

My dream hire these days for good IT projects will be someone that creates web sites with a passion. From start to finish. They will know html. They will know css. They will know javascript. They will know their subtleties. They will know their nuances. If I give them the requirements they can imagine the site and be able to give me a prototype in a couple of days or with in a week. They know how to put together stuff. They know how to give borders. They know how to design background or master pages. They know how to style forms. Hopefully they have had a few programming courses and a year or two experience with a programming language.

In traditional programming we expect things to take a few months. I would like to see a sense of urgency and intensity in this programmer. He/she is eager to finish and demo what is at hand. He/she thrives on and seeks feedback from users.

Designing Prototypes is an IMPORTANT job (and hence a skill) ...

I consider this ability to design sites a very important job both for entry level programmers and also for experienced programmers wanting to be senior developers or architects. This is the face of what they are designing.

I see substantial career growth for programmers that can do this. I see these programmers as cutting through to the core of the development problem.

I expect these programmers to do extremely well in the framework and language of their choice.

Don't start your project with out one of these on your staff...

One of these programmers profiled above is essential before starting your project. This programmer will make or brake the the project.

If you don't have one, get one.

If you don't have enough budget to get one, train one with some foresight.

If you want a great career in IT, become one...

If you are a programmer, try your best to acquire the skills of a web designer. Create your own independent web presence. Use blogs or use any online software to hone your skills.

If someone comes up and says, "I have a 20 page form based web site", see if you can model it in a week or two. See if you can upload it to a site for a demo.

Again, Web applications are conducive to prototyping ...

Because of the nature of HTMl and how the presentation layer is separated and well defined from the business layer the IT applications are quite conducive to prototyping.

This is quite a luxury for the previous generation of client server applications.

With primitive tools such as text editors it is possible to simulate a valid and accurate user experience with in a couple of weeks even for a seriously large size IT application.

Would you like to be an Entrepreneur...

Well no one else needs this skill more than you. It is all about selling fluffy dreams. There is no other substitute than a prototype for this...A fairly complex html demo can be put together in 2 to 3 weeks. What other great tool is there to take it before your customer...

More over this prototype ensures a quick delivery of your finished product as you have to communicate that much less when you hire the programmers. This benefit extends to corporate development as well.

Would you like to be an architect of IT...

This skill is essential in selling your vision for future IT projects and hence establish your TANGIBLE vision this way. As an architect it is also important to realize the role of these prototypes in determining data models for your web site. Depending on the framework of your choice some of these prototypes can be directly used in the development cycle. In that sense a prototype is not just a prototype, but an integral part of the entire development process.

My quest started with an innocent inspiration. I like words and their origins. I wanted to put a look up for dictionary.com on my web log. The form was simple enough with a single text field that takes a word or a phrase and then look up its meaning from an online dictionary.

While playing with the idea, I have realized that when a form has a single text field, "enter" button is acting like a submit with no need for an additional button on the form. I thought that was quite nice. I have added an additional link for unsuspecting users to explicitly look up the meaning if they were not yet clued into the enter. I liked the outcome as the form blended so unobtrusively into the homepage that it does not even look like a form.

Looking back, I liked this form because

1. I could enter a word and look up the meaning by simply hitting enter. No need to shift the focus.
2. For new users the link worked like a button, and yet takes lesser space and looks more like a web page and not a diaglogue

More over actions resulting from both controls are rerouted through the same javascript function that looked up the meaning using a url. I was thrilled. "Wow, this is nice" I told myself.

Time passed. Another day and one more form. But this time the form has a few more fields and a couple of buttons. With stoic confidence I was certain I could work the same magic again. However hard I have tried I could not see why the form is not getting submitted on "enter". So I have started cutting the form down half at a time. When I have reached the single text field it started working. I kind of guessed at this point that at least one of the buttons have to be a submit button and that resolved the issue. But now I wasn't sure if it was a fluke with ie that the single field worked at all with out a submit button.

I decided to google (investigate) the mater. What followed was a string of surprises.

I came to know that indeed the single text field case is part of the spec. I came to know that it is possible to use images as input controls in forms. I also have realized some common patterns that one can use by intelligently navigating the onclick, onsubmit and action javascript functions. It is also possible to make input controls read only or disable them. It is possible to change the target of a form to paint the result in the same page or a new page etc. This article explores some of these topics in more detail in addition to providing a further reading in the references section.

Nevertheless it continues to be a challenge to style text fields, buttons, and forms in general. Encoding of form data and submitting a form programmatically are large topics by themselves. I have included these items at the end for further exploration.

Rest of the article

Rewriting SendRedirect to deal with SSL (or https) offloading

The following weblog/article

How to hide and unhide html sections/controls such as "div"

has the following sections

• setting up a div
• showing the div
• hiding the div
• visibility tag
• display tag
• sample code
• swapping between small and large images

During those years I found myself sharing a cube with two more individuals at one of the consulting firms. One of these good friends is a copious programmer. He used to get quite irritated as the boss would demand his work sooner. His reason was that he might take longer but his code would run the first time. He was quite right in a good number cases. In contrast I might take ten runs before even compiling and then another ten runs to actually get it working. I have always looked upon a day when I would write code and it would somehow miraculously run the first time.

Well after all these years I have a small victory to report. Recently Pramod, a friend, asked me to provide a facility for him in Aspire/J2EE to set a parameter on every database connection he uses. So I have created this fairly involved facility based on "connection events" that did the following

• Raise event when a connection is created
• Raise event when a connection is closed
• Raise event when a connection is requested from a pool
• Raise event when a connection is put back into a pool
• Provide an event distributor so that he can override any events
• Provide a default event handler that can call an sql statement on all opened connections

I have also created a write up for him on my site on how to use the facility along with release notes for the jar file. I was gearing up to hear from Mahaveer, who is using this jar, all kinds of issues as I have not even unit tested the facility other than compiling it with eclipse.

Then I was talking to Pramod on a completely different subject and he mentioned the whole thing worked fine as he expected and Mahaveer is using it.

I am quite positive I may have to wait another few years for this to happen.]]> 2008-01-02T17:42:16Z 2005-08-02T21:09:55Z tag:weblogs.java.net,2005:/blog/satyak/106.3037 2005-08-02T21:09:55Z

Except for the different medium those words ring true for the inimitable talent of Damian Conway as a speaker. This was clearly in display during last year OSCON. I am eager to see his presentations and speeches this year. This is one thing that you don't want to miss at OSCON.]]> 2008-01-02T17:42:16Z 2005-02-05T17:45:26Z tag:weblogs.java.net,2005:/blog/satyak/106.2005 2005-02-05T17:45:26Z