Re: BizTalk server Topology & scalibilty

Actually, if I understood the question correctly, this is definitely
possible. Receive adapters are bound to one or more hosts, send adapters
ard bound to a host, and orchestrations can be bound to a host. In
addition, tracking can be configured on a host basis. So you can definitely
have host that is enabled for tracking and that has all of the receive
locations bound to it. You can have another host that you setup your send
ports on and that you bind all of your orchestrations to. There is some
trickiness in terms of the send ports getting bound to default hosts and not
being able to change the host for the MSMQT adapter, but for hte most part
it is straight forward.

Matt


"Jon Fancey" <JonFancey@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A1DE7E78-1DA3-4C27-9E82-EA0CDD0F4BC2@xxxxxxxxxxxxxxxx
> HaloX,
>
> I'm afraid the simple answer to your question is No.
>
> What you are essentially asking is to split different but related
> activities
> within the BizTalk engine across multiple engines on different servers. As
> Hugo points out BizTalk is stateless, that is to say all state is
> maintained
> only in the SQL server databases (unless one inadvertently starts creating
> stateful adapters, orchestrations, etc but that's another story). This
> includes orchestrations, pipelines etc. So, in a non-deterministic way the
> load from receive to send *may* be processed by different servers, for
> example if the orchestration instance is dehydated to the SQL store and
> subsequently rehydrated on another box.
>
> But this is non-deterministic and as such you aren't able to *specify*
> particular servers for particular tasks at this granularity. The only way
> to
> achieve this is to perform routing between servers (by name) within say an
> internal service such that a received request is passed by an
> orchestration
> on box A to box B which will send a reply. This would require some
> hoop-jumping though to avoid a request/reply pattern just passing straight
> back through both boxes for the response. It probably wouldn't buy you
> much
> either if perf or scalability is what you're after.
>
> However, if you are not using a request/reply pattern, say you are using a
> one-way request and one-way response, then you could just deploy each of
> these to different machines (groups - that don't share the same SQL
> config)
> and configure it to achieve what you want. The connection (if any) between
> the two though then has to be handled by you explicitly i.e. you'll have
> to
> do your own correlation.
>
> Hope this helps clarify it a bit for you. I am interested why this is your
> desired config?
>
> "HaloX" wrote:
>
>> Looking through the BizTalk documentation and books I see recommended
>> configuration of hosts. There are the following configurations:
>>
>> 1) Single server: Single server runs ALL BizTalk and SQL operations
>> 2) Two Server: A single server runs SQL while another runs all BizTalk
>> operations.
>> 3) Multiple Server: Multiple servers running BizTalk and configured
>> with
>> each machine host running specific isolated functions to scale out the
>> receive, processing, transmitting and tracking. One or more (recommended
>> for
>> this configuration) servers running SQL in cluster.
>>
>> Now, the issue is I have a SQL cluster running SPS. I want to leverage
>> this
>> cluster because it is hardly tasked and I will have BizTalk run on a
>> seprate
>> SQL instance. I would like to have two machines running BizTalk:
>>
>> * One configured a Message Box Master Recieve, and Tracking
>> * One configured for Transmit and Orchestrations
>>
>> Will BizTalk support this configuration. Nothing in the documentation
>> identifies if certain configs AREN'T supported, but from my experience
>> this
>> doesn't mean much. In SPS there are certain configs not supported and
>> nothing in the initial documentation identified this.
>>
>> Thanks


.

Relevant Pages

  • RE: BizTalk server Topology & scalibilty
    ... within the BizTalk engine across multiple engines on different servers. ... Hugo points out BizTalk is stateless, that is to say all state is maintained ... only in the SQL server databases (unless one inadvertently starts creating ... > this configuration) servers running SQL in cluster. ...
    (microsoft.public.biztalk.server)
  • Re: 403 Error on NODE 2 of Network Load Balanced Server Farm
    ... I followed the instructions under ... Configuring Two Virtual Servers to Host the Same Content ... >> application pool name and configuration. ...
    (microsoft.public.sharepoint.windowsservices)
  • 403 Error on NODE 2 of Network Load Balanced Server Farm
    ... to set up two servers in a NLB to host the same content. ... application pool name and configuration. ...
    (microsoft.public.sharepoint.windowsservices)
  • Re: Tutorial
    ... Deploy from VS2005 expects the BizTalk ... configuration to the BZ database. ... VS2005 server explorer provide a view of the BzTalk server. ... from the server (where the host is running). ...
    (microsoft.public.biztalk.general)
  • BizTalk 2004 NLB
    ... We are planning to use BizTalk 2004 in the following ... configuration could someone see any issues with the ... Solution will use 4 servers. ...
    (microsoft.public.biztalk.general)