As I mentioned previously, crossing service boundaries is, without a doubt, expensive. Moving toward service orientation has to be done knowing that there are costs, some obvious and some hidden. The first cost I will discuss is the first one on the tips of most developers’ tongues; of course, I’m talking about performance. Performance should not be used as a driving factor for deciding whether or not to move toward service orientation. We should always keep Moore’s Law in mind any time we look at performance as a requirement. I will loosely describe Moore’s Law by paraphrasing it. Essentially computing power and data density has been proven to almost double every 18 months and that trend is expected to continue for years to come. It is my belief that this same growth potential can be applied to network bandwidth. This means that our performance concerns today are not likely to be as significant a concern tomorrow. Always remember that one of the key reasons enterprises want to start implementing reusable services is application longevity.
With all that said, there are some strategies that should be used to carefully monitor potential performance problems. Wire-level tracing and message size is a key metric for understanding service-oriented performance issues. Asynchronous invocation is another important strategy when using service orientation, as it will allow applications to avoid locking situations under heavy load. Finally, always beware of over-extending legacy components. Although there are obvious benefits to renewing that investment, not all components are ready for the stresses introduced by high-volume, online synchronous traffic. I can’t stress enough how important extensive quality control practices are in a service-oriented enterprise.
When developing services in a service-oriented architecture, we are always forced to code to the lowest common denominator when it comes to things like security, type systems, and tools. Security introduces a number of challenges. Interoperable security is very complicated. Both method-level security and role-based security become very challenging to implement when considering interoperability concerns. Service orientation also immediately violates a key security tenet that says you should always look to minimize your attack surface. Extending services over universal channels exposes them to the same attacks as any other code that can be invoked over HTTP. This type of code has traditionally been attacked regularly because of its accessibility.
Interoperability is still very challenging especially if your goal is complete toolkit interoperability. What that means is that any Java Web Services toolkit can consume a contract from an ASP.NET web service, and vice-versa. This introduces numerous challenges. Developers have to avoid intrinsic types and empty arrays. There are a number of date and time issues when going across platforms, and there are very careful decisions that have to be made when deciding how a contract and schema are exposed to heterogeneous clients.
The tools available today for service-oriented development are still somewhat unsophisticated and, at times, even create problems when using their embedded features. A good example of this is how Visual Studio .NET allows developers to create proprietary web services and will at times generate code proxies that have deficiencies. The tools for service-oriented development continue to evolve, and Visual Studio 2005 is a great improvement over previous versions. Developers are free to modify and build things by hand if they are so inclined, but productivity suffers immensely.
Other issues that are costly but can be overcome are durability, data type centralization, and standards. Durability becomes an issue when design strategies are not followed that ensure autonomy in a delivered service. This can create a situation where services and all dependent applications become increasingly brittle. Data type centralization is challenging as well. Type ambiguity begins when centralized types are not reused across varying services. For example if your company uses something called an “Order” that type should be defined and used consistently across services that act upon an “Order”.
Lastly I will mention the issue of standards. I know it seems hypocritical to consider standards a negative even though they have gotten us to where we are, but I’ll explain why. Currently the standards that are available are quite extensive. This makes them difficult to digest and frequently misunderstood. Also, there are a lot of standards currently available. Reading them all is probably unrealistic, and these standards are still in their infancy. Most of them are less than five years old and will continue to evolve. Because of these issues, the standards driving SOA can be quite overwhelming.
