- This topic has 2 replies, 1 voice, and was last updated 9 years, 3 months ago by
.
-
Posts
-
-
Hello forum,
The WCF adapters has lot of built in capabilities ….w.r.t to actual implementation I have a Doubt . can some one give me information for the same ..
Background.
Earlier i used WCF Adapter NETTCP Binding based receive port created in BizTalk Admin console and I could submit messages to BizTalk , to host the service I did not use any other Windows Service or WAS / IIS etc …but I belive it was hosted by BizTalk itself. ONLY THE MEX endpoint information is published in IIS and IIS is not actually hosting the service. this was for internal Clients so Having BizTalk and Nettcp WCF Service was behind a Fire wall in intranet and no need to get in DMZ
Doubt
I also started using a similar Implementation of WCF Receive port using WShttp Binding . and this time i used the WCF Service Publishing Wizard. ..it works well but I needs a Virtual Directory in IIS i thought it would be just for meta data but upon testing I Found that the Receive Ports Listens to that VirtualDirNAme/Service.svc hosted in IIS,.
My doubt is can I expose a WSHttp based Receive Port without Using IIS or WAS on biztalk machine ? or Can I use some other hosting envoirment for WSHttp based Receive Port i.e. if I have IIS on a seperate machine what kinda Trusts and Permissions I need to setup say IF My IIS is in DMZ and Biztalk sits behind a firewall, what are the implications , server hardning issues etc…as such funtionality is for external callers and IIS has to be kept in DMZ.
Thanks in Adavance for your guidance
-
Your receive location must be resident in IIS/WAS on a BizTalk server. The receive location code is responsible for receiving the message from the wire, running the pipeline, any maps and writing to the MessageBox database. If this code executes in the DMZ you will need to open firewall ports to expose the BizTalk SQL databases to the DMZ. This is less secure than opening ports 80, 443 to allow HTTP access to a web service inside your network.
The standard practice for offering public web services from BizTalk is to use a reverse proxy such as ISA server or create your own web service in the DMZ that calls the BizTalk web service internally. My preferred option is the reverse proxy approach. The ISA server or other vendors product is specifically built as a security device. You do not have to write code and be concerned about potential security issues in this code. The reverse proxy is less maintenance and probably more secure.
Latest ISA server is now called Forefront Threat Management Gateway 2010
-
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.