I am trying to access a webservice from my server using this tutorial consume web services.. i have been successful in accessing the web service and retrieving a string from it. but in most of the tutorials i have come across we need to give the method names in the web service thru the SOAP actions.. Is there any way in which we can even retrieve the methods that are present in the web service first within our application and then access it using those methods,, so the web service will be more flexible then and we can add more methods later??
You can use WSDL from service and generate proxy. WSDL contains service methods list. Check this
The first thing that springs to mind is to hit the WSDL definition, and search through it for the messages and data types you want.
I am developing a wcf service (basicHttpBinding) that should also be consumed by non .net clients (e.g. Java clients). But now I wonder how the client can define his client config file. Or is this file only needed for .net-clients? (I am thinking of configurations like maxReceivedMessageSize or maxItemsInObjectGraph for example).
Each development platform (call it as you want: SOAP stack, Framework, API) has its own way to configure communication. You don't need to bother with it. You just need to expose correct WSDL and client's developer will be responsible for configuring the client application based on his needs.
If you want to extend documentation of your service in WSDL you can use wsdl:documentation. WCF doesn't offer it by default but you can use this technology sample to extend WCF. You can use such documentation for example to describe that service operation can return large amount of data. Another approach to add wsdl:documentation is using WCF Extras.
From the sound of it, the client shouldn't have access to those configuration options. For instance, why should a client to the WCF service be able to specify the maxReceivedMessageSize?
What you probably want to do is define these configuration options on the server-side. If a client makes a call and there is a conflict with one of your options (i.e. the client exceeds maxReceivedMessageSize), you'll want to throw a SoapException back to the client.
If you want to let the client have access to the configuration settings before he or she sends a request, you can always implement a simple web service method that sends back the values.
I've been playing around with WCF and I have managed to a WCF service to generate both SOAP, POX, and JSON formats pretty easily based on this example (I added the soap config).
http://www.c-sharpcorner.com/UploadFile/ashutosh.shukla1/3040/Default.aspx
And I see that if you add a timestamp field to your data base tables you can actually have a plain old WCF service work with Linq to SQL via this-
http://jonkruger.com/blog/2008/02/10/linq-to-sql-in-disconnectedn-tier-scenarios-saving-an-object/
I'm still a little confused about WCF vs WCF Data Services vs WCF Ria Services. I guess my goal and my question is.
Is it possible to write one service with multiple endpoints that does it all...POX, JSON, Java client compatible SOAP 1.1 with https and user name/password protection, and OData secured with https possibly as well? If so that sounds amazing, as I can create a self hosted uber data provider service that offers numerous ways clients can connect and use data.
Are we there yet? If so what do I use (still confused on the differences)?
I have a web service that is used by many different clients using many different languages.
I want to switch it to wcf to take advantage of the many different endpoints.
However what has been stopping me is that I am afraid that the clients will have to use a special sdk to connect (if they are using java or php or some other language) that is different then the sdk they use to connect to the existing web service.
Is this true? Or is connecting to WCF the exact same as it is for web services in other languages.
The project I am currently working on has multiple WCF configurations, some are using the default SOAP implementation, and some are using a POX (plain-old-xml) style message.
So the short answer is 'yes' you can configure WCF in such a way to work with just about anything.
However, be warned that as soon as you step outside the default little box that WCF has set up for you, it gets pretty complicated. You end up with a lot of custom message parsing and security handling if you go to a POX message format. Its easier if you stick with SOAP though.
As for needing a 'special SDK' you won't. You can communicate with WCF with simple HTTP POST messages if needed.
I have clients that are using VB.NET apps (using SOAP) and Java apps (using POX) to hit my WCF services.
A basicHttpBinding endpoint in WCF is exactly a standard SOAP endpoint, and your Java or PHP clients will not have to change in any way.
I have a Windows Service which performs a certain function, and then needs to send that information off to a webservice for processing. The webservice is hosted by a remote web application. I am trying to ascertain the best way to call the webservice(s) as each web application might be only 2.0, or 3.5 etc. In my windows service, I am defining each "client" in the app.config, e.g.
<Client WebServiceUrl="http://location.com/webservice.svc" Username="" Password="">
</Client>
The web application must implement two web services that are required for my windows service to run, however not sure the best way to implement the "rules" for the web application.
EDIT:
I'll try and rephrase..
The Windows Service runs every 30 seconds and obtains a list of information. The service supports multiple "clients" as shown above. When each client process is run, the data is collected and is then needed to be sent to the supporting web application.
The windows service does not know what to do with the data, it is just sending it. Each web application for a client would be in different locations, and could possibly be built in 2.0, 3.5, PHP, etc. All the windows service cares about, is that when it performs its processing for a client, it is able to send the data to the webservice location defined in the app.config of the windows service.
What I'm trying to determine is how to connect to the webservice (which I'm leaning towards WCF, however Basic or WS not sure), and what rules need to be defined for the web application in how to build the response.
If the Windows service is to support php applications etc, WSHttpBinding would not be an option, which would mean BasicHttpBinding would then work. The other thing to decide is whether or not to utilise a RESTful service or SOAP service.
Hope this makes more sense.
I'm not really clear on what you are doing.
It seems like you have 3 things: A Windows Service, and then a web service, hosted in a web app.
I think your question is, what to use, REST, ASMX, WSE or WCF, when interconnecting the Windows Service app with the remote web service.
ASMX, WSE and WCF are alternative programming models for the web service. REST is not a programming model. It is not like the other three.
ASMX and WSE will require that you use Web services and SOAP.
WCF can allow you to use Web services and SOAP, REST (XML or JSON) over HTTP, or a binary format over TCP, among other options.
Because it is flexible and current technology, I'd recommend WCF. ASMX is now termed "legacy technology" by Microsoft. Doesn't mean it won't work, but it will not get updates. (Much like WinForms versus WPF). WSE is no longer in mainstream support, as far as I know. For these reasons, I wouldn't recommend starting a new project on WSE, nor on ASMX.
WCF is more general than ASMX and can seem more complicated, for that reason. But once you make some choices and zero in on what you want (for example choose HTTP and REST, or choose binary and TCP), it's more powerful. WCF can be used as the programming model on both the client or sender (in your case, the Windows Service, I guess) and/or on the server (the web service hosted in the web app).
Using WCF on the client side does not imply you must use it on the server side, and vice versa. On the other hand, if you control the source code on both ends, I would recommend using WCF on both sides.
As for "how to implement the rules for the web app" - I don't understand what you are asking there. Maybe if you are more specific on the question there, someone will be able to help out.
Update: Based on your additional explanation, I'm going to suggest you look at the REST stuff in WCF for .NET 3.5. In PHP it's very easy to implement a REST-style service, and with WCF, the same is true for .NET. Now in your case the Windows service is the client and it is sending out a request, an update request, to various servers that reside on your customers' networks. According to REST principles, I'd make those outbound requests PUTs or POSTs, depending on the semantics of the call.
Then you could ship some example service code to your (uppercase) Clients, to get them started on building what they need to receive your outbound PUT/POST messages.
Security is a concern though. You didn't mention it at all, which is surprising. Security is not one of those things best deferred, so that you "add it on later". You should think about it early - it may affect the protocol choices you make. For example, if you need to mutually authenticate the clients and servers (the latter at your "uppercase" Clients' networks), then you may want to go with SOAP, which gives you good options on the protocol side for security. Secure Web services extensions (WS-Sec, etc) are well supported in WCF, but not sure about the status of this capability in PHP.