Besides that SOA (Service Oriented Architecture) is a cool buzz-word nowadays, it's also an architecture that can bring you some interesting advantages.O'Reilly webservices.xml.com has an article that provides following definition:
SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. ... How does SOA achieve loose coupling among interacting software agents? It does so by employing two architectural constraints:
- A small set of simple and ubiquitous interfaces to all participating software agents. Only generic semantics are encoded at the interfaces. The interfaces should be universally available for all providers and consumers.
- Descriptive messages constrained by an extensible schema delivered through the interfaces. No, or only minimal, system behavior is prescribed by messages. A schema limits the vocabulary and structure of messages. An extensible schema allows new versions of services to be introduced without breaking existing services.
I like to compare a SOA's facade (see also the Facade design pattern) as a single point of contact that hides the business object model and the technical implementation of the provided service. The only thing that I, as a consumer of the service, need to know is the location of that service. If I have to explain SOA I sometimes use the following metaphor: If I have a problem with my computer I call the helpdesk using the telephone number (= service location). Once connected they give me some choices: software related problems, hardware related problems, ... (the service describes itself). So I don't have to know the internal structure of the helpdesk and I don't have to know which department will take care of my problem (the complex structure is hidden).
There is a lot of information available on how to build and use SOA, but there is one area that keeps bothering me: reporting. In the “good old days” of pure two-tier Client/Server programming it was quite simple: the reporting engine connected directly to the database and fetches the data by executing SQL statements. Even in the three-tier and n-tier models this way of getting the data to the reporting engine stays the same.
So how would you deal with reporting in a Service Oriented Architecture? Of course you still could bypass the whole service layer (plus the layers beneath it) and connect directly to the database but you'd loose advantage of the facade so you'd have to deal with the possible complex database model. Connecting directly to the database also won't work in a distributed environment where the client and server are separated by the internet for example. (I know this statement is debatable because you could use SQLXML, but you'd have to expose your database server to the internet.). A solution could be building the report upon the results of a call to your service. A nice example of this way of working is InfoPath (assuming that the facade is exposed as a web service). You can create InfoPath forms based on web services, even complex XML structures can be transformed into good-looking forms. In my opinion this perfectly fits in a SOA.
But (unfortunately) InfoPath is not (yet?) usable as a reporting engine, it requires a client license and I don't know if it would be possible to pass a parameter to an InfoPath form without user intervention. Does anyone know if there are other solutions or products available?