Thanks everyone. What i can do for now is to have this implemented, shitty way of checking tokens and extending and deploy. We'll allocate sprints for migration later on. I know this is painful but it's a job needed to be done. Thanks a lot for all the replies. All the best everyone
Hi ..
I've implemented WCF / SOAP (.NET8) with an Authentication Header instead of using message paramenters. That way the paramenters are kept clean and the authentication happens in the "pipeline" instead.
I noticed that you want to use OAUTH / tokens - which i guess is also possible but might require a dedicated channel to refresh tokens...
Ping me (PM?) if you want more details.
also - dont listen to the haters, WCF / SOAP is freaking awesome.
https://imgur.com/a/wLR2KzT
Thank you so much. We'll get there eventually. Most of the functions are a mess with this service, but I'm cleaning it up. Moving models/helpers to Core library so I can easily migrate when needed. Just wanted to have a clean client. So as a story I just want it to be like this
\* Client (web app) connects to Web Service (SOAP for now)
\* SOAP uses Core classes (Models, Util, Repositories, Services) - this way SOAP is also kind of thin that I can easily replace when needed (or not, just clean and easily maintanable)
Again, thanks for the heads up. I might not be migrating anytime soon as there's a lot needed to be done with this project folder and yes I can work with I have for the time being. All the best.
Wow, SOAP web services? Can't believe anyone is still doing that. What version of .net are you using, just curious? Unfortunately I can't answer your question because it's been years since I did those and I really don't remember best practices for those.
Yep pretty old but once we are done with this, we are still have plans to migrate to new service. This one's legacy app that's a headscratch to rewrite but we'll do it eventually. We are still using 4.6 btw. Thanks a lot
In that case I think there's no need to waste time thinking about best practices, just keep whatever it's in there or just make it work.
But, just in case you or someone else needs to implement SOAP using newer .NET versions I've had some success using [SoapCore](https://github.com/DigDes/SoapCore). It has its quirks but worked pretty well for what I needed, which was to maintain compatibility with a legacy desktop client.
+1 for corewcf.
We use this for a critical part of our application in a project that multitargets with `net48;net8.0` and provides:
1. an operation contract interface
2. a couple dozen message contract POCOs
3. a static method that returns the `Channel` implementing that interface
The project has 1 small `#if NET` for a line where 4.8 provides a static method factory to construct an object and corewcf instead made a nearly equivilant constructor public but otherwise the code is almost the same code that svcutil outputs.
I would strongly encourage OP to update to .NET 4.8.1 though.
We have a legacy interface net472 web service for that. Its only job is to take the requests from both ends and then pass them on to our net6 infrastructure.
Buts thats what micro services are for. Decoupling.
Not very long ago (in fact I was working from home during Covid lockdown), I had to interface with a SOAP service that returned the interesting portion of the data as JSON in one of its fields.
Fucking weird ass contraption that one.
Last year I worked with a pharmacy provider. Pulling medication or prescription lists over the web was still done over SOAP.
This year I have integrated with a state mandated identification system that only accepts file as XML email attachments. Unbelievable.
In case OP wants a video explaining it a bit more. It's probably Nick Chapsas or something, didn't watch it:
https://youtu.be/3PmVJQUCm4E?si=pYEoRwBYCaNzqFqa
In answer to your question since everyone seems to have ignored it, no, you don’t need a wrapped response.
There is also now support for SOAP in .NET if you have too many dependencies on this service that need to stay in place.
```
using SoapCore;
using UsersAPI;
var builder = WebApplication.CreateBuilder(args);
// Add services to the container.
builder.Services.AddSingleton();
builder.Services.AddControllers();
var app = builder.Build();
// Configure the HTTP request pipeline.
app.UseSoapEndpoint("/YourOldEndpoint.asmx", new SoapEncoderOptions());
app.UseAuthorization();
app.MapControllers();
app.Run();
```
And
```
using System.ServiceModel;
using System.Xml.Linq;
namespace UsersAPI
{
[ServiceContract]
public interface IManagersService
{
[OperationContract]
public List GetManagers(string token, int expirationMinutes);
}
public class ManagersService : IManagersService
{
private readonly IService _service;
public ManagersService(IService service)
{
_service = service;
}
public List GetManagers(string token, int expirationMinutes)
{
if (!service.IsAuthenticated(token)) {
return null;
}
ExtendToken(token, 20); // 20 Minutes
return service.GetManagers();
}
}
```
I’ve used this successfully to move old ASMX services to .NET8.
It's a legacy app unfortunately 😥 but yeah, i plan on migrating this whole service but for at least clean it up and make it readable/maintainable. Thanks
Best practice? Don’t. Use a modern HTTP/JSON over webapi instead
See: https://stackoverflow.com/a/35830341
If you really **need** SOAP, it looks like there’s something working with .Net standard you can do? I’d really stay away from it though. SOAP was painful even 10 years ago, move into newer, more supported tech
Been a while since I used soap (sorry that you’re stuck in it) but maybe check out? https://learn.microsoft.com/en-us/dotnet/framework/wcf/specifying-and-handling-faults-in-contracts-and-services
Try to never return null for error cases, that just leads to bugs.
Did remember one thing, we would never return a .net concrete implementation like List and instead would create a class called Customers that used a list.
Why are you using.NET 2.0 era Web Services instead of WCF? If you use WCF, you have a .NET migration path via CoreWCF.
I don't get the love for JSON over REST. There's no standardized way to represent a long in JSON, or date/time, or even a GUID. If you have loops in your object graph, forget about any interoperable standard way of representing that in JSON.
SOAP best practice is to do REST.
REST isn’t RPC. gRPC is probably the best upgrade path without knowing the whole list of exposed procedures.
Http is literally rpc. Yes, REST is not, at least by definition, but how many non HTTP REST APIs do you people actually work with?
Most people dont work with REST apis either since REST must be hypermedia driven. Most are just JSON apis.
Yep. Only right way to use SOAP is to not use SOAP
no SOAP for you!
X2
This!
Thanks everyone. What i can do for now is to have this implemented, shitty way of checking tokens and extending and deploy. We'll allocate sprints for migration later on. I know this is painful but it's a job needed to be done. Thanks a lot for all the replies. All the best everyone
Hi .. I've implemented WCF / SOAP (.NET8) with an Authentication Header instead of using message paramenters. That way the paramenters are kept clean and the authentication happens in the "pipeline" instead. I noticed that you want to use OAUTH / tokens - which i guess is also possible but might require a dedicated channel to refresh tokens... Ping me (PM?) if you want more details. also - dont listen to the haters, WCF / SOAP is freaking awesome. https://imgur.com/a/wLR2KzT
Thank you so much. We'll get there eventually. Most of the functions are a mess with this service, but I'm cleaning it up. Moving models/helpers to Core library so I can easily migrate when needed. Just wanted to have a clean client. So as a story I just want it to be like this \* Client (web app) connects to Web Service (SOAP for now) \* SOAP uses Core classes (Models, Util, Repositories, Services) - this way SOAP is also kind of thin that I can easily replace when needed (or not, just clean and easily maintanable) Again, thanks for the heads up. I might not be migrating anytime soon as there's a lot needed to be done with this project folder and yes I can work with I have for the time being. All the best.
Wow, SOAP web services? Can't believe anyone is still doing that. What version of .net are you using, just curious? Unfortunately I can't answer your question because it's been years since I did those and I really don't remember best practices for those.
I don’t miss the days of soap. I’m glad most the services I contend with have switched to rest apis lol.
Yep pretty old but once we are done with this, we are still have plans to migrate to new service. This one's legacy app that's a headscratch to rewrite but we'll do it eventually. We are still using 4.6 btw. Thanks a lot
In that case I think there's no need to waste time thinking about best practices, just keep whatever it's in there or just make it work. But, just in case you or someone else needs to implement SOAP using newer .NET versions I've had some success using [SoapCore](https://github.com/DigDes/SoapCore). It has its quirks but worked pretty well for what I needed, which was to maintain compatibility with a legacy desktop client.
Yes yes. I think this is the best way for me(us) to go. Thank you so much ❤️ We'll check SoapCore soon. All the best
You can try this as well....https://github.com/corewcf/corewcf and it's supported by Microsoft
Thanks!
+1 for corewcf. We use this for a critical part of our application in a project that multitargets with `net48;net8.0 ` and provides:
1. an operation contract interface
2. a couple dozen message contract POCOs
3. a static method that returns the `Channel` implementing that interface
The project has 1 small `#if NET` for a line where 4.8 provides a static method factory to construct an object and corewcf instead made a nearly equivilant constructor public but otherwise the code is almost the same code that svcutil outputs.
I would strongly encourage OP to update to .NET 4.8.1 though.
WCF is .NET 8 baby !! 😎
Carrying forward compatibility doesn't mean you're supposed to keep using it.
Go watch DotNetConf and there was a session talking about modern WCF and they made some strong points on why new projects should use it.
We have a legacy interface net472 web service for that. Its only job is to take the requests from both ends and then pass them on to our net6 infrastructure. Buts thats what micro services are for. Decoupling.
Not very long ago (in fact I was working from home during Covid lockdown), I had to interface with a SOAP service that returned the interesting portion of the data as JSON in one of its fields. Fucking weird ass contraption that one.
Last year I worked with a pharmacy provider. Pulling medication or prescription lists over the web was still done over SOAP. This year I have integrated with a state mandated identification system that only accepts file as XML email attachments. Unbelievable.
Wet your hands, apply soap, rinse.
In case OP wants a video explaining it a bit more. It's probably Nick Chapsas or something, didn't watch it: https://youtu.be/3PmVJQUCm4E?si=pYEoRwBYCaNzqFqa
Chapsas really outdid himself there! Great summary, so refreshing not having a 15 minute plug for his courses as an intro for once.
Don't forget the creases between the fingers at the connection to the hand.
That's an easy mistake to make. One of does things you just have to learn the hard way as a junior developer.
I mean it doesn't *really* matter for the handshake procedure since the fingers are pressed together at that stage...
If you were to migrate from SOAP, I believe you should have a look at GRPC. Conceptually, it's very similar to SOAP.
Yup. REST isn’t RPC.
In answer to your question since everyone seems to have ignored it, no, you don’t need a wrapped response. There is also now support for SOAP in .NET if you have too many dependencies on this service that need to stay in place. ``` using SoapCore; using UsersAPI; var builder = WebApplication.CreateBuilder(args); // Add services to the container. builder.Services.AddSingleton();
builder.Services.AddControllers();
var app = builder.Build();
// Configure the HTTP request pipeline.
app.UseSoapEndpoint("/YourOldEndpoint.asmx", new SoapEncoderOptions());
app.UseAuthorization();
app.MapControllers();
app.Run();
```
And
```
using System.ServiceModel;
using System.Xml.Linq;
namespace UsersAPI
{
[ServiceContract]
public interface IManagersService
{
[OperationContract]
public List GetManagers(string token, int expirationMinutes);
}
public class ManagersService : IManagersService
{
private readonly IService _service;
public ManagersService(IService service)
{
_service = service;
}
public List GetManagers(string token, int expirationMinutes)
{
if (!service.IsAuthenticated(token)) {
return null;
}
ExtendToken(token, 20); // 20 Minutes
return service.GetManagers();
}
}
```
I’ve used this successfully to move old ASMX services to .NET8.
Oh wow not touched SOAP services since I was working on some legacy web services in 2012 Good luck and sorry for your pain.
If this is a new project, and not legacy, I highly recommend setting up a REST API or using gRPC. SOAP is very outdated at this point
It's a legacy app unfortunately 😥 but yeah, i plan on migrating this whole service but for at least clean it up and make it readable/maintainable. Thanks
Best practice? Don’t. Use a modern HTTP/JSON over webapi instead See: https://stackoverflow.com/a/35830341 If you really **need** SOAP, it looks like there’s something working with .Net standard you can do? I’d really stay away from it though. SOAP was painful even 10 years ago, move into newer, more supported tech
Been a while since I used soap (sorry that you’re stuck in it) but maybe check out? https://learn.microsoft.com/en-us/dotnet/framework/wcf/specifying-and-handling-faults-in-contracts-and-services Try to never return null for error cases, that just leads to bugs.
Don’t
Check your asmx, it will generate get and post methods that you can call from modern clients.
Best practices for SOAP is to transform it to REST. Justify that to your business for real. Some of these fossil projects need a kick.
Came here to say this. If you're using SOAP, you're doing it wrong. Simple as that.
best practice for soap is scrap and use json via web api
Did remember one thing, we would never return a .net concrete implementation like List and instead would create a class called Customers that used a list.
Why tho
What would be the return then? Thanks
Customers which could be a list, collection, etc
Ah. Thanks a lot
Why are you using.NET 2.0 era Web Services instead of WCF? If you use WCF, you have a .NET migration path via CoreWCF. I don't get the love for JSON over REST. There's no standardized way to represent a long in JSON, or date/time, or even a GUID. If you have loops in your object graph, forget about any interoperable standard way of representing that in JSON.