It's the end of the summer, still warm outside, and your friends from the Big Data team have millions of millions of records processed per second with Hadoop and give the happy smiles of those who are doing something new and cool. And you have GET, POST, may be PUT, then again GET. Occasional DELETE and if you are really lucky, you've got PATCH in the logs. You are starting wondering, is it really still cool, be a web service developer, does anyone care, what is new here ? Apache CXF has been around for so many years. What is next ?
Keeping a project such as Apache CXF alive and healthy for a long time is not an easy task. Dan, the lead, gave a nice presentation about Apache CXF in Denver, about the work we have done to keep CXF relevant and up-to-date. Dan did not mention it during the presentation: Apache CXF dependencies are always up to date, with the project being constantly aligned, optimized and having the workarounds in place should a given underlying module prove too rigid in supporting CXF in doing what it should do. CXF is a well-oiled, fast web services engine thanks to Dan.
This is all good you may say, but what is next ? What revolution am I talking about ? JAX-WS is not evolving, JAX-RS is not exactly new either. You can even say, CXF is old ? Well, the CXF fire is as alive as ever, the revolution is brewing, CXF is going to get to the next level where it will become one of the de-facto choices for writing new, secure, user-centric HTTP services. The need for such services will only keep growing.
The industry is not sleeping, lots of new exciting technologies are being developed: OAuth2, JOSE, WebCrypto, OpenId-Connect. It's all incredibly cool. It's new. It's only a beginning of the long development life-cycle. Apache CXF wants to be there.
And finally to the [OT] moment: Arcade Fire is fantastic group. Wake Up. Wake Up to the Next CXF Revolution, be part of it, and give your friends that happy smile again ! Tell your grandchildren you were there when it started (LOL while I'm typing it).
Have Fun !
Tuesday, August 19, 2014
Friday, August 15, 2014
Learn JOSE and become a better Web Service Developer
The work around OAuth2 and JOSE in particular has inspired me.
So much that I've ordered several books from Amazon.co.uk - and it's been quite a while since the idea of buying a book occurred to me; and several books in the age of Google ? - see, it did inspire me.
Sometimes we the developers think that we know all and if not all then we think we won't need that extra piece of knowledge, being the experts we are. The software engineering is not easy. We have the deadlines and our regular work to be well taken care of. No time for reading the books: the more busier and older we become the less time we have.
This is why I like OAuth2 and JOSE. JOSE, specifically, is a very fine effort, it represents a set of nicely aligned specifications tackling the various issues related to signing and encrypting the arbitrary payloads and using simple and effective JSON metadata to describe the signature and encryption operations. It's led by the people who understand what they do. JOSE deals only with the best/most trusted/most understood signature and encryption algorithms. It's a set of 'books' about the latest in the cryptography.
It is already starting and will affect the way we do secure HTTP services. I already claimed it in the earlier post about OAuth2 and repeat it again here.
Learn JOSE, understand it, start using it, become a better engineer !
So much that I've ordered several books from Amazon.co.uk - and it's been quite a while since the idea of buying a book occurred to me; and several books in the age of Google ? - see, it did inspire me.
Sometimes we the developers think that we know all and if not all then we think we won't need that extra piece of knowledge, being the experts we are. The software engineering is not easy. We have the deadlines and our regular work to be well taken care of. No time for reading the books: the more busier and older we become the less time we have.
This is why I like OAuth2 and JOSE. JOSE, specifically, is a very fine effort, it represents a set of nicely aligned specifications tackling the various issues related to signing and encrypting the arbitrary payloads and using simple and effective JSON metadata to describe the signature and encryption operations. It's led by the people who understand what they do. JOSE deals only with the best/most trusted/most understood signature and encryption algorithms. It's a set of 'books' about the latest in the cryptography.
It is already starting and will affect the way we do secure HTTP services. I already claimed it in the earlier post about OAuth2 and repeat it again here.
Learn JOSE, understand it, start using it, become a better engineer !
JAX-RS is not only about REST
I've been planning to post this 'philosophical' piece for a while.
The JAX-RS specification (Java API for RESTful services) has really got off the ground long time ago. JAX-RS 2.0 with its new brilliant features, with three JAX-RS 2.0 frameworks around (there will possibly be more, we never know), is and will further contribute to the popularity of JAX-RS.
JAX-RS 2.1 work will go ahead soon enough and it will be another great specification, I've no doubt the spec leads will take care of making that happen, same way they did for 2.0 :-).
The central line of this blog though is that JAX-RS is actually not only about REST. It may sound like a shock to some people but the beauty of this specification is that it has completely re-opened the HTTP web service development space and will continue doing so for quite a few more years to come.
It's an important fact: developers always want to do something new, even though it's a fact that existing Web service technologies has proven to be able to deliver: many many people have written SOAP endpoints that work, many many people have designed endpoints according to REST style, the WEB rules. But REST is not the end of the web services road, it is only a set of proven rules.
We all know many JAX-RS endpoints are not necessarily that RESTful, in a a nutshell they support simple HTTP endpoints, often with 2 HTTP verbs only max - and it is absolutely OK: JAX-RS does and will help no matter how far one would like to go in their HTTP endpoint design.
The JAX-RS specification (Java API for RESTful services) has really got off the ground long time ago. JAX-RS 2.0 with its new brilliant features, with three JAX-RS 2.0 frameworks around (there will possibly be more, we never know), is and will further contribute to the popularity of JAX-RS.
JAX-RS 2.1 work will go ahead soon enough and it will be another great specification, I've no doubt the spec leads will take care of making that happen, same way they did for 2.0 :-).
The central line of this blog though is that JAX-RS is actually not only about REST. It may sound like a shock to some people but the beauty of this specification is that it has completely re-opened the HTTP web service development space and will continue doing so for quite a few more years to come.
It's an important fact: developers always want to do something new, even though it's a fact that existing Web service technologies has proven to be able to deliver: many many people have written SOAP endpoints that work, many many people have designed endpoints according to REST style, the WEB rules. But REST is not the end of the web services road, it is only a set of proven rules.
We all know many JAX-RS endpoints are not necessarily that RESTful, in a a nutshell they support simple HTTP endpoints, often with 2 HTTP verbs only max - and it is absolutely OK: JAX-RS does and will help no matter how far one would like to go in their HTTP endpoint design.
Subscribe to:
Posts (Atom)
