I’ve been involved in an interesting scenario recently which has given me enough fodder for a number of posts. In the first phase of a project recently completed, we were tasked with adding functionality to an existing app by combining it with data from other sources and providing access to our CRM system as well as some pages on the website. Now the existing app is a classic ASP system with some simple webpages wrapping a multitude of stored procedures.
Deciding on the integration layer was easy. Since we’ve been building up a Biztalk powered SOA over the past 2 years, it took the shape of orchestrations exposed as webservices. We havent been down the route of publishing schemas as web services yet and i’ll explain why in a later post. The crux of the issue then was what the back-end of the service looked like. How do we connect to the LOB application?. In some cases, the adapter is a given because the third party application has a particular interface but what do you do when there is more than option?
We were wary of connecting directly to the database and first considered using something like the Service Factory to wrap the database in a simple Entity service just providing CRUD functionality. On closer examination though it seemed that all the logic was inside the SP’s anyway so adding a business layer and a SOAP interface on top of that was just an unnecessary overhead.
So we decided to go down the route of the SQL Adapter. My reasoning at that point was “its just one type of adapter vs the other” (hence the title of the post) and as long as the interface had the right granularity it didnt matter. To cut a long story short, we ran into a number of issues because as we found out during implementation, the interfaces didnt really have the granularity we needed. For instance , instead of being able to call just one SP to do a certain operation we would need to call 2 or 3 and the flow between the 2 or 3 SPs was controlled by the ASP front end. Recreating the logic inside an orchestration was too much work (and for several reasons we didnt want to take out core business logic away from the application itself) , so we had to write more wrapper SPs. On top of that we also had to change the schema of the DB in some places and enhance existing SPs’ and so on. We couldnt make wholesale changes either to avoid breaking the existing front end. In short , the integration layer was directly exposed to all the vagaries of database development. We got there in the end, but not without considerable loss of hair and sleep.
I was a kid when Kramer vs. Kramer was released and i dont remember how the movie ended. I do know however, that at the end of this, we definitely preferred one Kramer (the SOAP adapter over our WS interface that never got built) over the other Kramer (SQL Adapter).
To be fair, it really wasnt the fault of the adapter anyway. If the SP’s had the right granularity and had been layered in a way that avoided the orchestration having to know too much about the database schema, then the SQL interface would have been just as good.
You might ask why bother with the SOAP adapter at all. Here are some of my reasons
- Adapters vs Inline calls: I dont want to call the business layer directly from the orchestrations via expression shapes. I want the reliability that adapters give me.
- Ease of development: We needed something easy to develop. The team hasnt been exposed to writing custom Biztalk adapters so far and with the time pressure it didnt seem appropriate to try that route particularly since it seems there are so many options involved in writing custom adapters and there definitely wasnt enough time to evaluate them. Also, if we then ran into trouble when deploying them, it would be a bit of a nightmare.
- Its just a facade anyway: Since all the logic would have been kept in the BLL (and some parts of the DAL), the ASMX is only a facade as would be the BTS adapter so why create unncessary fuss just for a measly interface!! .
- Its a long way to WCF: If we were in the R2 world we could have written a WCF adapter over the business layer directly and opted for a non SOAP transport, but we are still in the “old” v2006 and WCF is very far away.
- Non WS interfaces could be a limiting factor: If the opportunity arises in future to productize this, then the biztalk adapter wouldnt have any value unless the customer had biztalk. If they required a web service interface then the ASMX would have been just the ticket (also because WCF isnt on our radar now).
I wouldnt consider myself a guru anyway so perhaps there are even deeper technical reasons why one adapter could be better than another for a given scenario, but the above factors contributed to my stand.
Interestingly, for our next project, we are now tasked with adding a big block of functionality to the old application and exposing that to the integration layer. We have also been asked to overhaul the old application to make it more integration friendly. You can guess which route I’m going down now.
In my next post I’ll tell you about another debate that came up for the new projects.
I’d like to hear from you on how you choose adapters when you have different options and are free to make your own decisions. (Dont rub salt by telling me how wonderful WCF is and how the LOB adapter SDK could make my life easier. I know all that and living in hope that i’ll get to play with those toys sometime soon, but for now i gotta make do with what I have).
