I have a requirement to use Jersey 2 as the Rest interface. I need to adapt this to an existing system which has used CXF to pass in SOAP requests. I know I should use CXF-RS but... it's not what the client wants.
I am auto-generating a WADL from a XML model and using that to autogenerate the resource classes (using CXF, but behind the scenes so to speak), so I really don't want to call a producer template from within the resource class.
So, I have thought that I could wrap the REST resource class in aspects that would capture the necessary information. Looking at it further I realise there are post-processing filters which would give me enough information to fire off a Camel producer template with the appropriate information taken from the resource method in question. That's where I am planning on heading.
And yet: I really want to do something a bit more stasifying and maintainable and reusable by creating a real Camel endpoint to do what I want. A consumer for now. I know this is possible. But my question is - where do I start? How do I map the Jax-RS resource classes to, say an exchange object and the parameters to headers. It seems as if it should be simple but I don't really understand the process by which one can as it were hijack the resource methods into the consumer method in a Camel component. Primarily I want to take advantage of the automatic JAXB conversion from xml to objects that it allows for.
Have a look at this example and see if that helps, basically it exposes a REST endpoint and injects producer template into a bean that calls an activemq endpoint.
Related
I've been reaching wrapped services examples for java and spring and I cannot find anything useful. There are plenty of tutorials for java and spring web services but nothing on wrapped ones
Basically if given 2 wsdls, how can I create a wrapped service? I am hoping there are working examples or even a nice start to finish tutorial to help me out.
i think what you're looking for is like a 'federated service' or a 'business delegate' pattern. that is, one WSDL showing all the methods for the other two WSDL's combined.
one way of doing this is using Spring Integration. with Spring Integration you could expose your 'consolidated' WSDL and then route the various methods to the specific correct actual endpoints. have a look at this in the Spring Integration documents about exposing a webservice and then subsequently routing and invoking others.
Problem Overview
I'm using apache camel 2.4 and have been asked to setup an internal messaging system in one of our maven/spring projects. This may seem a little weird but its because they have plans to separate some functionality out at a later date and want the integration side already covered.
Desired Functionality
Basically I have a bean (A) that does some processing and creates a serializable object. I have another bean (B) that accepts said serializable object and does some additional processing that we want to occur asynchronously.
The plan is to have bean (A) produce a message via the SEDA component of Camel and have it consumed by bean (B) internally.
What I've Done
So far I have implemented this by;
-Creating a RouteBuilder implementation that defines the route.
-Configuring my CamelContext in spring to use said route builder.
-Creating a "producer" class that has the CamelContext as a property and uses this to create a ProducerTemplate with which to send the message. - used by bean (A).
-Defining bean (B) as the consumer (via "bean:beanB" in the configured RouteBuilder).
Question
This works but, being new to Camel, i'm not sure if this is a very good way of implementing the desired functionality. Having looked further at the Camel docs its seems like there's lots of different ways I could do the same thing (configuring the route in spring, rather than defining a RouteBuiler implementation, using the SedaEndpoint implementation, defining the ProducerTemplate in spring and using this as a dependency rather than the CamelContext itself.....).
What would be standard practice / best method for implementing the desired functionality?
you can wire things together various ways, but what you have described is pretty standard...
that said, you might consider the following...
don't create a new ProducerTemplate for each invocation of your producer (reuse it, etc.)
be aware of the expected messaging rates of the producer/consumer and possibly enable multi-threaded consumption using camel-seda concurrentConsumers property
use a newer version of Camel than 2.4 (currently at 2.10.2)
I am early on in a REST implementation and have recently learned that we could be putting our JAX-RS annotations on our Java service interfaces rather than the class implementations.
To me it seems like this could result in a clean class file, but might also result in developers have to constantly muddle between files.
What are the pros and cons of each approach?
You should put it in an interface. Rather, my practice requires me to put it into an interface, because my client and server sides are sharing the same jax-rs definition.
I am inclined to use jax-rs for REST-RPC.
The reason for REST is to allow an web service URL API to be serviceable and "clientable" by any programming framework.
The use of jax-rs restricts us to using java on the server side.
The use of jax-rs for REST-RPC restricts us to using java on both server and client sides.
What is REST-RPC?
In a not too convoluted attitude of explanation, RPC is a way of calling a function/method on the client, which when sent over the wire is serviced by the server such that the same function/method exists on the server side.
RestEasy allows you to use the jax-rs definition on the client-side to call the same function serviced on the server side.
RestyGWT, too, with some modification to the interface to specify a callback method would allow you to (somewhat) use the jax-rs definition on both client and server side. You simply have to write a script to move the return type to the type argument of the callback method.
You might question why restrict ourselves to performing java on both sides? Would that not defeat one of the purposes in life of REST? I think jax-rs REST-RPC is a convenient route to implementing and testing a jax-rs service. If you wanted to implement a jax-rs service, you probably would do it initially in Java on both sides anyway. And then when your service gets off the ground, you could start writing PHP or python clients.
Writing your jax-rs in interface files would allow you to publish your interface for client side operations. This is especially true for REST-RPC. However, you could run enunciate over your jax-rs definition to publish your web service API to non-java programmers.
I have some ongoing rambling on this subject...
http://h2g2java.blessedgeek.com/2011/11/gwt-with-jax-rs-aka-rpcrest-part-0.html.
I think I have to respectfully partially disagree with Blessed Geek here. What is mentioned is a very specific use case which requires the usage of annotations on the interface.
In my own experience, I have encountered cases where the framework either by design or by bug does not respond properly to placing annotations on the interface. For example, Apache CXF does not properly process #PUT requests with #PathParams defined in the path when you place the annotations on the interface. Don't ask me why. CXF is not alone in this; Spring Security suffers from similar limitations in placing annotations on interfaces. So this is a counterpoint to the one mentioned above.
In cases where you are free to choose where to place the annotations, I would urge you to consider what makes sense from a standpoint of intention, design, and ease of development.
As a philosophical argument, some folks say that placing annotations on interfaces is another form of contract programming- you are saying that implementations will abide by certain rules.
The other side of that coin (depending on your definition of interfaces) is that interfaces should not care about what steps their implementors take in achieving the goal defined in the method contract. For example, why place a #Transactional annotation on an interface when you might have two implementations, one of which has no idea what a "transaction" might be?
In practice, the lines blur. In the case of defining a restful endpoint, you may prefer to place the proper annotations on the interface. I think this makes sense in most cases; you probably won't have multiple implementations where the same method signature responds to different HTTP verbs. However you could come up with a situation where different implementations prefer to consume and produce different media types.
So, the big idea here is "it depends." But hopefully this is some food for thought for those who may stumble upon this question.
I had a similar question when using JAX-RS with JAX-B. My hope was to use JAX-B annotations on interfaces not classes. This doesn't work as I expected, the reason is due to the unmarshaller. To solve my issues, I ended up using classes. Here is a description of why and what I found.
I want to access an external RESTFul Web service via Java, and use an open source package that processes the returned XML or Json result and creates object(s) from this data.
I know that there are many solutions out there for this, and I'd like to get your feedback on which one I should use.
For accessing the web services, I know that I can use packages such as apache HttpClient etc. but I'm sure that there are packages that wrap this and also take care of processing the returned data (i.e. creating java objects from the result).
Thanks,
Nina
Spring is great, but this is one case where there are higher-level libraries out there that make it even easier. See for example the clients that come along with JAX-RS implementations like the Jersey client and the CXF client. Some implementations can even provide clients through dynamic proxying if you have a service interface and resource classes available. This way, you hardly have to write any code at all.
Spring Rest Template is your friend.
Spring MVC has something called "RestTemplate" which can be used exactly for this.
http://aruld.info/resttemplate-the-spring-way-of-accessing-restful-services/
http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/
I need to create a system oriented around Methods where providers can register for the Methods they handle and consumers can do two things (for now) - either get Metadata for a method or execute it. I'm considering creating a REST style architecture where methods are resources with unique URIs and an interface consisting of two methods - getMetadata and Execute.
I'll need to have an equivalent of #RequestMapping so that the provider that handles specific methods can be located by the central dispatcher. As a result the provider will return either Model or Metadata object.
This looks pretty similar to Spring MVC but I don't want to expose and consume my resources(methods) over the web and use http as this will incur unnecessary overhead. Instead I want to use it like a standard java API where java methods are called and java objects are transferred.
I can do that by writing my own equivalent of #RequestMapping and Dispatcher logic but I was wondering if there's a better way to do this with Spring. Any suggestions?
Thanks!
Kostadin
You are saying you want to do using REST and everything will have a unique URI but not over HTTP?? Sounds like you are looking for RMI or something similar... Chech Burlap or Hessian both of them has excellent support from spring.
There's software out there called NetKernel that might interest you. Its literature says that it is an implementation of Resource-Oriented Computing. It looks like it rigorously separates its logical computing model from the physical details. It's RESTful, defining a resource model, a limited set of verbs, and a naming scheme. Implemented in Java. Comes with HTTP and other transports built in.
It doesn't have a Java in-process transport, but you could probably write one for it pretty easily.
Hmm...if you never need to process requests from out-of-process sources, it's probably overkill for you, but maybe it will show you some useful patterns.