|
Home > Archive > BizTalk Server General > December 2005 > messaging only 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 |
messaging only web service
|
|
|
| I used the 'Create from schema' option of the 'BizTalk Web Services Publishing
Wizard' to create a web service (publish schema as a web service).
I defined a schema for both the incoming and outgoing (response) message
of the web service.
The wizard creates a web service and a two way request-response SOAP port
for me. Because there is no subscription created for the outgoing part/message
of the port I am wondering how to make the web service return a message back
to the calling application. In other words, how do I create a subscription
for this web service without using an orchestration?
Thanks in advance,
R vS
| |
| Yoss Dahan 2005-12-20, 7:59 am |
| R vS wrote:
> I used the 'Create from schema' option of the 'BizTalk Web Services
> Publishing Wizard' to create a web service (publish schema as a web
> service).
> I defined a schema for both the incoming and outgoing (response) message
> of the web service.
> The wizard creates a web service and a two way request-response SOAP
> port for me. Because there is no subscription created for the outgoing
> part/message of the port I am wondering how to make the web service
> return a message back to the calling application. In other words, how do
> I create a subscription for this web service without using an
> orchestration?
>
> Thanks in advance,
>
> R vS
>
>
Because this is a two way port (by definition, as you wish to send a
response) you have to find a way to return a response to the 2way
receive port created for the web service.
They key question is of course what is needed to generate the response
as I have to assume there's some logic involved.
The obvious way is to use an orchestration of course, it will accept the
message and return a response. you have chosen not to go down that road.
Another way is to use a 2way send port to forward the request (or
another, mapped request) to another system using any 2way send adapter.
for instance - you can use the http adapter to post the request to a web
page that will run some code and return a response, this response can
then be mapped to the web service response.
A third way can be to have a custom pipeline on the receive side to
process the request and generate a response.
the pipeline can then use the BTS.RouteDirectToTP to create a loop back
meaning the message will be sent back to the receive port immediately
upon arrival to the message box.
Personally I try to avoid using that as I think it's bad architecture,
but i did find myself using it occasionally.
I hope this helps
Yossi Dahan
| |
|
| Hello Yoss,
Thanks a lot for your response. The options 1 (use an orchestration) and
3 (create a pipeline) make sense to me.
The second option that you describe is not completly clear to me.
How is the result message that comes back, from the 'other system' (in this
case the website), forwarded to the webservice response port. The send part
of this webservice port still has no subscription for the message, or has
it? So I doesn't pick up the message from the message box?
Thanks again,
R vS
> R vS wrote:
>
> Because this is a two way port (by definition, as you wish to send a
> response) you have to find a way to return a response to the 2way
> receive port created for the web service.
>
> They key question is of course what is needed to generate the response
> as I have to assume there's some logic involved.
>
> The obvious way is to use an orchestration of course, it will accept
> the message and return a response. you have chosen not to go down that
> road.
>
> Another way is to use a 2way send port to forward the request (or
> another, mapped request) to another system using any 2way send
> adapter. for instance - you can use the http adapter to post the
> request to a web page that will run some code and return a response,
> this response can then be mapped to the web service response.
>
> A third way can be to have a custom pipeline on the receive side to
> process the request and generate a response.
> the pipeline can then use the BTS.RouteDirectToTP to create a loop
> back
> meaning the message will be sent back to the receive port immediately
> upon arrival to the message box.
> Personally I try to avoid using that as I think it's bad architecture,
> but i did find myself using it occasionally.
> I hope this helps
>
> Yossi Dahan
>
| |
| Yoss Dahan 2005-12-20, 7:59 am |
| R vS wrote:
> Hello Yoss,
>
> Thanks a lot for your response. The options 1 (use an orchestration) and
> 3 (create a pipeline) make sense to me.
> The second option that you describe is not completly clear to me.
> How is the result message that comes back, from the 'other system' (in
> this case the website), forwarded to the webservice response port. The
> send part of this webservice port still has no subscription for the
> message, or has it? So I doesn't pick up the message from the message box?
>
> Thanks again,
>
> R vS
>
>
>
>
>
I'm sorry, you are right, there are two small pieces missing from my
description -
first of all, say you have developed a small aspx page to accept the
message in an http post and return the response. you will not need to
create a 2way send port pointing at this page and use the port filter to
subscribe to the correct message (or to the particular receive port)
second, you need to be familiar with a small biztalk magic here, if a
2way send port subscribes to a 2way receive port the response from the
send port is automatically routed back to the send side of the initial
receive port, so once you have your send port configured you don't
really need to worry about the way back.
Hope this makes the 2nd option a bit clearer.
Yossi Dahan
|
|
|
|
|