I would like to implement an API in Spray (Scala), that allows me to process a simple SOAP request. The request is a POST with a WS-Addressing payload. Although I can get the XML document, and I am aware of the existence of javax.xml.ws.soap.Addressing, I'm not sure how to tie the two together.
Can I use the above mentioned Addressing support in a spray route? if so, how? I can't figure out how to use an AddressingFeature in Scala.
Any help would be appreciated. If I can solve this, I can probably address other WS-* support I need.
Can I use the above mentioned Addressing support in a spray route?
The short answer is no, or better, why would you want to?
It's possible to build JAX-WS web services in Scala, but if you're trying to do it in Spray you're crossing paradigms. You really need a JAX-WS framework if you have to support WS-Addressing and other WS-* features.
I started with Spray as a WS-* refugee, and I doubt I'm the only one. I prefer Spray and I know you can use it to parse out your e.g. MessageId or Action and use them to build a Route, but I wouldn't reach for JAX-WS to make it happen.
Related
i have a project in vertx.3, i wanna to consuming a SOAP service.
is there a lib in vertx that allow me to do that?
i do a lot of search and i get anything.
please some one can help me!
There is no SOAP module in the Vert.x stack. That being said, you can craft SOAP messages in XML yourself, also by reading the WSDL descriptor if any.
For sure this is not an ideal solution, but it is doable.
Another option is to use the Vert.x Camel Bridge and have Camel / SOAP do the endpoint adaptation for you.
I have an architectural question. I want a Java client to communicate with a Java EE server (Glassfish). I don't want to use remote EJB invocations and use GlassFish Application Client Container, I need something more lightweight. So I consider calls over HTTP.
RESTful seems to me the easiest way from the technical point of view. But I'm confused about architectural style. I mean, I'm NOT creating a system that is defined in terms of 'resources', but in terms of 'methods'. So JAX-WS may be appropriate, but I would prefer to transfer not only XML, but just raw data in HTTP message body.
Should I consider servlets or something else? What is the best practices for client-server communication?
raw data in http message body
What kind of raw data, like bytes encoded in base64? That doesn't really sound like the typical job for HTTP. Somewhere in between EJB and Webservices there are other solutions that may fit better and can be faster. For example messaging/serialization frameworks like Apache Thrift or Protocol Buffers.
Anyways, if you go the HTTP way:
Sometimes it's possible to model method-like endpoints as resources, but doesn't always work. If there are no resources, just call it a "Web API" and only keep RESTful concepts and best practices that make sense for you. Caching, nice URLs and leveraging HTTP status codes and header for example.
JAX-WS isn't limited to transferring XML. It it's based on WSDLs though, which you might not need. REST API are easier to handle and more flexible.
JAX-RS is a good choice to build any kind of non-WSDL Web APIs. It provides a clean API and a lot useful features, even if you only use it for simple GET/POST operations.
One of the key points of building a RESTful API is HATEOAS. Now, Jersey offers a linking ability which is quite good (see this link). But I have seen the draft of the HAL Specification and it seems to be a well thought piece of work.
I am interested if there is some lib that makes it easy to adhere to HAL in Jersey. I have seen the references mentioned in the draft like https://github.com/HalBuilder. But I am using direct POJO marshalling and I do not know how to mix that with Halbuilder.
So, is there already some lib that incorporates HAL into Jersey? Or maybe I can use some kind of filter to enhance the generated POJOs manually? If yes, can someone give me a clue where to look next to accomplish this?
I can't find any direct support for this in Jersey, but there should be ways to customize the marshaller that Jersey uses to convert your POJO's to JSON. (either by using HalBuilder, or create some HAL-compatible code of your own)
If you use Jerseys JAXB based JSON support, take a look at BootstrapTypeConverterTest in the jettison source code which demonstrates how a converter can be used to cusomize JSON output. Unit-testing conversions to/from JSON should be a simple task and jettison-project has good examples to look at.
If you use Jerseys "POJO Support"-method, take a look at JacksonHowToCustomSerializers for a similar example on how to create your custom serializers.
(If JAXB is involved, you can also do cool things like processing custom annotations.)
You probably have a pretty good idea of how your objects (input) looks like and what JSON code (output) you expect, so creating unit tests for these conversions should be a relatively simple task.
Even if this is not really an answer, I had not enough characters to put it in a comment :)
If you're really new to REST, I think you're beginning probably in the wrong way. I don't know exactly your requirements, but if you only want to learn, begin with an easy REST service, use Web API from .net or something similar in Java (a simple servlet would be enough) and try to implement a service which only uses the tools delivered by http (the verbs, the request header and payload, the response message). REST API design rulebook from Marc Massé could be a good reference to learn. Create your own communication protocol with POJOs or POCOs and once you really what you can do REST and how it works, you can use a framework to ease your work.
If you begin with a framework you may miss the essence of the concept...
I hope it helps!
It's very little that's required to adhere to HAL. I suggest you roll your own mini-library where you wrap your POJOs in HAL-objects. This way you get the code the way you like it and it will be way simpler than HalBuilder.
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.
I'm trying to get a handle on web services and was wondering if I get some help from the SO community. In particular, a I'm trying to get a handle on WSDL, UDDI, SOAP AND JAX-P, because I'm most familiar with Java.
Edit:
Please tell me if I'm right or wrong on these definitions:
WSDL: This is a schema to describe what kind of XML documents can be passed to and from the WS.
UDDI: This is the most confusing to me ATM and don't really have a good def.
SOAP: Basic protocol used.
JAX-p: This is used for parsing the XML documents.
As an alternative to the SOAP path you might also want to consider looking into REST-based (or RESTful) web services, for Java in particular JAX-RS: The Java API for RESTful Web Services.
That's a very broad question. At a high level, SOAP refers to the XML protocol of the messages that travel back and forth. WSDL is another XML protocol that defines the format of the SOAP messages (very useful for tools that translate SOAP requests and responses for you). Typically a SOAP service endpoint will also have a way to access the static WSDL document about that service (e.g. if a service is hosted at http://myservice.com/services/MyService, the WSDL will usually be served from http://myservice.com/services/MyService?WSDL in most implementations). UDDI is yet another XML protocol that describes queries to a registry asking for information about SOAP services stored there.
Learn SOAP and WSDL first. UDDI is not all that widely used (although getting more so slowly). JAXR is the Java API around UDDI, which means that you probably should never need to write a raw UDDI query yourself.
JAXP is just a Java XML parser API. It can be used for lots of things, not just SOAP and WSDL. Apache Axis is a good Java SOAP client tool, and wsdl4j is a good WSDL parsing tool, although Axis will also autogenerate SOAP requests and responses from Java objects for you by parsing WSDL. Optimally, you should never need to parse a WSDL document yourself, but you often have to in practice when the tool doesn't quite do what you want.
If you want a practical introduction, do the Spring Web Services tutorial: http://static.springframework.org/spring-ws/sites/1.5/reference/html/tutorial.html
Web Services messages are defined according to the WSDL schema. Some parts will define where the message is supposed to go, and some parts will define the message contents.
Good Thomas Erl introduction to whats in the WSDL
They can be embedded in SOAP messages for transmission.
UDDI is like a look up directory to find web services you might use / consume. If you're trying to tie two specific systems together as opposed to broadcast the offering of some services, its probably irrelevant to you.
In Java, you can use a web services containers like Apache Axis to comprise your web services. JaxP could be used to parse XML documents for transmission etc.
You should read some overviews from the web and then post some more specific questions :-) Maybe if you described what you were trying to achieve, some readers would have experience with similar requirements.