when i create a web service using eclipse 3 types of bindings appear : SOAP12BINDING,HTTPBINDING and SOAP11BINDING what do they refer to ??? am a newbie in Web services
They refer to three different ways of connecting to your web service, SOAP 1.1, SOAP 1.2 and XML over HTTP.
Clients will be able to connect to your service using any of these three protocols, and the server component will form responses with the appropriate protocol.
As far as your server component coding goes, it probably won't make a difference to you which protocol clients choose to use.
Related
So right now our company has custom SOAP web services that hold functions to do things (e.g. sending emails, getting employee info, etc.) and are connected via Service References.
We want to make the switch to Web API 2, but I'm kind of lost on how we can (or if it's possible) to do that since all of our services interact with SOAP.
I wanted to create brand new Web APIs for each service we have which would hold the methods, but I'm not sure where to start. I've scoured the internet, but I haven't really found anything that answers my question.
Can someone shed some light on this for me? Thanks
well, you can create the Web API Service, and exposes the functions that you need, maybe, this service can be accessed from anywhere, but, the real functionality is on the soap (that can be in a DMZ for example), so, create a class library that consume those services and Web API now use this class library, so Web API will be only a facade.
But, first think, is really necessary have this facade in web api to consume those services?
Remember that if your soap services are built with WCF, WCF has support for HTTP protocol.
I want to implement REST service in gwt .But I don't know how to go about it. I read some documents where they have implemented it using RestyGwt and jercy. But I have one app which is deployed on tomcat. Then situation is that my client side app is calling the methods on the application present on tomcat.
I have to implement it using REST so that my client side call will first go to Proxy service on client then it make REST call to the application on tomcat and fetch result and return. How can I do this in gwt. ?
As mentioned, you can only communicate with REST service.
Anyway, maybe take a look on dispatch concept in GWTPlatform and their way of implementing it. (https://github.com/ArcBees/GWTP/wiki/Rest-Dispatch).
Idea is easy, you have an action on client side which is registered to deal with rest url. You can define action interface with some additional annotations to tell what is excepected to be send and received. They are using piriti library for json serialization.
It is up to you if you need only client side implementation or you would like to use server side service creation too.
You can NOT implement a REST service in gwt, since gwt is thought as a client-side solution.
What the GWT kit provides for server side are a few utilities to facilitate the comunication between client-side and server-side when both are written in java (RPC, RF).
So you can consume a REST service from gwt (RequestBuilder, gwtquery-ajax, etc), but if you want to provide REST services you need a 3party solution for your server side like Jersey, CXF, etc.
There are, though, 3party solutions which provides the server side and client simultaneously like restygwt, errai-jax, etc.
If you are looking for a simple and reliable solution to query rest services from the client, in this question you have a client implementation done with gwtquery (ajax, databinding, promises)
In my project I am using a wsdl provided by TIBCO to generate web service client classes. These clients are responsible to to consume TIBCO web services over SOAP/JMS.
I see that the designer has made a comment in design doc like this:
TIBCO jms bindings are proprietary, so standard tools liek JAX-WS , JAX-RPC cannot be used to generate clients. Hence Spring Web Services will be used to generate the clients.
What does this mean? The designed is no logner with the team. I have no way of asking him
Standard SOAP binding to JMS defines a set of JMS properties that can be then used by the toolkits like JAX-WS or JAX-RPC to send the SOAP over JMS. E.g. SOAPJMS_requestURI, SOAPJMS_soapAction, SOAPJMS_contentType, etc.
The developer has probably not followed all the requirements stated in the standard and e.g. already existing endpoint that produces the SOAP requests might not set all the required JMS properties when sending a JMS message, or it might require different set of JMS properties to be set for messages that it consumes.
Spring-WS is probably more flexible when it comes to such customizations and not so picky when processing received messages thus it was recommended by the developer.
At the time the TIBCO code was written, there was no standard for SOAP over JMS (A W3 recommendation for SOAP over JMS was released just over a year ago) and all SOAP over JMS bindings were proprietary.
All this really means is that some tools will not understand the bindings and you will need to configure them yourself manually. Other tools will understand the bindings and will automatically configure the bindings in the client. Try it with different frameworks and see how you go.
I am using Jersey/Tomcat6 for dveloping some web services. Compared to what I did for SOAP services, I am not getting the idea what should I share to my clients once the services are developed...just the URL of the web service ?? For SOAP, the WSDL file was enough, as the clients self-generated the stubs.
My service returns a list of User objects (with 2 Strings) in JSON format. How would my clients de-serialize the JSON if I share just the service URL with them ? Do I need to share the entity bean (The User class, and the list class) on my server side too ?
I have been reading about some WADL files for REST...are they helpful here ?
Thanks for any help !
It sounds like you probably want to put together an example client to give to your, er, clients to show them how to use the REST service. Ideally, of course, your REST service would fully support HATEOAS (Hypermedia As The Engine Of Application State), and so the means of traversing the resources to get the desired results would be discoverable; I've found that real HATEOAS implementation is rare, though. For a RESTful-ish service (one that doesn't fully support HATEOAS), example clients are useful. You can usually implement your example client in HTML with some Javascript; this makes everything very accessible for most REST client users.
I want to use a WCF service and consume it using all the mobile platforms iPhone, android, Blackbery, Nokia etc'
Whats my best strategy for using those clients with a WCF service. it will have to be secured of course.
Thanks
amit
I disagree with SOAP and JSON. Use RESTfull service with POX (plain old xml). It will be most probably supported by all platform. Mobile phones can have limited SOAP stack implementations and JSON is usually used with browsers. My friend has BlackBerry and he continuously complains about its support for JavaScript.
To secure your service use HTTPS.
Use a SOAP or JSON endpoint. Most platforms will have support for these (or it'll be easy to find libraries). JSON is more web oriented (Javascript) but will work in other situations as well.
Mono supports WCF so maybe their iPhone and Android will support it as well.
Totally agree with #Ladislav on not expecting clients to be able to consume SOAP. Seems like SOAP stacks are lacking unless your client is native .NET or Java. Your clients will thank you by allowing them to choose JSON (web clients) or XML (system integration). Secure via HTTPS and basic auth or an API key.
If you already have an existing infrastructure of WCF services that you want to aggregate, or adapt, for downlevel clients you could put that POX (or 'REST') service in front of them and let it handle mapping protocols and formats for you. e.g. HTTP/S to TCP/IP and XML or JSON to SOAP.
The upside is that you will make it easier for downlevel clients to consume your services. The downside is that you've added an extra layer, which will cause complexity. Some tools, like WCF Routing Service (free) or Apigee (commercial), coupled with a solid automated deployment proces can help mitigate this complexity.
To build a REST service that supports XML or JSON, create your service with this template, it's designed for .NET 4.0. From there you can configure endpoints that respond in XML or JSON and let your client tell the service what response type it wants.
EDIT You can also have the service respond in a default format to reduce every client having to specify what format.
<standardEndpoints>
<webHttpEndpoint>
<standardEndpoint name="" defaultOutgoingResponseFormat="Json"/>
</webHttpEndpoint>
</standardEndpoints>