Sergey Beryozkin

Advanced queries involving multiple entities

Sergey Beryozkin - Thu, 07/19/2012 - 13:25
As I've mentioned a number of times, FIQL can help with expressing the advanced search conditions in a compact and easy to understand syntax.

The queries like "find all the books published before a given date" are very easy to type in FIQL and extending this query with a restriction like "and having the page count between 80 and 100 pages or less than 20" is quite straightforward too, manually, or with the help of the client FIQL builder.

However, what if one would like to do a query involving multiple entities, for example, "find the library in a preferred location where all the books published before a given date and written by more than 2 authors are available" ? Or imagine or more interesting query if you'd like.

This bit, "where all the books published before a given date and written by more than 2 authors" is an easy one to support with the CXF search extension. The question is, how to structure the advanced query such that Book entities matching the arbitrary complex query are selected first and then a Library entity is checked per every Book on whether it matches its own selection criteria or not.

Another question is how to express the requirement that it is actually "the list of books",  "published before a given date and written by more than 2 authors and available in one of the libraries in a preferred location", that has to be returned to a user.

As you can see, there are at least two main requirements to deal with. First one is how to let users choose which entity (among a number of entities being matched) is actually returned which affects the response representation. Second one is how to do an advanced query involving multiple entities at the level of the JAX-RS application handling such a query.

The good news is that the first requirement can be easily managed with the help of URI path and/or query components. For example, an expression like "/books[date=le=2012-02-11]/library" can be used to find all the libraries having the matching books, and the one like "/library(dist=lt=10;dist=gt=5)/books(date=le=2012-02-11)" can get all the books matching a given search criteria available in a library within a 10 km range from some well-known location (such as the city center) but not closer than 5 (given that the parking is not free within a 5 km range).

It is really up to the designer of the service how to get the actual expressions captured, which characters to use to mark them, example "[" and "]", "(" and ")" or ";" and how to support the selective retrieval of the entities involved in the multi-entity search. See this section for more examples.

Yet another good news is that a complex multi-entity query can be managed pretty easily at the JAX-RS resource level, see this section for a number of options on how it might be done. Note how multiple FIQL expressions can be handled.

What is mentioned there is that it can be more optimal to get say JPA to execute a JOIN like query at a database level in one go as opposed to getting it to find a list of entities matching the first FIQL expression, then doing the follow-up in-memory match against the selected entities.

Right now CXF can not automate the process of creating a JPA TypedQuery or SQL expression which can 'span' the multiple entities - this is the next task, and in meantime please experiment with the demonstrated approach and see how it fares against the one involving the composite JOIN-like queries. Alternatively, introspect the captured search conditions as shown in this section and build a composite query in the code.

Please also have a look at the OData4J project and check how the advanced queries can be managed there. 

Finally, I'd like to answer on the following question: why one would worry about offering such a search interface to users, would it not be simpler to offer a Google-like search interface where one enters a few words and gets the list of matching data pages ? I think that when one creates a service for exposing the data with the known properties and relationships, the opportunity is there to offer an optimized search engine for users to get the customized search experience.







Categories: Sergey Beryozkin

JMS Transport support for CXF JAX-RS clients

Sergey Beryozkin - Tue, 07/10/2012 - 14:25
I blogged about the support for JMS by CXF JAX-RS endpoints two years ago.

The main reason behind making the JAX-RS frontend (associated by most users with supporting HTTP-based communications) JMS-aware was to do with getting the most from the 'investment' made into implementing the RESTful services on top of CXF JAX-RS.

If one has the resource code relying on the JAX-RS runtime to make the inbound data delivered to the right method and easily consumable in the form of a given JAXB bean instance, then the possibility is that this code can work equally well when the data comes to this resource handler either via HTTP or JMS or indeed some other transport, example, CXF Local Transport.    

CXF is super-flexible in the way it can support multiple transports, and it does make sense to get JAX-RS based endpoints optionally supporting non-HTTP transports.

And it is exactly for the same reason that CXF JAX-RS proxies (and I have to admit, WebClient :-) - simply because proxies and WebClient are using the same base code) also optionally support JMS transport now, thanks to the contribution from Willem.

So why would one want to use CXF JAX-RS client code with JMS ? As noted above, it is primarily about making the same code, client one in this case, re-usable in different contexts. I could've noted again that REST principles can probably be applied even to RS-232 endpoints if really really needed :-) but I'd rather focus on the re-usability aspect.

For example, consider a newly introduced HTTPSPStateManager implementation for making it easy for users to quickly set up a centralized distributed SSO cache endpoint. You've tested it and seen it working with HTTP. Now the time has come up for you to move to a more sophisticated distributed cache implementation for it to scale really well in the production. But then you realize that by simply getting HTTPSPStateManager proxies and the endpoint addresses use  a JMS scheme you can get an entirely different cache support, still using the same configuration, so you are going to give it a go and see what happens.

Or perhaps you have a Camel JAX-RS endpoint, supported by Camel transport and jaxrs:endpoint or CXFRS bean or endpoint, supporting both HTTP and JMS. It would be cool to get the same Camel CXFRS client to be able to talk to the endpoints using either HTTP or JMS.

I'm hoping users can come up with more interesting cases which will be possible thanks to the optional end-to-end support for JMS in the JAX-RS frontend.

Enjoy!    








Categories: Sergey Beryozkin

How to test CXF JAX-RS endpoints

Sergey Beryozkin - Tue, 07/10/2012 - 12:54
Users have been asking during the last couple of years how to test CXF JAX-RS endpoints. One of the users from the CXF community would always point to either a blog entry or paste a code example showing how the endpoints can be tested easily enough.

The problem has been all the time that there was no any documentation on the CXF JAX-RS wiki specifically describing the steps required to get the tests set-up and running.

A new wiki page has been added recently and it documents how the endpoints and indeed the consumers can be tested easily by using either the embedded Jetty or the newly added support for CXF Local Transport. The latter option is quite cool is that it does let to test the complete end-to-end invocation without spending the time on setting up HTTP mocks, by only having an address value to include a "local:" URI scheme.

This wiki page will be expanded to show how the tests can be run in the different test environments. Let us know please if you have some material ready to be contributed to the wiki :-)
Categories: Sergey Beryozkin

From FIQL expressions to typed JPA queries

Sergey Beryozkin - Wed, 06/27/2012 - 11:46
Imagine you are working on the RESTful service implementation that relies on JPA2 but having a bit of a difficulty coming up with an interface that can neatly let users search the service data with queries allowing to express something more interesting than just "find all the data that have a given property equal to a given value".

Yes, FIQL is fantastic and its ability to express complex queries in a fairly simple and compact way is hard to beat.  CXF  offers an option to convert the captured FIQL expressions to other query languages and representations and now JPATypedQueryVisitor for converting FIQL queries to JPA2 TypedQuery or CriteriaQuery objects has been introduced. This can help users with creating typed JPA2 queries easily and getting the most of their JPA2-based services.

Major thanks to Jeff Wang for driving this enhancement with his contributions.

Next we will try to support hierarchical queries, for example, find all the chapters with a given content from books with a given set of properties or find all the books with the given properties that only have the chapters with a given content, etc. You can expect other useful converters, example for Casandra CQL and Lucene query languages, being added in time. Finally, the support for the alternative URI query languages is also on the map.

Watch this space :-)
Categories: Sergey Beryozkin

SAML Web SSO for CXF JAX-RS endpoints

Sergey Beryozkin - Mon, 06/25/2012 - 17:34
Last week Colm announced that support for SAML Web SSO profile was available starting from CXF 2.6.1. 

We have also created a new CXF wiki page dedicated to describing the way the CXF JAX-RS applications can be protected with SAML SSO filters.

Colm has done a comprehensive testing against many popular IDP implementations which support SAML SSO and we believe that CXF offers one of the most configurable and interoperable SP SAML SSO implementations, even at this early stage.

I think it is a pretty major milestone for CXF JAX-RS and for CXF Security overall. CXF already offers a production quality WS-Trust STS implementation, Oliver has just finished the first release of Fediz. Having  a quality Service Provider SAML SSO support will help users get CXF JAX-RS endpoints integrated with the enterprise security services which is very important.

This SSO support and other SSO implementations to be supported by CXF will also make it easier to build more distributed OAuth2 applications.

We are planning  to work on a demo demonstrating SAML Web SSO in action. Stay tuned :-)




Categories: Sergey Beryozkin

RESTful Data Updates with Talend Studio

Sergey Beryozkin - Fri, 06/01/2012 - 15:21
I created a presentation few months ago which showed how one can create a simple DB browser for exploring the arbitrary databases using Talend Open Studio for ESB.

The Customers DB explorer we created last time was supporting GET queries allowing to return the list of all the customers and the individual customer records.

I've worked recently on enhancing the job that we created last time for supporting more involved GET queries as well as data updates with POST, PUT and DELETE verbs. The presentation is available here.

The demo shows the original ReadCustomers DB job, as well as ReadCustomersAndOrders one which additionally manages GET requests for all the orders of the individual customers and the individual orders only.

The CRUDOrders  job shows how to create the new orders for specific customers, update and delete the existing orders, and query the list of all the orders for all the customers. Check how easy it is to configure the job to return a status like 400 in case of attempting to add an order for a non-existent customer.

Note that in this demo I did not really focus on showing how the individual jobs can be created from scratch, in order to keep it shorter in time. There are many other presentations available from Talend Channel, in series like this one, which show how various Talend components can work together, please follow one of those presentations or this one to get more information about it.

In this demo I really wanted to highlight that REST components can manage different HTTP requests (queries, updates, etc), with different, possibly overlapping URI paths and data payloads.

The tRESTRequest component linking HTTP verbs and URI templates is based on the JAX-RS matching algorithm and you can see how flexible the configuration can be, with as many capturing templates as needed added to the relevant HTTP mappings.

More work will be needed for it to support the richer set of media types, in addition to XML, JSON and forms. More flexible support for identifying newly created resources will be needed too.  We will be showing the relevant presentations in time.

I'd like to encourage those who are interested to play with creating RESTful jobs and provide us with the feedback.

In meantime I'll work on creating a demo showing how a RESTful job can be packaged as an OSGI bundle and deployed into Karaf with HTTPS and Basic Authentication supported by the container.

Stay tuned !
Categories: Sergey Beryozkin

Controlling Large Payloads in CXF

Sergey Beryozkin - Wed, 04/25/2012 - 12:11
You may have already read that so called hash-collision attacks may affect many of the existing Web applications. A massive form, XML or JSON payload with specially constructed keys can be posted to the service and cause the denial of service situation due to the fact many of XML, JSON or form payload processors depend internally on the map implementations that are not capable of dealing with such data effectively.

It does not have to be a specially ill-prepared payload. Huge XML or say multipart/form-data application payloads with open-ended list of child elements or parts may significantly slow down the services too.

There has been a number of announcements from the major projects on the workarounds that may need to be taken, for example, please check this Tomcat issue.

Security has always been and going to be  a major story in Apache CXF and obviously we spent some time on making sure CXF endpoints can be adequately protected in such cases too.

For a start, we followed the Tomcat's lead and introduced a "maxFormParameterCount" endpoint property then can be used to restrict a number of form name/value pairs passed in the HTTP POST body.

We also introduced a DepthRestrictingStreamInterceptor that can be used to enforce a number of limits on the incoming XML payloads such as: the total number of elements, the maximum number of child elements and the maximum stack level. More fine-grained, element-specific limits may be supported in the future. Note it was already possible to protect CXF WS endpoints with the relevant system properties before the introduction of this interceptor.

Additionally, CXF JAX-RS endpoints and JAXB-based providers can be individually configured with the limits that will be imposed on the incoming payloads. Note that even JSON payloads can be controlled by the default Jettison-based JSONProvider.

HTTP 413 will be returned whenever the limit is reached.

Finally, as has already been mentioned on this blog, we had a high-quality contribution which made it possible to control the attachment limits by using an "attachment-max-size" property.

Please check the CXF Security and JAX-RS DataBinding sections for more information, test with the recently released CXF 2.6.0, 2.5.3, 2.4.7 and 2.3.10 distributions and provide the feedback.

Categories: Sergey Beryozkin

Custom JAX-RS Contexts in CXF 2.6.0

Sergey Beryozkin - Fri, 03/30/2012 - 10:49
CXF 2.6.0 is due to be released soon, with several new features likely to get the developers interested.

CXF is about to become much more OSGI-friendly which will open the way for many new interesting enhancements to come thanks to Dan and Christian leading this major refactoring effort.

The JAX-RS frontend has benefited (as usual :-)) from the core CXF improvements. One of the positive side-effects was that the initial go at splitting the fairly big JAXRS module was attempted.

Most of the optional JAX-RS providers were moved with all their optional dependencies to the new cxf-rt-rs-extension-providers module, Christian's refactoring of the clustering feature helped to drop the JAX-RS specific extension with JAX-RS clients now being able to use same fail-over feature configuration as their JAX-WS brothers :-), and the code to do with the WADL to Java code generation made its way to its real home, the cxf-tools-wadlto-jaxrs module. The CORS code now lives in cxf-rt-rs-security-cors, it needs to as enforcing the CORS across multiple servers will very likely require more enhancements to the current filter and the couple of annotations.

Finally the FIQL search extension code got moved to the new cxf-rt-rs-extensions-search module. I think this extension has a lot of offer and more enhancements will start coming in sooner or later due to the power and simplicity of FIQL.

Moving the FIQL code presented a challenge, how to get the core JAX-RS frontend to populate the SearchContext offering an optimized access to the FIQL queries ? The name of this custom JAX-RS Context class is hard-coded within the frontend in the earlier CXF versions but with the extension now moving away it was not an option any more.

The new ContextProvider extension was to be the answer I was looking for and here is the implementation which creates a SearchContext instance by relying on the CXF Message class which has all the information about the current request. The last thing that needs to be done is to get the ContextProvider registered with JAX-RS endpoints.

It is actually quite a major enhancement, now the users can inject whichever contexts they like. For example, JAX-RS 1.1 HttpHeaders context offers a number of utility methods for accessing the HTTP headers. Lets say you'd like to help the application developer to handle Origin headers but HttpHeaders can not help. Well, write a custom OriginHeader ContextProvider, extract the Origin out of the message and make it really easy for the application developer to access various Origin parameters. You can use ContextProviders whenever you'd like to offer an optimized access to some of the information available in the current request.

I believe Jersey was offering a similar extension probably from the very early start. One can not deny Jersey was an absolute star :-) at the start of the JAX-RS, and they continue to be the major JAX-RS implementation, but CXF just keeps catching up even though it took us a bit of time to get to the ContextProvider.

Note ContextProvider looks similar to JAX-RS ContextResolver but they actually serve different purposes with the latter meant to simplify processing the data possibly involving the custom media types, see this method. I believe it was originally introduced to handle custom JAXBContexts. After thinking a bit about reusing ContextResolver I decided not to in order to avoid possible conflicts.

Finally, having to register the ContextProvider providing SearchContext instances led to another enhancement request. In CXF one needs to explicitly register custom JAX-RS providers and I believe it works well most of the time due to the flexibility offered by the explicit configuration approach. However, having an option to get simple basic providers auto-discovered would be useful too - thus a new enhancement request to support the optional class scanning is now pending.

It is always useful to refactor and simplify code - more often than not it has the positive side-effect of the new features added :-)
Categories: Sergey Beryozkin

All Roads Lead to Mainz

Sergey Beryozkin - Tue, 03/27/2012 - 17:36
They say all the roads lead to Mainz. Indeed, this year it is the home to JAX-2012, a very popular conference for Java developers in Germany.

The Talend team which includes Bernd Trops, Principal Consultant with Talend, Christian, Oliver and myself will be there. We are going to present few sessions during the Apache Integration Day on 18th April, so be there if you can :-)

I'm a bit nervous given that my German is not perfect :-), but with Bernd, Christian and Oliver all talking German I should be fine :-)
Categories: Sergey Beryozkin

Simple DB Browser in Talend Open Studio

Sergey Beryozkin - Tue, 02/14/2012 - 18:19
The screen-cast showing how to create a basic DB browser within Talend Open Studio is now available on the Talend Channel.

This presentation is more involved than the one showing how to create a simple REST endpoint. This time a basic database containing a list of customer records is exposed via HTTP and we go through a number of steps showing how the task of creating an arbitrary DB browser can be approached.

Initially the complete list of records is returned and then the optimized one containing smaller records but with links pointing back to complete individual records is returned.

What are we going to present next is the job which also supports the various data updates with a bit more complex database involved. Some options for dealing with exceptions will be shown. I haven't mentioned that JSON is also supported by default so we'll show the way it is supported out of the box too.

As I've already mentioned before our REST Tooling project is an ongoing effort and there will be quite a few things enhanced and improved over the near future. We are brainstorming with my colleagues various ideas such as how to make it feasible to bind the data to views in the most transparent way, how to secure the services, how to make the integration with other Talend components more complete, etc.

So I expect us producing quite a few exciting demos over the time :-)

In meantime, please view the presentation and provide us with the feedback.
Categories: Sergey Beryozkin

Distributed OSGi RI 1.3 is out!

Sergey Beryozkin - Tue, 02/07/2012 - 13:37
The signs are that the fortunes of Distributed OSGI are looking good.

Distributed OSGI RI based on Apache CXF (Apache CXF DOSGi RI) has been around for a while, and quite a few OSGI developers have experimented with and built custom applications on top of it successfully.

However, it's been more than a year since DOSGi RI 1.2 has been released and this project has been inactive recently. In meantime, two more Distributed OSGi implementations have been announced by two OSGI heavyweights, one by my colleague JB, and another one by Guillaume Nodet.

Now, as far as Apache CXF DOSGi RI is concerned, we are seeing users asking the questions quite regularly and this is a sign this implementation and the whole idea of the Distribured OSGI is of interest to some OSGI developers, more on it below.

So after getting some of issues reported against DOSGi RI 1.2 for the last couple of months, we have released Apache CXF DOSGi 1.3. Please see the release notes for more information (note there is a minor typo in the release notes, it is CXF 2.5.2 which this release is based upon, not CXF 2.5.1).

The major improvement in this release is that it is now possible to register custom CXF interceptors (pre-configured if needed) as service properties with the underlying JAX-WS and JAX-RS frontends.

WSDL-first approach is also supported now which is a good news for SOAP developers, see this project for an example. Of course, the JAX-RS frontend was trying to offer something similar :-), so a new org.apache.cxf.rs.wadl.location property has been added. Please see this updated page for more information on all the new properties.

If you are an existing user of the DOSGI RI then please try this new release.

If you have never tried it and wonder what is the story with DOSGI then try it too. DOSGI RI is quite sophisticated in that not only the basic endpoint and consumer creation is supported but also a mechanism for the distributed discovery is wired in.

But it is this fact that the OSGI programming model is used to drive the creation of the web service endpoints and consumers which is appealing to some developers and that is what one should focus upon first when experimenting with DOSGi.

If you think about it, the way to create a new web service endpoint or stop the old one in OSGI is typically to deploy a new bundle or stop the existing one from the shell or possibly from the UI management console. I guess it is quite rare that the custom application bundle will deal with updating the bundles itself.

In DOSGI, the creation if web services endpoints and consumers is actively driven by the typical OSGI BundleContext and ServiceTracker calls. If this style of managing the web services indirectly by the custom application registering or looking for OSGI services does appeal to you then DOSGI could become a perfect fit for your project.

In DOSGI 1.3 we fixed some basic blockers to get the project active again. The future releases will likely focus on making the distributed discovery working really well and also on improving the way the custom configuration can be applied.

One more thing which I'd like to mention is that if you are interested in OSGI in general and possibly in DOSGi and looking for a way to get involved in the open-source project and make a difference then please think of contributing to this project.
Categories: Sergey Beryozkin

OAuth without the end user explained

Sergey Beryozkin - Mon, 01/30/2012 - 18:13
One is the most confusing things in OAuth is a so-called 2-leg OAuth flow where an explicit authorization step involving the end user pressing an Allow or Deny button is not taken.

There are many resources on the web explaining what is an OAuth 2-leg flow. Most of those explanations are effectively describing the process where the 3rd party consumer accesses its own space on the resource server, possibly with the end user itself 'hiding' behind such a consumer.

But the classical OAuth is about the 3rd party consumer being able to access one way or another the resources of the end user. How does a 2-leg flow gets into the picture ?

Please read this blog entry. This is the best explanation I've seen so far and it was so good I had to stop doing my current task immediately and quickly update the CXF OAuth 1.0 code to be able to handle all the variations of the 2-leg flows better.

I think this 'pure' 2-leg flow described by Andrew is really close to a client credentials flow in OAuth 2.0. Without a pre-authorized access token (authorization code) the options are limited for a 2-leg flow.

Please see the updated documentation for more information on how CXF supports OAuth and its 2-leg flows in particular.
Categories: Sergey Beryozkin

Make your Application Server CXF JAX-RS friendly

Sergey Beryozkin - Thu, 01/26/2012 - 13:06
Now and then I'm seeing users reporting issues on the forums to do with deploying web applications with CXF JAX-RS libraries into some of the popular Java EE application servers.

So I thought, while investigating a problem reported on the CXF users list to do with using a CXF Redirection feature in WebLogic, that it was also worth giving it a try and experimenting with deploying a complete OAuth demo web application packaged as a war archive that we are working upon into several popular application servers.

Initially I focused on testing Glassfish, JBoss and WebLogic and you can see the notes on how to overcome various deployment issues here.

It was a rather interesting exercise and I had few observations at a time.

WebLogic was the simplest to work with, as far as deploying the application was concerned without having to tweak anything at the container level. The management console of WebLogic is quite sophisticated and seems like this application server is still very capable. I only had to tweak the servlet configuration to get a CXFServlet using a wildcard URI pattern redirecting to WebLogic specific JSP engine properly as advised by the user who reported the issue.

Glassfish is OSGI-enabled and it was interesting to see Apache Felix serving as the default OSGI framework, which is a good news for the OSGI community at large, as it should drive the fixes back to this Apache project.

I had hard time though getting past the Jersey filter trying to deal with this application - it was failing eventually due to it not able to inject a CXF-specific JAX-RS Context instance. I only managed to get it work after removing one of Jersey jars from the available libs - one would only have to do it or may be something simpler :-) if the war has JAX-RS Application implementations and the OAuth demo has 5.

JBoss 7 was easy enough to deploy to. RestEasy also tries to load Applications but it was much easier to deal with it in JBoss. As a side note I thought the way JBoss 7 managed to move away from having to dump all the libs into common folders was very impressive. It is somewhat similar to the Apache Karaf's features mechanism, with Karaf having the repository of libraries and features linking those libraries together. In JBoss the repository itself has some additional metadata.

One thing I thought about after finishing this exercise was that the fact that the deployed applications are eagerly scanned for JAX-RS interfaces exposes a possible issue with these scanners. And the issue is that these scanners need to check if a deployed war contains a /META-INF/services/javax.ws.rs.ext.RuntimeDelegate resource or not and if it points to some alternative implementation then just leave this web application alone.

It would make it simpler not only for CXF JAX-RS users who may want to work with Glassfish or JBoss but for Jersey and RestEasy users too who may want to try the containers where either of this popular implementations is not natively supported. Besides, it would meet the general expectation that a self-contained war should be deployable to any Java EE container.

In meantime, please consider contributing the tips to this section. The tips in the WebLogic section have been provided on the CXF users list, so please keep them coming.
Categories: Sergey Beryozkin

CORS Support in CXF

Sergey Beryozkin - Fri, 01/20/2012 - 11:07
Cross-Origin Resource Sharing (CORS) is a W3C specification (Working Draft) which "defines a mechanism to enable client-side cross-origin requests". Please see the Introduction for more information.

We had several users asking questions about how CORS could possibly be supported in CXF. Then at some point of time a mysterious :-) sergkorney offered his help with prototyping an initial code for a CORS filter, and the process moved forward.

Benson took charge and wrote a comprehensive and well-documented filter implementation which follows the specification very closely.

This filter can do the preflight and simple request checks. It interacts with the JAX-RS runtime by relying on its selection algorithm to confirm that an application has a resource method which is capable of dealing with the current request in cases when the filter does not block. If a JAX-RS resource method which can handle the HTTP OPTIONS verb indicates via a dedicated annotation that it will handle the preflight check, then the filter will delegate to it. JAX-RS root resources and individual methods can be customized for them to take part in the CORS process.

It is likely to grow into a more complex security feature in time.

Please review this initial documentation (with the link to the package.html), start experimenting and provide the feedback.
Categories: Sergey Beryozkin

RESTful endpoint in 60 seconds in Talend Open Studio

Sergey Beryozkin - Wed, 01/11/2012 - 14:42
I briefly mentioned in the end of this this post that we are working on the tooling for creating RESTful endpoints in Talend Open Studio for ESB.

I'd like to offer to your attention my first screen-cast available on the Talend Channel. It shows how one create and test a basic HTTP Service endpoint echoing the POST payload back to the client. I timed it all for some fun, so it actually did took me 60 seconds to create a service and about 60 seconds to test it.

Of course one would spend much more time on developing a more involved service but the idea was to give you a glimpse of how easy you can create a RESTful service as well as to point to the flexibility of the tooling as far as wiring the extra components in is concerned.

Future presentations will show how to create more involved services, those supporting multiple HTTP verbs, with more components facilitating the access to the real data.

Please listen to this short presentation, download the Studio and try creating your own HTTP service and also check what it offers with respect to working with SOAP services and Camel routes.

Oh yes, one more thing, if you are into languages and you'd like to hear what an Irish-Belorussian accent is about :-), then please listen indeed to this screen-cast

Enjoy !
Categories: Sergey Beryozkin

Maven archetype for creating CXF JAX-RS applications

Sergey Beryozkin - Fri, 01/06/2012 - 12:42
A number of Maven plugins that CXF JAX-RS users could try for generating the initial code they could build upon for creating working applications was close to zero not too long ago, in fact it was actually 0.

Then we added a wadl2java plugin so the numbers started to look better :-).

And now starting from CXF 2.5.1 an archetype plugin for creating Spring-based JAX-RS applications is also available, all thanks to Benson.

Please see this page for more information.
The generated project will get the integration tests running too, so having a simple end-to-end application created and tested in less than a minute is really cool.
Categories: Sergey Beryozkin

Jettison 1.3.1 has been released

Sergey Beryozkin - Thu, 12/29/2011 - 16:48
Jettison 1.3.1 has just been released, please see this page and the Download page for more information about the latest fixes.

The two updates which would be of interest to CXF users (or those who rely on other stacks that ship the providers wrapping Jettison) are to do with making it possible to create formatted JSON outputs and making sure that the ignorable (empty) text content (reported by JAXB when processing the mixed content data) is blocked. The latter update, among other things, will make the WADL JSON representations look nicer given that they are produced from the wrapped XML payload.

Few other improvements made it into this release too, particularly those JIRAs which had the patches attached to them have been resolved.

I'd like to encourage the Jettison community to continue providing patches and as far as I'm concerned I can say that the patches will be eventually applied and the fixes will make it into the the future Jettison releases.

Happy New Year !
Categories: Sergey Beryozkin

Associating user login names with OAuth Access tokens

Sergey Beryozkin - Mon, 12/12/2011 - 18:25
The classical OAuth flow involves the authorized 3rd-party client magically accessing the end user's resources without even specifying a user name or id, for example:

GET /user/calendar

How can the server figure out which resource to return ? The answer is that the request will have an Authorization header with an access token key and in OAuth 1.0 the token needs to get the information about the end user authorizing a given 3rd party consumer associated with it at the authorization time.

With this association in place, the server will have an easy way to get to the name or id of the user used to authorize the client, and the way to do it in soon to be released CXF 2.5.1 is documented here.

I'd like to thank Glen for helping me with getting this enhancement done.

We are continuing working on the demo which will show most of the CXF OAuth support in practice. Please stay tuned to see how you can write secure OAuth applications with CXF :-)
Categories: Sergey Beryozkin

Locator Support For RESTful Services in Talend ESB

Sergey Beryozkin - Wed, 12/07/2011 - 11:26
Back in June I blogged about CXF JAX-RS providing a fail-over support for RESTful Java clients and mentioned some relevant work started in Talend.

Things are happening in the Talend land where all the interesting new features in Apache projects that our Coders team is contributing to are taken on board, analyzed and wired in the products real fast. And the newly released Talend ESB 5 brings a Locator support for RESTful endpoints and clients with the client-side Locator feature built on top of the CXF fail-over mechanism. Kudos to the ESB team for implementing it.

If you get a working HTTP-centric code then having such a code not hard-coding the endpoint address of the RESTful server which is part of the large WEB application and seeing it working even after a given server or the HTTP connection to it goes down will be encouraging.

Are you all into writing large RESTful applications end-to-end ? Have problems answering to your friends who like working with SOAP (they are still your friends though :-)) and tell you that with REST it's not possible to write Locator-aware fail-over capable clients ? If the answer to either of those 2 questions is yes then go to a new Talend web site, download Talend ESB v5, get to /examples/talend/tesb/locator-rest and proceed from there.

One thing I should mention is that Talend Open Studio for ESB is also available for download, it builds on top of Talend Data Integration suite and offers a second-to-none UI support for developing web services and routes. If you work with CXF SOAP Web Services or Camel then you probably won't be able to get back to your old UI tools after trying Talend Open Studio for ESB.

And the good news is that we are working on bringing the users a tooling for developing RESTful applications. It is a work in progress but it's happening, stay tuned !
Categories: Sergey Beryozkin

Observations about Maven Central Search URIs

Sergey Beryozkin - Wed, 11/23/2011 - 14:30
I was using a Maven Central Search Engine to find a Google GWT artifact. The search engine is very useful, no doubt about it. I then somehow got focused on the actual URI which identifies the specific GWT artifact I was after:

"http://search.maven.org#search|gav|1|g%3A'com.google.gwt'%20AND%20a%3A'gwt'".

I'm using single quotes just to keep the whole URI expression inside double quotes.

That does not seem like a user-friendly URI to me, and I guess it does not have to be, but I'd just like to analyze it a bit more.

I'm not sure what "|gav|1|" is about, but the main expression (encoded), is really this one:

"g%3A'com.google.gwt'%20AND%20a%3A'gwt'" which reads like this: "find resources with a group 'com.google.gwt' and artifact 'gwt'".

Now compare it with this equivalent FIQL expression which CXF will happily help to handle:
"g=='com.google.gwt';a=='gwt'"

thus giving us

"http://search.maven.org?_s=g=='com.google.gwt';a=='gwt'".

This query a bit simplistic but FIQL does start 'scaling' when we want to use composite queries, for example:

"http://search.maven.org?_s=g=='com.google.com';(a=='gwt',a=='gwt-inject');(v=gt=2.0;v=le=3.0)"

which reads "Find all the modules with a given group, with artifact set to 'gwt' or 'gwt-index' and having versions greater than 2.0 but less or equal to 3.0". It's impressive how FIQL can capture so complex queries in a compact way with a URI which humans can understand. FIQL simply rocks and I encourage users to experiment with it more. By the way, check out the client-side FIQL support, can be handy for building FIQL queries inside the HTML forms.
Categories: Sergey Beryozkin

Pages

Subscribe to Talend Community Coders aggregator - Sergey Beryozkin