Apache CXF mentions five different options for consuming a web-service: https://cxf.apache.org/docs/how-do-i-develop-a-client.html#HowdoIdevelopaclient?-BuildingClients
WSDL2Java generated Client,
JAX-WS Proxy,
JAX-WS Dispatch APIs,
Simple Frontend Client Proxy,
Dynamic Client
While there is some explanation of when to use 'Simple Frontend Client Proxy' and 'Dynamic Client', but for the other three it is not very clear about scenarios when one would be preferred over the others. Looking for answers or any helpful links about it.
JAX-WS APIs are probably not explained in detail, because they are part of the specification: https://jcp.org/en/jsr/detail?id=224
For a typical usecase I would recommend to follow the WSDL2Java approach which is also described here: https://cxf.apache.org/docs/developing-a-consumer.html
The Dispatch API allows you to develop clients more dynamically. If that's interesting for you, you should read chapter 4.3 of the spec.
Related
I like the APIs of the Retrofit and OkHttp rest/http libraries from Square. I am evaluating options for writing a server-side rest client. For each request to my SOAP-based web service, I have to consume another, restful web service, thus my need for a rest client.
My question is, are Retrofit and OkHttp suitable for server-side use in a highly concurrent web app, or are there likely to be issues, known or otherwise, stemming from these APIs having been designed for use primarily outside of the server-side?
Reading the documentation and perusing the code, nothing jumped out at me to indicate that these libraries would not be suitable. But I don't want to be a guinea pig either. Has anyone experienced any issues with server-side use under high load/concurrency? Had success? Anyone from the dev teams for those libraries care to comment? ;)
We use OkHttp on the Square Cash server and we haven't had problems.
Some of the default settings are not suitable for server side usage, for example, the maximum number of concurrent requests per host defaults to 5.
There is some discussion on this at https://github.com/square/okhttp/issues/4354.
In the microservices architecture world (using Spring Framework), Retrofit/Okhttp may not be a good fit as a REST client for inter-service communication. Using WebClient/RestTemplate will have at least the below advantages over using retrofit for the same purpose:
RestTemplate/WebClient can be easily configured to make use of client-side load balancing (Ribbon), thereby requests can be rotated among various instances or another microservice.
Hystrix can be easily configured with RestTemplate, thereby increasing the fault tolerance (circuit breaker pattern) of the overall system w.r.t inter-service communication.
Service discovery can be easily configured using Eureka or Consul, thereby the client need not know the host/port/protocol of the target web service. All we need is to enable the discovery client.
Alternatively, you can also explore Feign, which is a declarative web service client similar to retrofit, but with all the advantages of RestTemplate.
You can also have a loot at the following article:
https://www.javacodemonk.com/retrofit-vs-feignclient-on-server-side-with-spring-cloud-d7f199c4
In my project I am using a wsdl provided by TIBCO to generate web service client classes. These clients are responsible to to consume TIBCO web services over SOAP/JMS.
I see that the designer has made a comment in design doc like this:
TIBCO jms bindings are proprietary, so standard tools liek JAX-WS , JAX-RPC cannot be used to generate clients. Hence Spring Web Services will be used to generate the clients.
What does this mean? The designed is no logner with the team. I have no way of asking him
Standard SOAP binding to JMS defines a set of JMS properties that can be then used by the toolkits like JAX-WS or JAX-RPC to send the SOAP over JMS. E.g. SOAPJMS_requestURI, SOAPJMS_soapAction, SOAPJMS_contentType, etc.
The developer has probably not followed all the requirements stated in the standard and e.g. already existing endpoint that produces the SOAP requests might not set all the required JMS properties when sending a JMS message, or it might require different set of JMS properties to be set for messages that it consumes.
Spring-WS is probably more flexible when it comes to such customizations and not so picky when processing received messages thus it was recommended by the developer.
At the time the TIBCO code was written, there was no standard for SOAP over JMS (A W3 recommendation for SOAP over JMS was released just over a year ago) and all SOAP over JMS bindings were proprietary.
All this really means is that some tools will not understand the bindings and you will need to configure them yourself manually. Other tools will understand the bindings and will automatically configure the bindings in the client. Try it with different frameworks and see how you go.
Let's say I have some service that talks over ZeroMQ sockets, and I want to provide access to that service to a single-page web application. I'd like the web app to talk to a service that provides a REST API (for control and queries) and WebSockets (for monitoring), and which does this by talking ZeroMQ to the first service. I'd like to write this in Scala.
What options are available to me for building that second service?
A very integrated solution would be to use Akka/Play2 for this.
Akka would be the core component talking to the ZeroMQ socktes via akkas ZeroMQ Module, which gives you a nice Scala-API and Akka/Actor integration. This Akka/Actor system can than be accessed via HTTP/WebSockets by using either play-mini or play2 which mainly differ in the style of defining HTTP endpoints.
For REST API I would recommend Spray - a nice library with a very concise and flexible DSL for defining web services. We've integrated Spray into our current project and are pretty happy with it. As for play-mini, AFAIK, it depends on the entire play2 project, so you'll end up with a lot of stuff you don't need.
I'm trying to implement integration using JMS as a transport and SOAP WebServices being interfaces for my applications to be integrated.
Is it required that the WSDL itself defines transport as JMS?
Can I leave it to be HTTP and move the configuration of the JMS queues elsewhere?
I'm considering Apache Camel as an alternative.
The JMS parts in the WSDL are only hints how to invoke the service. There might be somewhat tricky without the hints if you rely on some import tool generating skeleton code, without the hints though.
I have even used WSDLs with both HTTP and JMS transports defined in them, so that is also possible.
How you configure your queues is another matter, because it depends on which framework you use.
I can't see how Apache Camel should be an alternative to SOAP over JMS. Camel is an integration engine (actually able to do SOAP over JMS) but not a transport standard itself. As a small sidenote, I really recommend Camel to do integration tasks.
You might want to carefully think about your requirements for your integration needs. SOAP over JMS can be quite powerful, but also a bit complex to design with, since people tend to think about SOAP as a synchronous service definition and JMS is designed mostly for asynchronous communication, even though there is somewhat support for synchronous calls as well.
I have been reading about REST and SOAP, and understand why implementing REST can be beneficial over using a SOAP protocol. However, I still don't understand why there isn't the "WSDL" equivalent in the REST world. I have seen posts saying there is "no need" for the WSDL or that it would be redundant In the REST world, but I don't understand why. Isn't it always useful to programmatically bind to a definition and create proxy classes instead of manually coding? I don't mean to get into a philosophical debate, just looking for the reason there is no WSDL in REST, or why it is not needed. Thanks.
The Web Application Description Language (WADL) is basically the equivalent to WSDL for RESTful services but there's been an ongoing controversy whether something like this is needed at all.
Joe Gregorio has written a nice article about that topic which is worth a read.
WSDL describes service endpoints. REST clients should not be coupled to server endpoints (i.e. should not be aware of in URLs in advance). REST clients are coupled on the media-types that are transfered between the client and server.
It may make sense to auto generate classes on the client to wrap around the returned media-types. However, as soon as you start to create proxy classes around the service interactions you start to obscure the HTTP interactions and risk degenerating back towards a RPC model.
RSDL aims to turn rest like a hypermedia, in other words, it has more information than a service descriptor like WSDL or WADL. For example, it has the information about navigation, like hypertext and hyperlinks.
For example, given a current resource, you have a set os links to another resources related.
However, i didn't find Rest Clients that supports this format or Rest Server Solutions with a feature to auto generate it.
I think there is a long way for a conclusion about it. See the HTML long story and W3C vs Browsers lol.
For more details about Rest like Hypermedia look it: http://en.wikipedia.org/wiki/HATEOAS
Note : Roy Fielding has been criticizing these tendencies in Rest Apis without the hypermidia approach: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
My Conclusion : Now a Days, WADL is more common that Rest and Integration Frameworks like Camel CXF already supports WADL ( generate and consume ), because it is similar to WSDL, therefore most easy to understand in this migration process ( SOAP to REST ).
Let's see the next chapters ;)
Isn't it always useful to programmatically bind to a definition and
create proxy classes instead of manually coding?
Agree wholeheartedly, this is why I use Swagger.io
Swagger is a powerful open source framework backed by a large
ecosystem of tools that helps you design, build, document, and consume
your RESTful APIs.
So basically I use Swagger to describe my models, endpoints, etc, and then I use other tools like swagger-codegen to generate the proxy classes instead of manually coding it.
See also: RAML
There is an RSDL (restful service description language) which is equivalent to WSDL. The URL below describes its practice http://en.wikipedia.org/wiki/HATEOAS and http://en.wikipedia.org/wiki/RSDL.
The problem is that we have lots of tool to generate code from wsdl to java, or reverse.
But I didn't find any tool to generate code from RSDL.
WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate
However, REST uses the network protocol by using HTTP verbs and the URI to represent an objects state.
WSDLs tell you at this place, if you send this message, you'll perform this action and get this format back as a result.
In REST, if I wanted to create a new profile I would use the verb POST with a JSON body or http server variables describing my profile to the URL /profile
POST should return a server-side generated ID, using the status code 201 CREATED and the header Location: *new_profile_id* (for example 12345)
I can then perform updates changing the state of /profile/12345 using the HTTP verb POST, say to change my email addresss or phone number. Obviously changing the state of the remote object.
GET would return the current status of the /profile/12345
PUT is usually used for client-side generated ID
DELETE, obvious
HEAD, gets the status without returning the body.
With REST it should be self-documenting through a well designed API and thus easier to use.
This is a great article on REST. It really help me understand it too.
WSDL 2.0 specification has added support for REST web services too. Best of both worlds scenario. Problem is WSDL 2.0 is not widely supported by most tools out there yet. WSDL 2.0 is W3C recommended, WSDL1.1 is not W3C recommended but widely supported by tools and developers.
Ref:
http://www.ibm.com/developerworks/library/ws-restwsdl/
The Web Application Description Language (WADL) is an XML vocabulary used to describe RESTful web services.
As with WSDL, a generic client can load a WADL file and be immediately equipped to access the full functionality of the corresponding web service.
Since RESTful services have simpler interfaces, WADL is not nearly as necessary to these services as WSDL is to RPC-style SOAP services.