I've got existing Play application, I need to add to it remoting capacities.
RMI would be ideal choose, since I don't need to rewrite original client application. It's possible to run rmi registry myself, but I would like to avoid it. In EJB container rmi registry starts itself.
Another option - is to use Hessian for example, but in this case I need to add special servlet mapping in web.xml Is it possible to do it in Play ?
Or I can use web-services, but it's more like overkill in my situation. And again I need to add mapping in web.xml for Axis of CXF for example.
Could you suggest fastest and easiest way to add remoting for play application ?
Play provides a library (WS) which makes it very easy to connect with 3rd party apps via HTTP requests. That would be your best bet if you can add a REST layer to the remote application.
If not, you could try to use RMI and run play within a Java EE container as a war file (to get access to container), but that will hinder the normal developemnt flow.
Choosing one or the other may depend on the effort involved to add that REST layer. If it's not too complex, I would favour that.
Just use REST json services, you have everything in play to do so, nothing else is needed
Related
Here's my situation: I'm running a JBoss 7 in Domain Mode with several nodes. One node is in charge of my Liferay 6.2 another one runs several other web applications. Now I'd like to implement some kine of Single Sign On routine. So to use my web applications you have to go through liferay first. Authenticate agains liferay, then go one to one of the web applications.
So the question is whether there is a way to expose some of liferays methods to access the user store and check if the user, who's accessing a web application is the same as logged in on liferay. Developing some sort of bridge is fine with me. I'm thinking of a portlet which does all the interaction with liferay and exposes some methods like readUser(). Maybe I can do a jndi lookup for this portlet or a component embedded in this portlet to call readUser() from my other web applications. I think this sounds a bit like EJB stuff.
Using Liferays API, Services and LocalServices to read user information etc. shouldn't be that difficult (already played a little with that). I just don't know how to establish a communication between a web application and liferay.
If it's not working this way, I would settle for something else, maybe a webservice or an other way that makes sense but I'd like to try the EJB/JNDI approach first (except this makes completely no sense). Maybe someone can point me in the right direction.
Turning my applications into portlets is not really an option because these applicaions are quite large and already exsist for quite some time. So I'd like to leave them mostly unchanged - outside of auth stuff.
Thanks and regards
Sebastian
You can use a service builder and you expose your service as remote.
Several Options:
Just access Liferay's API methods from your applications. You can access the JSON API at http://www.example.com/api/jsonws.
There's also a SOAP interface (http://www.example.com/api/axis), that's typically available only from localhost (you can configure otherwise in portal-ext.properties)
You can encapsulate calls to those services by creating your own services. Use the tool of your choice or Liferay's servicebuilder. You can create empty entities and just refer to Liferay's own entities. Servicebuilder will generate JSON or SOAP WS if you let it. (what Slimen Belhajali mentioned)
As you specifically talk about the check for user identity, you might even want to think of a completely different solution and just look at single-sign-on (SSO) solutions. This way you'd sign in only once (to the SSO server) and automatically (implicitly) to your webapp as well as to Liferay. This works best if both access the same userstore, e.g. on LDAP.
I'm creating an application that relies heavily on dynamic creation/management of various resources like jms queues, webservice endpoints, jdbc connections... I have a background in java EE and am currently working on a jboss 7 server however I'm finding it increasingly difficult to control these things programmatically. The hardest thing to control seem to be the webservices. I need to be able to generate WSDLs (and XSDs) on the fly, manage the endpoints, soap handlers etc and the system simply does not seem to be set up to do that.
Other application servers don't seem to really offer any groundbreaking solutions so I'm wondering whether perhaps java EE is not the best solution to this particular problem?
Is there an application server that allows you to do just that? Is there another technology that does? Should I just roll a custom solution that integrates all the separate modules (e.g. a jms server, a web server etc...)?
UPDATE
To clarify, most java EE stuff is accomplished through a mixture of annotations and XML configuration. This however assumes that you have a POJO and/or a jar/war/... per resource.
Suppose I have a #WebServiceProvider bean which can be reused for multiple input/output combinations (for example because it dynamically redirects the content). I need to be able to deploy a new "instance" of the provider on the fly. This means I do not want to duplicate the code and redeploy it, I just want to take that one existing bean on the classpath and deploy it multiple times with different configuration settings. This also means I need to manage the WSDL dynamically. The end result should be a webservice that works pretty much like a standard webservice on the application server with the necessary integrated security, soap handlers,...
I imagine that at some point in the application server code, there must be a class "WebserviceManager" which has a method like "createWebservice(...)" that is actually used by the deployment module whenever it discovers a webservice annotation. I want access to that method and similar methods for creating jdbc connections, jms queues,...
You can use OSGi for these kind of scenarios. It is perfect for hot deployment of varios modules.
I have a java Swing application client and multiple glassfish servers with different names running copies of the same Stateless EJB JAX-WS for fail over.
First, is this a proper way to set up fail over and are there any resources available to help?
Secondly, the way I did it was to import all methods from the web services into seperate java classes then have a separate management class that calls each method. Within each method call it determines the appropriate connection (i.e. if the web service call fails it increments to the next web service). The problem is this is a large amount of code that is difficult to maintain as it is not an efficient method.
Any help is much appreciated, thank you.
First, is this a proper way to set up fail over
I recommend to use an application server with clustering capabilities, e.g. GlassFish v3.1
http://glassfish.java.net/public/clustering31.html
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/
Currently, I only know a way of doing RPC for POJOs in Java, and is with the very complex EJB/JBoss solution.
Is there any better way of providing a similar functionality with a thiner layer (within or without a Java EE container), using RMI or something that can serialize and send full blown objects over the wire?
I'm not currently interested in HTTP/JSON serialization BTW.
EDIT: For clarification: I'm trying to replace an old EJB 2.1/JBoss 4 solution with something more easy to manage at the container level. I need to have entire control over the database(planning to use iBATIS which would allow me to use fairly complex SQL very easily), but the only things I want to keep over the wire are:
Invocation of lookup/data modification methods (automagic serialization goes here).
Transparent session control (authentication/authorization). I still have to see how to accomplish this.
Both items have to work as a whole, of course. No access should be granted to users without credentials.
Because I'm not very fond of writing webapps, I plan to build a GUI (Swing or SWT) that would only manage POJOs, do some reporting and invoke methods from the container. I want the serialization to be as easy as possible.
As is nearly always the case, Spring comes to the rescue. From the reference documentation, you will want to read Chapter 17. Remoting and web services using Spring.
There are several methods to choose from. The beauty of Spring is that all your interfaces and implementations are vanilla POJOs. The wiring into RMI or whatever is handled by Spring. You can:
Export services using RMI:
probably the simplest approach;
Use HTTP invoker: if remote access is an issue, this might be better for firewalls, etc than pure RMI; or
Use Web Services, in which case I would favour JAX-WS over JAX-RPC.
Spring has the additional benefit in that it can do the wiring for both the server and the client, easily and transparently.
Personally I would choose either (2) or (3). HTTP is network friendly. It's easy to deploy in a Web container. Jetty's long-lived connections give you the option over server push (effectively) over HTTP.
All of these methods allow complex objects to be sent across the wire but they are subtly different in this regard. You need to consider if your server and client are going to be distributed separately and whether it's an issue if you change the interface that you need to redistribute the class files. Or you can use a customized serialization solution (even XML) to avoid this. But that has issues as well.
Using a Web container will allow you to easily plug-in Spring Security, which can be a bit daunting at first just because there are so many options. Also, HttpSession can be used to provide state information between requests.
Simple RPC is exactly what RMI was built for. If you make a serializable interface, you can call methods on one app from another app.
If you only need value objects then just ensure the POJOs implement Serializable and write the objects across sockets (using ObjectOutputStream). On the receiving end read the objects using ObjectInputStream. The receiving end has to have a compatible version of the POJO (see serialVersionUID).
Hessian/Burlap 'protocol-ize this: http://hessian.caucho.com/ and http://www.caucho.com/resin-3.0/protocols/burlap.xtp
You could try XStream (http://x-stream.github.io/) over REST. Easy to apply on e pre-existing set of pojos.
Can you give some further information as to what you're trying to achieve, since you're not interested in rest/json ?