|
Home > Archive > BizTalk Server General > January 2006 > Architectural Problem: Own Adapter vs. SQL Adapter
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Architectural Problem: Own Adapter vs. SQL Adapter
|
|
| Adam Boczek 2006-01-27, 9:28 pm |
| I've to connect my application (.NET, SQL Srv 2000) with a new
middleware (BizTalk 2004) in my company, so I have to "open" my
application to the world. The first concept is to create an own adapter
and do it in elegant, "on the business level" way. The second idea is
to create some kind of interface tables (in/out) and use them as source
for SQL Server Adapter for BTSrv 2004.
Which is the best architectural choice? What about performance,
security etc? Is the idea with an own adaptor too risky (complexity and
so on)?
Please help. I've a scope meeting about it tommorow...
Adam
| |
| Matt Meleski 2006-01-27, 9:28 pm |
| Just a few thoughts:
1) For creating your own adapter, there is some risk involved
a) You would have to decide on how your adapter would
communicate with your Application. Would it be messages dropped in MSMQ,
Exchange tables in a database, Web Services Interface, Socket interface etc.
b) Is you application interface constantly evolving or complex. Will you
have to make changes to your adapter to accomodate the changes to the
application interface ?
An example would be with the Sharepoint Adapter. In functionality, it has
been greatly improved, but if I want to delete one specific item in a
document library from the Sharepoint Send Adapter, it will not do it (or I am
pretty sure it cannot).
2) Therefore, if you are new to BizTalk, or you are building a
prototype/proof of concept , then using an existing adapter to communicate
with your application is a great way to quickly get up and running, instead
of immediately building your own custom adapter.
What you could do then is decide on a protocol to communicate with your app.
Lets say you choose Web Services, then you could build a Web Service API to
expose your app, then you could use the out of the box Soap Adapter to call
the Soap API from Biztalk.
3) Having said all the above, I do not want to completely rule out building
your own adapter. It does have it's advantages, in that it provides a
consistent interface your application. ie. New developers would just know how
to configure your adapter to
exchange messages with your application.
Matt
"Adam Boczek" wrote:
> I've to connect my application (.NET, SQL Srv 2000) with a new
> middleware (BizTalk 2004) in my company, so I have to "open" my
> application to the world. The first concept is to create an own adapter
> and do it in elegant, "on the business level" way. The second idea is
> to create some kind of interface tables (in/out) and use them as source
> for SQL Server Adapter for BTSrv 2004.
>
> Which is the best architectural choice? What about performance,
> security etc? Is the idea with an own adaptor too risky (complexity and
> so on)?
>
> Please help. I've a scope meeting about it tommorow...
> Adam
>
>
| |
| Tomas Restrepo \(MVP\) 2006-01-27, 9:28 pm |
| Hi Adam,
> I've to connect my application (.NET, SQL Srv 2000) with a new
> middleware (BizTalk 2004) in my company, so I have to "open" my
> application to the world. The first concept is to create an own adapter
> and do it in elegant, "on the business level" way. The second idea is
> to create some kind of interface tables (in/out) and use them as source
> for SQL Server Adapter for BTSrv 2004.
>
> Which is the best architectural choice? What about performance,
> security etc? Is the idea with an own adaptor too risky (complexity and
> so on)?
I agree with the points presented by Matt in that it is complex to create a
custom adapter. Furthermore, one thing to consider is that adapters usually
(though not necessarily) deal more with the lower level issues of
connectivity, security and so on, while it's the payload flowing through the
adapters (i.e. the messages themselve) that represent the business-level
information and requirements. As I said, this doesn't have to be so, but
it's a common pattern.
One option I would consider is to start by defining a set of reusable
business documents (xml schemas) you can use to send and receive data
relevant to your application from/to biztalk and other external entities.
That way you can sort of isolate the payload definition from what goes on
the wire itself (like the SAP adapter does, btw). You can even use an
envelope pattern here to simplify it.
Once that is done, you can really concern yourself in an easier way how to
do the low-level connection. For example, you could really just use
WebServices to do so, based on your business schemas you defined above. Or
you could simply provide a way for your application to send the XML messages
out through a MSMQ queue or an HTTP POST, and so on.
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
| |
| Adam Boczek 2006-01-27, 9:28 pm |
| Many thanks Matt and Tomas for your ideas.
But I'm still not sure which way is the best. My application works in a
global intranet (till now 32 countries are using it). New middleware
with BizTalk is a part of this intranet but I do not have control over
it. So I'd like to have something between WebServices solution and fast
direct access solution (means SQL Server Adapter). I'd like to serve a
functionality with my own business rules but without cons of slow
protocols like soap etc. "offer".
| |
| Tomas Restrepo \(MVP\) 2006-01-27, 9:28 pm |
| Hi Adam,
> But I'm still not sure which way is the best.
well, it's not an easy question, and it really depends on a lot of things we
probably don't know about your scenario 
> My application works in a
> global intranet (till now 32 countries are using it). New middleware
> with BizTalk is a part of this intranet but I do not have control over
> it. So I'd like to have something between WebServices solution and fast
> direct access solution (means SQL Server Adapter). I'd like to serve a
> functionality with my own business rules but without cons of slow
> protocols like soap etc. "offer".
SQL Server doesn't necessarily have to be the fastest or best solution,
depending on the ammount of data you generate, what the concurrency and
frequency is and stuff like that.
It also depends a lot whether your scenarios are primarily one way or two
way (and in which direction) or one-way both ways. You also need to consider
transactional semantics, and whether you are more interested in a fully
synchronous implementation or you can do with some asynchronicity (which
doesn't necessarily mean a lot of delay). It also depends on the data size,
and whether you are more comfortable with a push or a pull solution (by now
I've probably confused you even further, I know)
For example, if my scenario was based of basically moving data one way, for
example having my custom app notifying of business state changes to external
observers (aka biztalk and from there to third entities), and my data was
smallish in general, I would probably go myself with having the app (or a
service thereof) generating messages into MSMQ queues and have BizTalk read
those. It's fast (MSMQ was built to push messages into queues very, very
fast), very reliable if done well, and you already have adapters to work
with it, meaning less time to develop.
However, if my scenario included synchronous request/response type of
interactions, I would certainly not use MSMQ at all, or if the messages were
very big (because of MSMQ message size limitations).
Sure, going through the DB might seem like less work at first, but it
usually involves either: Replicating a lot of data (i.e. putting all
business data into the message notification tables) or putting just the
notifications themselves out and have the interested party query the real
business data off the real db tables, which is a) cumbersome to maintain, b)
increases contention and concurrency, and c) it's painfull to deal with the
application's business rules as you're going to the DB directly.
One thing I do not have clear from your scenario is just where do you expect
to get the data to. You say that your application works on the global
intranet, but it doesn't seem like that would be significant for solving
your biztalk problem unless you expect the base application and the biztalk
solution to be deployed far away from each other (i.e. if they are not in
the same data center, to put it somehow).
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
|
|
|
|
|