Santosh Benjamin's Weblog

Adventures with AppFabric, BizTalk & Clouds

SOA – Adapters and Kramer vs. Kramer

with 3 comments

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).


Written by santoshbenjamin

November 24, 2007 at 4:22 PM

3 Responses

Subscribe to comments with RSS.

  1. In my experiences, you can’t (always go completely) wrong with inlining 🙂

    Inlining really is one of the more understated methods of retrieving data when adapters come up short (an occurence that happens more often than not, at least in a pre-WCF world). Everyone’s first and foremost answer to the connectivity question is the adapter – and why not? Most people buy it for the adapters in the first place; for them to come up short really leaves a bad taste with a lot of people. After all, the purpose of the adapters is to prevent BizTalk developers from having to write that layer of code in the first place!

    But inlining has its advantages, and I think the product team made a quiet (but important) statement having a scenario in the SDK and documentation with an inline scenario. Sometimes you have to provide specific code for specific scenarios; anyone with a few projects under their belt will gladly admit that BizTalk covers a lot of things, but as circumstances get more onerous, the more one has to write code to cover particulars that no one thinks of when putting together adapters…

    When used in conjunction with the BRE or SSO Config store, you can have a pretty flexible and adaptive inline solution for accessing your back end. While you save yourself a trip to the MessageBox when performing the communication, you don’t necessarily lose any reliability if you test your exception handling scenarios with the Scope shapes.

    That’s not to say Microsoft could have written better adapters – the SQL and Oracle adapters go down in history through the pre-R2 product line as being pretty crappy.

    In any case, that’s my opinion, and I look forward to reading others’ responses to the matter.

    Best wishes – love the blog!

    Lucas Vogel

    November 25, 2007 at 7:12 AM

  2. Hi Lucas,
    Thanks for the great feedback and the compliment on the blog!! I have had a sneaking suspicion for a long time that inlining wasnt all that bad but it seemed that everything i read pointed to adapters as a preferred way. You’re quite right. With some solid exception handling we could achieve an equivalent level of error reporting , even simulate the “failed message” functionality (for instance by marking the message as BAD in the pipeline – i read something about that technique a while ago) and get a lot of what the adapter would give. I guess we wouldnt get retries without putting in some orch/code patterns for the same, but perhaps the retries are more a nice to have than a must have. For instance, if the backend system is down, its nice to have your service retrying the communication, but equally it could be even better to just inform an administrator immediately and put that message somewhere where it can be resubmitted. I havent seen the inline scenario in the SDK yet. This technique could do with a bit more publicity and more info on the pros and cons. I’ll do some more investigation on this and post my findings.

    Thanks again.


    November 25, 2007 at 1:35 PM

  3. […] Debating the nature of the Integration Layer In a previous post on project goings on I talked about our choice of adapters and the lessons we learned. One thing we […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: