According to this BizTalk documentation, the HTTP receive adapter must be in the application (middle) layer. This means BizTalk is limited to a 2-tier architecture, which for modern enterprises is a pretty big limitation.
Is the reverse proxy suggestion that Microsoft recommends (on the link above) the common solution to this problem? Has anyone used any other configuration to use the HTTP receive adapter in the web/perimeter layer and been able to negotiate messages through an application layer?
If the reverse proxy method was used, were existing proxy's in the enterprise used or were dedicated proxy's configured for the solution?
I believe you are confusing application tiers with network architecture.
BizTalk is almost by definition the middle tier, implying at least a 3-tier solution. There would be the client that calls a BizTalk service, the BizTalk application itself, and some line of business application that contains most of the business logic (and then whatever database/repository that system uses to store its records). There could be more than one line of business application that BizTalk interacts with to process the client request.
The diagram and article you have referenced simply describe how you can use a reverse proxy to grant external clients access to BizTalk HTTP(S) endpoints that are hosted on your internal network.
These days it is becoming more common practice to expose the web service via Azure Service Bus Relay or API in Azure. But yes, it is was common to expose your BizTalk web service via a reverse proxy with proper security in place. If you place your BizTalk server in the DMZ, you have to poke a lot of holes from BizTalk to your internal systems, which is what you want to avoid.
Keep in mind, the "n-tier" thing is pretty much meaningless. An app can be as many tiers as you want to count.
However, in 99.9% of cases, there is no reason to put the BizTalk HTTP host or any other endpoint on the perimeter network.
Depending on local polity, shops will do either port forwarding or inbound proxy (reverse proxy isn't really a thing either ;).
There are absolutely no limits in BizTalk for way to accomplish this. How depends entirely on what your network team allows or prefers.
Related
I have a platform archicture with 3 Tiers (Presentation Tier, Application Tier and Data Tier).
I'm currently building a Web Api on the Presentation Tier with OData. I have read that microsoft is going to deprecate OData with WFC, since they don't have enough recourses to continue the project. As an alternative, I want to mascarade the 3Ties platform into 2Tiers, so that OData (on the Presentation Tier) could have direct access to Data Tier.
In order to achieve this I need a Reverse Http Proxy Server right?
Which reliable opensource/free Reverse Http Proxy Servers exists for windows?
Apache has a great reverse proxy built in (using mod_proxy). I've used it for years.
http://geronimo.apache.org/GMOxDOC11/configure-apache-httpd-as-a-reverse-proxy-modproxy.html
https://www.digitalocean.com/community/tutorials/how-to-use-apache-http-server-as-reverse-proxy-using-mod_proxy-extension
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
I am kind of new to system architecture. That is, all of my web apps have been relatively flat...two machines at the most running web client and database.
I have been handed the following architecture:
1 VMware machine will run the web application, an MVC 3 app.
1 VMWare machine will host the SQL Server database
1 VMWare machine will host the services.
The machine I'm confused about is the last one. From what I understand, the services project contains references to three other projects: the model, where the entity framework edmx resides, the entities project, which contains T4 templates that use the entity edmx file as input, and the business project which is where the actual business rules are implemented and the meat of the CRUD actions take place.
From what I understand, the intent is to not run an IIS WCF web services interface, but to make calls to WCF services (like those hosted in the MMC services snap in) on the machine over the internet. There is a deployment project in the solution for the services project but I don't know if it's configured properly. I think the idea is to just run the installer on the services machine and it will work.
My specific question is if there are any important things that I need to keep in mind when implementing, configuring, and deploying these services?
I'm kind of new to all of this. I was under the impression that you had to make calls to WCF services via IIS hosted endpoints and that you couldn't (or it at least was inadvisable) to make what amounts to RPC-like calls to machines over the internet.
Since you are new to WCF services, I suggest reading this MSDN article on Hosting and Consuming WCF services.
From what you describe, it looks like you are using Windows Service as a host for your WCF service.
The most common choice for a host is IIS because of its extensive features including self-starting services, ease of deployment, load balancing and so on.
Windows Service is a valid host, provided you can justify the question 'Why not IIS?'. Maybe, you need full control over the activation and lifetime of your WCF service. Not sure.
p.s. Ensure the account that your Windows Service runs under, has the minimum privileges.
I need to host my WCF service but I am unable to decide whether I should host it in IIS or a windows service?
What are the advantages, drawbacks, benefits of one over the other please?
Thank you
IIS under version 7 is out of the question for any serious hosting anyway....
As for IIS7+/WAS vs. self-hosting in a NT service:
the IIS7/WAS setup will "load on demand", e.g. when your first request comes in, a ServiceHost will be created, then that service host creates the service class to handle the request. This is beneficial from a memory point of view (uses no memory for the ServiceHost if no requests come in), but it's a bit of an additional overhead on the first call when IIS first needs to spin up the service host
NT Service allows you to pre-create the ServiceHost and open it so it's ready to handle requests right away; a bit more memory usage, but a bit more responsive, at least on "first calls"
Another benefit of self-hosting: you're 100% in charge of when the service host starts, pauses, stops, and so on. With IIS/WAS, you're at times at the mercy of IIS with its potential to recycle app pools at the worst possible moment......
The main advantages of IIS is that it handles the lifetime of your service for you: activation, recycling...
Its main drawback if you don't have v7 is that without WAS it can only host http based web services
The services need more care in case of fatal error... and then need to be installed whereas a web site can be copied to its web folder once it has been created
If your version of iis is >= 7, then I don't see a lot of interest in not using WAS as it supports all the wcf transports, others might have a different view though...
Real application how can i use this app fabric ??
How can i put my business logic in this and this logic use in my windows azure application??
Thanks
The Azure AppFabric is a collection of services that allow to you leverage functionality traditionally provided on premise by infrasture components common to most networks. Currently, it consists of the following:
Azure AppFabric Service Bus - allows for connection of applications by providing a centralized relay point in the cloud. Applications create outbound connections to the rendezvous location, thus helping mitigate the challenges posed by security measures like firewall restrictions on in-bound connections and IP masking via NAT layers. This feature includes both 'real time' options as well a 'message buffer' dynamic to allow for more disconnected style communication.
Azure AppFabric Access Control Service - the "ACS" allows WIF applications to quickly access various identity providers and consume a single format of claims token. Used in conjunction with products like ADFS, it allows cloud hosted applications to authenticate against on-premise identity stores.
Azure AppFabric Cache Service - currently in public testing, this service brings the "Velocity" style functionality to applications. This provides them with a distributed cache system as well as a new session provider.
There's more features/services coming in 2011, but these are the hot ones currently. Regarding hosting your business logic, this is not something that is currently available in the Azure AppFabric. There's been mentions that we may eventually see the potential for placing applications "on the edge", meaning the servers that front the Azure AppFabric connections, but no ETA or even firm commitment that this will happen.
You can implement your business logic in Windows Azure, in a web or worker role depending if you need it to be synchronous or asynchronous.
You can surface the business logic using the service bus, though you could also implement your logic on premise and surface them via the service bus.
AppFabric is not a business logic layer. Think of AppFabric as cross-cuts, or glue between different parts of your application.
For now Business logic goes in components like a web or worker role, or an on premise app which you could expose on the internet using AppFabric Service Bus.
In a future release, AppFabric will release "Composite Apps" which in a nutshell seem to allow you to deploy managed WCF/WF workflow services, which makes for a better "business engine". But for now I think you could probably just use Workflow services in a web role.
I am a beginner to webservice concepts. Now I know how to deploy webservice in IIS. I checked the webservice URL
There I can see SOAP protocol contents and WSDL (after url type ?WSDL).
My questions are:
Can I run the webservice by replacing localhost with my IP
address any where outside systems
Do I need to study SOAP and WSDL seperately at any time though both
are generated by visual studio
itself
1: broadly yes, but it depends on your IIS configuration and network topology. Typically, most of the internet won't be able to address your IIS unless you have configured the firewall etc. And DNS would be more typical for public servers. In complex scenarios you may have host-headers, multiple NICs/IPs, or other complications meaning that the IP (by itself) does little.
2: Entirely up to you; it depends largely on the project. If you are only serving your own projects, you can probably ignore the WSDL and rely on VS to do the right thing. If interop/portability is a major concern (to other frameworks/languages), then perhaps write the WSDL first.