|
Home > Archive > BizTalk Server Orchestration > June 2005 > Orchestration exposed as web service
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 exposed as web service
|
|
| Victor 2005-06-28, 7:49 am |
| Hello,
I need your "best practises" advise. We have some orchestrations, which:
1. must be exposed as web services for client applications
2. and at the same time must be accessible to be called from another
orchestrations.
At the moment I can see two decisions:
1. orchestration is exposed as web service, so client applications and
another orchestrations access this orchestration only by using exposed web
servise
2. we have two orchestrations: first one encapsulates process logic; it
doesn't receives any messages, it only gets some messages as parameters so
it can be called form other orchestrations; second one is wrapper for
exposing web service, it receives request message from client applications,
calls first orchestration and passes request message as a parameter, gets
response message and sends it to client.
Which approach is better? From one point of view, first one is better,
becase in the case of second approach we will have two orchestrations
instead of one. But accessing one orchestration by calling web service from
another orchestration looks like a not very good decision.
So I'm waiting for your comments.
Regards,
Victor
| |
| Scott Colestock 2005-06-28, 5:52 pm |
| The other thing you can consider is simply publishing the schema (not the
orch) as a web service - and have your orchestration simply subscribe by
message type (direct binding) rather than by port. That way your
orchestration can serve both purposes without a facade orch.
Scott Colestock
www.traceofthought.net
"Victor" <vitiok@takas.lt> wrote in message
news:OxkyF49eFHA.3932@TK2MSFTNGP12.phx.gbl...
> Hello,
>
> I need your "best practises" advise. We have some orchestrations, which:
>
> 1. must be exposed as web services for client applications
> 2. and at the same time must be accessible to be called from another
> orchestrations.
>
> At the moment I can see two decisions:
>
> 1. orchestration is exposed as web service, so client applications and
> another orchestrations access this orchestration only by using exposed web
> servise
> 2. we have two orchestrations: first one encapsulates process logic; it
> doesn't receives any messages, it only gets some messages as parameters so
> it can be called form other orchestrations; second one is wrapper for
> exposing web service, it receives request message from client
> applications, calls first orchestration and passes request message as a
> parameter, gets response message and sends it to client.
>
> Which approach is better? From one point of view, first one is better,
> becase in the case of second approach we will have two orchestrations
> instead of one. But accessing one orchestration by calling web service
> from another orchestration looks like a not very good decision.
>
> So I'm waiting for your comments.
>
>
> Regards,
> Victor
>
| |
| Victor 2005-06-29, 2:47 am |
| >> 1. orchestration is exposed as web service, so client applications and
[vbcol=seagreen]
> The other thing you can consider is simply publishing the schema (not the
> orch) as a web service - and have your orchestration simply subscribe by
> message type (direct binding) rather than by port. That way your
> orchestration can serve both purposes without a facade orch.
Yes, that's the third possible solution. But what about the performance if
we compare the second approach and this one? As I understand, having direct
binding involves messages "transferring" through message box, and it would
have worse performance than calling orchestration. Am I wrong?
Victor
| |
| Scott Colestock 2005-06-29, 5:51 pm |
| Even with option 2 that you laid out, you still take a trip through the
message box - you will never go directly from an adapter to your
orchestration. The message has to first be published, and then the
orchestration subscribes. That fact is just hidden from you a bit when you
aren't subscribing by, say, message type.
Scott Colestock
www.traceofthought.net
"Victor" <vitiok@takas.lt> wrote in message
news:ucjjtNHfFHA.3960@TK2MSFTNGP14.phx.gbl...
>
>
> Yes, that's the third possible solution. But what about the performance if
> we compare the second approach and this one? As I understand, having
> direct binding involves messages "transferring" through message box, and
> it would have worse performance than calling orchestration. Am I wrong?
>
>
> Victor
>
>
>
| |
| Victor 2005-06-29, 5:51 pm |
| I know that when message goes from adapter to orchestration it does so
through message box 
When I asked about performance I wanted to ask about passing messages
between orchestrations, not web services.
When message comes to orchestration through web service it actually comes
through message box, so in my option 2 and your option with direct binding
performance would be nearly the same I guess.
But when message is being send to other orchestration:
- in your option with direct binding calling orchestration (which sends the
message) puts message into message box, so after that our orchestration gets
it from there
- in my option 2 message is being passed as a parameter to other
orchestration by using Call Orchestration, so as I know it goes directly to
that orchestration, and performance in this place is better than with direct
binding, isn't it?
Victor
---------------
Lemonas
"Scott Colestock" <scolestock@community.nospam> wrote in message
news:%23fIz7BLfFHA.3944@tk2msftngp13.phx.gbl...[vbcol=seagreen]
> Even with option 2 that you laid out, you still take a trip through the
> message box - you will never go directly from an adapter to your
> orchestration. The message has to first be published, and then the
> orchestration subscribes. That fact is just hidden from you a bit when
> you aren't subscribing by, say, message type.
>
> Scott Colestock
> www.traceofthought.net
>
>
> "Victor" <vitiok@takas.lt> wrote in message
> news:ucjjtNHfFHA.3960@TK2MSFTNGP14.phx.gbl...
| |
| Scott Colestock 2005-06-29, 5:51 pm |
| Ahhh, I understand your question better. Yes, having the orchestration
"callable" through direct binding will not be as fast as if the
orchestration accepted parameters and you used the "call orchestration"
shape from the caller.
But don't optimize too early - depending on the work you are doing in the
orchestration (which might be significant, if you're trying to achieve
reuse) the extra trip through the messagebox might not mean much perf-wise
in the grander scheme.
Take a peek at the biztalk performance whitepaper - notice that "Call orch"
vs. "start orch" (the latter goes through the msg box too) compare at 140
orchs completed/sec vs. 90 for the"start" case. This is for the case where
the "second" orchestration (the callee) has a near-empty implementation.
Once the implementation is significant, this kind of difference will start
to look quite small.
Scott Colestock
www.traceofthought.net
"Victor" <vitiok@takas.lt> wrote in message
news:epYX82LfFHA.572@TK2MSFTNGP15.phx.gbl...
>I know that when message goes from adapter to orchestration it does so
>through message box
>
> When I asked about performance I wanted to ask about passing messages
> between orchestrations, not web services.
>
> When message comes to orchestration through web service it actually comes
> through message box, so in my option 2 and your option with direct binding
> performance would be nearly the same I guess.
> But when message is being send to other orchestration:
> - in your option with direct binding calling orchestration (which sends
> the message) puts message into message box, so after that our
> orchestration gets it from there
> - in my option 2 message is being passed as a parameter to other
> orchestration by using Call Orchestration, so as I know it goes directly
> to that orchestration, and performance in this place is better than with
> direct binding, isn't it?
>
>
> Victor
>
>
> ---------------
> Lemonas
> "Scott Colestock" <scolestock@community.nospam> wrote in message
> news:%23fIz7BLfFHA.3944@tk2msftngp13.phx.gbl...
>
>
| |
| Victor 2005-06-30, 2:53 am |
| Thank you Scott, now I've had all answers I needed
Victor
|
|
|
|
|