Friday, November 18, 2005

What should a SOA enterprise server do for me

Friday, November 18, 2005

What should a SOA enterprise server do for me

While SOA as a technology may not be mature enough, and primitive still at adoption levels, the concept behind it is promising. As I understand SOA better and better, I begin to have more and more expectations.

Let us talk about 'pulling'/'pushing' data . Data or information on a case by case basis may exist in various forms in heteregenous applications. I can get my data stream via messaging queues such as railways ticket bookings, online lottery engagements, the most often used example being stock and forex quotes.

Or I could have my information coming through SMTP systems (our dear email in Simple Message Transfer Protocol) which according to me is really a content managed workflow system that has been time tested and working very reliably.

Or from the traditional RDBMS APIs or database webservices which follow open standards of SOAP and WSDL.

Or via real time feeds such as a patient's heart beat, pulse, BP, lung saturation etc from the monitors in an Intensive Care Unit in a hospital on to the doctor's real time monitoring system

Or via Applications and information from enterprise systems such as SAP or Siebel based applications where data is got just from SAP(abstracted to the app level and not about APIs or depper layers of data storage and persistence).

Or from the hugely invested silos of information available in mainframes such as CISC where data sometimes need to be just got from screens and not from data layers.

And when I do successfully get the continous data out of these sources, I should have the facility for me to define how different types of data are to be validated (for e.g. the doctor should be able to say, 'Attend to the patient, don't validate,if it is an emergency without bothering to register him/her to the hospital repository), to be computed (for e.g. no taxation for income levels lesser than a certain amount), to be transformed ('Get all those long binary strings and convert them to giga object types).

I should also be able to inherit validation, transformation or security rules because they have all been already defined and running in all my heterogenous systems for years!

I understand that 80% of SOA effort is towards Exception Handling. That's logical because SOA itself requires an integration layer inbetween the model and presentation layer and due to the variety of different interfaces and due to their complexities the exceptions can be plenty. But they all need to be handled as beautifully they were handled in their original stand alone systems earlier if not better.

The whole thing looks very promising but as I sit down with the requirements, I'm bogged down because it looks complex. User experiences will dictate a lot of design in this area and the end-user is the King!

No comments: