I need to write integrations to multiple external web services. Some of them are SOAP (have WSDL), some of them pretty much ad hoc - HTTP(s), authentication either by basic auth or parameters in URL (!), natural-language like XML which does not really map nicely to domain classes..
For now, I've done the spike integrations using Spring Web 3.0 RestTemplate and binding using JAXB2 (Jaxb2Marshaller). Some kind of binding is needed because domain classes need to be cleaner than the XML.
It works, but it kind of feels bad. Obviously this partially just because how the services are built. And one minor issue I have is naming of RestTemplate as services have nothing to do with REST. This I can live with. JAXB2 feels a bit heavy though.
So, I'm looking for some other alternatives. Ideas? I'd like to have a simple solution (so RestTemplate is fine), not too enterprisey..
While some of your services may be schemaless XML, they will still probably have a well-documented API. One of the techniques that the Spring folks seem to be pushing, at least from the web-service server side, is to use XPath/XQuery for retrieving only the information you really need from a request. I know that this may only end up being part of your solution, but I'm not sure that this is a situation where one particular binding framework is going to meet all your needs.
If I understand correctly you have 1 application that has to make calls to various external (web) services by use of different technologies. The first thing that comes to mind is to have some intermediate level. While this could be something as elaborate as en ESB-solution, my guess is that is not what you're looking for.
You could for example achieve this intermediate level by having a class hierarchy with at its top an interface 'Consumer'. Method to be implemented: doConsume() and so on.
If you look into it you'll probably have the opportunity to make use of several design patterns like Strategy or Template. Remember to be pro-active and try to ask a few times 'What if ..' (As in: what if they need me to consume yet another service? etc.)
If JAXB feels too heavy there are other API's to be found:
Axis
JAX-WS
CXF
other
It'll depend on the situation which one would be better. If you run into troubles with any of them I'm sure you'll be able to find help here on SO (and from people who have more hands-on experience with them than me ;-)
Related
REST webservices imply the server-side is stateless (for the most part) and urls correspond to resources and HTTP GET/POST/DELETE/PUT methods correspond to operations on those resources.
I am planning to work on a JSON services layer that is dependent on server-side state, having urls that correspond to resources and having urls like /add /update /delete corresponding to different operations and all of those urls using HTTP POST.
What is the right terminology for this? Should this be called JSON
web services? Is there any specific term for this?
It looks like Jersey+JAX-RS would be very useful for this purpose. Is it ok?
Would it make sense to use Struts for this kind of application?
JSON is a file format which your rest service may (or may not) use to send its answers. If you use this format to communicate with your webservice, you cann say that your service is a JSON web service.
Indeed, Jersey is a good JAX-RS implementation. However it is not the only one.
If you need a webapp to interact with the webservice you can use Struts. However, you can use any other tool (included some more recent technology, struts is really old) for the front-end of your system.
Well, it's not REST. However trying to defeat that tide of general misunderstanding just isn't going to happen.
What you are describing is actually what most of the world views as REST and therefor should be mostly OK with just calling it as such.
In the presence of a true Restifarian, you will get some push-back because they will be correct - however, there isn't really much need to add a tremendous amount of confusion to your daily life as the distinctions (and the MASSIVE benefits they afford...) are largely lost on anyone you work with.
(1) is accurate enough, or simply rest. (2) is redundant but it is a good framework for the technology. (3) I would say no, but noticing when this question was asked, I'm sure you already decided.
I am working on an application which is built in .NET and Java. The Java component contains the complete Rule base using Redhat BRMS suite. The .NET client (UI and desktop based applications) will be consulting the Java Rule engine and sending/receiving the JSON data. The decision which has been taken is to expose the Rules engine (Redhat BRMS 6.0.0 using Drools) as a REST based API. I have come-up with the following design approaches:
Write a REST controller in Spring framework and service classes for calling BRMS.
Write a simple REST controller using JBOSS proprietary RESTSY or JAXRS.
Write a Camel adapter and wrap the REST calls behind the Camel and let the Camel talk to Drools.
Wrap REST behind SOAP based webservices.
I want to ask which one would be the better approach for designing such as System.
Any other thoughts are welcome.
As might be obvious from https://github.com/gratiartis/sctrcd-payment-validation-web and https://github.com/gratiartis/qzr my general preference is for exposing my Drools business rules using REST APIs in a Spring application.
The only alternative I consider in the above list is 4, where the API is exposed through a SOAP web service. Albeit definitely not wrapping a JSON REST service! A well-designed Spring application can expose functionality through both REST and SOAP APIs with very little effort.
I have usually exposed via SOAP when working with .NET clients. Firstly, the .NET tooling has excellent support for generating proxies based on WSDL that you have defined. Secondly, the WSDL forms a well-defined contract which both you and the client developers must obey. Having a strict contract can be very useful in preventing arguments. Although if your interface is simple, it may not be so much of a benefit.
The other key reason is that the WSDL does not change unless you change it deliberately. A REST JSON API may seem quick to develop, thanks to Jackson generating everything for you. However, it can expose your internal object model (and dependencies!), meaning that unless you are careful, what seems like a trivial change to an internal model can make private data visible and can break clients.
All that said, if you can keep the API reasonably simple and have a good relationship with the .NET devs (perhaps you're one of them), then going with the Spring REST API would be my recommendation. Feel free to steal code from the github repos if it can help you get started!
btw - If you were to consider Camel, it's worth noting that there is a Drools-Camel component which does quite a bit of the work for you.
In my view,
I would go with the option 1. This is the simplest and easiest approach.
Option 2 may be second choice.
Option 3 - Looks like if there are some routing rules you could choose. Again its could make it complex.
And definitely not option 4 to make it complicated with SOAP.
The application I am developing will be "responsive" , do async communication and pass a lot of JSON back and forth.
I Need a Java MVC WEB framework that supports
1) Minimum amount of BLOAT and "behind the scenes magic". With any framework, there is always a trade-off between framework functionality vs complexity. But, when the time comes when i face a problem and have to "fight the framework"(and that time always comes), I want it to be a fair fight. Minimizing the sheer size of the framework increases the probability of a fair fight.
2) Native RESTFUL support. I.e. route html verbs and perform content negotiation.
3) Straightforward support for processing JSON. Using an arbitrary json processor of my choice, i.e. jackson or gson e.t.c..
4) Straightforward persistance support, e.g. JPA e.t.c.
5) Some set of template systems, e.g. freemarker, velocity e.t.c.
6) Native authentication/authorization security scheme with support for a "role based" security OR Integrate easily with spring security
All of the above should be integrated in the framework. Not in some third party user contributed module that rots away when a new version of the framework comes along.
I sat down for a day and experimented and found the following candidates
Spring MVC 3
1) To get the proverbial "Hello World" example up and running in Spring MVC 3 i needed the following jars:
org.springframework.beans-3.1.0.RELEASE.jar
org.springframework.expression-3.1.0.RELEASE.jar
org.springframework.asm-3.1.0.RELEASE.jar
org.springframework.context-3.1.0.RELEASE.jar
org.springframework.core-3.1.0.RELEASE.jar
org.springframework.web-3.1.0.RELEASE.jar
org.springframework.web.servlet-3.1.0.RELEASE.jar
And finally some definitions in xml file, "dispatcher-servlet.xml". I don't know if that accounts for BLOAT or too much behind the scenes magic. But it doesn't give me a warm and fuzzy feeling of being somehwat in control
2) Spring 3 supports this and from the examples i saw it does not look too nasty
3) Supported, but from the link in (2) it seems as if processing json is limited to using the jackson library. At least if you want to use the magic annotations for content negotation.
Quote:
"Underneath the covers, Spring MVC delegates to a HttpMessageConverter to perform the serialization. In this case, Spring MVC invokes a MappingJacksonHttpMessageConverter built on the Jackson JSON processor. This implementation is enabled automatically when you use the mvc:annotation-driven configuration element with Jackson present in your classpath."
Bit of a warning signal for me. I would like to have clear programmatic control over what JSON processor i am using. Maybe i am missing something here. This qualifies as unwanted "behind the scenes magic" in my book
4) Yep
5) Yep
6) Yes
Play Framework
1) Version 1.2 weighed 88,5 MB on my disk. Doesn't run in servlet container, so getting the hello world example and running was easy peasy compared to spring, where even finding out which jars i needed was shrouded in secrecy. Obviously a lot of stuff happens behind the scenes in play. I guess all I can hope for is that it does not do more than it has to. And that the arcitecture is sane. But, when i have to fight the framework some day, will I be dead on arrival ? Who knows...
2) Yep and it does so elegantly. Thumbs up.
3) Yes, but it uses gson under the covers. Again, why can i not control this programmatically ? Fortunately, one can pass an arbitrary serializer to gson to override the default. And I think that parameter maps to the second parameter of the play renderJSON() native function. So play passes with half a thumb up.
4) Yep. Has a JPA module
5) Yep. Uses groovy. Fine by me.
6) Should be possible by combining the secure and the deadbolt modules. Don't know how well it stacks up against spring security. I dont see any in-built support for password encryption and the likes. And have no idea how difficult (if even possible) it would be to integrate with spring security. Don't know if i would be comfortable deploying sensitive data and relying on the play! framework for security. Would probably have to build something on top of it.
Restlet
Maybe a peculiar candidate as it's marketed to be used for "restless web services". But for my points (1) -(6) and my type of application where most of the user interaction is async, it seems like a good fit. I can run it on static resources or dynamically generated content and spit out any content type.
1) Restlet 1.1.1 is about 54 MB. Glanced the hello world example. I liked the absence of XML files. And just like play it has its own server(jetty connectors). The hello world example looked very clean and easy.
2) Yes, and the approach is very "programmatic"
3) Yes, but it seems only via a jackson extension module. Given the programmatic nature of this framework, it seems likely that there are other options but i didn't find anything in the documentation or in the user group forums.
4) Describes itself as "persistance agnostic". OK, that's good i guess. But i want to persist and not re-invent the plumbing on my own. Or at the very least i want a little howto showing that it CAN be done with some effort. There is a third party jpa module But it's built on restlet 1.0. Restlet has a spring module though, so maybe i can integrate with spring persistance stuff ...
5) Yes, there is a freemarker extension
6) Has a native scheme for this. At a fist glance, not as "rich" as spring security. Again, maybe I can integrate?
SUMMARY
Spring MVC 3: Supports all of the requirements, maybe with the exception of (1). Only concern I have is that it seems complex and I get a vague unpleasant feeling of not being in control. I really don't want to be "bogged down" by the framework later on as my application grows.
Play: Very pleasant experience. Fun even. If only the security scheme was more advanced, or if I could at least integrate with spring security(and find documentation on how to do it)
Restlet: For some reason this framework resonated with me. The Programmatic approach induces a feeling of control. But if I can't do persistance in some easy-cheasy way then it's a no go. Can't really understand why this is not built in. Doesn't everyone need this?
What say people who have used any of the above frameworks?
Are my observations accurate?
Did I leave out a framework that should be here?
Alternatives?
the comparison between Spring and Play is now highly out of date, since Play 2.0 has been rewritten in Scala and is better in almost every possible way.
Check it out: http://www.playframework.org/
I can only speak for Spring here.
When I was forced to use Spring for a non-REST project last year I cringed. Not only did I have just a few days to pick up the basics, I didn't like all the "magic" it did, nor was I familiar with IoC principles.
But it grew on me. It grew on me pretty fast too. Since then, I've used Spring for all kinds of Web projects, including one that exposes a RESTful API.
The strengths of Spring from my perspective are: a) it's actually pretty lightweight and usually keeps out of your way once you've got things configured, b) TONS of examples and a great community for support, c) doing REST is a cinch, once you get your configuration right, d) an API design that makes the gods weep with joy, and e) IoC is life-changing.
Speaking to your concern with bloat... I've used other Web frameworks for Java, and Spring is the least bloaty of them all IMO. It might LOOK like a lot, but it's really not. Compared to Struts and Seam (both of which I still have nightmares about), Spring is antithetical to bloat. Moreover, the IoC will let you get away without having to write tons of boilerplate, making your app less bloaty as well.
You mention you don't want to get bogged down by the framework as your app grows. This will not happen in Spring, I guarantee you. It is designed to stay out of the way and to keep you from becoming dependent on any one framework. Your code--if designed correctly--could drop Spring in the future for something else with not a whole lot of cursing and head banging. It favors convention over configuration, meaning the common stuff should work out of the box without having to tinker around too much. For those things that are off the wall, it gives you enough rope to hang yourself.
In summation, I would highly consider Spring.
The two I can recommend is RESTlet 2.x, which I use on every project. And RESTEasy which I am considering using on an upcoming project.
What I like about RESTlet is all the routing is in one place. It is very feature rich.
What I don't like about RESTEasy, and I have not looked at it all that deeply, is the Annotations have all the routing strewn across the code base on each method, of what could be many classes. Not having them all in one place, will make maintainability more difficult.
Why I am still considering RESTEasy, is having multiple GET methods per class might cut down on the resource class explosion that can occur in RESTlet.
Both are JAX-RS compliant, if that is important, and either one is a solid investment in time and functionality.
As for templating, use StringTemplate, stay away from things like FreeMarker, they just lead to a world of pain in maintainability.
Most projects, we seem to do some kind of SOAP web service consumption. And every time, it feels like being hit repeatedly over the head with a brick. For example, we end up with:
Dozens of generated classes our developers barely understand
Awkward APIs (especially when consuming .NET web services)
Hacks to deal with the fact that we normally generate from a local WSDL file (the remote service rarely exists at the time we start development)
In Python, I've used Suds (https://fedorahosted.org/suds), which provides a really natural (but obviously less type-safe) API. I know this is comparing apples and oranges, but there has got to be a less painful way to call a remote web service than generating so much code.
We'll probably use this in the Play framework for the time being, although I'd like something generic if possible. We also use Spring a lot, although I'm looking into Guice right now for a simpler alternative.
Martin
i've had pretty good experience using the apache axis2 librarys. Any point against those?
(forgot the link: http://axis.apache.org/axis2/java/core/ )
Check Apache CXF (http://www.coderanch.com/t/224490/Web-Services/java/Axis-Vs-CXF). It is very easy to use.
I'd like to write an applet (or a java Web start application) calling its server (servlet?) to invoke some methods and to send/retrieve data. What would be the best way/technology to send and to retrieve those message ?
Protocol:
If you don't care about interoperability with other languages, I'd go with RMI over HTTP. It has support right from the JRE, quite easy to setup and very easy to use once you have the framework.
For applicative logic, I'd use either:
The command pattern, passing objects that, when invoked, invoke methods on the server. This is good for small projects, but tends to over complicate as time goes by and more commands are added. Also, it require the client to be coupled to server logic.
Request by name + DTO approach. This has the benefit of disassociating server logic from the client all together, leaving the server side free to change as needed. The overhead of building a supporting framework is a bit greater than the first option, but the separation of client from server is, in my opinion, worth the effort.
Implementation:
If you have not yet started, or you have and using Spring, then Spring remoting is a great tool. It works from everywhere (including applets) even if you don't use the IOC container.
If you do not want to use Spring, the basic RMI is quite easy to use as well and has an abundance of examples over the web.
HTTP requests? Parameters in, xml out.
XML is still my preferred choice for data interchange.
Using XML with something like xstream that removes much of the hassle of XML Java libraries. You can serialize and deserialize objects in a very simple way.
A lightweight solution could be Hessian too.
A simple example is here.
If you need an ORM for that case: try Cayenne.