Re: Architectural Problem: Own Adapter vs. SQL Adapter
- From: "Tomas Restrepo \(MVP\)" <tomasr@xxxxxxxx>
- Date: Thu, 26 Jan 2006 18:43:21 -0500
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@xxxxxxxx
http://www.winterdom.com/
.
- References:
- Architectural Problem: Own Adapter vs. SQL Adapter
- From: Adam Boczek
- Re: Architectural Problem: Own Adapter vs. SQL Adapter
- From: Tomas Restrepo \(MVP\)
- Re: Architectural Problem: Own Adapter vs. SQL Adapter
- From: Adam Boczek
- Architectural Problem: Own Adapter vs. SQL Adapter
- Prev by Date: pipeline debugging from VS
- Next by Date: Re: pipeline debugging from VS
- Previous by thread: Re: Architectural Problem: Own Adapter vs. SQL Adapter
- Next by thread: RE: Using %SourceFileName% with WSS adapter for Biztalk 2006
- Index(es):
Relevant Pages
|
