I'm writing a web-service with Axis and getting request as below.
<NS13:PrefixCd xmlns:NS13="http://abc/def/common/name">MR</NS13:PrefixCd>
<NS14:FirstNm xmlns:NS14="http://abc/def/common/name">ARTURO</NS14:FirstNm>
<NS15:LastNm xmlns:NS15="http://abc/def/common/name">DOPAZO</NS15:LastNm>
In the request every element have namespace and in my response all the namespaces are in root element.
It is possible to put the namespaces in element level in the response.
I have used jaxb to create my skeleton. Please give some advice to fix this issue?
JAXB - to the best of my knowledge - does not support this kind of customization. You could use XSLT to customize your response...
Related
I’m stuck with trying to connect to my SOAP API. The goal is to retrieve a quote via the “Getquote” function which is available in our webservice and use that quote in an application in Bubble.is. Therefore, I want to make it work through form-data so I can reuse the keys and values in Bubble. I get a succesfull quote through the raw method. See picture
Raw method:
You can see that all my fields are in the body so with the form-data method I put all the individual fields in key and value but I get the error message you see below.
Form data method:
Can someone see what I'm doing wrong? Excuses me for I am just starting. There might be some beginner mistakes in there. Thanks for the help!
SOAP encodes messages by using XML. Form data uses a completely different encoding, which the SOAP server doesn't understand, hence the error.
Although I've never used it, there is a Chrome extension called Boomerang that supports SOAP requests, and which may suit you better.
I know it is not the current ways of doing things but...
How do I pass a http parameter to a WSDL URL?
I tried to attach it to the end of the query String like
"http://host:port/serviceA/methodA?wsdl¶meterName=value"
but the webservice refuse to read it.
What is the correct way of doing it?
I am no authority, but I am working with a web service (SOAP) at the moment - SOAP services seem to expect an XML Document, delivered as a POST.
Try doing a HTTP POST instead of a GET:
curl -d parameterName=value "http://host:port/serviceA/methodA?wsdl"
I solved this question by changing the endpoint URL. (not the WSDL URL)
Thanks for you reponses.
I am bit confused with WSO2 ESB aggregator mediator.
I need to send three messages to different systems via WebServices, but the three systems have different message formats, so i need to transform each response to canonical model before validate onComplete expression, how can i achieve this?
Thanks for your quick response!
I know that XSLT transformation is what i need to transform the response message, but the problem is i don't know where to put it. What i understand is the onComplete section needs a xpath expression from response message, but the three message have different xpath values.
for example:
Response 1:
<ns:getCustomerInfoResponse>
<ns:Status>
<ns1:Code>0</ns1:Code>
<ns1:Desc>SUCCESS</ns1:Desc>
</ns:Status>
</ns:getCustomerInfoResponse>
Response 2:
<v1:findByIdResponse>
<output>
<StatusCode>0</StatusCode>
<StatusDesc>OK</StatusDesc>
</output>
</v1:findByIdResponse>
What i need is transform two (or three) responses to unique canonical response before validate onComplete expression to something like:
<ns:response>
<status>
<code>0</code>
<desc>SUCCESS</desc>
</status>
</ns:response>
Thanks.
Thanks Ratha for your response.
Consider the following scenario:
In a bank there are three different systems: Credit System, CoreBanking System and CRM system.
I need to do something like "get all balances from all products", so, the request is the customer id, then the customer id is sent to CRM for obtaining all customer products. Depending of the product (Credit Card or Savings Account) it needs to send the customer id to Credit System or CoreBanking. Finally, each system will response and the ESB needs to response with both balances.
Hope you can help me with this use case!
Regards.
I don't think it is right to use aggregate mediator here, since you are receiving different responses from the service endpoints, which can not be correlated using xpath.
Aggregate mediator, which can be used along with clone/iterate mediators. Clone and iterate mediator is used to send same requests to multiple endpoint/such like scenarios.
My questions;
Are you sending same request to different endpoints and which are responding different type of responses? If so, it looks bit wrong, how you defined your services.
If you are sending different requests and getting different response, and want to aggregate( or create a new reponse) based on the responses which you received from your backend services, it will fall into service chaining pattern, which you can find in the ESB documentation.
Hope this is clear to you.
You can use XSLT mediator to get messages in to a unified format. please refer [1] for the XSLT mediator sample.
[1]. http://wso2.org/project/esb/java/3.0.1/docs/mediators/xslt.html
Thank You,
Dharshana.
This blog also explains your scenario with a sample...
If I understand you correctly, you want a combination of service chaining, transformation and iteration/aggregation.
So you start by sending the request to the CRM System, it will then respond with the different products, subdivided into Credit Card or Saving Account.
Then you could use two iterate mediators to split the response into the different requests for the two endpoints and collect the responses by using the aggregate or property mediator in the response sequences.
Now that you have the responses of the Credit System and CoreBanking service, you can start to transform (XSLT) and aggregate them to your response (balances).
Here you can find an example for service chaining and a bit of XSLT transformation.
Regards.
I am working on web services POC. I need to develop a Spring-based web services, that use XML/HTTP i.e. HTTP binding (NOT SOAP/HTTP) so that I can invoke a web-service with URL parameters like the one example described in the WSDL specification especially a GET with query parameters.
I am unable to map the URL's query-parameter to the end-point's (#EndPoint) method parameter.
Is it possible to develop such a web-service (XML/HTTP bound) with spring-ws?
Is it possible to invoke such a service with GET request + query string?
Let me know for any such examples/tutorials.
Please take a look at this page (http://static.springsource.org/spring/docs/3.0.0.M3/spring-framework-reference/html/ch18s02.html). Assuming that you are using spring 3, I believe you should find some relief there.
Based your question, I assume you already have the DispatcherServlet declared and mapped in web.xml. The trick, then, is to pull out the arguments. The page indicates how to pull arguments from both the URL (which I believe is your goal) and from the request body.
Good luck and write back if anything is unclear.
We have HTTP webservices that are RPC. They return XML representing the object the either retrieved or created. I want to know the advantages (if any) of "restifying" the services.
POST http://www.example.com/createDoodad
GET http://www.example.com/getDoodad?id=13
GET http://www.example.com/getWidget?id1=11&id2=45
POST http://www.example.com/createWidget
POST http://www.example.com/createSprocked
One thing I see is that we don't need representations for EVERY resource and we don't need to support all operations (GET, PUT, POST, DELETE) on all resources either.
Basically my question is this.
Convince me that I should be using restful services instead of RPC over HTTP and what would those restful services should be?
For one it's all about semantics, a URI is a Uniform Resource Indicator. HTTP provides methods to GET, POST, PUT, and DELETE a resource. HTTP headers specify in which format I want to recieve or send the information. This is all readily available through the HTTP protocol.
So you could reuse the same URL you use for HTML output to get XML, JSON in a way that HTTP was meant to be used.
XML-RPC and SOAP are based on calling methods that are described by an XSD or WSDL file whilst REST is based on getting/modifying resources. The difference is subtle but apparent. The URL solely describes the resource and not the action as is often the case with SOAP and XML-RPC.
The benefits of REST are that you can utilize HTTP verbs to modify a resource as supposed to a method call that could be named create/new/add, etc. Meaningful HTTP status codes instead of different kinds of error responses and being able to specify different formats on the same resource in a standard way.
You also don't have to accept ALL the verbs on a RESTful resource, for example if you want a read-only resource just return a 405 status code Method Not Allowed on any verb which isn't GET.
Should you redo your RPC calls to REST ? No, I don't think so. The benefits don't outweigh the development time. Should you learn REST when setting up a new Webservice ? Yes, I personally do think so, consuming a REST resource will feel a lot more natural and can grow much more rapidly.
EDIT
Why I feel REST wins over XML-RPC/SOAP is that when developing websites you already aggregate all the neccessary data for the output to HTML, you also write validating code for POST bodies. Why should you change to a different protocol just because the transport markup changes?
This way when you design a new website (language agnostic) if you really think of URI's as resources you basically use your URI's as method calls with the HTTP verb prefixing the method call.
That is, a GET on /products/12 with an HTTP header Accept: application/json; basically (imaginary) translates to getProducts(12,MimeType.Json).
This 'method' then has to do a couple of things
Check if we support JSON as a MIME type. (Validate request)
Validate request data
Aggregate data for product 12.
Format to JSON and return.
If for some reason in the next 4 years YAML is going to be the next big craze and one of your consumers wishes to talk to you in that way this MIME type is plugged in a lot easier than with regular web services.
Now product 12 is a resource you most likely also want to accept HTML MIME types on to display said product, but for a URI like /product/12/reviews/14/ you don't need an HTML counterpart, you just want your consumers to be able to post to that URL to update(PUT)/delete(DELETE) their own review.
In thinking of URIs strictly as resources, not just a location of a web page, and these resources in turn combined with the HTTP request to method invocations on the server side leads to clean (SEO friendly) URLs and (more importantly?) ease of development.
I'm sure there are frameworks in any language that will automatically do the mapping of URIs to method invocations for you. I can't recommend one since I usually roll out my own.
ASP.NET MVC also works on the same principle, but in my opinion it doesn't produce RESTful URIs. ASP.NET MVC makes the verb part of the URI by default having said that it's good to note that by no means does ASP.NET MVC force this (or anything for that matter) upon you.
If you're going to choose a framework at the very least they should:
Bind URI's to methods on the server
Support Object to JSON/XML, etc. serialization. It's a pain if you have to write this yourself although, dependent on the language, not neccessary all too difficult.
Expose some sort of type safe request helpers to help you determine what was requested without parsing the HTTP headers manually.
Try taking the verbs out of your URLs:
POST http://www.example.com/Doodad
GET http://www.example.com/Doodad/13
GET http://www.example.com/Widget/11/45
POST http://www.example.com/Widget
POST http://www.example.com/Sprocked
Query strings shouldn't be used for accessing a resource in a hierarchical, non-query manner. Query strings are usually ignored when caching, which is dangerous and slow.