I am just getting started with SOAP web services and stumbled across WSHttpBinding and BasicHttpBinding.
I'd like to know 2 things based on following use case:
Suppose, there is web service which accepts country name as request and returns state list as response.
What are the pro's and con's of WSHttpBinding or BasicHttpBinding on the basis of my simple use case above?
Citing WCF Soap Rest WSHTTPBinding
Between basicHttpBinding and wsHttpBinding, there differences are as follows:
basicHttpBinding is the very basic binding - SOAP 1.1, not much in terms of security, not much else in terms of features - but compatible to just about any SOAP client out there --> great for interoperability, weak on features and security
wsHttpBinding is the full-blown binding, which supports a ton of WS-* features and standards - it has lots more security features, you can use sessionful connections, you can use reliable messaging, you can use transactional control - just a lot more stuff, but wsHttpBinding is also a lot *heavier" and adds a lot of overhead to your messages as they travel across the network
Put simply WsHttpBinding supports the WS-* specification. The WS-* specifications are standards extending web service capabilities. ANother big difference is that Basic sends data in plain text by default wherein WS supports security and encryption.
As to your use case, if you are a very security conscious individual and coder as we all should strive to be and your country and states web services should be secured - it may be a good idea to use WSHTTPBinding but IMHO that will lock you into WCF and .Net. If you do want to go that route and utilize WS and WCF, this SO article explains how to modify the binding settings for interop wshttpbinding is only for .net clients?
Related
Right now I'm working in WebApi (trainee developer), and have good knowledge in webapi . But , I don't know anything about WebServices.
My Questions are :
1.What is WebServices?
2.What is the Use of WebServices?
3.Instead of WebServices why we are using WebApi.
4.Where we can use WebServices?
5.At a time We Can use both Webservices and WebApis?
Exposing the Existing Function on the network
A web service is a unit of managed code that can be remotely invoked using HTTP. That is, it can be activated using HTTP requests. Web services allow you to expose the functionality of your existing code over the network. Once it is exposed on the network, other applications can use the functionality of your program.
Interoperability
Web services allow various applications to talk to each other and share data and services among themselves. Other applications can also use the web services. For example, a VB or .NET application can talk to Java web services and vice versa. Web services are used to make the application platform and technology independent.
Standardized Protocol
Web services use standardized industry standard protocol for the communication. All the four layers (Service Transport, XML Messaging, Service Description, and Service Discovery layers) use well-defined protocols in the web services protocol stack. This standardization of protocol stack gives the business many advantages such as a wide range of choices, reduction in the cost due to competition, and increase in the quality.
Low Cost Communication
Web services use SOAP over HTTP protocol, so you can use your existing low-cost internet for implementing web services. This solution is much less costly compared to proprietary solutions like EDI/B2B. Besides SOAP over HTTP, web services can also be implemented on other reliable transport mechanisms like FTP
For Example in Asp.Net Core : https://dzone.com/articles/step-by-step-aspnet-core-restful-web-service-devel
We are using SOAP based web services to let end user schedule service appointments. Our portal is WebService client & we have a number of Vendors(who are spread across the globe in various timezones) who are building Webservice Server operations.
We are thinking to build it as a contract first SOAP based web services so that we have tight control(interface based e.g. date-time format should be standard xsd:dateTime etc.) over what can be sent & received as part of XML messages for possible success & error scenarios(via different error codes). We want to keep single client code for all the vendors. We would like to determine
1) Should we think about using RESTful web services?
2) Is there any way the vendors can use RESTful services also if they want at their end(by sticking to our WSDL contract) & we use SOAP at our end
First a little bit about,
REST (Representation State Transfer) is an architecture style to develop webservice. In which data and functionality are considered as a resource and can be accessed via URI (Uniform Resource Indicator). It follows client server architecture and uses stateless protocol (usually HTTP). Typically in REST webserivces resources are acted upon by GET, PUT, POST,DELETE operation. Generally we use JSON to exchange data between client and server. It is light weight.
On the other hand SOAP (Simple Object Access Protocol) is a XML based mesaage protocol. Which is generally used on enterprise level to define their own interfacing and operations as services. It also follows REST architecture.
So basically, it is a RESTful webservice.
Now to answer your question,
It seems you are going to expose your webservice client on enterprise level. Which is going to be used by many vendors to implement their own webservice server.
So, it is perfect, you go with SOAP webservices.
You will define the skeleton of the webservice like Message formats, Operations, binding etc which is called WSDL. It is widely used standard and very easy to understand by any third party. Something called WADL is used for REST services also but it is not very user friendly.
The same contract (WSDL) will be used by your vendors to implement the webservice on their server in Top to Bottom approach using some API, for example JAX-WS.
This way you will have a tighter control over your operations, formats, security etc. in a single contract (WSDL).
Now if a vendor wants to use REST webservice instead of SOAP. You can build a JAVA proxy on top of your client. Which will convert your soap messages into REST to send/receive request/response to REST webservices. But you can not dictate your contract in this approach. Although, You can recommend vendors to build their own proxy to handle your SOAP webservice requests. This way your contract will be intact.
If you are going to expose your webservice client for small applications then it is alright to go with REST but if you are an enterprise and going to expand in future, you should go with SOAP for robust features and easy maintenance.
Disclaimer: please do not consider this answer as really serious.
Well, I think question too abstract. Why do you asking it? Because you see yourself that currently everything is RESTful? Then you'r right. You can do any protocol. But if you will do REST with JSON instead of XML, everybody will thank you. And if you will use 40 years old technology for creating modern service, then probably not. Same for your contractors.
The only advantage SOAP seems to have in your situation is that it is already implemented.
SOAP is a complex standard with unfriendly implementation and verbose implementation - i.e. hard to work with and maintain. Also note that you are not even using it "by the book" since your security is external to it and not using ws-security
REST based interfaces would make your and your users' lives easier. I suggest you take a look at standards and tools like swagger for building APIs.If you're running on premise you can take a look at API gateways like tyk If you're running in the cloud you also take a look at AWS API Gateway
Spring Framework provides many technologies for applications to communicate with each other over HTTP.
HTTP Invoker
RESTful MVC Controller
JAX-WS
Spring-WS
What are the differences among them? What criteria dictate which one to choose?
JAX-WS is a standard maintained by the JCP (Java Community Process) and every full featured application server implements it (or, at least, provides an implementation for it). It's easy to use (you just need a few annotations in your service class endpoint) and you don't need to worry about the implementation (and your application will carry less dependencies within it).
Spring-WS was widespread when JAX-WS was a work-in-progress (or didn't ever existed). It achieves the same that JAX-WS but it's a bit more cumbersome. From my experience it's loosing adepts in the benefit of the latter.
HTTP based services (as HTTP invoker and REST) claim to be a bit more lightweight than JAX-WS (because the endpoints don't need to handle the SOAP envelope) but are not as strong-typed as WSDL based ones.
When I have to choose I usually decide for JAX-WS if there is not a strong reason for the REST based approach. I don't like at all the HTTP Invoker one because it's security issues (even though when talking about intranets), but I think this is a kind of personal choice.
If you are integrating your own apps and you have tight control over application client and wire (e.g.corporate intranet) then use HTTP Invoker - it's really transparent to application and easy to setup. Http invoker over Internet with non reliable client authentication (without PKI auth) may be not good idea, there are security problems with java serialization used in invoker.
If invoker doesn't suit you well, and it's your own apps - then consider REST.
I think WSDL based services are good for external integration - you can define protocol with strict rules.
There are 2 types of web-services as I know. First one is custom xml formatted messages and the second one SOAP standard xml messages. What are the differences between them? Which one is better, what are pros and cons of each of that two approaches?
By "ordinary" I assume you mean RESTful services. This discussion would be a long one, so I'll try to give you some key points:
RESTful services are the most used flavor of Web Services. They are closely linked to the functionality and principles of HTTP and can be accessed as simple as a GET request (other operations are POST, DELETE and PUT). The core concept is the "resource" which is identified by an URI. Common formats for REST are XML and JSON. It's a pretty straightforward and easy to use technology, which is what makes it so widely available.
SOAP web services are based on XML, most of them adhering to the RPC-style of app design (calling remote methods on a server and getting a response), and use 3 main pillars:
WSDL - Web Service Description Language - used to describe a service in terms of available operations, parameters, etc.
SOAP - Simple Object Access Protocol - used to construct interaction messages between the entities involved (client, server).
UDDI - Universal Description, Discovery and Integration - used to classify and publish available web services to a repository and enable discovery by potential users.
SOAP Web Services tend to have high overhead and generally have very verbose messages, but may be good if you need to implement more complex functionality and interaction in your application.
Strictly speaking only the Soap services are webservices. They are based on the WS-* Specs standardisized by W3C and Oasis. Sometimes a also reffered as Webservice are so called POX-Endpoint (Plain old XML) or REST Endpoint, which allows you to simply get a raw XML via HTTP GET.
SOAP Services carry their schema in form of a wsdl endpoint (usualy append ?wsdl to the service endpoint), so there a lots of tools to create proxy objects and hide the complexity of the webservice call. With POX Services you need to know which schema to use from e.g. the documentation.
SOAP Services carry the payload inside the SOAP Envelope (an XML Schema with header and body with the payload in the body). Having a header independent from the payload allows to reroute the content, sign and encrypt, authenticate etc. without knowing the content. But you pay by additional overhead in the message itself.
POX on the other hand leaves all that to the webserver and relies usualy on HTTP for authentification and compression. Encription and signing had to be done by your system. It is low overhead but also low discoverability.
Whats works best for you depends a lot on your scenario. If you work in a .Net or Java World, you often find it simplest to create a proxy and use that to work with the webservices as remote objects. You get a well build infrastructure and a comfortable programming experience. If youre environment does not support the proxy generation or if it had to be called from anything, POX might the very much more lightweight way to go.
"Web Service" refers to a more abstract and general concept. We can say that anything that can be served on web is a Web Service. SOAP Web Services or RESTful services are special kind of Web Services which has wide acceptance and has their own standards. While SOAP services are built on a new XML based standard, RESTful approach makes use of existing HTTP methods, hence more widely accepted (to my experience).
I am developing an appplication that consume data from WCF Web Service, but the data need to be retrieve from differents servers applications provided by different suppliers.
The question is what programming language support the develop of a Web Services from a WSDL that already exist?
For example in .NET you could use "wsdl.exe /serverInterface" to generate a server interface. See Implementing Service Interface
In Java see: Top Down Java Bean Web Service
But I don't want the suppliers to be attached to an explicit tecnology.
... I don't want the suppliers to be attached to an explicit tecnology.
You are taking about web services. The idea with web services is that it allows interactions between heterogeneous machines (and technologies).
For the interaction to happen, there is no need for the machine to use the same programming language or technology. What's important is the protocol used. In your case SOAP.
The protocol defines the communication interface or contract. For web services, the interface is described by the Web Services Description Language (your WSDL).
WSDL is in a (more or less) human readable format, but more importantly in a machine-processable format. The idea is that you use the WSDL to generate the code/classes that respect the contract; at the server side they are called Skeletons, and at the client side, Stubs.
A lot of programming languages have means or tools to generate stubs/skeletons from WSDL but again, that's not the important part. The important part is respecting the contract.
The WSDL just allows you to automate the creation of some boilerplate code. It's not mandatory to use the WSDL to create the server/client so any technology can be used (with or without the WSDL).
As long as you do that, you do not attach yourself to an explicit technology. So in the "WCF Web Service" you mention, you can drop the "WCF" word.
The only care you must take is with the interface between the systems. You must ensure the Web Services Interoperability as we don't live in an ideal world and some specifics from the technology stack "could leak" in the contract if you are not careful.