What design patterns must be evaluated while implementing a web service?
More importantly, what security aspects must be taken into account for a web service? Since a WSDL contains the complete information of the service including the input, output formats and access url, doesn't security get compromised with web service?
Thanks in advance,
Edit
Would just like to add a couple of things.
I am developing the service in Java that would be deployed on a JBoss server hosted on a Linux (Fedora) machine.
As far as authentication mechanism is considered for invoking the services, yes I do have that in place. Unless the user gets a token, he would not be able to use the other services which actually perform the business operation.
Also, have hidden the actual request in 2 layers of XML using CDATA for the actual request body inside the SOAP Envelope body. Something like the below code.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:myns="http://testserver/testservice">
<soapenv:Header/>
<soapenv:Body>
<myns:Operation>
<myns:OperationRequestBody><![CDATA[-- actual request XML goes here --]]></myns:OperationRequestBody>
</myns:Operation>
</soapenv:Body>
</soapenv:Envelope>
Is there any security aspect for URL - say using HTTPS protocol, which I understand would be a configuration at the server level.
well it depends on number of things:
whether you are exposing your webservice inside the organization (where you dont have to worry much about security) as opposed to exposing the webservice externally.
one thing we do (when we expose internally), we use Windows/NTLM authentication so that specific people in our domain can run it.
I would make sure i dont expose anything that can crush the web service :) (like GetAllData or smth similar) so that you expose only methods that is stateless and easy to throttle if needed.
also, used confluence's API (based on webservice), and they used Authentication mechanism, where you logon first, and you are given token, and you have to attach that token on every web service call that you do.
Related
We are designing a Web application which is invoked by an external system. We are going to receive a Web service from an external system which looks like this:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tis="http://schemas.tis.com/1.2/" xmlns:der="http://schemas.tis.com/DataProvisioning/">
<soapenv:Header>
<tis:SessionId>99999999</tis:SessionId>
</soapenv:Header>
<soapenv:Body>
<tis:Create>
<tis:MOType>SPPM#http://schemas.tis.com/DataProvisioning/</tis:MOType>
<tis:MOId>
<der:codex>12345677</der:msisdn>
</tis:MOId>
<tis:MOAttributes>
<der:createSPDD ProfileID="1" Action="createData">
<der:TechProduct Action="add" BarCode="15">
<der:Arguments ArgName="arg1" ArgType="string" ArgValue="1"></der:Arguments>
<der:Arguments ArgName="arg3" ArgType="string" ArgValue="2"></der:Arguments>
</der:TechProduct>
<der:TechProduct Action="delete" BarCode="21">
<der:Arguments ArgName="arg1" ArgType="string" ArgValue="1"></der:Arguments>
<der:Arguments ArgName="arg3" ArgType="string" ArgValue="2"></der:Arguments>
</der:TechProduct>
</der:createSPDD>
</tis:MOAttributes>
</tis:Create>
As you can see this SOAP Envelope we will receive contains namespaces in it. Up to now my Web services applications have been coded using JAX-WS and bottom-up approach (just adding #WebService and #WebMethod annotation to classes). What is the correct way to design a Web service that needs to receive a message based on namespaces ? Should I design first the WSDL ? I cannot see how to collect attributes which are in the Header or Body such as MoType or MoId. Any help ?
Thanks a lot
From your question it is tough to understand whether you want to expose a web service or you want to consume one. If you want to expose a web service with this structure and namespace you can choose bottom-up or top-down approach. Using top-down approach you will create
WSDL (here clearly you can mention the namespace for the service related details)
Schema (define the namespace for request and response elements)
Generate the Java classes from the WSDL and Schema.
Write the implementation for the Web Service interface.
If at all you want to consume the service then no need to write any WSDL. Get the WSDL and Schema(if any) from the service provider, Generate the Java classes from the WSDL and Schema received. You dont have worry about reading the values based on namespaces, the jaxws framework will do it for you.
Google the steps to consume a jaxws service.
Does SOAP always need WSDL or can it work without WSDL? I've been doing some reading on the internet and it's making me confused.
From what I can see, SOAP request can contain the message in the XML: http://www.w3schools.com/soap/soap_example.asp. Then why do I need WSDL? Or does it depend on how the SOAP service is set up in the server end?
WSDL is a description of the service (Web Service Description Language). It is mainly used to a) describe the service in a non-ambiguous way, and b) allow tools to generate client and/or server code, which make building, and interacting with, the service easier.
You can certainly implement, or interact with, a SOAP service "by hand" but you wouldn't want to.
I have done a few use cases on WSO2-ESB including protocol mediation with transformation and service-chaining.
In all of them I had to manually write the wsdl for the proxy service. Having experienced other vendor products including Oracle and Tibco where wsdl generation is done by the tool.
Would it be right to assume in WSO2 ESB one needs to manually write the wsdl file to expose a proxy service on any protocol, do not see any documents calling that out.
Considering the usage of wsdl in practical use cases.
I have seen posts stating "you can give the WSDL available at your Axis2 service" but most of real time use cases would not be pass through and have custom request and response.
Thanks,
Wajid
I'm also confused with manual wsdl creation. As far as I can see there are gaps in wsdl proxy description. When I do wsdl proxy with WSO2 I have to indicate wsdl to expose
its either as:
"none" and I have only mediate function exposed
"same contract" and this breaks the whole idea of proxy because after that clients read original wsdl and go straight to original server access point.
or and I have several options to make my own wsdl.
With rich SOAP API (hundreds of methods) none of above work well, considering that manual support of exposed WSDL is rather cumbersome.
I wonder if there is more adequate way for proxying WSDL?
You can use java2wsdl generator tool to achieve the WSDL generation.
For the proxies, if you try to restrict access for some operations in your backend service, you can attach customized wsdl to the proxy.
The customization has to be done by yourself and it is simple..
If you want to generate a wsdl fro your service, jsut deploy the service in wso2as, and check the service dashboard, wsdl option to view the wsdls.
I have a web service with a client written in Java. The service works behind a firewall and if the java client wants to consume the service, then its request is blocked because the request contains links. So the request contains validator references like this:
...<S:Envelope xmlns:S="http://schemas.xmlsoap.org/wsdl/"...
Shall I fix it in the wsdl file? That is the only place which contains this link:
<definitions targetNamespace="http://mycompany.com/" name="RentalServiceService"
xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:wsp="http://www.w3.org/ns/ws-policy"
xmlns:tns="http://mycompany.com/" xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata"
If I generate a client in .net from the wsdl file, then it does not put any link references into the request...
Thanks
Zoltan
Don't remove namespaces from the XML message. Configure your firewall instead!
Normally, SOAP is friendly with firewalls because it piggybacks on top of HTTP. If you remove the namespaces from the XML you might get it through the firewall but the web service that must make use of the message might fail to parse it because you removed the namespaces from it. XML namespaces are important because they correctly identify the domain to which each element inside the message belongs to.
Just as an observation, the <S:Envelope xmlns:S="http://schemas.xmlsoap.org/wsdl/"... is a copy paste error of some sort?... or maybe part of the problem?! The namespace for the SOAP envelope should be http://schemas.xmlsoap.org/soap/envelope/ for SOAP 1.1 or http://www.w3.org/2003/05/soap-envelope for SOAP 1.2.
That aside, if the SOAP message is correctly formatted, it should pass through the firewall. If it doesn't, then the solution is to configure the firewall properly and not mess with the SOAP message. Your network administrators should spend time understanding web services security and properly configure the firewall.
My suggestion would be to keep port 80 just for your users requests/responses from browsers and expose the service on a different port number with proper configurations. Maybe you could even set up a reverse proxy inside a DMZ to improve the web service security. With that, you won't expose your internal web service server directly to the Internet.
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.