We're upgrading a server application to .NET Core 6. It provides SOAP Web Services to several existing clients via .ASMX pages. .NET Core doesn't support server-side WCF anymore. gRPC, or at the very least CoreWCF, are recommended alternatives. Unfortunately, we have no control over the hundreds of deployed client applications. The alternative must be fully compatible with them, including the URL, which is hardcoded, and message formatting.
From my understanding, gRPC is a replacement for WCF, but it's unclear if it's capable of supporting SOAP over HTTP. Another alternative, CoreWCF, does support it, but it might be a significant technical investment for a stop-gap technology. It would be nice to leverage the learning curve towards more current. It's unclear whether either of the solutions is capable of servicing ASMX files.
Does gRPC support SOAP? If so, is it straightforward, or does it require a considerable amount of development effort? Finally, does either CoreWCF or gRPC support serving ASMX files? If not, is it possible to simply respond to ASMX URLs seamlessly?
I found SoapCore, a solution that serves our needs perfectly.
https://github.com/DigDes/SoapCore
I incorrectly thought ASMX was a WCF feature, but it's just a facility provided by ASP.NET for basic server-side HTTP/SOAP. Since our application is based on ASP.NET, the ASMX URL can be accessed via MVC URL routing:
public void ConfigureServices(IServiceCollection services)
{
services.AddSoapCore();
services.TryAddSingleton<ServiceContractImpl>();
services.AddMvc();
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
app.UseRouting();
// Route "ServicePath.asmx" to our service endpoint
app.UseEndpoints(endpoints => {
endpoints.UseSoapEndpoint<ServiceContractImpl>("/ServicePath.asmx", new SoapEncoderOptions(), SoapSerializer.DataContractSerializer);
});
}
While it is a stop-gap solution, it's specifically a SOAP messaging library rather than a general-purpose protocol framework. Setting it up and putting it into production requires straight-forward and simple.
Related
After reading Microsoft documents I am still confused. I need to deploy a .net core 2 web application I developed to an IIS server and I can't get a straight forward answer on anything. This is just the beginning of my questions.
What is the difference between IWebHost, WebHostBuilder, BuildWebHost?
Thanks!
First of all, let me start with that I very much disagree with your statement: The documentation on ASP.NET Core is actually very good. Yes, it may be still lacking in some details, and it also has some problems catching up to changes with releases, but overall the content is really good and the team working on it is really doing a remarkable job. It’s really difficult to author a documentation for such a large and fast-moving framework, and the amount of information you get through the documentation is actually very good. You will likely get to recognize that once you have overcome the initial problems in starting with a new framework.
But coming back to your question:
IWebHost: The web host is the general thing that hosts and runs your web application. It gets created when your application starts up, and then it will construct all the necessary pieces, like the Kestrel web server, the application middleware pipeline, and all the other bits, and connects them, so that your application is ready to serve your requests.
The web host is basically the thing that makes up your web application.
IWebHostBuilder: The web host builder is basically a factory to create a web host. It is the thing that constructs the web host but also configures all the necessay bits the web host needs to determine how to run the web application.
With ASP.NET Core 2, you will usually create a “default web host builder” which will already come with a lot defaults. For example, the default web host will set up the Kestrel web server, enable and configure logging, and add support for the appsettings.json configuration.
Usually, your applications will always start with such a default web host and you then just use the web host builder to subsequently configure the web host before it is actually being built.
BuildWebHost is part of the older convention before ASP.NET Core 2.1 where the default pattern in the Program.cs was to build the web host in a separate method. With 2.1, this was changed so that the method would no longer build the web host directly but just create the web host builder (hence the method now being called CreateWebHostBuilder). So basically, the .Build() call on the web host builder was refactored out of the method. You can see this nicely in the migration guide for 2.0 to 2.1.
The reason this was done is to make the CreateWebHostBuilder reuseable. The builder configuration that happens in that method is basically everything that is necessary to configure the web host. So by making that reusable, without generating an actually created web host, it can be used for other purposes. In this case, this was done for integration testing using the TestHost. The test host will basically host the web host internally for your integration tests, and it will do so by looking for the CreateWebHostBuilder method.
With ASP.NET Core 2.1, the default pattern you see in the Program.cs is the following (comments added by me for further explanations):
public class Program
{
// main entry point for your application
public static void Main(string[] args)
{
// create the web host builder
CreateWebHostBuilder(args)
// build the web host
.Build()
// and run the web host, i.e. your web application
.Run();
}
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
// create a default web host builder, with the default settings and configuration
WebHost.CreateDefaultBuilder(args)
// configure it to use your `Startup` class
.UseStartup<Startup>();
}
Btw. this topic is generally covered in the application startup and hosting sections of the official documentation.
ASP.NET Core 3.x
Starting with ASP.NET Core 3.0, there has been a change with the setup I described above. The reason for this is the generic host. The “generic host” is a generalization of the web host and the web host builder, to allow non-web scenarios outside of ASP.NET Core, making ASP.NET Core itself just a “hosted service” that runs on top of the generic host.
IHost: The host is the component that hosts and runs your application and its services. This is a generalization of the previous IWebHost but fullfills basically the same task: It starts configured hosted services and makes sure that your app is running and working.
IHostBuilder: The host builder constructs the host and configures various services. This is the generalization of the previous IWebHostBuilder but also basically does the same just for generic IHost. It configures the host before the application starts.
There is the Host.CreateDefaultBuilder method that will set up a host with various defaults, e.g. configuration using appsettings.json and logging.
IHostedService: A hosted service is a central component that the host hosts. The most common example would be the ASP.NET Core server, which is implemented as a hosted service on top of the generic host.
You can also write your own hosted services, or add third-party services that allow you to nicely add things to your application.
The generic host introduced with ASP.NET Core 3.0 and .NET Core 3.0 basically replaces the previous IWebHost and IWebHostBuilder. It follows the very same architecture and idea but is simply reduced to non-web tasks so that it can work with a number of different purposes. ASP.NET Core then just builds on top of this generic host.
what is this WCF ? i used web services little bit but don't know about theses WCF, read a lot on google but couldn't get its technical terms like
http://www.codeproject.com/Articles/139787/What-s-the-Difference-between-WCF-and-Web-Services
or msdn.
It says like communication over HTTP and SOAP , serialization, soap etc but yet I'm not qualified to understand these. Help me, guide me and please in easy wordings.
[WebService]
public class Service : System.Web.Services.WebService
{
[WebMethod]
public string Test(string strMsg)
{
return strMsg;
}
}
etc
and how to use them with asp.net ?
Windows communication foundation or Wcf is a framework for building services. Wcf supports exposing web services, services based on urls (rest) or services ment only to work on a single machine, such as two different programs communicating via shared memory.
Basically wcf abstracts the service (a .net interface) and the transport (or in wcf terms, a binding). A single service in Wcf can be exposed as a web service or using shared memory without any actual code changes, the endpoints are all based on app config files.
Perhaps this article on msdn will make things clearer
http://msdn.microsoft.com/en-us/library/ms731082.aspx
Some terms,
Interoperability - to operate, or work together, with something else (inter- between, operate- work together) a wcf service can interoperate with a client written in java for example
Serialization - to convert an object to a stream of bytes that can be sent somewhere and then deserialized back into an object
We have a windows service that is self-hosting a WCF Data Service, using the DataServiceHost class. Everything is working just fine, but we would like to hook up some HTTPModules to the service, if possible. One of the HTTP Modules would be for custom basic authentication, the other for auditing (including responses, which is why an HTTP Module works so well for this).
Keep in mind that we are running as a regular windows service, so we have no web.config, the service is not hosted by IIS, and it is not an ASP.Net application.
So, my questions are:
Is it possible to have an HTTP Module listen on a self-hosted WCF data service?
If this is not possible, what options would I have that are similiar to the power of an HTTP Module?
WCF doesn't operate on the same request pipeline as standard ASP.NET applications, although you can take advantage of a number of ASP.NET features (like session) if you configure your service for ASP.NET compatibility.
[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
However, it looks like you just need something that will let you jump into the pipeline the way that HTTPModules do for an ASP.NET Application. That being the case, there are plenty of options. You can check out this page for a lot of samples.
You mentioned authentication, and there are plenty of options built into WCF that can save you from rolling your own solution. Check it out here.
I have been going through the book "Learning WCF" trying to get my head around creating and using WCF web services. The first part of the book walks the reader through creating and then consuming a simple "Hello World" web service.
The problem I am having is that the client application seems to have no know the structure of the WCF Interface when calling it. How can this be necessary if a web service could be called from any number of programming languages?
I have listed the relevant example code below ...
Here is the code for the Interface
[ServiceContract(Namespace="http: //www.thatindigogirl.com/samples/2006/06")]
public interface IHelloIndigoService
{
[OperationContract]
string HelloIndigo();
}
Here is the code for the Service that hosts the web service
static void Main(string[] args)
{
using (ServiceHost host = new ServiceHost(typeof(HelloIndigo.HelloIndigoService) ,
new Uri("http: //localhost: 8000/HelloIndigo")))
{
host. AddServiceEndpoint(typeof(HelloIndigo. IHelloIndigoService) ,
new BasicHttpBinding(), "HelloIndigoService");
host. Open( );
Console. WriteLine("Press <ENTER> to terminate the service host") ;
Console. ReadLine();
}
}
Here is the code for the client app that consumes the WCF service
This is where I get confused. Since this client application could be any language capable of calling a web service why is there a necessity of knowing the definition of the interface?
using System. ServiceModel;
[ServiceContract(Namespace = "http: //www.thatindigogirl.com/samples/2006/06")]
public interface IHelloIndigoService
{
[OperationContract]
string HelloIndigo( );
}
static void Main(string[ ] args)
{
EndpointAddress ep = new
EndpointAddress("http: //localhost: 8000/HelloIndigo/HelloIndigoService") ;
IHelloIndigoService proxy = ChannelFactory<IHelloIndigoService>.
CreateChannel(new BasicHttpBinding(), ep);
string s = proxy. HelloIndigo();
Console. WriteLine(s) ;
Console. WriteLine("Press <ENTER> to terminate Client.") ;
Console. ReadLine();
}
Am I missing an important point here? Perhaps my understanding of what is needed to consume a web is lacking. My goal is to be able to use WCF to create a .NET service that could be called from any programming language or environment.
Might anyone suggest a good tutorial on creating "cross platform consumable" web services from within .NET? Thanks!
This approach is based on shared interface (the book acutally does not share the interface but instead it uses local copy) and is successfully applied in environment where both client and server are written in .NET. This approach is not usable for interoperability or SOA solutions.
Other approach uses metadata exposed by the service. Metadata are defined as WSDL document plus several XSD documents. These metadata files are way to provide information about your service to both .NET and non .NET developers. The book contains definition of Metadata (mex) endpoint so you will definitely read about that.
Using metadata in .NET means creating service proxy. You can do it automatically using Visual studio's Add service reference or command line utility svcutil.exe. Anyway generated proxy code will probably still contain the interface created from metadata. It is used to create transparent abstraction of the service for the client.
'The interface' doesn't mean a .NET interface file, it means the more general programming interface - a set of objects with properties, and methods with parameters. This is also called the service contract.
The reason that the client and the service need to share (i.e. both know about) the interface is simple when you think about it - if the client doesn't know the interface, how do they know what operations are available and what the expected request/response objects should look like?
Every WCF service is composed of
A - address
B - binding
C - contract
The contract is declared using an interface on the serverside. It declares which methods are available to the client. If you are using a http binding you can invoke a service operation by issuing a http request (using a http client in any library or language - or even a web browser) pointed at the correct address. So the client does not need any interface reference at all. It just needs to follow the ABC of the service.
Here is a nice blog on WCF and Java interopability.
To answer your question on how to develop 'cross platform consumable' web services, consider the REST approach. Making REST-style web services truly makes them independent of the platform that consumes them. Simply put, they use the already well established HTTP protocols everything supports: GET and POST Http methods.
You could then have a Java app simply make POST calls to your WCF services with your own custom XML content in the payload without having to fiddle with more complex stuff like making SOAP wrappers and the like. Check out Rob Bagby's article on REST:
http://www.robbagby.com/rest/rest-in-wcf-part-i-rest-overview/
What is the difference between them?
When would I opt for one over the other?
This answer is based on an article that no longer exists:
Summary of article:
"Basically, WCF is a service layer that allows you to build applications that can communicate using a variety of communication mechanisms. With it, you can communicate using Peer to Peer, Named Pipes, Web Services and so on.
You can’t compare them because WCF is a framework for building interoperable applications. If you like, you can think of it as a SOA enabler. What does this mean?
Well, WCF conforms to something known as ABC, where A is the address of the service that you want to communicate with, B stands for the binding and C stands for the contract. This is important because it is possible to change the binding without necessarily changing the code. The contract is much more powerful because it forces the separation of the contract from the implementation. This means that the contract is defined in an interface, and there is a concrete implementation which is bound to by the consumer using the same idea of the contract. The datamodel is abstracted out."
... later ...
"should use WCF when we need to communicate with other communication technologies (e,.g. Peer to Peer, Named Pipes) rather than Web Service"
From What's the Difference between WCF and Web Services?
WCF is a replacement for all earlier web service technologies from Microsoft. It also does a lot more than what is traditionally considered as "web services".
WCF "web services" are part of a much broader spectrum of remote communication enabled through WCF. You will get a much higher degree of flexibility and portability doing things in WCF than through traditional ASMX because WCF is designed, from the ground up, to summarize all of the different distributed programming infrastructures offered by Microsoft. An endpoint in WCF can be communicated with just as easily over SOAP/XML as it can over TCP/binary and to change this medium is simply a configuration file mod. In theory, this reduces the amount of new code needed when porting or changing business needs, targets, etc.
ASMX is older than WCF, and anything ASMX can do so can WCF (and more). Basically you can see WCF as trying to logically group together all the different ways of getting two apps to communicate in the world of Microsoft; ASMX was just one of these many ways and so is now grouped under the WCF umbrella of capabilities.
Web Services can be accessed only over HTTP & it works in stateless environment, where WCF is flexible because its services can be hosted in different types of applications. Common scenarios for hosting WCF services are IIS,WAS, Self-hosting, Managed Windows Service.
The major difference is that Web Services Use XmlSerializer. But WCF Uses DataContractSerializer which is better in performance as compared to XmlSerializer.
Web Service
is based on SOAP and return data in XML form.
It support only HTTP protocol.
It is not open source but can be consumed by any client that understands xml.
It can be hosted only on IIS.
WCF
is also based on SOAP and return data in XML form.
It is the evolution of the web service(ASMX) and support various protocols like TCP, HTTP, HTTPS, Named Pipes, MSMQ.
The main issue with WCF is, its tedious and extensive configuration.
It is not open source but can be consumed by any client that understands xml.
It can be hosted with in the applicaion or on IIS or using window service.
Basic and primary difference is, ASP.NET web service is designed to exchange SOAP messages over HTTP only while WCF Service can exchange message using any format (SOAP is default) over any transport protocol i.e. HTTP, TCP, MSMQ or NamedPipes etc.
What is the difference between web service and WCF?
Web service use only HTTP protocol while transferring data from one application to other application.
But WCF supports more protocols for transporting messages than ASP.NET Web services. WCF supports sending messages by using HTTP, as well as the Transmission Control Protocol (TCP), named pipes, and Microsoft Message Queuing (MSMQ).
To develop a service in Web Service, we will write the following code
[WebService]
public class Service : System.Web.Services.WebService
{
[WebMethod]
public string Test(string strMsg)
{
return strMsg;
}
}
To develop a service in WCF, we will write the following code
[ServiceContract]
public interface ITest
{
[OperationContract]
string ShowMessage(string strMsg);
}
public class Service : ITest
{
public string ShowMessage(string strMsg)
{
return strMsg;
}
}
Web Service is not architecturally more robust. But WCF is architecturally
more robust and promotes best practices.
Web Services use XmlSerializer but WCF uses DataContractSerializer. Which is
better in performance as compared to XmlSerializer?
For internal (behind firewall) service-to-service calls we use the net:tcp
binding, which is much faster than SOAP.
WCF is 25%—50% faster than ASP.NET Web Services, and approximately 25%
faster than .NET Remoting.
When would I opt for one over the other?
WCF is used to communicate between other applications which has been developed on other platforms and using other Technology.
For example, if I have to transfer data from .net platform to other application which is running on other OS (like Unix or Linux) and they are using other transfer protocol (like WAS, or TCP) Then it is only possible to transfer data using WCF.
Here is no restriction of platform, transfer protocol of application while transferring the data between one application to other application.
Security is very high as compare to web service
The major difference is time-out, WCF Service has timed-out when there is no response, but web-service does not have this property.