currently i have an web app build with Strus2 and Spring (IoC, Transactions), and i want to split this into 2 apps; one client which will contain only the web part and one core services that will be accessed via webservices and/or rmi.
I have a dilemma in what technology should i use for "glue", because i like the fact that webservices can be accessed by any clients (php,.net,...,mobile), but as i understand java rmi is faster then webservices.
I was thinking to expose the functionality via webservices and rmi in the same time... but i do not know how to do that.
Also in my current app i have a ajax action that is executed each second from the client to the server, and in this new configuration i think that there will be some performance penalties due to this.
How should i "attack" this situation ?
Thanks,
but as i understand java rmi is faster then webservices.
Why do you think this? Do you have a citation to bolster this claim?
Both RMI and webservices are using TCP/IP; both incur similar network latency. The former uses Java or CORBA serialization to send messages over the wire; the latter uses either HTTP (for REST) or XML over HTTP (for SOAP or RPC-XML).
The relative speed is far more dependent on what those services are doing and how you code them.
I would prefer a web service because simple and open win. You are restricted to RMI/CORBA clients if you use RMI.
Nice. You are running Spring and you already have all you need. Just throw in a few jars (spring webservices and related jars) and you should be good to go.
Please refer :
http://static.springsource.org/spring/docs/2.5.4/reference/ejb.html
http://static.springsource.org/spring/docs/2.5.4/reference/remoting.html
Related
We are developing a service for our portal / web client developed using JSF . My advice was to expose the service as REST but another team member said to go with RMI implementation since its easier to deal in java object from development and testing point of view.
My argument was development and testing efforts with be pretty much the same but we will get all the goodness of REST web services.
FYI : We already have REST setup so there is no extra cost in framework support. This services are exposed for our smartphone client who uses REST api.
At the end our Manager decided to go with RMI way but I still think REST would be smarter way.
What would be your choice REST or RMI?
Note : Nothing against my team member or Manager just trying to learn here.
If there are firewalls between your client and server, it is likely that RMI traffic might be blocked. HTTP traffic is open on most firewalls and REST should have no problem getting through.
The biggest argument against RMI and for REST/SOAP etc is that the client does not have to be Java.
If your front-end could change down the road from JSF to ASP, then you'll be in some trouble.
Other than that, RMI is the way to go. An even better way to go is EJB ( which is a layer on top of RMI ) with additional advantages -- lots of vendors already implement the EJB spec, you get the advantages of object pooling, transaction management etc.
Is the client in Java, use RMI. But that is to simple thought. As it is only a point to point protocol.
REST as a paradigm is interesting if you have e.g. many reads and like to use HTTP technologies for caching etc. The next thing is you likely can easy implement "paging cursors" so you send data as a small page and add info how to retrieve the next page.
Your question basically is formulated as if it is a technology question. Which is the wrong approach. You should not bother about technology but about system architecture. The whole software system, its abilities, its performance, its scaling, its configuration and its maintenance is completely different depending on your usage of RMI or REST.
I have a web application in JAVA (Spring MVC framework) and I want to connect to a website and use its web services which wrote in php, is it possible ? if yes how can I do that?
It doesn't matter what language one used to create a webservice. You can talk to any webservice by agreeing on how it exchanges messages.
Yes, Spring integrates well with Apache Axis: http://axis.apache.org/axis2/java/core/docs/spring.html
To consume web services with Spring you can use JaxWsPortProxyFactoryBean to create a client proxy: http://musingsofaprogrammingaddict.blogspot.com/2009/03/writing-and-testing-jax-ws-clients.html
From Spring in Action, here's how you'd configure an example web service proxy bean:
<bean id="spitterService" class="org.springframework.remoting.jaxws.JaxWsPortProxyFactoryBean"
p:wsdlDocumentUrl="http://localhost:8080/services/SpitterService?wsdl"
p:serviceName="spitterService" p:portName="spitterServiceHttpPort"
p:serviceInterface="com.habuma.spitter.service.SpitterService"
p:namespaceUri="http://spitter.com"/>
The beautiful thing about web services, and web services are beautiful things, their hosts are made with wsdl's, their client is made in Spring! (Totally stole that from the mouse (just a warning, as per the comments, this rhyme is not to be used as an authoritative anything. It is an attempt at humor by someone who was excessively tired at 3 AM because of Win 7 issues))
Web services are language agnostic -- the only thing which matters is that they are up and running (and serving valid outputs), not that they are using technology X, Y, or Z. Theoretically, you could even have a webservice running on something written in Piet or Brainf*ck.
A tutorial on how to create a client can be found here.
Use CWSDLGeneratorDocument.php for generate WSDL file in DOCUMENT/LITERAl style and use standart library JAX-WS in java 1.7.
I am working on a server application that does the following:
Read data from a measuring device that is being addressed via a serial interface (javax.comm, RXTX) or sockets.
Exchange data (read and write) with another server application using sockets.
Insert data from (1) and (2) into a database using JDBC.
Offer the data from steps (1) to (3) to a JavaScript-based web app.
My current prototype is a stand-alone Java application and implements task (4) by writing the data to an XML file that is being delivered to the client via a web server (Apache), but I consider this to be a hack, not a clean solution.
This server application needs to start up and work also without any web clients being present.
I would like to integrate this server application into a Java application server, but I do not have much experience with these technologies and don't know where to start. I have tried some simple examples for TomCat and GlassFish, but that did not bring me any further because they are all built around serving web requests synchronously and stop where it would be getting interesting for me.
Is this possible to run such an app within TomCat or GlassFish?
If yes, where would be a good point to start (examples, which base classes, ...)?
Would it make any sense to split the application and implement only task (4) in a servlet, the rest in an ordinary application, communication via sockets, etc.?
Would other servers, e.g JBoss, be a better choice and if yes, why?
Edit:
The reasons I want to use a Java EE container are:
I would like to have a clean external interface for step (4).
On the long run, the application will need to scale to a huge number of simultaneous clients (at least several 10.000), so a want a standard way of scalability and application management.
In general, it's not a good idea to implement all of this in a servlet container such as Tomcat.
A servlet container is designed to service requests from a client. It sounds like you have a process which will be running all the time or at least periodically. You can do this in Tomcat, but it's probably easier to do it outside. Leave Tomcat to do what it's good at, servicing requests from browsers. It's happiest when the requests are short lived.
So I would do as you suggest, and only have step 4 in the container. You can easily interrogate the database populated in step 3, so there is no need to create web services to populate the servlet container.
For step 4, you will need to expose some services from Tomcat, either through rest, soap, whatever you like. The javascript clients can then interrogate these services. This is all completely doable with Tomcat.
For scalability, there shouldn't be a problem using Tomcat. If all it's doing is pumping data from the database to the client, there probably isn't a reason to choose a J2EE container. If you don't have need of complex transaction management or security, try using something open source. It sounds like you can get what you want from Tomcat (& hibernate & spring security if necessary). If you start to have performance problems, then the fix will probably be the same for JBoss & Tomcat: you need more servers.
My advice: stick to the simple open source solutions and move to an application server only if you find it to be necessary.
I would loosely couple the solution and not try to do everything on the Java EE/Servlet container as exchanging data using sockets (managed by the application itself) is not something you typically want to do from a Java EE/Servlet container.
Running this on a Java EE container might also be overkill as this doesn't sound like a typical enterprise application where stuff like security and transaction management is important and the app could benefit from services provided by the Java EE/Servlet container.
I'm writing some application that will work in a background (windows service? maybe some application server?)
Application receives some data, then it transforms/packs/optimizes in another thread and then in another thread it sends data to next server (using WebServices).
There will be thick client (probably Swing) for monitoring whole process thru WebServices.
All application will be written by my team (so there is no need to use complicated integration services).
Application will be composed from loosely coupled classes (simple DI pattern),
maybe JMS will be helpful ?
I'm wondering what technologies should I use.
Tomcat? Glassfish? or maybe something lighter ? Spring server?
You doesn't need any application server. Keeping it as much light weight as possible is a good choice. My suggestion for you is to use a lightweight framework that supports DI, transformations, threading/seda and integration (invoking weservices) out of the box, so that you can concentrate on your application logic. The frameworks like Apache Camel, Mule etc are good candidates.
Tomcat is not an application server. I have never heard of spring server.
here is a list of java application servers .
The most widely used are JBoss and Glassfish.
I have an axis web service deployed on JBOSS. My web service is synchronous.
So, how does a web service handle multiple requests? And how do I simulate/test that my code can handle multiple requests well?
You can use Apache JMeter for this. Here's a webservice test plan guide.
That said, I agree with skaffman that Axis isn't the optimum choice for webservices. If you can, use Sun Metro or Apache CXF instead, both which are JAX-WS implementations.
Axis isn't the most modern or performant of the web service stacks (and that's putting it kindly), but it should have no problem with a decent load of simultaneous requests. If there's going to be a problem, it's more likely to be with your own code.
The best way to test this is to use Axis to write a web service client, and use it to fire a large number of requests at your server. If you've already used Axis to generate java artefacts, it should be fairly straightforward.