Service development is about to explode in the enterprise, but these are not the custom-crafted, high value, reusable services you might see cruising the pristine avenue of your company’s SOA center of excellence. No, this will be massive. Instead of nicely architected brownstones with clean lines and aesthetic appeal, you’ll brush with small, hastily constructed, one-off services as far as the eye can see. Its urban sprawl in SOA land, and things are about to spiral out of control.
Where will this “urban sprawl” of services come from? The new killer app for SOA is Rich Internet Applications (RIA). Vendors and pundits are vocal about the perfect fit of RIA and SOA. Environments like Flex , Appcelerator, and many of the AJAX-based development environments like Tibco GI seem to perfectly match RIA and services.
It seems like an excellent fit on the surface, using services to populate sections of the display and to perform major operations like "process order". But management of the services is a glaring risk area. SOA generally strives to create coarse-grained services aligned with steps in a business process. You can visualize each service as an activity node on a flow graph. From this basic idea you get many of SOA's benefits: coarse grained, loosely coupled, reusable services that can be re-orchestrated into new business processes.
In the RIA-SOA scenario, left unchecked, I envision a high number of very granular services. Most of these will be tightly coupled, not very reusable, and RPC style. Maybe there is nothing wrong with this, but it is a significant divergence from the core principles of SOA.
I personally like the idea of RIA-SOA, but the trick will be to encourage and enforce SOA principles in the development of this new style of application. Otherwise, expect rampant proliferation of low-value services.
I can envision certain RIA development styles that are more “service oriented” than others. A quick example can illustrate this. Suppose an auto insurance company needs a new policy administration system. From the user perspective, an agent may enter a policy number and expect to see the auto policy in a multiple-tab view. Lets say that one tab shows the policy owner (name, address, contact info, etc), another tab shows coverage information (dollar limits for damage, medical, liability, etc.), and a third tab shows premium information.
The designer of such an application has many alternatives to supply services to power the screens. The primary characteristic differentiating the approaches is how coarse-grained the services are. For illustrative purposes, lets talk about three degrees of coarse-grain-ness: coarse-grained, medium-grained, and fine-grained. A coarse-grained approach would provide services to “get policy” and “update policy”. The RIA application would call “get policy” when the agent enters the policy number. Each tab would read and update appropriate sections of the single, shared policy structure. The agent would click an update button to invoke the “update policy” service under the covers, which sends the policy structure to a service which performs the needed updates. This strategy not only limits round-trip calls to the server, but conforms to SOA norms by encouraging development of more coarse-grained services that are likely more reusable and more loosely coupled.
A medium-grained approach would provide us with a separate service invocation for each of the tabbed panels. Three tabs leads to 6 services to read and update appropriate portions of the policy. The application would likely exhibit better perceived performance, as the user could view the first screen as soon as the first service (get policy owner) completes. While we have potentially 6 round trips instead of 2 in the coarse-grained case, the update operation may deal with less data, since we only have to update individual portions that changed. These services seem reusable and loosely coupled as well, as they are grouped around business information that likely is used by many applications.
A fine-grained approach leads to a larger number of services. Imagine you design your GUI top-down. You go along building screens and stubbing out services you will later create to populate the fields and react to user events. Your services are precisely defined to fit the specific needs of each screen. It a bit harder to imagine this style with our insurance example, but perhaps we define a service to retrieve name, another for address information, and another for contact information. Each section of each screen gets its own service. We have many more services now, but we increase the opportunity for perceived visual refresh performance. Another benefit is that the service definitions fall out immediately from the information sections of each screen, making the design effort straightforward. But the sheer number of services will cost us in terms of management overhead. And these services are so closely aligned to screen layout as to make reuse outside the RIA environment very unlikely.
From this example, we see that as we move down the scale towards more fine-grained services, we increase the opportunity for perceived visual refresh performance while we increase the number of round-trip service invocations to the server. We also increase the management overhead by introducing dramatically more design artifacts.
While the policy administration example shows tradeoffs in the service design approaches, in the context of service orientation, the characteristics are not quite so arbitrary. To be service oriented, you must strive to provide coarse-grained services that are reusable and loosely coupled. To a large extent, if you think in terms of defining the information payloads for services at a higher level, from the business analyst perspective, you will achieve better reuse and loose coupling. On the other hand, if your service interface is defined by a specific set of screen fields, you have tightly coupled your service to its consumer. When the screen changes, your service interface must change. Such a service has a singular purpose, will not be reusable in any other context, and so by definition, is not service oriented.
The message to RIA designers and architects is simple. Yes, industry needs you to combine RIA and SOA to achieve a new level of productivity and richness of user experience. But you should take up of the cause of SOA while you build your RIA. Be service oriented so your services are loosely coupled. Be service oriented so your services can be reused elsewhere. Your efforts will be a productivity multiplier within your organization, bearing fruit from your work long after your current project. Be service oriented, and in the process, you can stop the sprawl.
