Right-Size Your Infrastructure

Tip: Make use of some service infrastructure, and size it right. In particular, make up for areas WCF doesn’t provide strong support for, such as loosely-coupled routing and centralized management.

Hint: The extremes of no infrastructure at all and a bloated infrastructure are to be avoided.

Rationale: If a company is seriously pursuing SOA, there are going to be a lot of services and clients eventually. There is going to be a need for some infrastructure to complement the business services. UDDI directories, message brokers, and Enterprise Service Buses are all examples of SOA infrastructure. With good SOA infrastructure in place, the configuration of services and their interconnections can be managed centrally at the enterprise level.

                SOA infrastructure services should be as thin as possible (a “thinfrastructure”), expanded as needed, and build solidly on service standards. Infrastructure services can serve purposes such as these:

·         Directory of services

·         Message router

·         Message transformation

·         Rules service

·         Workflow host

·         Integration adapter

·         Activity monitor

What if I Don’t? You’ll lose the flexibility to provide good change management. Failure to provide any SOA infrastructure eventually results in a set of clients and services that work together as initially designed but can’t easily be changed individually.

Use a Discovery Mechanism to Locate Services

Tip: Find other services using a discovery mechanism, such as a directory.

Rationale: The default way WCF clients identify services is to define their endpoints in an application configuration file. This can become unwieldy if there are a large number of services and clients in use. A better approach is to have clients locate services through a discovery mechanism.

                Possible discovery mechanisms include the following:

·         Direct Discovery: Use a protocol such as WS-Discovery over UDP. A client broadcasts a search request and matching parties respond. Because we don’t have this capability in WCF yet, this is not a recommended technique.

·         Registry Discovery: Service information is contained in a registry, such as a UDDI registry or a custom “locator service”. Clients query the registry to find an appropriate service to talk to.

·         Mediated Discovery: Services and clients interconnect through an intermediary, such as a Message Broker an Enterprise Service Bus (ESB). The intermediary puts clients and services together.

What if I Don’t? If each client and service has to be configured locally, you’re going to find it difficult to view or modify your configuration from an enterprise-level perspective.

Use a Loosely-Coupled Routing Mechanism

Tip: Avoid tying services together directly. Use a configurable routing mechanism to connect clients in a loose-coupled fashion.

Rationale: WCF is a great technology that champions loose-coupling, but it makes no provision at all for loosely-coupled routing. If a service in turn becomes a client of additional services, you have a tightly coupled situation. Instead, each service should exist on its own as a truly reusable component. The interconnections between services should be handled by a flexible router. Routing can be accomplished by an Enterprise service Bus, or a Message Broker such as BizTalk.

What if I Don’t? You’re going to run into the classic point-to-point problem, where it becomes more and more expensive to integrate and manage systems. Help them find each other with a good discovery mechanism.