Performance Impact: Granularity of Services
ZapThink has a great article regarding the granularity of services; that is, how fine or coarse grained services are in terms of the services and interactions available.
What is mentioned, but not highlighted, and appears to be somewhat assumed (at least in this article), is that the end-result, regardless of the process used to build services, revolves around business processes.
[The] concept of granularity is incredibly important to the enterprise architect because it has a direct impact on two major goals of Service-orientation: the composability of loosely-coupled Services, and the reusability of individual Services in different contexts. Before an architect can go about designing a Service Contract, they must first somehow come up with the requirements for that Service. As we discussed in the Right-Sizing Services ZapFlash and in numerous other white papers and writings on this subject, an architect has two general approaches to identifying Services: starting from the business-process or a business model and decomposing that into sub-processes or sub-models recursively until some condition is met by which it can’t be decomposed any further. Alternatively, an architect can start from the IT systems already implemented, expose Service interfaces from the APIs and access points that already exist, create Service Contracts on top of those interfaces, and then compose them together until the business process requirements are met. While top-down approaches are generally favored to achieve the “right” level of granularity, in reality, proper Service-oriented approaches combine both top-down and bottom-up in a continuous and iterative manner. [emphasis added]
Basically, you either work top-down, starting from the business process and decomposing or you work bottom-up, composing services into business process components. The subtlety here is that the end-result is a business process, not a disparate set of services that mirror a set of objects and interfaces.
This is an important distinction in SOA-land. While services composed by exposing the public methods of any given object as interfaces are certainly by definition a service, they aren't business services and are therefore less useful in scenarios in which integration and composition as part of a larger business process is necessary.
The Performance Impact of Architectural Decisions
There's an important performance facet to granularity of services and the way in which services are ultimately composed.
If services are too fine-grained and require multiple invocations of operations to achieve even the simplest of processes, you have added overhead in terms of TCP session management as well as the inherent latency involved with the processing of XML and SOAP-based messages. That's a good reason to focus on process activities as services rather than their composite steps.
Consider the following scenario:
You have a business process X that requires invoking 4 operations. You did not encapsulate the business process, but built instead services with the appropriate operations (interfaces). The client, therefore, must compose the business process.
Assume the average latency in parsing and processing the messages for each operation is approximately 10ms on the server and another 10ms on the client. Assume the time it takes to setup and subsequently teardown a TCP session is 4ms. For this scenario, we'll assume the network latency is a total of 1ms per operation invocation (obviously over a LAN :-) ).
The total time required to invoke 1 operation is 10ms + 10ms + 4ms + 1ms = 25ms. The total time to execute this particular business process is therefore 4 * 25ms = 100ms.
Doesn't seem like much, does it?
Consider a coarser grained service, one that consists of a business process exposed via a single operation (interface). Using the same timings, the time to execute the business process is 25ms. 10ms + 10ms + 4ms + 1ms = 25ms.
The finer grained service requires 4x the time to process.
While these numbers may appear trivial (and in fact are probably too low in terms of the parsing/processing time required depending on the size and nesting depth of the messages) consider the exponential growth in time that occurs when you have thousands of users executing the same process. The coarser-grained service is going to scale much better than the fine-grained service, and it's going to have the side-effect of being much easier to implement for the consumer, as well as easier to modify in the future. After all, if the steps within the business process fail...the client needs to change. In a coarse-grained scenario if the steps within the business process change the modification is transparent to the client. No change necessarily required.
While there are certainly solutions to the problem of network latency and even TCP session management (BIG-IP can alleviate much of the impact from these two sources) there aren't really any viable solutions to improving the parsing/processing of messages. XML co-processors may decrease the impact, but add network latency and TCP management into the equation yet again. The gains are often lost by implementing such solutions because they are also "services" in that they are network-hosted solutions. XML gateways only alleviate the pain associated with overlay protocols and standards such as XML Encryption and XML Digital Signature much in the same way an application delivery controller reduces the impact of SSL-encrypted transport on performance.
The biggest impact on service execution performance comes from the parsing and processing and encapsulation into XML of responses on the server. That can't currently be addressed by any viable solution other than being a lot more attentive to the way in which you compose the services that comprise your SOA.
When architecting services consider careful how the services will be used and be cognizant of the impact of your design on performance and scalability. Simply exposing every method in an object as a service interface isn't a good way to proceed on your path to service-enabling your organization. You have to think business process if you not only want to gain the benefits of a SOA, but don't want to gain the performance problems associated with poorly designed services.
Remember, services are not the only way to reuse code, and reuse isn't the only reason to implement a SOA.
Imbibing: root beer