Hi,
I need some help in design, wondering if we need to create
custom Adapter or directly call the .NET classes from the
Orchestration.

Here is my senarioo..
I am trying to integrate our Web site with our internal
application(s) using BizTalk server. Plan is to create an
Orchestration and expose it as Web service which can be
consumed by the Web server. So for so good. All our
internal applications are written in .NET and accept data
in XML format and return the result in XML format. My
question is, should I directly call these .NET classes of
internal application(s) from Orchestration?  Or write
adapters for our applications which in turn call our .NET
classes?
Any input/benefits/drawbacks of each method would be
greatly appreciated.

Regards,
Thanks in advance.
Chandan

[ Post a follow-up to this message ]

Hi,

Would it be an option to create a Web Service Facade for your internal
applications? You could then call the web services directly form BizTalk.

Calling the applications from .net would mean they need to reside on the
same box as BizTalk server. Writing custom adapters may be complex.

/Alan


"Chandan" wrote:

> Hi,
> I need some help in design, wondering if we need to create
> custom Adapter or directly call the .NET classes from the
> Orchestration.
>
> Here is my senarioo..
> I am trying to integrate our Web site with our internal
> application(s) using BizTalk server. Plan is to create an
> Orchestration and expose it as Web service which can be
> consumed by the Web server. So for so good. All our
> internal applications are written in .NET and accept data
> in XML format and return the result in XML format. My
> question is, should I directly call these .NET classes of
> internal application(s) from Orchestration?  Or write
> adapters for our applications which in turn call our .NET
> classes?
> Any input/benefits/drawbacks of each method would be
> greatly appreciated.
>
> Regards,
> Thanks in advance.
> Chandan
>

[ Post a follow-up to this message ]

Can you describe what you're trying to accomplish in a little more detail?
What are your "internal applications" trying to do and how do they relate to
your web application and BizTalk? Are they receiving data from your web app
or sending data to your web app?

One general thing I've found helpful is to keep in mind the concept of
"loosely coupled" applications.  If you are trying to use BizTalk to submit
an order from a web app to a backend system, then directly connecting them
can be bad for speed, scalability and reliability. Having your web app post
XML to your BizTalk Server thru MSMQ or a web service and then having
BizTalk process this XML to your backend systems keeps everything more or
less "loosely coupled" so if your backend system is down the entire process
doesn't fail.

--
Jeff Lynch
"A BizTalk Enthusiast"
http://dotnetjunkies.com/WebLog/jlynch/


"Chandan" <anonymous@discussions.microsoft.com> wrote in message
news:2c2f01c4a566$afc30f60$a501280a@phx.gbl...
> Hi,
> I need some help in design, wondering if we need to create
> custom Adapter or directly call the .NET classes from the
> Orchestration.
>
> Here is my senarioo..
> I am trying to integrate our Web site with our internal
> application(s) using BizTalk server. Plan is to create an
> Orchestration and expose it as Web service which can be
> consumed by the Web server. So for so good. All our
> internal applications are written in .NET and accept data
> in XML format and return the result in XML format. My
> question is, should I directly call these .NET classes of
> internal application(s) from Orchestration?  Or write
> adapters for our applications which in turn call our .NET
> classes?
> Any input/benefits/drawbacks of each method would be
> greatly appreciated.
>
> Regards,
> Thanks in advance.
> Chandan

[ Post a follow-up to this message ]

Thanks for the response. here is more detail.
Our Web application is more like a Portal to lot of our
internal applications. If one of our internal application
were to go down only the section which relates to that
application on the Web site will not work, but rest of the
site will continue to work.

One of the example is, when the web user tries to places
an Order on the web, we check the stock availability
against internal system. Only if the stock is available,
we let them place an order. When an Order is created the
Order is directly created on the internal application.
Keeping this in mind what would you suggest, should we
write an adapter or direct .NET class invocation from the
Orchestration.
Any further input would be greatly appreciated.

PS: Our internal applications are available 24/7. If this
were to go down, we will display appropriate error on the
Website.

>-----Original Message-----
>Can you describe what you're trying to accomplish in a
little more detail?
>What are your "internal applications" trying to do and
how do they relate to
>your web application and BizTalk? Are they receiving data
from your web app
>or sending data to your web app?
>
>One general thing I've found helpful is to keep in mind
the concept of
>"loosely coupled" applications.  If you are trying to use
BizTalk to submit
>an order from a web app to a backend system, then
directly connecting them
>can be bad for speed, scalability and reliability. Having
your web app post
>XML to your BizTalk Server thru MSMQ or a web service and
then having
>BizTalk process this XML to your backend systems keeps
everything more or
>less "loosely coupled" so if your backend system is down
the entire process
>doesn't fail.
>
>--
>Jeff Lynch
>"A BizTalk Enthusiast"
>http://dotnetjunkies.com/WebLog/jlynch/
>
>
>"Chandan" <anonymous@discussions.microsoft.com> wrote in
message
>news:2c2f01c4a566$afc30f60$a501280a@phx.gbl... 
create[vbcol=seagreen] 
the[vbcol=seagreen] 
an[vbcol=seagreen] 
data[vbcol=seagreen] 
of[vbcol=seagreen] 
our .NET[vbcol=seagreen] 
>
>
>.
>

[ Post a follow-up to this message ]

From what describe, I would definitely recommend a loosely coupled approach
using cached data

--
Jeff Lynch
"A BizTalk Enthusiast"
http://dotnetjunkies.com/WebLog/jlynch/


"Chandan" <anonymous@discussions.microsoft.com> wrote in message
news:13d801c4a600$68448bb0$a601280a@phx.gbl...[vbcol=seagreen]
> Thanks for the response. here is more detail.
> Our Web application is more like a Portal to lot of our
> internal applications. If one of our internal application
> were to go down only the section which relates to that
> application on the Web site will not work, but rest of the
> site will continue to work.
>
> One of the example is, when the web user tries to places
> an Order on the web, we check the stock availability
> against internal system. Only if the stock is available,
> we let them place an order. When an Order is created the
> Order is directly created on the internal application.
> Keeping this in mind what would you suggest, should we
> write an adapter or direct .NET class invocation from the
> Orchestration.
> Any further input would be greatly appreciated.
>
> PS: Our internal applications are available 24/7. If this
> were to go down, we will display appropriate error on the
> Website.
> 
> little more detail? 
> how do they relate to 
> from your web app 
> the concept of 
> BizTalk to submit 
> directly connecting them 
> your web app post 
> then having 
> everything more or 
> the entire process 
> message 
> create 
> the 
> an 
> data 
> of 
> our .NET 

[ Post a follow-up to this message ]

Sorry about that. Poor typing skills. Here is the rest of my post.

From what you describe, I would definitely recommend a loosely coupled
approach using cached data (assuming you're using an ASP.NET web app) on
your web app and orchestrations / web services to submit order to your
"internal applications". This will allow you the best scalability and
reliability in the long run. Take a look at the MSIB documentation for
additional ideas.

http://www.microsoft.com/windowsser...ib/default.mspx

--
Jeff Lynch
"A BizTalk Enthusiast"
http://dotnetjunkies.com/WebLog/jlynch/


"Jeff Lynch" <jeff.lynch@houston-lynch.com> wrote in message
news:uJy4UqipEHA.1152@TK2MSFTNGP11.phx.gbl...
> From what describe, I would definitely recommend a loosely coupled
> approach using cached data
>
> --
> Jeff Lynch
> "A BizTalk Enthusiast"
> http://dotnetjunkies.com/WebLog/jlynch/
>
>
> "Chandan" <anonymous@discussions.microsoft.com> wrote in message
> news:13d801c4a600$68448bb0$a601280a@phx.gbl... 
>
>

[ Post a follow-up to this message ]

Hi Thanks for your quick response. Unfortunately we can
not work on the Cache data as our products are perishable.
We have multiple channels for taking the Order. Web site,
Call centre and our Retail Outlets.   Hence we want to use
single data source. What would you suggest in this
scenario?
Thanks in advance.
Chandan
---Original Message-----
>Sorry about that. Poor typing skills. Here is the rest of
my post.
>
>From what you describe, I would definitely recommend a
loosely coupled
>approach using cached data (assuming you're using an
ASP.NET web app) on
>your web app and orchestrations / web services to submit
order to your
>"internal applications". This will allow you the best
scalability and
>reliability in the long run. Take a look at the MSIB
documentation for
>additional ideas.
>
>http://www.microsoft.com/windowsser...m/ebusiness/msi
b/default.mspx
>
>--
>Jeff Lynch
>"A BizTalk Enthusiast"
>http://dotnetjunkies.com/WebLog/jlynch/
>
>
>"Jeff Lynch" <jeff.lynch@houston-lynch.com> wrote in
message
>news:uJy4UqipEHA.1152@TK2MSFTNGP11.phx.gbl... 
loosely coupled[vbcol=seagreen] 
in message[vbcol=seagreen] 
application[vbcol=seagreen] 
the[vbcol=seagreen] 
places[vbcol=seagreen] 
available,[vbcol=seagreen] 
the[vbcol=seagreen] 
the[vbcol=seagreen] 
this[vbcol=seagreen] 
the[vbcol=seagreen] 
data[vbcol=seagreen] 
use[vbcol=seagreen] 
Having[vbcol=seagreen] 
and[vbcol=seagreen] 
down[vbcol=seagreen] 
in[vbcol=seagreen] 
internal[vbcol=seagreen] 
create[vbcol=seagreen] 
be[vbcol=seagreen] 
classes[vbcol=seagreen] 
>
>
>.
>

[ Post a follow-up to this message ]