Can I write a web service that implements the same methods and returns the same custom objects using both C#/WCF and also Java Web Services? And if so, can I then access the web services using a single web reference but with different addresses?
I'm asking because I have to host a web service that has a GetCitations and GetTerms method for publically exposing our database content. We are on IIS, so I was going to do it with WCF. However, other partners in the project also have to host an equivalent service and they are all Java based.
We are then building a software app that needs to connect to any number of these services (as defined at runtime by a user). I am expecting that we can have one set of classes to connect to these services (but with different endpoitn addresses), but am not sure whether I'm right in expecting this to work.
Is this possible?
And what considerations/restrictions are there?
Thanks.
It shouldn't be a problem, if you make sure that both services have equivalent wsdl files and you use http/soap binding.
I am not sure about using the binary (net.tcp) one with WCF, though. It might be a problem.
One way to do it is to use JAX-WS (Java 6) to expose a method as a web service.
The JAX-WS stack allows for automatically generating the correct WSDL at runtime.
The .NET team can then take that WSDL, and use standard tools to create a mock implementation of that WSDL. This mock implementation is then used as the actual .NET implementation, and you then use standard tools to generate the WSDL for that web service.
You now have to web services with the same semantics each with their own WSDL.
Both Java and .NET can implement a SOAP compliant web service, so the answer is yes, you can write a .NET and a Java webservice that implement the same WSDL.
Related
I am working on a Visual Studio Application that references a WCF web service, and after some reading online I am pretty confused.
I have read that WCF is a framework for building a web service, but it is not an API. Is this true?
I was under the impression that Web Services are APIs; I always thought that APIs were Software as a Service (SaaS). Doesn't that mean that APIs and Web Services are pretty much the same thing? Or do I have the wrong idea?
Could this be a misconception of my understandings of SOAP and REST?
Basically I want to know whether a WCF built web service counts as an API, and why/why not?
WCF is an API that can be used to create APIS within your application.
Web Services usually involves creating an API within your application. There are valid APIs that are not Web Services, like the Win32 API.
Its possible to build a WCF web service with one web method for an application that would not be considered an API specifically since it does not contain a set of routines, protocols, or tools for building applications.
Review http://en.wikipedia.org/wiki/Application_programming_interface for what an API is.
According to wikipedia, yes, yes it is:
APIs often come in the form of a library that includes specifications
for routines, data structures, object classes, and variables. In other
cases, notably SOAP and REST services, an API is simply a
specification of remote calls exposed to the API consumers.
An API (Application Program Interface) is a way to interact with components of a system. It defines the operations that can be used to get data out or push it in.
WCF (Windows Communication Foundation) itself is a framework for building web services and other applications that need a communication channel to share data with other services/applications, it is actually a lot larger on what it can do. You can read more about it on MSDN. It is an API as it gives you objects that allow you to tell it interact with its' components.
REST and SOAP are just architecture styles that can be used to serve data via a service, it is defining how you should interact with the data rather than the components themselves.
does listing application program interface means listing all the properties in the project ??
Web Service endpoint and API endpoint are more or less the same?
does listing application program interface means listing all the
properties in the project ??
API is a list of software components and their definitions that are shared/opened for any other consumers (other software components, web clients etc.) So for C# API is list of members (classes, methods and their signatures, properties etc) that can be used to cooperate with the system.
Web Service endpoint and API endpoint are more or less the same?
It is not always the same. API is a general term. It is something that allows someone to work with the system. But in context of web services and REST - it is the same.
Generally speaking that service technology has been emerging and the current trend has been Web Services and now REST.
Why you use it ? It is because Let say you have a function can PrintFile() and you want me to use it from my machine, you need a way to tell me how to connect with it. so that means, the function code is with your machine, and my machine can call with some parameters. That is why we need these technologies.
There has been many technologies like DCOM, ASMX , SVC, REST. I have given a comparison below.
COM Limitation: COM should be packaged along with the program. COM is accessible for only specific programming langugage, which means C++ dll is not directly accessible to Java.
DCOM Limitation: A proxy needs to be installed on local machine. Again a compatiblity issue, permission headache.
ASMX Web service that is accessible through HTTP protocal and the client only needs to know how to call through a proxy that uses SOAP as a message protocol.
SVC Client still needs to have a knowledge to interpret SOAP.
Why Web service era is drying… Web service calls require a standard to be followed such as SOAP. Not all devices knows about these standards. This adds a complexity to provide a library at client level that can communicate in SOAP message format and web service can be connected. In case of REST WebApi it uses http. Thus, it has less overhead as compare to previous technology. Now what it means to your coding that your functions are available as is from Mobile to a Desktop. All you need is HTTP to call, which is available even in 20 $ mobile phones.
Thus, you should use WEBAPI technology to provide your function so that I can call your method from my machine.
Hope it helps you.
I am designing an Android application which is supposed to connect to a server via WCF web service.
I have a WCF web service written in .NET 4.5 and it is a self-hosted web service. It has SOAP endpoint configuration and it is not a very complex service, however it does include some methods which return DTOs (Classes containing lists, other DTOs and value types).
Now the problem I am facing is that I wish to use some sort of tools to consume the web service definition and generate the proxy classes. I have been successful doing this with the help of Eclipse, but the resulting generated code uses alot of external libraries not available within Android.
Now my question is, what are the preferred tools/methods to consume WCF SOAP web services?
I found that using the following tool gave me the best generated code.
https://code.google.com/p/android-ws-client/
I do recommend this tool to anyone looking for consuming a WCF SOAP web service.
Here's my situation: I'm writing a SOAP client using WCF. I am going to invite 3rd parties to develop services that my client can consume. This is kind of backwards from the norm, I think. As the client develper, I'm creating the specification, and the server developers are following it.
When it's the other way around, and the server developer is using C#/.NET, the process would go something like:
1) Service developer creates C# interface, a service type that implements it, and a host to serve it.
2) Service developer uses its server to generate WSDL and provides it to client developer.
3) Client developer uses WSDL document to generate a proxy and uses the proxy to consume the service.
However, I'm completely at a loss as to how to do this in reverse. So far, the only thing I've been able to thing of is to do step 1 as a mock, generate the WSDL for my mock, and provide it to the service developer. I'd prefer not to have to go through the work of doing this. Plus, I'm not sure how feasible it is for the service developer to generate a service based on a a WSDL document, especially since the service developers would probably not be using .NET. They could be using any number of SOAP frameworks and languages. I'm afraid that their service implementations would end up differing enough that my client application wouldn't be compatible with all of them at the same time.
I want this to be as easy as possible for the service developers, to encourage them to write them, but I want to have a single client, without having to modify my client code for each server.
I'm not really familiar with SOAP frameworks, other than WCF, so I don't really know how much is the same/different from WCF implementation.
Ideally, I'd like to just provide them with the C# interfaces, or run them through some tool that would generate information that they can use to implement their services in their language/framework of choice, and perfectly implement my specification.
What would be the best way to accomplish this?
My understanding is that a c# based client "prefers" SOAP because when you add a web service reference it creates a proxy class from the wsdl found at the url you specify.
Which almost makes it transparent to the c# client that we are even using a web service, it almost feels like we are using a local class library. you call methods and you use objects.
My question is can REST achieve the same affect. I assume that it can't since it doesn't have wsdl and thus visual studio can't generate a proxy class for it. But Please correct me if I'm wrong?
A "run of the mill" REST service cannot achieve the same kind of tight integration with C# - mostly because it lacks the metadata that a SOAP service will provide (with a list of methods and their parameters and all that stuff).
The WCF Data Services (built on top of REST) do work much the same way as SOAP services, since the OData protocol contains extensions for pure REST services that provide metadata information needed to create a good, useful client-side proxy.
REST can be used to generate client side class libraries. For Example You can create proxy classes for MS generated REST services. In fact MS is actively pushing this model for Entity Framework based WCF DATA Services, e.g. those used by Silverlight and RIA applications. check out MS ODATA framework for REST which involves creating client objects out of standard REST queries.
http://msdn.microsoft.com/en-us/library/dd673930.aspx