In the past years a lot of people told us about service oriented architecture. Loose-coupling, Contract First, Service Versioning, Orchestration, Mapping.
One of the main goals of the SOA is to build IT systems that can be easily adapted to the changing needs of companies. What does it mean? Companies do not act alone in the market. They are connected to various partners, outsource parts of their business processes – or in other words, they consume certain aspects of their work as services from partner companies. Those partner networks are quite dynamic, as partners have to be exchanged from time to time for different reasons.
SOA takes this principle over to the IT. Stand-alone services are defined and can be consumed from different applications and clients. Methods like “Contract First” help service providers to create stable interfaces for their services. Service Versioning ensures backward compatibility while the service itself is under ongoing development. The rise of the web service technology delivered a solid technological basis for the implementation of the new services.
We heard a lot about the different approaches for the service implementation. But as long as we are not the service provider, we are more interested in consuming existing services. So which of the described approaches ensures, that I can easily exchange my service providers? How could my service provider do a proper “Contract First” design, when the service was created by the service provider alone - without any involvement from me as a potential client? I think the answer is simple: It is not really possible. The contract will reflect the business processes of the service provider. – Not necessarily mine (Conway’s Law ) .
Let’s take a look at an easy example from my daily work. : Consuming Online CreditCard Authorization
We are building worldwide eCommerce applications, where we offer online credit card authorization. As we are more a logistics company, we do not offer the authorization service our self, but use payment service providers (PSP) for it. We use RBS World Pay for Europe, Cybersource for North America and Cobre BEM for the Latam region. Although all three companies offer the same service to us, the interfaces are very different. The following things differ:
- Message Contracts with different field names
- HTTP POST vs. HTTP GET vs. SOAP Web Service
- Error and Result Codes
- Backend Tools
When I need to implement an online credit card authorization, I don’t want to care about the different PSP service contracts I need one solid facade. It means I have to encapsulate the real interfaces to the PSPs.
The following figure illustrates the situation.
The Service DAL is a component inside our application that encapsulates the communication with the different service providers. This DAL is implemented by using the provider pattern, where each provider implements one interface. You probably see the equivalence to the typical SOA figures, where our service DAL would be an integration platform like biztalk. Such integration platform usually forces us a consumer contract (I choose the name by chance.). Interestingly, in our department we seldom applied this idea when we called external services within the application code. – without having a biztalk in place.
The provider pattern however also offers the possibility to consume a service functionality from different external service providers.
The CreditCardProviderManager class implements logic to initialize and select the providers depending on the current scenario. The abstract class CreditCardProvider defines the Consumer Contract, and the different providers implement the mapping to the external services.
I made good experience with that approach of integrating external services into applications, because it forces you to think about a stable contract the fits for your business needs. – Not for the needs of the particular service provider.
To come back to the initial question: Does service orientation give me more flexibility for my business processes and applications? – I think YES, but you should not use the service contract without a proper mapping to a consumer contract.
0 Responses to “SOA – More flexibility for my business processes and applications?”