Friday, November 20, 2015

WADL and Swagger United in Apache CXF

Who could've thought that Swagger and WADL can be real friends ?
Both Swagger and WADL are about describing REST APIs and while the former has a definite momentum, the latter has proved to be very capable and helpful to JAX-RS users.

The important thing is that we have users who submit WADL documents  to the runtime or build time code generators which is all working fine. We also have Swagger users who use cool Swagger features and being happy with a nice UI being generated. And WADL users, while being happy with WADL (which IMHO is indeed a very capable language for describing schema rich XML but with some extensions - even JSON - services) would like to use Swagger to introspect the code generated by WADL processors and have a nice API UI.

So my colleague Andrei and  Francesco, Apache Syncope maestro, have driven the work about enhancing a WADL generator to set WADL documentation fragments as Java Docs in the generated sources and then having CXF Swagger features being very smart about enhancing Swagger JSON payloads with these Java Docs, with Francesco doing some magic there. I should also mention Andriy Redko doing some work earlier on directly with Swagger for it to better support JAX-RS annotations and initiating the CXF Swagger project and Aki Yoshida doing a lot of Swagger2 work next.

So here you go, WADL and Swagger United in Apache CXF.

IMHO this project has been a perfect example of the power of the Open Source collaboration with the contributors from different teams working effectively on this project.

HTrace your Apache CXF Service flows

Andriy Redko keeps pushing CXF to the next level with adding new features nearly every few weeks :-).

One of his latest projects has been to do with wiring Apache HTrace into CXF such that CXF users can HTrace calls starting from CXF clients going to CXF servers and then to such HTrace aware containers as HBase  and using the collectors like Zipkin.

I'm looking forward to Andriy talking in detail about it on his blog and at the conferences, but in meantime you can check the documentation. Note that it works not only for JAX-RS but for JAX-WS too: if we can have a new feature working with both frontends then you know it will be done. The demo is here.

Give it a try and stay on top of the web services game :-)
Enjoy !


JAX-RS 2.1 specification work has started

JAX-RS 2.1 specification work has finally started after a rather quiet year and this is a good news for JAX-RS users at large and CXF JAX-RS users in particular.
JAX-RS 2.1 is entirely Java 8 based and a number of new enhancements are on the way. I was concerned earlier on that having a Java 8 will slow down the adoption but I think now the spec leads were right, Java 8 is so rich and JAX-RS needs to be open to accepting the latest Java features - ultimately this is what will excite the users.

The main new features list is: support for Server-Sent Events (something CXF users will enjoy experimenting with while also keeping in mind CXF has some great WebSocket support done by Aki), enhanced NIO support and introducing a reactive mode into Client API.

I've already mentioned before that JAX-RS 2.0 AsyncResponse API is IMHO very impressive as it makes a fairly complex task of dealing with suspended invocations becoming rather trivial to deal with. Marek and Santiago are doing it again with the new 2.1 proposals. Of course there will be some minor disagreements here and there but overall I'm very positive about this new JAX-RS project.

We now have a CXF Java 8 master branch to support the future JAX-RS 2.1 features but having a Java 8 trunk is great for all of the CXF community.

What is really good is that there appears to be no obvious end to the new requirements coming into the JAX-RS space. The HTTP services space is wide open, with the new ideas generated around the security, faster processing, etc, and it all will be eventually available as future JAX-RS features. I'm confident JAX-RS 3.0 will be coming in due time too.

Friday, October 9, 2015

[OT] Apache CXF: Nothing Else Matters !

One can ask, do web services still matter in the today's world of emerging technologies such as Cloud and Big Data ?

Of course they do still matter. Take Big Data. The important thing to realize is as far as a remote client interacting with your HTTP server which internally initiates BigData flows is concerned it is still a client and HTTP server only - the client submits the data and gets the response it needs - the mechanism used to produce this response is, and has to be, completely opaque to the remote client, nothing unusual here, simply a proper service design leaking no implementation details to the client. In some cases one may not want to link BigData response streams to remote clients but in other cases it may make a perfect sense.

So yes, the web services do still matter because one still needs a production-quality, secure, flexible HTTP layer between the remote clients and internal data systems.

In fact, if you are an Apache CXF user, I can already hear you all saying (or even singing ?), Apache CXF: Nothing Else Matters ! Just make it loud enough to have your colleagues from the other team hear it :-)

Thursday, October 8, 2015

Make your CXF JAX-RS servers OpenId Connect ready

We've been doing a lot of work during the last year to ensure CXF developers can start experimenting fast and effectively with the latest RS security advancements such as OAuth2 and JOSE which are also the building blocks for OpenId Connect (OIDC).

With OAuth2 and JOSE modules becoming quite solid, it was time to turn the attention to OIDC, OIDC RP being a starting point - which is a mechanism to log on the users into the servers by federating to OIDC IDP providers such as Google and Facebook.  OIDC is a fairly complex protocol but with OAuth2 and JOSE covered it was not that tricky after all.

The initial result is these two demos:

1. BigQuery

This demo shows a client OAuth2 server that accesses a user's BigQuery data-sets. The demo checks a public data-set of Shakespeare works but once you have a Google Developer account you can easily create your own BigQuery data-set and use the demo to access it instead.

2. Basic OIDC

This demo shows that a server does not have to be specifically coded around OAuth2 flows to use OIDC - it only uses OIDC to log-in the users and then work with these users.

I'd like to encourage you to run these demos - ask at CXF users or #apache-cxf if you have any issues running them and start making your CXF servers OIDC-aware now !

I look forward to the feedback from the early adopters. And please watch this space - this is only a start :-)

Wednesday, October 7, 2015

Apache CXF and Aries Blueprint Everywhere

Many times, when developing JAX-RS demos, I had to solve the following issue: how to describe the demo endpoints to be run in OSGI and the same endpoints to be run in Tomcat.

Typically I'd create a Spring context file describing few JAX-RS endpoints and use it when running a demo in Tomcat. Next I'd create an equivalent Blueprint context file and run the demo in Karaf.

It works but having to duplicate the contexts in Spring and Blueprint languages is unfortunate. Granted, one can use Spring DM to run the endpoints described in Spring contexts in Karaf but OSGI developers know Spring DM is a finished line.

So we did some work first to make a CXFBlueprintServlet referencing a Blueprint context working in OSGI - the same way a CXFServlet can work with Spring contexts in OSGI with the help of Sprinjg DM.

Next, my colleague Alex suggested to have the same mechanism working in non-OSGI deployments - for the reason described above, i.e, to reuse the same context language (Blueprint) when deploying CXF endpoints to OSGI and servlet containers. As it happens Apache Aries team already did some work for supporting Blueprint in non-OSGI setups, so after doing some more work in CXF and Aries we can now have CXFBlueprintServlet loading Blueprint contexts in standalone Tomcat/Jetty too. Some work still needs to be done here, particularly ensuring such endpoints can run offline, but overall it looks promising.

The short overview is here.  Note the same web.xml and Blueprint context is used in OSGI and non-OSGI setups - the only thing which changes is a single Maven Aries dependency.

Note this mechanism works for CXF JAX-RS and JAX-WS endpoints.

If you are a Blueprint fan: Enjoy!  

Thursday, May 14, 2015

The Rise Of Apache Tika

Apache Tika is an interesting project. It is not a very big one but IMHO it is poised to become the project every team serious about doing the complex, unstructured, binary content processing will talk about and use.

The power of Apache Tika lies in the simplicity it offers for processing different types of binary and other types of complex data. Consider a simple situation: your project needs to support analyzing PDF files. One approach is to write a PDF library specific routine. This approach stops scaling as soon you need to support Excel and ODT files too. And stops working once you have a task to support a possibly unlimited number of types of data.

Apache Tika helps with generalizing the processing of arbitrary types of data and thus offers a unique opportunity for a given project to offer a real value add-on.

I really liked this presentation at the recent Apache Con NA.  It was absolutely packed with the interesting content and Chris talked a lot about applying Tika to solving the real life problems. Andriy Redko did a brilliant talk about the CXF and Tika integration. There were more Tika presentations and I regret I could not make it to all of them.

The future is bright for Tika. And for the projects that will use it :-)