I'm working on .NET, I want to write an interface on web service for my clients(multi client) so they can inherit from my interface to make their own web service, and I can call their web service dynamically.
Is there any way to make it?
Thanks.
Edit:
Because I'm new on web service. I will make it more clear.
I want all my customer's web sevice have same method.
I have several cuatomers. I want to have some object or interface from my web site so they can inherit from it.
I can store their web service's URL to database, and I can call their service dynamically.
So, how to do it?
It is very simple, you don't need to do anything in terms of inheritance really, that's the basic premise of web services.
Just create a dummy web service of your own (You can use this one for testing as well to return test values) and give URL to your customers.
They can all get the specs (basically they just need to add "?WSDL" at the end of your test web service) and get WSDL which they should implement into their own web service.
If that test web service is internal to your network you can simply get WSDL yourself and email it to them.
Once they all implement this web service, you can just connect to theirs and it will behave exactly the same.
Related
Description:
I have an client app consuming a WCF service, both runing on .NET Core and hosted as web apps in Azure.
The client has access to an interface that the service implements as its DataContract.
Currently I consume the service via creating a ChannelFactory based on an DataContract of the WCF service.
Because lots of reasons I'd like to move away from WCF.
My first idea was to convert the WCF service to a Web API and implement something like OpenAPI (Swagger) and from there consume the API via generated docs.
However I can't really find anything similar to the way you would consume a WCF contract and then be able to call upon its methods.
Question:
Is it possible o use a shared interface between the consumer and a Web API in a way that enables me to call upon the methods (routes) in that interface? Be it using OpenAPI (Swagger) or any other framework/lib/or otherwise.
Please let me know if anything is unclear and I'll add info, I'm aware its a somewhat broad question.
I have code that calls a web service. We'll say a "3rd party" web service. So I can get the wsdl for this service, in fact I've generated a proxy class using this wsdl.
The requirement that I'm trying to meet is this: Create a web service that LOOKS just like the above mentioned one, but does other stuff. So the web service URL will be changed in a config file/database, to allow switching between the two web services.
What I'm not sure about is how I can use that proxy class that I generated, or some other method, so that the namespacing and data contract look exactly the same. I don't know much about this and these are terms that colleagues have tossed out there. I only need to actually implement one of the web service's methods in my version.
Build site with any technology you know of and return responses that match that service.
Note that if you just need to return static enough responses for occasional testing you can use Fiddler as it allows to return arbitrary responses instead of real once.
I have a sharepoint web service running at specified host + "/_vti_bin/UserProfileWebService.asmx". I would like to instantiate a web service client, so that i could interact with this service. This is basically what I am trying to do: http://msdn.microsoft.com/en-us/library/ms550407.aspx.
How is this done in .NET? And do I have to use the MOSS API to know what functions it supports?
EDIT:
I guess I should add that I want to connect programmatically, not through a web reference, because that seems to be static.
In VS (2008/2010) you can add a web service reference to your console project for example. It will auto-generate the proxy classes for you to use in your code.
I am trying to create a sort of "bootstrap" web service using a classic .net C# .asmx page and not WCF. (The business requirements for this project are specific and do not want a WCF service).
Basically, I am trying to do this:
Create a new web service (I have no problem doing this)
That service needs to make a SOAP based call to a Sharepoint Web Service
I need to consume that service
I need to add additional pieces of information for my web service to the SOAP result (No problem here either)
The issue I have having is with point #2 and #3. I have found plenty of articles using WCF to consume SOAP based Web Services or using "Linq" to connect to sharepoint etc., but that's not what I'm looking for.
What I am looking for is simply a step by step process of what I need to do to push me in the right direction.
Example:
add a web service reference??
add this line(s) of code to create a new SOAP request??
add this line(s) of code to parse and consume the service??
Thank you very much in advance!!!
Sample code would be greatly appreciated as well!
There's nothing magical about the fact that it's a web service. Just use "Add Service Reference" and then treat it like any other piece of code referencing a web service.
Also, are those who wrote the requirements aware that a WCF service can expose a basicHttpBinding endpoint that looks exactly like an ASMX web service endpoint? It would also have the benefit of all of the features of WCF, in addition to not using what Microsoft considers a "legacy technology".
The SharePoint Developer Center at MSDN would be a good place to refer to for general information, tutorials, etc. Server and Site Architecture: Object Model Overview in the Windows SharePoint Services 3 SDK would be a good place to start learning about the SharePoint object model, as the terms (SPSite, SPWeb, etc.) that you'll come across in examples can be confusing.
Basically you will want to add your web reference to the SharePoint web service that you intend to use. The specific reference that you use will depend on what you're trying to accomplish, there's a whole list of available Windows SharePoint Services Web Services. Those are for general SharePoint tasks such as interacting with lists and sites; there's also a whole separate set of web services for SharePoint Server which is what you would use for interacting with the Business Data Catalog, Enterprise Search, and any of the other features that come with SharePoint Server, not Windows SharePoint Services.
When you add the web reference in visual studio, it will automatically generate the proxy in your project against the remote web service and you use the generated proxy to do what you want to do. However, working directly against the web services, pretty much everything will return a generic XmlNode that you'll have to deal with, so if you're working in .NET, a much better alternative to using the web services directly would be to download the SharePoint SDK and program against the server object model.
If you do end up using the object model, make sure you read both of these thoroughly:
Best Practices: Common Coding Issues When Using the SharePoint Object Model
Best Practices: Using Disposable Windows SharePoint Services Objects
Here is small tutorial on what you're trying to do:
http://www.xefteri.com/articles/show.cfm?id=15
I have ASMX services for my web application that I would only like available to the same application.
Is there a way for the web service to only be accessible by the same application, such as relative/absolute path restrictions?
The easiest route would be to just not use a web service. If you're calling from the same application, you can probably just pull your logic into a separate class, and call it directly in your code, not via web service.
Two ways to do this:
Have the web services hosted on a different box. The main web box is on a publicly accessible IP (ie. in the DMZ), while the web service box is only accessible to the internal network.
You might be able to do this with sufficient networking gymnastics. For example, host the web services on the same box but a different IP, and have the firewall block any outside calls to that IP.
Web services can be called by all sorts of code, not just code that's part of a web site. So, in general, there is no "calling URL".