Service orientation via web services can often be the best approach for enabling core business processes. The most important aspect to finding the SO sweet spot is determining what can be reused. Services are often considered application building blocks. With that comes a great responsibility for the application visionaries. There is a natural time during an application’s envisioning when service boundary identification can be done by those that best understand what business processes can be reused.
If these services are envisioned and designed with the enterprise in mind, and not the specific application being envisioned, there is a good chance that a reusable service will be delivered. There are a lot of inherent risks here too. You have to involve the right resources for auditing those services which are thought to be reusable. Typically in a large enterprise there could be other projects that have either already started or already built a large portion of that same service.
Loosely-coupled, reusable services have a number of other obvious benefits. That is if the services are designed using the four service-oriented tenets listed here:
1. Boundaries are explicit: This means that we make no assumptions about what is behind an SO boundary. We cross service boundaries intentionally to use a service that would most likely be usable by more than just our application. These boundary crossings are expensive and should be done only when necessary. It is tempting to do this as a standard architectural approach with the hopes that a library of services will become a reality by accident. Architecture never happens by accident, service boundaries being explicit is the most important tenet to understand and abide by.
2. Services are autonomous: This is self explanatory really; autonomy, by definition, means self-governing or stand alone. This becomes important when you start to look at services that are defined based on the needs of a specific system or interface. When services can not be independently built, versioned, and deployed, they are destined to fail in the long run. Without careful adherence to this tenet, services will never reach their potential for reuse or longevity.
3. Services share schemas and contracts, not classes and types: This speaks to the platform neutrality of services. All services are designed to exchange contracts for behavior and schemas for data structure. Avoiding type system dependency is what ensures interoperability.
4. Compatibility is policy-based: Policies define the constraints for accessing the service. This allows services to define a mechanism for communicating no matter what their current capabilities are. This guarantees that services will always be capable of negotiating a set of rules for communication. As services begin to provide enhanced capabilities like transaction flow and reliable messaging, a policy can still be defined that will allow first generation ASMX services to talk text-based XML over HTTP.
When the design strategies for delivering services keep these tenets in mind, they can realize many benefits. Portability of the individual parts of an application is inherent because of the neutral nature of the transport channel. Each of these parts is also individually scalable. Services can also see a huge gain in maintainability and extensibility because of their centralized nature. Services are also potentially durable, reusable core components in enterprise architectures.
There are some other great reasons to look at implementing service-oriented architectures today. One reason is that it provides the ability to extend the investment of the legacy components in your architecture. I love the saying: “If it ain’t broke … front end it.” Implementing a service-oriented front end for a legacy system will expose that same business logic to an entirely new generation of applications. This does come with risks, but if those legacy systems you intend to expose via service orientation are carefully tested, there is a great opportunity for renewed ROI.
Another great implementation of service orientation is often referred to as shared state or workflow-type applications. The best example I can think of is a loan application. If that loan might have a number of different states that numerous applications would act upon during its lifespan, then you will most likely benefit greatly from a service-oriented approach.
The obvious scenarios still apply as well. When you have a need for interoperability, service orientation has obvious benefits. If you need to expose your application’s business logic to a brand new front end hosted on a disparate platform, SOA provides exceptional ROI.
