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.
Related
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'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.
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.
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.