Implementing Services

In my previous post I mentioned that we made a decision to use the Microsoft Development Application Framework (EDAF) when constructing our services in order to handle duplicate messages sent to service providers. While that is true, that's not the only reason we decided to use EDAF. I should add that we're not using EDAF for all the services in our taxonomy.

What we did decide was to implement the various types of services as follows:

• Process Services. Implemented as BizTalk 2004 orchestrations or Ultimus workflows. These services will be exposed both through a Service Façade implemented as an EDAF operation (business action). A Process Service may encapsulate more than one orchestration if those orchestrations are a logical part of the process. However, if a Process Service invokes another Process Services it would do so through the Service Agent and its Service Façade. In other words logical boundaries need to be drawn between Process Services even if they are implemented as orchestrations on the same BizTalk installation.
• Activity Services. Where transactional coordination of the entity services is required, implemented as BizTalk orchestrations. These services will be exposed through a service façade implemented as an EDAF operation. Where transactional coordination is not required, for example in the case where a business activity can be encapsulated in a single Domain Layer stored procedure that includes the transactional control, the service can be implemented as an EDAF services
• Entity Services. Implemented as EDAF services
• Infrastructure Services. Implemented as EDAF services
  

The way these services interact can be seen in the following diagram.

As mentioned above, our architecture calls for the implementation of Service Facades through which services of all types will be invoked. This is one of the two primary patterns that we wanted to implement and which EDAF could really help us tackle. More formerly, these patterns are:

• Service Façade. This pattern implements services using a common framework to ensure consistent enforcement of a variety of operational requirements such as management, performance monitoring, security, and logging. In order to implement these cross-cutting concerns our architecture employs the Enterprise Development Application Framework (EDAF) version 1.1.
• Service Agent. As discussed in my previous post this pattern encapsulates the concerns of service consumers with regard to service discovery, security credentials, and intelligent caching of time-sensitive data (e.g., token for a reservation message pattern). Because Compassion will primarily include clients built on the Microsoft .NET platform, the service agents will be developed as .NET class library assemblies

In the next post I'll lay out our justification for using EDAF.