|
Home > Archive > BizTalk Server General > April 2006 > Orchestration best practices
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 |
Orchestration best practices
|
|
| vsavkin 2006-04-01, 2:38 pm |
| Hi,
I have project with multiple orchestrations in it. At the begining it was
ok, but now I added more orchestrations. Now, if I need to do changes in one
orchestration, I have to redeploy all of them. What is the best practices
for orchestrations, to keep it all in one project or put each orchestration
in its own project? Sometimes if you need to do changes in one
orchestration, you don't want to shut down all of them, especially if it
runs in production.
Thanks,
Vladimir.
| |
| Eric Stott 2006-04-01, 2:38 pm |
| The best practices require a little bit of forward thinking...
If you know that development is going to be ongoing, you would most likely
need a seperate project for each orchestration. I would put all
orchestrations that have to do with a single business process in their own
project.
Eric
http://stottcreations.com/blog
"vsavkin" <vsavkin@newsgroup.nospam> wrote in message
news:uvPlhffUGHA.2704@tk2msftngp13.phx.gbl...
> Hi,
>
> I have project with multiple orchestrations in it. At the begining it was
> ok, but now I added more orchestrations. Now, if I need to do changes in
> one orchestration, I have to redeploy all of them. What is the best
> practices for orchestrations, to keep it all in one project or put each
> orchestration in its own project? Sometimes if you need to do changes in
> one orchestration, you don't want to shut down all of them, especially if
> it runs in production.
>
> Thanks,
> Vladimir.
>
>
| |
| Tomas Restrepo \(MVP\) 2006-04-01, 2:38 pm |
| Vladimir,
> I have project with multiple orchestrations in it. At the begining it was
> ok, but now I added more orchestrations. Now, if I need to do changes in
> one orchestration, I have to redeploy all of them. What is the best
> practices for orchestrations, to keep it all in one project or put each
> orchestration in its own project? Sometimes if you need to do changes in
> one orchestration, you don't want to shut down all of them, especially if
> it runs in production.
You sure would need to separate orchestrations into separate assemblies.
However, the best way to do it would depend a lot on what your especific
architecture is, and how dependencies between your orchestrations. For
example, if you use Call or Start orchestrations shapes, it creates a
one-way dependency that, in some cases, needs to be inverted or removed
completely, which can be accomplished via direct-binding and a few other
tricks.
You also probably want to group some orchestrations together either because
they are related (either from a business point of view or because of
dependencies), since you don't want to end usually with one orchestration
per assembly.
Another thing is how you put your other biztalk artifacts in the assemblies.
For example, you'll want to move base and common schemas into separate
assemblies, as long as those are very static (otherwise a change in the
schema will force versioning in all other dependent objects/assemblies).
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
|
|
|
|
|