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.
Related
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.
Is omnisharp server similar to IIS express? Let's say I have a project folder which has only html files, I start the ominisharp server through atom text editor. It gets started and says listening at port xxxx
If I browse localhost://xxxx/index.html will it serve that file?
I am newbie please clarify
No, the point of the Omnisharp server is not to be a general purpose web server - it's to act as a service. Think of it as an "IDE service" that just happens to exposed itself over HTTP, as that's the easiest way for many clients to talk to a service.
Unless you need to integrate something with Omnisharp yourself (i.e. writing code to be a client), you can probably just think of it as a plugin for whatever you're using. (In most cases there will be an actual plugin, which then talks to Omnisharp.)
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 am at my wits' end on this one.
FYI, I work in infrastructure, not .net development, so I know very little about WCF and next to nothing about Visual Studio as an environment, but I don't think that's where the problem lies.
We have a WCF service running on a couple of IIS 7.5 servers on our internal network. This is exposed to the outside world via reverse proxy on Apache 2.2.15 on Fedora 11. The reverse proxy handles load balancing between the IIS servers, as well as SSL.
The WCF service is configured to use transport level security, and the IIS servers have self-signed SSL certificates. The reverse proxy does not authenticate the IIS servers, and the only reason we have SSL on the IIS servers in the first place is so the WSDL will present the correct location URL.
We thought we had it working perfectly, but there's one annoying and crucial exception: the WSDL can't be added as a service reference in Visual Studio on machines running Windows Vista or later. On an XP machine, it's fine, but anything later throws the following error:
There was an error downloading
'[URL]'. The operation has timed out
Metadata contains a reference that
cannot be resolved: '[URL]'. An error
occurred while making the HTTP request
to [URL]. This could be due to the
fact that the server certificate is
not configured properly with HTTP.SYS
in the HTTPS case. This could also be
caused by a mismatch of the security
binding between the client and the
server. The underlying connection was
closed: An unexpected error occurred
on a send. Received an unexpected EOF
or 0 bytes from the transport stream.
If the service is defined in the
current solution, try building the
solution and adding the service
reference again.
The WSDL is accessible through a browser, or through regular SOAP, on any machine and without any SSL complaints. It's just Visual Studio that has an issue.
Initial Googling revealed that it might be a problem with the cipher suite that VS used, suggesting that VS on Vista or later would by default attempt to use TLS1.0 in HTTPS connections, and if an intermediary device didn't support that protocol, it would just drop the request. This is definitely not the case, though. The reverse proxy explicitly prefers TLS1.0, and even when viewing the WSDL through a browser, it flags up as using TLS1.0 for the connection.
Having pointed the proxy at other functioning WCF services on different IIS servers, the same error occurs, leading me to assume it revolves around the reverse proxy configuration. The trouble is that it seems to be identically configured to another reverse proxy carrying out the same task elsewhere.
It's presumably some transport level issue around how VS establishes HTTPS connections on different operating systems, but I simply don't know enough about it to hazard a guess about what that might be. Anyone have any suggestions?
Well, that was embarrassing.
I'm sure there's some unwritten cosmic law that results in me finding the incredibly simple solution to a problem I've been grinding away at for days about ten minutes after posting it up on StackOverflow.
The ServerName directive in the virtual host config didn't match the URL. It did match the certificate (which has a Subject Alternative Name, so it didn't throw up any SSL warnings), but that wasn't the name I was accessing it with.
I'm assuming there's some extension of TLS1.0 that VS uses which enforces this, which isn't used by browsers or SOAP clients. This is probably useful information for anyone else trying this with a certificate that has Subject Alternative Names. It wouldn't have come up otherwise.
If i am hosting a WCF service so that someone(i.e someone whom i know) can consume my service, but what if someone else(i.e someone whom i don't know) consumes it then would do i? How do i prevent that?How can this be achieved?
Can it be done through service throttling or what are the other ways of achieving this?
If you want some some clients to be able to use (or view) your service and some clients to not be allowed to use (or view) your service then you need to setup authentication on your service so that only clients that you allow can access (or view) your service.
I don't know your entire scenario, but transport security with Basic authentication would probably be enough. To enable that you would disable Anonymous access in IIS, configure IIS to use Basic Auth and then in the binding configuration set:
<security mode="Transport">
<transport clientCredentialType="Basic" />
</security>
Set your mex binding to use the secure binding instead of the default mexHttpBinding.
You would also need an SSL certificate for your site (if using WSHttpBinding).
UPDATE: Here's a sample, Custom Secure Metadata Endpoint that demonstrates how to implement a service with a secure metadata endpoint.
No, there's no mechanism in WCF to allow certain clients from using your service while prohibiting others. You'll need to approach this from a different angle.
One way is to not automatically publish your metadata from your service - e.g. make it almost "invisible" - and then distribute the necessary metadata information in the form of one or several WSDL and one or several XSD files to those clients you want to connect to your service. If your metadata is not available, someone just browsing to your service address will not get any information about what to call.
The metadata exchange is controlled by the <serviceMetadata> behavior, and by having a "mex" endpoint on your service. Remove both and your service is invisible.
The other way would be to prohibit any external users to access your WCF server based on firewalls and network rules. This cannot be done by WCF, but your network administrator could limit which IP's have physical access to the machine where your WCF service runs.
Marc
UPDATE:
In order to ship metadata to those users who should be able to call your service, you can do one of two things:
1) Using svcutil.exe /t:metadata (path+name of your service assembly), you can extract the metadata from your service assembly (e.g. MyServiceLibrary.dll). This will give you one or several WSDL and one or several XSD files, which you need to ship to your intended users. They can put these files somewhere on their harddisk and then in the "Add Service Reference", instead of entering the URL to discover the service, they can type in the name of the main WSDL (which imports all other files) and they'll get their client proxy.
Or:
2) With the service up and running, you could "Add New Project" to your solution, choose a Class Library (MyService.Client), then do a "Add Service Reference" and enter your service URL. This will create all the necessary files and everything in your new class library. Compile this class library and ship that assembly MyService.Client.dll to the users you want to allow access to your service.
With both solutions, you don't need to have metadata exchange enabled, and someone else cannot just walk up to your service and get all the information needed in order to call it.