I have an application written in Scala/Akka and trying to add SOAP support. Anyone did it with Alpakka? Or what is the best way to do it. So far I think Camel is the best solution.
Currently, Alpakka does not support SOAP, but there is an open ticket. Your best bet is probably to use Camel integration in your Scala/Akka project. To that end, take a look at the streamz project or the Camel integration module in Akka (the latter is deprecated but may serve your needs).
There is also a library that provides some SOAP integration with Play.
Related
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.
We are about to take on a large project implemented in Grails (2.3.7). The application makes heavy use of many different (end-points as well) REST-ful webservices. We are of course interested in using what is considered to be "best standards" (at least currently).
We are currently considering:
- Using the Groovy HTTP-builder
- Using the "REST Client builder" plugin
Any other we should consider and what are your experiences using the above mentioned?
I have used both http://grails.org/plugin/rest and http://grails.org/plugin/rest-client-builder and both provide a nice wrapper around HTTP Builder library. The "rest" plugin provides dynamic methods for you if you like using that syntax. I prefer REST client builder though. Both are easy to work with.
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've been reading up about Akka and it really seems nice. Can you somehow set it up to work with Apache Mina or similar techs? I.e not only use it in conjunction with servlets.
Hmmm, seems you already have a technical solution (Mina).
May I ask what is the problem you're trying to solve?
RemoteActors are using Netty, it's basically only the JAX-RS (Jersey) and Comet (Atmosphere) integration that runs over servlets.