We've been looking at ways to share customer information between two applications:

One approach was having both applications use the same OLTP database. This presented some challenges; namely, it coupled the two applications very closely together, creating a huge ripple effect if either application needed to change. A second solution was to use ETL scripts to shift data between application databases. This decouples the applications a little, but integrating at the data layer means we lose a lot of context.

Web Services

For our third solution, let's explore the use of web services. In this solution, the Web Store would "own" the customer information. The Marketing application would store its own application-specific data, but it would make a web service call to fetch customer information. The solution might look like this:

The web service could be implemented many ways:

• An RPC endpoint, using SOAP for operations like fetching and updating customers, perhaps implemented using WCF
• A RESTful endpoint, with Customers as a true resource, exposed as XML or Json
• A URL that just returns a CSV of Customers

Advantages

In the previous approaches, the Web Store application gave up control over its data. ETL scripts might have meddled with customer data, bypassing the application domain logic.

With this approach, Web Store retains complete control over how other applications access and modify the data it owns. It can validate updates to customers, reuse some of the domain model code, block updates to archived customers, and so on. Best of all, it can change the database schema completely without upsetting grumpy DBA's ;-)

Disadvantages

While this approach has many advantages over the previous solutions, it has a major downside: the reliability of the Marketing solution is coupled to the Web Store solution.

Although a critical system like Web Store is unlikely to be completely offline for a period of time, this architectural mistake could manifest itself in other ways:

• If the Web Store is exceptionally busy, the Marketing solution may run very slowly
• A bug in the Marketing solution (like calling a service in a tight loop) could have negative impacts on Web Store's reliability
• If multiple applications begin to depend on Web Store's web services, the Web Store team may have to deal with a myriad of versioning issues.

These issues are especially important if either application has any kind of SLA.

Conclusion

It's important to note that while WSDL/MEX and technologies like WCF do a good job of decoupling applications by using contracts, they alone don't fully decouple the uptime, reliability and performance issues that come about when integrating applications.

What experiences, good or bad, have you had creating web services that are consumed by other applications (not just between client/server apps) in your enterprise?