Monday, December 19, 2016

[OT] You worked with CXF, Have a Great Time Out

Apache CXF has had a good year, with thanks to you using it, reporting the issues, asking the questions, with some of you spending a lot of your own time on helping improving it and keeping it flying and alive.

Time has come for a well deserved break. Have a Great Time Out, enjoy it !

Tuesday, November 29, 2016

Bean Validation for CXF JAX-RS Proxies

If you work with CXF JAX-RS Client proxies and have been thinking for a while, wouldn't it be good to have the proxy method parameters validated with the Bean Validation annotations, before the remote invocation is done, then a good news is, yes, starting from CXF 3.1.9 (which is due soon) it will be easy to do, have a look at this test please.

If you have the code which is considered to be safe with the respect to how it initializes the entities which will be posted to the remote targets then the client side bean validation might not be needed.

It can be more useful for the cases where the proxies are collecting the data from the databases or some other external sources - using the bean validation check to minimize the risk of posting some not well initialized data can indeed help.

I'd like to thank Johannes Fiala for encouraging us to have this feature implemented.

Friday, October 21, 2016

Fediz OIDC Story will continue at Apache Con EU 2016

ApacheCon Europe 2016 will be held in Seville Spain, Nov 16-18, with Apache Big Data starting on Monday Nov 14.

Colm and myself will continue talking about Fediz OpenId Connect following our presentation earlier this year.

Would you like to hear about our continuous effort to make the development of OpenId Connect applications with the help of Apache CXF OIDC, OAuth2 and JOSE code nearly as easy as writing a simple JAX-RS server and contributing to the idea of making OIDC going mainstream ?

Interested in making your own application server going OIDC way but concerned about the development costs ? See how Fediz IDP became OIDC-ready fast.

You are interested in the WEB security, and thinking about  where to start contributing to ?

Join us :-).  At the very least join all of us, listen to many interesting talks from my Talend, CXF and Apache SF colleagues. See you there !

Thursday, September 29, 2016

CXF JAX-RS 2.0 - Perfect HTTP Spark Streaming Connector

Even the most conservative among us, the web services developers, will be better off admitting sooner rather than later that Big Data is not something that can be ignored, it has become a major technology in the software industry and will continue becoming even more 'influential' with the Internet of things wave coming in.

Where will it place your typical HTTP service which GETs some data for the users from some data store or accepts some POSTs with the new data ?

While I'm somewhat concerned seeing BigData consumers collecting the sources via a variety of custom optimized protocols and low-level transports like TCP, I firmly believe HTTP connectors should and will play a big role in connecting the WEB users with the Big Data processing chains.

HTTP, being so widely used, is a perfect frontend to the local networks where the nodes process the data, and while HTTP is synchronous for a typical interaction, JAX-RS 2.0 REST services can be quite smart. A variety of typical REST patterns can be employed, for example, a POST request handler with the data to be run through a BigData chain can let the application thread deal with it while respond to the user immediately, offering a link with a job id where the status can be monitored or the results returned from.  Or the handler can rely on the suspended HTTP invocations and start streaming the results back as soon they become available.

I have created a Spark Streaming demo showing some of the possible approaches. This demo is a work in progress and I will appreciate a feedback from the Spark experts on how the demo can be improved.

The demo relies completely on JAX-RS 2.0 AsyncResponse - the typical pattern is to resume it when some response data are available - and what is good it can be suspended multiple times to do a fine grained optimization of the way the service code returns the data. StreamingOutput is another piece - it allows writing the data back to the user as soon as they become available.  FYI, CXF ships a typed analog, called StreamingResponse, you can see how it is being indirectly used in this RxJava Observable test code.

But let me get back to the demo. It shows two types of Receivers in action.  This demo service shows how an HTTP InputStream can be converted to a List of Strings with a custom Receiver making them available to Spark. The service currently creates a streaming context per every request which I imagine may not be quite perfect but my tests showed the service performing quite well when the input set is parallelized - less than a sec for a half of MB PDF file.

Speaking of PDFs and other binary files. One of the service methods uses a beautiful Apache Tika Parser API which is wrapped in this CXF extension. These few lines of code is what it takes to have a service enabled for it to push the content of either PDF or OpenOffice documents to the Spark pipeline (I only added PDF and OpenOffice Tika Parser dependencies to the demo so far). I'm sure you are now starting wondering why Tika API is still not used in your JAX-RS services which parse PDF only with the PDF specific API :-)

I keep getting distracted. Back to the demo again. This demo service is a bit more closer to the real deployment scenario. It uses a default Spark Socket receiver - JAX-RS 2.0 service, being a good HTTP frontend, forwards the HTTP stream data to the internal Spark Streaming TCP server which processes the data and makes them available to a JAX-RS AsyncResponse handler which is also acting as a Socket server. The correlation between a given HTTP request and the Spark output data is achieved with a custom protocol extension. I can imagine it will be easier with an internal Kafka receiver which is something that the demo will be enhanced with to try later on.

In both cases, the demo streams the response data pieces back to the user as soon as they become available to the JAX-RS AsyncResponse handler.

Additionally, the demo shows a CXF JAX-RS Oneway extension in action. HTTP Client will get a 202 status back immediately while the service will continue with processing the request data.

I'm sure the demo will need more work but I also hope there's enough material there for you to start experimenting. Give it a try please and watch for the updates. I think it will be very interesting to see how this demo can also be written with Apache Beam API, check this blog entry for the good introduction.

Enjoy ! 

Progress In The JAX-RS 2.1 space

For those of you thinking what is going to happen to JAX-RS a good news is that JAX-RS 2.1 will live, surely it was the only possible outcome given the quality and the popularity of JAX-RS 2.0.

Check out this Java One 2016 Key Note, and I will continue standing by my assertion that even more is to come from JAX-RS.  

As far as Apache CXF is concerned, Andriy  has been working hard on a JAX-RS 2.1 branch where he implemented a 2.1 Server Sent Events API. And after Marek released the very first JAX-RS 2.1 API artifact to Central Andriy merged his work to the CXF 3.2.0 master branch.

It is very good because we can now start working toward releasing CXF 3.2.0 with this early JAX-RS 2.1 API to be implemented for the CXF users to experiment with - JAX-RS 2.0 users will be able to migrate to CXF 3.2.0 without changing anything in their services code.

The new JAX-RS 2.1 features (SSE, NIO and Reactive Invokers, with the early API improvements likely to happen during the coming specification work) are cool and it is worth taking the hats off to the engineering minds of the Jersey team for the top work they did.

Wednesday, September 28, 2016

[OT] Become Most Enigmatic Person in The Office - Discover CXF

Going the winding Apache CXF path is not that scary for a web services developer - some features may not be there just yet but you may discover something new instead, while helping driving the CXF forward along the way.

Have no fear, answer the call, help your team discover what Apache CXF really is. And become the most popular and enigmatic person in your office :-)

Tuesday, August 23, 2016

SwaggerUI in CXF or what Child's Play really means

We've had an extensive demonstration of how to enable Swagger UI for CXF endpoints returning Swagger documents for a while but the only 'problem' was that our demos only showed how to unpack a SwaggerUI module into a local folder with the help of a Maven plugin and make these unpacked resources available to browsers.
It was not immediately obvious to the users how to activate SwaggerUI and with the news coming from a SpringBoot land that apparently it is really easy over there to do it it was time to look at making it easier for CXF users.
So Aki, Andriy and myself talked and this is what CXF 3.1.7 users have to do:

1. Have Swagger2Feature activated to get Swagger JSON returned
2. Add a swagger-ui dependency  to the runtime classpath.
3. Access Swagger UI

For example, run a description_swagger2 demo. After starting a server go to the CXF Services page and you will see:

Click on the link and see a familiar Swagger UI page showing your endpoint's API.

Have you wondered what do some developers mean when they say it is a child's play to try whatever they have done ? You'll find it hard to find a better example of it after trying Swagger UI with CXF 3.1.7 :-)

Note in CXF 3.1.8-SNAPSHOT we have already fixed it to work for Blueprint endpoints in OSGI (with the help from Łukasz Dywicki).  SwaggerUI auto-linking code has also been improved to support some older browsers better.

Besides, CXF 3.1.8 will also offer a proper support for Swagger correctly representing multiple JAX-RS endpoints based on the fix contributed by Andriy and available in Swagger 1.5.10 or when API interface and implementations are available in separate (OSGI) bundles (Łukasz figured out how to make it work).

Before I finish let me return to the description_swagger2 demo. Add a cxf-rt-rs-service-description dependency to pom.xml. Start the server and check the services page:

Of course some users do and will continue working with XML-based services and WADL is the best language available around to describe such services. If you click on a WADL link you will see an XML document returned. WADLGenerator can be configured with an XSLT template reference and if you have a good template you can get UI as good as this Apache Syncope document.

Whatever your data representation preferences are, CXF will get you supported.