Home Page › Forums › BizTalk 2004 – BizTalk 2010 › Where to implement functionality: Webservice or Orchestration?
- This topic has 4 replies, 1 voice, and was last updated 9 years, 2 months ago by
community-content.
-
AuthorPosts
-
-
November 29, 2006 at 3:14 AM #16583
Hello Gurus,
I´m an absolute beginner concerning BizTalk and since my company has one, I´m trying to explore the opportunities for it´s use. I´m currently developing an electronic telephone book, which has different functions such as "findEmployees()" or "getInformationFrom1Employee()". These functions will later on be used by other applictations too. Everything is going to be used over HTTP, so I probably need Webservices.
My problem is of conceptual kind. Where should I implement the functions? The functions are all very simple. They just take the params, search the database and spit out the results in XML. Just to get familiar with BizTalk I implemented the code in an Orchestration for each function. I only use the WebServices as an Interface between Consumer and BTSHTTPrecieve.dll.
Since Orchestrations are supposed to represent business-processes I don´t feel good about this concept since I only have one "business-step" rather than a business-process in my orchestrations. Would it be better to implement all of the functions in Web Services and to do without any orchestrations? Can an orchestration consist of only one business-step and one task, respectively?
Thanky for help!David
-
November 29, 2006 at 7:35 AM #16597
To your question, yes, an orchestration can consist of a single step, but in your case, the extra overhead makes it unnecesary. I'd just go ahead and write the web service as you currently discussed. Where BizTalk, and orchestration may add value is when you want to aggregate functions and expose a single interface. For instance, let's say that in order to do "GetInformationForEmployee()" you actually had to call three different systems (couple databases, maybe another web service that's already out there). In that case, might be a good idea to have an orchestration that calls all three systems for you, and exposes the single "GetInformationForEmployee()" interface to the caller. Given that there is naturally a latency and processing cost for calling into the BizTalk bus, I like to BizTalk to expose (synchronous) web services only when I'm doing some sort of business processing, multi-system coordination, rules, decisions, graceful exception handling, etc.
Hope that helps.
-
November 29, 2006 at 8:18 AM #16599
Thanks a lot, that sounds coherent!
When using an Orchestration with a web-service I have another question. I´ve been trying to do some performance tuning and found out that the BTSHTTPrecieve.dll takes approx. 2 seconds to pass my message to the pipeline. Since the entire response-time (client->webserver->biztalk->client) takes 4-5 seconds, I think that almost 50% of the time is not representative for just passing my message to the pipeline. Are there any ways to get it done faster? Does the BTSHTTPrecieve.dll check in an interval for new messages?
Here´s how it looks like:
client—>Web Service(0.5 Sec)
Web Service–>BTSHTTPrecieve.dll(0 Sec.)
BTSHTTPrecieve.dll–>PipelineIN(2 Sec)
PipelineIN–>Orchestration(0 Sec)Orchestration–>PipelineOut(1 Sec)
PipelineOut–>BTSHTTPrecieve.dll(0 Sec.)
BTSHTTPrecieve.dll->Webservice(1 Sec.)
Webservice->Cleint(0.5 Sec)
-
November 29, 2006 at 9:11 AM #16600
First of all, I'd kick your batch size (in the receive location for HTTP) down to 1. The documentation states:
Batching Support for the HTTP Receive Adapter
The HTTP receive adapter submits messages to the server in batches. The size of the batch used to submit messages to the server can be configured on the HTTP adapter receive handler.
-
November 30, 2006 at 1:47 AM #16622
If latency is a problem, then publishing your orchestration as a web service would cut out one step. The client would call the Biztalk web service directly, rather than going through a double hop
-
-
-
-
-
AuthorPosts
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.