I'm new to web services and I'm facing a design issue where we want to create a web service (preferably SOAP based) which will receive 2 parameters:
a string variable (Client Name);
XML data.
There are currently 2 different consumers of this web service but their number will increase. All consumers have separate XSD data that they will be sending, for example:
Consumer1:
<ConData>
<Customer>
<FirstName>FirName</FirstName>
<LastName>LasName</LastName>
</Customer>
<Acocunt>
<Number>112971</Number>
</Account>
<Order>
<OrderNum>0092123</OrderNum>
</Order>
<ConData>
Consumer2:
<ConData>
<SysData>
<CustomerFirstName>Name</CustomerFirstName>
<CustomerLastName>Name</CustomerLastName>
<AccountNumber>Au1o2n</AccountNumber>
<OrderNum>koo912</OrderNum>
</SysData>
<ConData>
This web service is supposed to take the XML data from these clients and store it into the database based on the consumer name. There is no processing required on our end for validating the XML as such, we just take it and store it in the database.
As a good design though, I'd like to define my web service with explicit parameters. The problem is that since their XML data format is different I'm not able to use a single XSD schema as a parameter in my WSDL. I can think of 2 options to address this:
1. Let them pass XML data as String in my web service instead of XSD mapping parameter. Though this is a valid approach, it seems like a bad design based on what I've read so far on the forums as it voids validation and needs lots of manual marshaling and unmarshaling and other problems. Plus my WSDL will not be able to define to my clients what format is expected etc.
2. Create 2 separate web services which will handle different individual consumers with their own XSD's. This again seems less viable since in future if we add more consumers we will have to add new web services with duplicate code for the same operation etc.
I was looking to see if there is a way to define multiple XSD's in a single web service WSDL or maybe a better way of solving this problem.
On a side note, I'd prefer to have a SOAP based web service but if this problem gets resolved using a RESTful web service in a better way then I can consider that as well.
You don't need to have a different web service or skeleton for each client, you just need a different WSDL.
Forget about sending this XML parameter as string, it has disadvantages that I won't repeat here since you already read about it too. So you need to send it as XML.
To keep it into one web service, you create the web service so that it accept any XML as input (type <xsd:any> for the parameter). Type <xsd:any> will mean any kind of XML, but at least it would be XML that you can validate for structure, for starters.
This simplifies versioning of your web service as you don't need to change the code when adding another XML type of input but unfortunately you lose strong typing for your web service and the WSDL generated for the web service will not state anything about the structure of the XML it's expecting (any XML is too vague). Your web service skeleton will be created with a type like Object, XmlElement, XmlDocument or whatever in your code. And the same will happen with all your client stubs.
But for your clients this can be fixed from the WSDL by providing each client with a different WSDL.
For that you create a WSDL of your web service with common content for all clients, except the <types> section, and then merge this common WSDL for each client with their own XML Schema. You will then expose each WSDL on different URLs for each client.
Now the clients will be able to generate strong typed stubs based on their own particular WSDL.
When a client makes a call to your web service, you identify the client XML Schema and use it to validate the XML parameter and see if it's the expected content.
And if the above seem to much, then you can always choose a loosely typed RESTful web service. Whatever solution you choose though, just make sure that you validate the incoming XML using the schema of the client that's sending it.
Related
I am new to Spring web services. I am going to create an xml request, and send it as a SOAP request to a web service and receive the response.I read different documents but still confused as I could not find a working sample yet.
I know that I should use WebServiceTemplate and WebServiceMessageSender, SaajSoapmessageFactory (please let me know if I am wrong) but not sure how to use them.
Do I need WSDL? if yes why?
If you have any sample code please send me to get clear on it.
Thanks
If you want to send SOAP requests, you would like to be a SOAP client. Seems like you want to use spring-ws project. Check out their great documentation on the client side. The same documentation will guide you through the process of creating a server. There are plenty of examples and ready-made configuration snippets waiting for you.
Spring-WS is built on top of XML Schema description of your message, so you will need WSDL to generate e.g. JAXB models of your requests and responses.
AFAIK, for "web services" , the WSDL file is the machine blueprint of the "ports" as they are called However! ports in WSDL "means" java language(or any other programming language used with a routine or sub or procedure or function) method and has a specific naming scheme associate the .wsdl xml file(template of the service). Each WSDL port(language method) has specifications of return value and data specifications for how to feed it arguments and their type values.
I am reading so many things to understand various things in WCF.
Very soon, actually, i want to move/convert existing WSE3 web services to WCF. In existing WSE web services, I have some (data) classes that model entities in our environment.
While transforming those classes, should I use Data Contract/Data Member attribute or the MessageContract attribute?
1. How to decide between Message Contract and Data Contract in WCF?
2. Does type of binding (like basicHttpBinding) has any role in this decision?
3. Does proxies created at client side (when we add web reference) change significantly depending on the Data or Message Contract?
(PS: I am trying to find a way so that existing WSE clients should be able to consume the WCF service without much alterations/modifications. Is it possible to use the current proxies generated from ASMX web services, to connect to the new WCF service just by setting URL of the proxy to WCF service?)
Here is a quick go at answering your questions:
1) Unless there is a specific reason like tweaking the structure of the soap XML, use DataContract instead of MessageContract.
2 & PS) Since you are currently using soap over HTTP, you'll most likely need the new services to be configured for basicHttpBinding. This will provide the interoperability that you need for the ASMX clients.
3) It shouldn't if the soap structure created by the WCF service matches your current soap.
I vaguely remember that WSE 3.0 supported some of the WS-* standards. If your current code depends on these then you may be able to also expose a wsHttpBinding for these operations but I don't think a default ASMX client works with a wsHttpBinding configured service.
It depends on control you need over resulting SOAP message. DataContract defines part of message body wrapped by element defined by operation. MessageContract defines a structure of whole message - you can use multiple body members, you don't have to use default wrapper element and you can also place some data into SOAP headers.
In your scenario the most important part is to define WCF to use same SOAP messages as your former WSE3 service. Here the important is how do you currently serialize data? If you use Xml serialization (and attributes) you can use it directly in WCF by switchinig from data contract serialization to xml serialization.
Btw. why did you use WSE3 instead of plain ASMX? Did you use message security? In such case you will need another binding. BasicHttpBinding is not able to do message security.
General answer is yes, you can create service wich your current client proxies will be able to consume. But in reality the effort depends on your current service and current code.
If I need a web service to pass back and forth a complex object, is there a reason I should prefer SOAP over REST? Here is an example of the possible SOAP message:
<soap:Envelope>
<soap:Header>
<Credentials>
<User>Joe</User>
<Password>abc123</Password>
</Credentials>
</soap:Header>
<soap:Body>
<MyComplexBusinessObject>
<Search>
<First>Joe</First>
<Last>Smith</Last>
</Search>
...
...
</MyComplexBusinessObject>
</soap:Body>
</soap:Envelope>
Using REST, I would be asking the client to POST the following xml and authenticate using Basic Authentication:
<MyComplexBusinessObject>
<Search>
<First>Joe</First>
<Last>Smith</Last>
</Search>
...
...
</MyComplexBusinessObject>
The SOAP message is slightly more complicated, but not by much. They are still both XML, but SOAP comes with a WSDL and most programming environments will generate proxy classes for you. However, most people I talk to say I should use REST instead because it's easier to use. But I don't see how SOAP is any harder to use.
Am I missing something?
Your first requirement of "passing back and forth a complex object" constrains your architecture to eliminate many of the benefits of REST. SOAP is designed for accessing remote objects, REST is not. REST supports passing media-types as simple as text/plain, which is far more primitive than dealing with an object.
If you haven't seen it already, this question and its answers cover most of the REST vs SOAP issues.
One major benefit of REST is that all you need to call and use it is a browser and a HTTP stack - pretty much every device and machine has that. So if ease of use and reach are you main goal - use REST.
One of the major benefits of SOAP is that you have a WSDL service description and you can pretty much discover the service automatically, and generate a useable client proxy from that service description (generate the service calls, the necessary data types for the methods and so forth).
So if discoverability and a strict, formal service description are more important to you, use SOAP (with the downside that you need a full-fledged SOAP client to call your service - your web browser won't be sufficient).
SOAP isn't harder to use - but it's just not quite as "pervasive" in terms of being available - any browser can call a REST service and get an answer - but then it needs to parse and interpret that response. SOAP gets nice data structure, but you need a SOAP client for this.
I view SOAP and REST as orthogonal APIs, designed to do different things.
SOAP is basically a fancy RPC, so if you want to send a computation request over to the server and get the result back, you use SOAP. If it would be local, it would be a method call to an object instance.
REST is a way to create, retrieve, update and delete remote objects, not in the sense of POO, using a uniform API. If it would be local, it would be like working with a file.
So they actually respond to different needs. You can bastardize one to do the work of the other, but you mangle the meanings.
If you develop both the service and the client, using SOAP is as easy as REST (actually easier).
You may prefer SOAP over REST if these conditions meet:
The entire service API is complex, not just one object.
The service is used within a relatively small network, and performance is not an important requirement.
You decide to spend the minimum amount of time to develop both the service and the API documentation.
Working on a docuSign integration with Coldfusion and need assistance in making the SOAP request using WS security.
Your question is a little short on detail, but I presume you mean the Web Services SOAP security extension.
We had to do this a few years back when communicating with a .NET web service. The basic idea is that you provide a set of extra SOAP headers that contains security info such as:
Timestamp
Username
Password
Etc
To do this you need to create a new XML document as per the standard defined here. Next you will need to write code to create the SOAP headers. This means:
Create your remote web service object, e.g.
var objWebSvc = createObject("webservice", "http://remoteURL?WSDL");
Creating an XML document to represent the new headers
Populating it with the required info (such as username and timestamp etc.)
Adding the XML document to the web service object, using addSOAPRequestHeader()
Call your remote web service
Then of course if and when they call your web service you'll need to parse out those headers from their SOAP request and validate them. That can be done by grabbing the XML using getSOAPRequestHeader() and parsing out the info.
I found this to be an error prone task and (basically) a royal pain. The web service we integrated with eventually dropped the requirement, apparently becuase the any web services trying to connect that were not native .NET were having a hard time implementing the specification.
Good luck!
I blogged this a while back. See if this helps:
http://onlineanthony.blogspot.com/2010/05/using-ws-security-for-soap-in.html
What is WSDL? How is it related to SOAP? Where does REST fit in all of that?
A WSDL is an XML document that describes a web service. It actually stands for Web Services Description Language.
SOAP is an XML-based protocol that lets you exchange info over a particular protocol (can be HTTP or SMTP, for example) between applications. It stands for Simple Object Access Protocol and uses XML for its messaging format to relay the information.
REST is an architectural style of networked systems and stands for Representational State Transfer. It's not a standard itself, but does use standards such as HTTP, URL, XML, etc.
Example: In a simple terms if you have a web service of calculator.
WSDL: WSDL tells about the functions that you can implement or exposed to the client. For example: add, delete, subtract and so on.
SOAP: Where as using SOAP you actually perform actions like doDelete(), doSubtract(), doAdd(). So SOAP and WSDL are apples and oranges. We should not compare them. They both have their own different functionality.
Why we use SOAP and WSDL: For platform independent data exchange.
EDIT: In a normal day to day life example:
WSDL: When we go to a restaurant we see the Menu Items, those are the WSDL's.
Proxy Classes: Now after seeing the Menu Items we make up our Mind (Process our mind on what to order): So, basically we make Proxy classes based on WSDL Document.
SOAP: Then when we actually order the food based on the Menu's: Meaning we use proxy classes to call upon the service methods which is done using SOAP. :)
Every time someone mentions SOAP/WSDL, I think of objects and classes defined in xml...
"You use SOAP just the same way that you would any PHP class. However, in this case the class does not exist in the local applications file system, but at a remote site accessed over http."
...
"If we think of using a SOAP service as just another PHP class then the WSDL document is a list of all the available class methods and properties. "
http://www.doublehops.com/2009/07/07/quick-tutorial-on-getting-started-with-soap-in-php/comment-page-1/
..and whenever someone talks about REST I think of HTTP's commands (request methods) like POST, GET and DELETE
SOAP -> SOAP(Simple object access protocal) is the application level protocal created for machine to machine interaction. Protocol defines standard rules. All the parties who are using the particular protocol should adhere to the protocol rules. Like TCP, It unwinds at transport layer, The SOAP protocol will be understood by Application layer( any application which supports SOAP - Axis2, .Net).
WSDL -> SOAP message consist of SoapEnevelope->SoapHeader and SoapBody. It doesn't define what would be message format? what are all the transports(HTTP,JMS) it supports? without this info, It is hard for any client who wants to consume the particular web service to construct the SOAP message. Even if they do, they won't be sure, it'll work all the time. WSDL is the rescue. WSDL (Web Service description Language) defines the operations, message formats and transport details for the SOAP message.
REST -> REST(Representational state transfer) is based on the Transport. Unlike SOAP which targets the actions, REST concerns more on the resources. REST locates the resources by using URL (example -http://{serverAddress}/employees/employeeNumber/12345) and it depends on the transport protocol( with HTTP - GET,POST, PUT, DELETE,...) for the actions to be performed on the resources. The REST service locates the resource based on the URL and perform the action based on the transport action verb. It is more of architectural style and conventions based.
You're not going to "simply" understand something complex.
WSDL is an XML-based language for describing a web service. It describes the messages, operations, and network transport information used by the service. These web services usually use SOAP, but may use other protocols.
A WSDL is readable by a program, and so may be used to generate all, or part of the client code necessary to call the web service. This is what it means to call SOAP-based web services "self-describing".
REST is not related to WSDL at all.
SOAP stands for Simple (sic) Object Access Protocol. It was intended to be a way to do Remote Procedure Calls to remote objects by sending XML over HTTP.
WSDL is Web Service Description Language. A request ending in '.wsdl' to an endpoint will result in an XML message describing request and response that a use can expect. It descibes the contract between service & client.
REST uses HTTP to send messages to services.
SOAP is a spec, REST is a style.
Wikipedia says "The Web Services Description Language is an XML-based language that provides a model for describing Web services". Put another way, WSDL is to a web service, as javadoc is to a java library.
The really sweet thing about WSDL, though, is that software can generate a client and server using WSDL.
Some clear explanations (for SOAP and WSDL) can be found here as well.
Difference between a SOAP message and a WSDL?
REST is light-weight in terms of encoding, much more useful for light weight devices i.e. non strict APIs.
REST is format independent. XML, HTML, JSON all options are available.
REST provides abilities for on 2 point message transfer (not surprising since REST stands for REpresentational State Transfer) where WSDL/SOAP interaction is multiple point message interaction.
REST does not require a new extension for XML messages, where in WSDL/SOAP this is the case.
WSDL/SOAP uses multiple transport protocols, REST relies on only HTTP. Therefore WSDL/SOAP can be used like a RESTful way, however simple requests can be overly complicated/heavy weighted.
A simple analogy: REST is like a motoboy delivers your food easy and quick. XML extended WSDL/SOAP more like UPS delivery, more structured and serious stuff but comes with a cost.
A WSDL document describes a webservice. It specifies the location of the service and the methods of the service using these major elements:
data types using in webservice
data elements for each operation
describe the operations that can be performed and the messages envolved
SOAP (Simple Object Access Protocol) is a messaging protocol that allows programs that run on disparate operating systems to communicate using http and xml.