I have a Java RMI application developed with Swing GUI interface. I want to change that to React app. Is it possible to call RMI methods from JavaScript?
No. It is not possible. Javascript is not Java at all.
You may consider to rewrite server side of RMI application to either Webservice or REST API application, then you'll be able to call its methods from Javascript. It can be also just a small wrapper application around existing RMI.
Like:
Javascript call (SOAP or REST) -> Wrapper call (RMI) -> Existing RMI app.
Maybe, you can use hessian protocol (reimplement RMI with hessian, just delegate from hessian servlet to local RMI). Use hessian.js
Related
I have a RFC-enabled function in sap (WebService).. I want to call this function and get the result using java. What should I do? (I already have the WSDL endpoint)
Call it like consuming any other normal web service.
Use JAX-WS,which is the Java standard for it.
See here and here for an example.You can also use HTTP clients to call the web service as well.Apache HTTP Client is a great library if you want to go in that direction.There is an example available here for that as well
I want to develop a Swing client application that will use a Java EE 6 backend. How does the Swing client communicate with the server? Do I have to make a web service that the communication go through or are there other ways?
There are other ways also in addition to web services.
One very common approach is RMI or Remote Method Invocation. It is a native extension of the Java platform that allows server-side objects to be directly accessible inside client-side code.
If you have no experience with RMI then take a look at the official Java Remote Method Invocation Tutorial
I think this might be a very useful document for you, complete with diagrams to demonstrate the architecture and communication modal.
There are to many communication types:
sockets gives to you the max communication speed.
a little communication overhead, you can use XML / SOAP
(plain)webservices too : fastest to implement. a HTTP GET, POST
RMI: I think is deprecated, but others are using. If you want only with Java backend from Java, you can use it
Yes, you can either create a web service (SOAP or RESTful), but since your client is a java application you can use jndi lookup to call EJB3 beans, it will work through rmi or soap, depending or your configuration. Something like here.
We have a Java API that needs to be supplemented/fronted with a SOAP/REST Web service Layer.
What does it take to implement Async Calls across process/server boundaries using
a) SOAP Webservices
b) RESTful webservices
Some of the methods might need multiple calls to respond to the request.
We will be using Java/J2ee to implement the SOAP/restful service using a library like CXF or Axis or Jax-RS/WS.
Any examples ? Gotchas ?
Thank you,
The Async Http Client is an open source library that was specifically designed for this type of problem. It utilizes futures and wraps up a lot of the detail and hassle out of making async calls.
The author has a very good getting started guide and there is an active discussion group. The author is a very talented developer and the project is under continuous development.
From the documentation:
The library uses Java non blocking I/O
for supporting asynchronous
operations. The default asynchronous
provider is build on top of Netty
(http://www.jboss.org/netty), the Java
NIO Client Server Socket Framework
from JBoss, but the library exposes a
configurable provider SPI which allows
to easily plug in other frameworks.
Your question is not clear. I am interpreting your question as you want your serverside code to call a remote REST web services in an Async manner. If so then your best bet is to use the Futures feature of java.util.concurrent it will do exactly what you want. If my interpretation of the question is wrong then please update your question with exactly where the async operations need to happen.
Akka http://akka.io/
Great framework, great performance - Here are their claims:
"""
Simpler Concurrency
Write simpler correct concurrent applications using Actors, STM & Transactors.
Event-driven Architecture
The perfect platform for asynchronous event-driven architectures. Never block.
True Scalability
Scale out on multi-core or multiple nodes using asynchronous message passing.
Fault-tolerance
Embrace failure. Write applications that self-heal using Erlang-style Actor supervisor hierarchies.
Transparent Remoting
Remote Actors gives you a high-performance transparent distributed programming model.
Scala & Java API
Scala and Java API as well as Spring and Guice integration. Deploy in your application server or run stand-alone.
"""
#Vivek
GET is async and other HTTP methods
are not.
This isn't true. Please go ahead and read about AJAX :-)
For REST web services (apart from GET) everything else (POST/PUT..) is Async, it returns you the HTTP status code of the opeeration.
If you want to make GET also Async then you will have to use Threads, We did it once in Spring framework using #Async annotation (which internally spawns a thread).
From get return the callback URL as the response and use threads to process the request asynchronously.
Apart from that, For both SOAP / REST once you get the request you can publish it on a JMS queue to make the service Async.
One of the best ways to implement asynch ops is to use callbacks. For REST APIs, design of APIs and Rest client should support this. For instance , client class should pass itself or it's inner class as listner. Rest API on server side should maintain request id and call back listener in map . Once processing is done , it can call method on listener based on request id from map.
Real question: why do you want to call it Async? Having looked at solutions for parallel processing on the Java EE side, it's not recommended that you spawn child threads within a container on your own.
In your case, it looks like the following:
1. you're looking to create a wrapper contract in WSDL (REST or SOAP or both) and if you clients are not just browsers (AJAX)(i mean you'd have adopters from the server-side), then, for JAX-WS -> you could create a #CallBack end-ponint (http://docs.oracle.com/cd/E15051_01/wls/docs103/webserv_adv/callback.html)
or
if it's REST end-point that requires being called from an adopter (server-side), use jAX_RS 2.0 feature
Note: Above assumes it's point to point but in an Async way
Here are a few options:
if you're looking to call REST Or SOAP or some other function asynchronously, you can use workManager API (JSR )
or
use JMS and use a request-reply model if you need it (short running) and calling multiple end-points in parallel
use WS-BPEL (only WSDL end-points) - this is a OASIS standard as well
use SCA (any component with any technology) that can contain assemblies of WS-BPEL component (stateless or stateful) running in BPEL engine like Apache ODE or IBM process server and other components and collaborates. This is a standard
I'm sorry if this question is a bit obvious, but I'm new to BlazeDS and can't seem to find an answer. I'm running Java on a BlazeDS server with a Flex front-end. I'd like to be able to instantiate my Java class only once, then have the Flex use the setters and getters to play with the data in the Java class (in a sense, treating the RemoteObject as if it were an instance of the class). As far as I've read this seems to be the way BlazeDS works, but every time I call any Java method from Flex, it calls Java constructors again, resetting anything input by the setter methods. Is there a way to have the server hold the instance of the Java class between method calls? Thanks!
You seem to have a misunderstanding of how this is works.
Objects in the Flex client and Objects on your server are completely independent. In normal circumstances, The Flash Player/A Flex App only talks to the remote service using either a WebSerice, HTTPService, or RemoteObject. RemoteObject supports AMF and Flash Remoting with BlazeDS, LiveCycle Data Services, ColdFusion, and a ton of other server side software.
When you make remote calls to the server, that request is no different than a standard web page call. It exists in "isolation" and knows nothing about any other call. In traditional HTML development we use session cookies to keep track of server sessions in a 'stateless' client. The same can be true for Flex calls. If your server sets cookies on the client; then the Flash Player will include those cookies in each request; matching up the service call to a server side session.
Whether an object is created with each call depends on what your remote call does.
The benefit that AMF / RemoteObject offers is that it can easily translate server side objects (Java Classes) to client side objects (ActionSCript classes). This is primarily used for passing of data between the two different entities. Usually people make Value Objects/Data Transfer Objects for this; but the classes can have the same exact functionality. It is not like the same object exists in both Flex and Java.
Does that help?
Basically I need webservice where client can request with id one boolean value from our webservice. What technology would be most suitable for this small API? Of course it is possible that there will be more functions to interface, but now we need only one function. It also needs to have authentication, so that only auhtorized clients can access service. And every client have different auth credientials.
What would be good technology for this purpose?
I am using resteasy to build my webservices and it is pretty easy to use ... just need to use annotations on my methods to deliver the webservices.
Here is a comparison of different JAX-RS frameworks. Take a look at it
First of all: authentication and authorization. Don't do it yourself, pick an app server or servlet container and configure it to do the job.
For the web service....
The simplest thing to do it just implement a servlet that responds to a POST (not a GET if request modifies internal state) and returns the result in the body. This way you don't need any frames works, no learning to do (if you already know servlets). The downside is it won't scale as you add more features, and your not using enough buzz words.
If you want a SOAP based webservice, then look at JAX-WS. Now that it's backed into java 6 it's pretty easy.
At the simplest level JAX-WS lets you put a few annotations on your class, like #WebService, and it auto generates a wsdl and exposes an instance of your class via the web service.
There is plenty of documenation out around how to do it:
http://java.sun.com/webservices/docs/2.0/tutorial/doc/
http://www.java-tips.org/java-ee-tips/java-api-for-xml-web-services/developing-web-services-using-j.html
http://cwiki.apache.org/GMOxDOC20/simple-web-service-with-jax-ws.html
JAX-WS + any servlet container (Tomcat is usual choice)
#WebService(targetNamespace = "http://affinity.foo.com", name="RewardsStatus")
#SOAPBinding(style=SOAPBinding.Style.RPC, use=SOAPBinding.Use.LITERAL)
public interface RewardsStatusIF {
#WebMethod(operationName="GetLastNotificationDate", action="urn:GetLastNotificationDate")
#WebResult(name="return")
public Date getLastNotificationDate() throws AffinityException;
...
Actually, you don't even need a servlet container. JAX-WS has a way to run the service under a standalone Java application. It has some limitations (I have failed to make a stateful service work), but it's
very simple to create.
Given that you tagged your question as "Java", I suggest Jetty. It is a very good small servlet engine. It has support for sessions, so adding authentication should not be a problem.
If you are using Java 6, there is already a HTTP Server builtin, it supports Http authentication. That's all you need. Check out,
com.sun.net.httpserver
You could use some restful framework like jersey.
An alternative to SOAP-based web services with JAX-WS would be JAX-RS (for RESTful web services).
We have a lot of scenarios on our project where we want small amounts of data available via simple HTTP URLs while the app is running and in my experience, Restlet (http://www.restlet.org/) seems to be one of the easiest things available for setting up simple "web-service"-like interfaces (RESTful interfaces) within Java apps.