- This topic has 2 replies, 1 voice, and was last updated 9 years, 5 months ago by
.
-
Posts
-
-
Hi All,
We'll shortly be starting implementation of BizTalk server 2006 in a big bank (over 1000 branches allover the country). What we plan to do at receive end is make most of the calls using SOAP (orchestrations exposed as web services). This is because Load balancing at receive end in BizTalk is limited to SOAP and HTTP adapters.
I am interested in knowing from all the experts out there in the community:
1) Is this the right way to go?, or are there any negative sides of using SOAP based interactions (like speed)?
2) Whats the usual practice in the industry (I know its not hard & fast), Is SOAP (orchestrations exposed as WSs) used extensively or other options like File, FTP, queue are more popular?
3) If you have a choice where you can chose b/w File, FTP, queue, SOAP, HTTP etc., which receive adapter would you prefer to use and why?
Thanks for your time,
Regards,
Sajid.
-
My first choice would always be Web Services (preferably WCF although you need BTS 2006 R2)
Legacy protocols like File and FTP should only be used when you have no other choice. These protocols require other software components to deliver messages and there is no continuity between sender and receiver.
HTTP is similar to Web Service, although is a lower level protocol – no metadata discovery, less options for security (restricted to HTTPS/SSL for authentication and encryption)
Queuing is an definite option for asynchronous messages when you cannot rely on the end-points being available, and you do not wish to handle error recovery/retries in your client code. WCF reliable messaging is not yet at the stage to replace MSMQ or Websphere MQ ( no underlying message persistence)
Using WCF will enable you to use a similar interface model for Biztalk delivered services and other services using the WS-* protocols.
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.