Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
I am working on a project where I need to make a call from .NET platform to non .NET Web service. I am making web service call using some methods where I can generate SOAP request to access web service. I made this communication using code given in code-projet site.http://www.codeproject.com/Articles/376168/Csharp-Dynamic-Web-Service-Invoker. I am able to communicate properly but I would like to make this communication more secure. Only reason to make web service dynamic is because it may reside on different locations.
My approach is to add secure token (some string) in a newly created header and add that header in outgoing SOAP request. And at receiving end (non .net platform), I will extract that value from header and verify against some algorithm and if things go fine, then only it will start rest of processes.
After researching couple of sites, I found that all the answers are for adding custom SOAP headers are pointing to direction where we use either WCF or Static web services. But here that is not the case. I just wrote simple plugin(Class) that makes this communication. I am calling web service after generating assembly reference after reading WSDL file from remote location.
I researched around 20-30 different forums to get answer to this question but none has the answer. Can someone help on this?
Only reason to make web service dynamic is because it may reside on different locations.
You can set a WCF client's endpoint at runtime. When the services implement the same contract this'll work fine with native .NET instead of some (non-compiling or at least incomplete) code from the web, which is good because you're very unlikely to find support for the latter.
Let's take a look at your actual problem:
I would like to make this communication more secure
Then start at the service side. What framework is the service written in, does it support security in any way? It really depends on how you want to authenticate the caller, but "add secure token (some string) [...] and verify against some algorithm" does sound a little bit like reinventing the wheel.
WCF can work with almost any, if not every kind of SOAP and HTTP security, so configure your service, use a regular, configurable WCF client and set the endpoint to the right address at runtime.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I want to use microservices architecture for my next project based on ASP.NET core.
I could exchange between the services via REST but it is really heavy to maintain.
Is there an other way for communication between microservices, for example over event bus like vertx.
I could use rabbitmq, but do not know, if it is a good option.
I think Rabbit MQ is going to work OK, especially if you have many consumers i.e. need load balancing, and/or if you need messages to be persistent, and also if conceptually, your micro-services are OK processing messages.
Otherwise, since you’re considering REST, I’d recommend WCF instead.
Just ignore Microsoft’s examples, those are too complex. You need to make an assembly containing protocols (in WCF terminology, service contracts) + messages they send/receive (in WCF terminology, data contracts) that’ll be shared between your services. Having a shared assembly will allow you to get rid of that enterprise-style XML configuration nonsense. This will also make maintenance simpler than REST, because the compiler is going to verify the correctness of your network calls: you forget to update one service after changing a protocol, and the service will stop compiling.
Here’s my demo which uses WCF to implement zero-configuration client-server communications in C#.
It’s currently set up to use named pipe binding i.e. will only work locally. But it’s easy to switch from NetNamedPipeBinding to NetTcpBinding which will do networking just fine.
P.S. If you’ll pick WCF, don’t forget the abstraction can and will leak. Any network call may fail with any network-related exception. Also you’ll need to reconnect sometimes (if you don’t want to, and your don’t have too many messages per second, you can use a connection-less protocol like NetHttpBinding but those are much less performant).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
After wasting over a month looking and reading about .Net Protections, I have convinced that there is no way to 100% protect .Net from decompiling ,even if there it won't last a lot.
However i though about rebuilding my app remotely to a server built in c# too.
My questions is:
1-is it possible to send methods to my app to be used there? (That shouldn't be a full method transfer).
2-Best practice for socket multi-threading to handle data from each client on my server.
Generally speaking, if you want to keep your compiled C# code from being decompiled, don't make the compiled bytecode available to anyone. You seem to sense that this will require a client-server system, and that's correct. You also want a "thin client," meaning that the client shouldn't contain any of your application's business logic but rely on the server for everything but user input and presentation of data. You could do this with a custom C# client or something written in HTML and JavaScript that would run within a web browser. (If you go with a web application, make sure you don't include any business logic in your JavaScript, because that will be sent to the browser in plain text.)
As for the idea of sending executable bytecode to the client from the server, that seems less secure than a web app. Even if you encrypt communication between the client and server, the client will still end up with executable bytecode that could be decompiled on the client side.
Before you start implementing the communications protocol yourself, do take a look at WCF. If both your client and server are .NET based, WCF is the easiest way to go.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Hi I'm developing a wcf web service that integrates with OneDrive and I need to access to the files (list, delete, download and upload) of the users that use my web service.
Is there a way to use Onedrive in an easy way? maybe some C# API...
I found the Live SDK but I can't understand how to use it, then there is SkyNet but I don't know how to use it and if it works with OneDrive.
In case I would have to use REST calls, can you explain how to authenticate and list file with REST?
thank you all
The main challenge you'll have with writing a WCF service is doing authentication. I'm not aware of a straightforward way to proxy authentication with your WCF service into the OneDrive service. The easiest approach would be to have the caller of the WCF service handle generating the auth token (see the examples for how to generate an auth token in the OAuth reference) and pass it to your service as one of the call parameters.
After that, you can use the Live SDK to make server-side calls using the token provided to your service from the caller as a parameter to your WCF method. You can either use the Live SDK to generate those calls, or you can make them yourself following the REST reference. Neither give you an object model that you can interact with, you'll need to understand how the REST service works and the structure of the returned JSON data to use the Live SDK.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm going to be working on a project that involves a number of elements:
ASP.NET MVC website
C# console application
iPhone App
To get all these separate applications talking to the database, my immediate thought was to use a WCF Service.
However, I now need to add an API to the site to allow third parties to select, insert and update records from their own applications.
In my mind, I would just create a separate RESTful service endpoint on my WCF Service which would be locked down using authentication and would only give access to certain methods.
However, I've been reading today about the Web API feature in MVC 4 which is meant to be the latest thing for RESTful APIs?
Should I be going along the line of using the Web API? or because my other applications need a web service, should I stick with a WCF Service?
If you intend to do RESTful development then you will definitely want to use the ASP.Net Web Api (which was originally called WCF Web Api and created with the goal of "Making REST a first class citizen in .NET".
Another thing to consider is that the WCF REST Starter kit is no longer supported.
Note that using Web Api doesn't mean you have to use ASP.Net MVC or IIS even as it can be self hosted.
For handling operations which are non-CRUD in nature I'd recommend Googling "REST non-CRUD". I found this blog post RESTful URLs for non-CRUD operations (and particularly the comments interesting). If you decide you NEED to have RPC calls then those may have to be done with WCF. That said since WCF REST is being killed off I'm not sure what the best solution is going to be. Having both is probably the best answer but at the same time it's not necessarily a good answer.
Another alternative would be a WCF OData Service but I'm not sure if that gets any support from an iPhone.
One last point to make (that can be deleted in the future as this is time sensitive)
Microsoft has provided a Go Live license with the beta which means that it is supported by Microsoft and you shouldn't have any problems upgrading to the file RTM.
Service Stack also looks like an option.
Demos, overview, examples is available here.
There's no right answer here. You can certainly do fairly well with a WCF RESTful service. Or you could use ASP.NET MVC. Both are perfectly valid, and both have strengths and weaknesses.
Ultimately, I'd suggest you go with whatever feels the most maintainable to you.
I would like to note that MVC 4 is in beta, so watch out for bugs and don't go live until it's out of beta.
Since you are going to create an ASP.NET MVC web site, it would be quite comfortable to use ASP.NET Web API also because programming model is very similar and those solutions are more or less integrated with each other.
I would be inlclined to look at what has the best support on all platforms that you are going to use, I suspect the iPhone app may end up driving your choices.
If it was pure .net I would still tend to lean toweards a SOAP service - it is not considered cool these days but it generally will do what you need on most platforms without having to roll custom solutions.
EDIT
ASP.NET Web API means that .NET now provides a great framework for developing a restful API, I revise my answer to say that I would now lean towards this - progress is great!
I have the same question.
In the MSDN site,
http://msdn.microsoft.com/en-us/library/jj823172(v=vs.110).aspx
Found a video tutorial where they said that for machine cosumption like iPhone or web app clients of JSON or xml, web API is recommended option. Its around the last part of the video.
While for more complex machine to machine communication WCF is prefereable.
http://channel9.msdn.com/Series/Building-Web-Apps-with-ASP-NET-Jump-Start/Building-Web-Apps-with-ASPNET-Jump-Start-04-Building-a-Service-Layer-with-ASPNET-Web-API
Here is a screenshot from their presentation.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Are they just the same protocol or something different?
I am just confused about it.
Actually, I want to call a web service written in C# with ASP.NET by Python. I have tried XMLRPC but it seems just did not work.
So what is the actually difference among them?
Thanks.
All of them use the same transport protocol (HTTP).
XMLRPC formats a traditional RPC call with XML for remote execution.
SOAP wraps the call in a SOAP envelope (still XML, different formatting, oriented towards message based services rather than RPC style calls).
If you're using C#, your best bet is probably SOAP based Web Services (at least out of the options you listed).
In order to call web service written in C#, you will need SOAP library that is able to consume WSDL (check it out in addition to all the useful terms mentioned here). Couple of the libraries i came across:
suds is a lightweight SOAP python client.
ZSI is more powerful library that also has WSDL consumption of complex types.
SOAPpy was good library. Unfortunately it was not updated since 2005-02-22, so i provided it here only for reference.
Python Web services page has more information and links on different related libraries.
They are completely different protocols, you need to find out the protocol used by the web service you wish to consume and program to that. Web services is really just a concept XML-RPC, SOAP and REST are actual technologies the implement this concept. These implementations are not interoperable (without some translation layer).
All these protocols enable basically the same sort of thing, calling into remote some application over the web. However the details of how they do this differ, they are not just different names for the same protocol.
xml-rpc: Its a mechanism to call remote procedure & function accross network for distributed system integration. It uses XML based message document and HTTP as transport protocol. Further, it only support 6 basic data type as well as array for communication.
SOAP: SOAP is also XML-based protocol for information exchange using HTPP transport protocol. However, it is more advanced then XML-RPC protocol. It uses XML formatted message that helps communicating complex data types accross distributed application, and hence is widely used now a days.