I need to make a decision between using Ruby vs. Java for SOAP integration. My entire web application is built on Ruby on Rails, and there is a significant back-end component that has to integrate with legacy systems using SOAP.
Java has extensive SOAP libraries like Apache Axis and seems to integrate very well with this type of "legacy" web services while Ruby has some gems like Savon and handSOAP.
I'm biased towards using Ruby libraries, but am concerned about performance / scalability issues. What are the performance/scalability issues attached with using Ruby?
To get more context, the integration with the legacy system has two components: a daily process, whose performance is less important, and a realtime query engine, whose performance is very important because users are waiting while the query is being handled.
I faced the same challenge recently. I originally went with Java, but wound up porting everything over to Ruby using Builder to construct the requests and Nokogiri for parsing the responses. I also use SoapUI to help with development/debugging of requests.
Why did I wind up going with Ruby over Java...
Simpler infrastructure. Why have two different paradigms in your architecture if you don't need it. If your site is Ruby on Rails, why introduce Java into it unless you need it.
Java has some nice libraries like Axis to convert SOAP requests to objects. But that really isn't a big problem., but really that isn't that much of a win when most of my logic is in Ruby. It was much easier for me just to work with the DOM through Nokogiri than to have intermediary Java objects.
All of my logic (ActiveRecord model objects, validation, etc.) were all in Java. I wound up having to replicate logic like database persistence to communicate between the Java code and the Rails code...boo
The performance concern seems like a red herring. If you are making SOAP requests, the network overhead will likely be your bottleneck, not the language parsing/executing.
Related
I have to re-design an existing application which uses Pylons (Python) on the backend and GWT on the frontend.
In the course of this re-design I can also change the backend system.
I tried to read up on the advantages and disadvantages of various backend systems (Java, Python, etc) but I would be thankful for some feedback from the community.
Existing application:
The existing application was developed with GWT 1.5 (runs now on 2.1) and is a multi-host-page setup.
The Pylons MVC framework defines a set of controllers/host pages in which GWT widgets are embedded ("classical website").
Data is stored in a MySQL database and accessed by the backend with SQLAlchemy/Elixir. Server/client communication is done with RequestBuilder (JSON).
The application is not a typical business like application with complex CRUD functionality (transactions, locking, etc) or sophisticated permission system (tough a simple ACL is required).
The application is used for visualization (charts, tables) of scientific data. The client interface is primarily used to display data in read-only mode. There might be some CRUD functionality but it's not the main aspect of the app.
Only a subset of the scientific data is going to be transfered to the client interface but this subset is generated out of large datasets.
The existing backend uses numpy/scipy to read data from db/files, create matrices and filter them.
The numbers of users accessing or using the app is relatively small, but the burden on the backend for each user/request is pretty high because it has to read and filter large datasets.
Requirements for the new system:
I want to move away from the multi-host-page setup to the MVP architecture (one single host page).
So the backend only serves one host page and acts as data source for AJAX calls.
Data will be still stored in a relational database (PostgreSQL instead of MySQL).
There will be a simple ACL (defines who can see what kind of data) and maybe some CRUD functionality (but it's not a priority).
The size of the datasets is going to increase, so the burden on the backend is probably going to be higher. There won't be many concurrent requests but the few ones have to be handled by the backend quickly. Hardware (RAM and CPU) for the backend server is not an issue.
Possible backend solutions:
Python (SQLAlchemy, Pylons or Django):
Advantages:
Rapid prototyping.
Re-Use of parts of the existing application
Numpy/Scipy for handling large datasets.
Disadvantages:
Weakly typed language -> debugging can be painful
Server/Client communication (JSON parsing or using 3rd party libraries).
Python GIL -> scaling with concurrent requests ?
Server language (python) <> client language (java)
Java (Hibernate/JPA, Spring, etc)
Advantages:
One language for both client and server (Java)
"Easier" to debug.
Server/Client communication (RequestFactory, RPC) easer to implement.
Performance, multi-threading, etc
Object graph can be transfered (RequestFactory).
CRUD "easy" to implement
Multitear architecture (features)
Disadvantages:
Multitear architecture (complexity,requires a lot of configuration)
Handling of arrays/matrices (not sure if there is a pendant to numpy/scipy in java).
Not all features of the Java web application layers/frameworks used (overkill?).
I didn't mention any other backend systems (RoR, etc) because I think these two systems are the most viable ones for my use case.
To be honest I am not new to Java but relatively new to Java web application frameworks. I know my way around Pylons though in the new setup not much of the Pylons features (MVC, templates) will be used because it probably only serves as AJAX backend.
If I go with a Java backend I have to decide whether to do a RESTful service (and clearly separate client from server) or use RequestFactory (tighter coupling). There is no specific requirement for "RESTfulness". In case of a Python backend I would probably go with a RESTful backend (as I have to take care of client/server communication anyways).
Although mainly scientific data is going to be displayed (not part of any Domain Object Graph) also related metadata is going to be displayed on the client (this would favor RequestFactory).
In case of python I can re-use code which was used for loading and filtering of the scientific data.
In case of Java I would have to re-implement this part.
Both backend-systems have its advantages and disadvantages.
I would be thankful for any further feedback.
Maybe somebody has experience with both backend and/or with that use case.
thanks in advance
We had the same dilemma in the past.
I was involved in designing and building a system that had a GWT frontend and Java (Spring, Hibernate) backend. Some of our other (related) systems were built in Python and Ruby, so the expertise was there, and a question just like yours came up.
We decided on Java mainly so we could use a single language for the entire stack. Since the same people worked on both the client and server side, working in a single language reduced the need to context-switch when moving from client to server code (e.g. when debugging). In hindsight I feel that we were proven right and that that was a good decision.
We used RPC, which as you mentioned yourself definitely eased the implementation of c/s communication. I can't say that I liked it much though. REST + JSON feels more right, and at the very least creates better decoupling between server and client. I guess you'll have to decide based on whether you expect you might need to re-implement either client or server independently in the future. If that's unlikely, I'd go with the KISS principle and thus with RPC which keeps it simple in this specific case.
Regarding the disadvantages for Java that you mention, I tend to agree on the principle (I prefer RoR myself), but not on the details. The multitier and configuration architecture isn't really a problem IMO - Spring and Hibernate are simple enough nowadays. IMO the advantage of using Java across client and server in this project trumps the relative ease of using python, plus you'll be introducing complexities in the interface (i.e. by doing REST vs the native RPC).
I can't comment on Numpy/Scipy and any Java alternatives. I've no experience there.
I am looking forward to developing a social web application using Java in backend (to support operations from Cassandra database) & php in the middleware. Is this kind of approach beneficial ? Any downsides of the above strategy ?
Are there other better options to ensure a scalable architecture ?
Edit : What do you guys think about doing it completely in JAVA (J2EE)?
Mixing PHP and Java does a few things:
You lose the benefit of the tight integration between PHP and MySQL, as Java will fit in the middle (with probably lots of complex spaghetti code).
You introduce a complex Controller layer between the PHP View and the Java Model, which could be easily handled by leveraging open source MVC projects such as Spring MVC or Struts 2.
You create a larger barrier for new
developers who are introduced to the
code, since they will have to learn
both programming languages.
I, personally, advocate the Struts 2 MVC architecture, with Spring integration to handle your data access using Hibernate or IBatis, or to whatever service/backend you may be connecting your model layer to.
If you are tied to PHP, I would suggest sticking with pure PHP and MySQL, since you have an entire community to help with troubleshooting, support, and technical help when you are looking for other developers to join the project.
The downside is having multiple programming technologies for a product that, from the way you described it, hasn't even started yet when a single one could fit the bill for the time being until you completely define how the program is going to evolve and change. How you think things are going to turn out today it not how they will turn out when the project is finished. By creating a tiered / multi faceted program runtime environment, you will be creating a debugging, scaling, and development nightmare. Get off the ground and then redefine your requirements to see if these massively complex structures are needed.
I generally think it's a good approach if you can manage the added complexity.
The benefits are:
PHP development is much more productive and
easier to learn than Java development
PHP, in my experience, is often better fit for web requirements
You still have all the power of Java in your backend
It's the way Facebook does it: (even though they have "pimped" their PHP http://developers.facebook.com/blog/post/358) front-End-> PHP, backend-> some other language:http://developers.facebook.com/blog/post/354
Then again as Geoffrey Wagner pointed out, it adds a lot of complexity and you should be very sure you need this kind of setup.
I have a startup considering building a Java backend and a Rails frontend. The Java backend will take care of creating a caching layer for the database and offer other additional services. The Rails frontend will mostly be for creating the webapp and monitoring tools.
What startups/companies out there are using this kind of setup? What are some gotchas in terms of development speed, deployment, scalability, and integration?
(What would be helpful for me is personal experience or informal case studies. I'd like to de-priorities answers addressing alternatives like Grails or JRuby unless it turns out to be a big part of the equation)
Thanks!
I've never done any rails development but here are my thoughts. Why not just use Grails? I've done a fair amount of Grails development and it works well for rapid prototyping. It also offers all the power of Java, Spring, and Hibernate. Instead of dealing with communication between two different technologies you could take advantage of the fact that Grails uses Spring and Hibernate under the covers to deal with caching as well as any other requirements these technologies support. If you have Java developers Grails should not be to hard to pick up. The grails plugin story is decent. All of them are stored in a central place and are easy to obtain but quality differs depending on the plugin author. You also have to remember that since Grails uses Groovy which is syntactically similar to Java and runs on the JVM it is very easy to use existing java code including the multitude of available Java libraries. I don't know this for certain but I assume there are a lot more libraries out there for use with Java and there for with Grails then are available for the Ruby language and Rails. I can't make a resource usage call for you but my question would be how many people do you have with experience designing Rails systems that use Java on the back end with all the gotchas that will go along with that? You may find that you have no one who is proficient at debugging when something goes wrong in communication between the two technologies.
I have used similar pair for one of my projects, but instead of RoR I used Python. I don't think there's large difference.
In general, there's nothing specific in this kind of programming. Two most important things you must care about:
good modularity;
well thought-out protocol between RoR and Java.
First is about exact functionality decomposition between parts of the system. We've got some troubles because of not understanding what part of a job must be done by Java, and what part by Python. In general, you must tie together all functions that are close to each other, and thing that are far must be connected in a very few places. I guess you know rules of good modularity, but in case of composing different languages this must be thought-out much more carefully. You can also be interested in creating several distinct Java services (e.g. one for database caching and another one for all the rest) to be able freely combine them or even use in other projects later.
Second is about communication between your parts. I can see two ways to communicate: through database and through pure network protocol. The former need some network communication anyway, so we used pure network protocol, without any other way to connect parts.
We had experimented a lot with SOAP, but it gave hundreds of errors: this protocol is quite ok to connect services written in one language (i.d. Java to Java), but terrible for connecting services in different languages - automatic tools for generating WSDLs gave different results for Java and Python, and manual creating of scheme was hard and labor-intensive.
So we used to REST. It uses all the features of HTTP protocol such as all four main HTTP methods (POST, GET, PUT, DELETE), error codes and many other things, so it covers almost everything you may want. The only restriction with REST is that it can't hold state, so you may need to implement your own sessions mechanism.
If you're not very comfortable with REST and seek some real example, see Facebook Graph API and for implementing REST services in Java you can use Restlets.
Perhaps I'm stating the obvious here, but the biggest gotcha here is the actual fact you're combining two technologies. Not only will development be slower - Rails and all Java frameworks are expecting to have a full Ruby/Java application - but for the other issues you mention (deployment, scalability, integration), the existing tools and solutions will not work, or at least not very well.
If you have a compelling reason to combine the two, go ahead but expect to spend more time on these issues than with a single technology solution. If you don't, pick either Rails or Java.
I would strongly urge you to consider having the frontend and backend in the same JVM for performance reasons.
For Rails, JRuby can run Rails, and you can have it in a Java EE container providing fast communication between components.
Having multiple architechtures which do not run in the same process requires you to do network based communication which takes much, much longer than just passing a reference to an object (I do not expect you to want to use shared memory).
Twitter.com is supposedly using a Java backend, and Rails for their web interface. Here are some resources:
http://www.radicalbehavior.com/5-question-interview-with-twitter-developer-alex-payne/
http://blog.adsdevshop.com/2008/05/02/twitter-is-not-abandoning-rails/
http://twitter.com/#!/ev/status/801530348
More specifically, they use Scala on the backend (which compiles to Java byte code):
http://www.artima.com/scalazine/articles/twitter_on_scala.html
I don't think there is anything wrong with this approach. However, you will be supporting two different platforms/VMs. I have seen this kind of situtation result in a sort of fracturing of expertise within an organization. And you end up paying to a lot to have two sets of expertise in house.
If the problem of segmenting expertise concerns you, I would suggest running JRuby of Rails. It is very mature now - and runs better than Rails on Ruby 1.8.x.
We have used Ruby on Rails for front-end and Core-Java SOAP Api for backend. It worked very well.
The main issue is not with performance but with the people. It is very difficult to hire expert people in Ruby on Rails for everything, instead you hire few or you can easily mould to just learn Rails UI.
As startup point of view, it is best strategy. So many believe ROR is best for startups... but very few knew it because in most of MNC's we use Java, so there is pressure to learn Rails and Code, or hire very few ROR developers. So instead you can use ROR for frontend (only few people do that, or it is easy to learn) and use experienced Java developers for DB updates and business logic.
I am an open source developer, and I need to write a highly-scalable web service. For a variety of reasons (basically poor support for concurrency), I am using Ruby on Rails for my app front-end but not for the back-end (read: http://www.ddj.com/go-parallel/article/showArticle.jhtml?articleID=212903282). My web service will need to call several partner APIs for each request, so it needs to be smart about threading to have high throughput.
What language / stack does the community recommend for writing such a web service? I haven't written Java in a while (and it seems really old school :D). I need to be able to prototype this service quickly.
What language / stack does the community recommend for writing such a web service? I haven't written Java in a while (and it seems really old school :D). I need to be able to prototype this service quickly.
Then I would definitely recommend to use Java and the JAX-WS API which, like other Java EE 5 APIs, is annotation-based to ease the development. In other words, you annotate a Java class and voilà, you're done and can deploy it as web service. This is really perfect for prototyping (even if I would switch later to contract-first approach). For an implementation of this API, you can use the reference implementation (JAX-WS RI) which is included in Java 6 (since Java 6u4) and also used in Metro, the web service stack of GlassFish (Metro = JAX-WS RI + WSIT). Another (very good) stack which also implements JAX-WS is Apache CXF.
If you want some numbers about the performances of JAX-WS RI, have a look at this benchmark, it will give you an idea of its capabilities (and/or of the hardware you'll need).
And to get an idea of what this API looks like, have a look at Introducing JAX-WS 2.0 With the Java SE 6 Platform, Part 1 and Introducing JAX-WS 2.0 With the Java SE 6 Platform, Part 2 (the complexity may not be very representative of real life though).
Update: I've mentioned JAX-WS RI, Metro, Apache CXF and I would understand if you tell me that this is confusing. The problem is that if you google for JAX-WS, you'll meet all these terms/acronyms. So I tried to give the minimal informations to clarify what they are. If you need any clarification or more details, just let me know.
A little known but good option is C++. There are a number of frameworks ranging from high level AJAX abstractions (Wt: http://webtoolkit.eu/) to simple CGI libraries (e.g. http://cgi.sourceforge.net/). The performance is very good and development is fast otherwise, but the need for recompiling all the time may obstruct your development. Another issue to consider is the smaller number of readily available webdev libraries and APIs, but I have found everything that I need (e.g. SOCI, LibXML++ and Boost.ASIO).
C# and Java are also high performance options but development in them might be slower than C++, largely depending on what you are used with. On the other hand you get plenty of libraries and support.
While most scripting languages (most notably Python and Ruby) lack proper support for multithreading due to them using global interpreter locks, this is not really a problem for web services. The problem can be worked around by running a separate process for each user. This has somewhat larger memory requirements, but in general it works well and it certainly is safer.
The bigger problem with Python and Ruby is that they execute the code extremely slowly. To make the problem even worse, Rails is a very slow framework, compared to other Ruby libraries. I have successfully created high-load web services with Ruby (using Ramaze web framework). Manual optimization on source code level is required for reaching acceptable performance levels, but for what I worked on this was enough and we could keep using Ruby.
If you choose to go on the Java path, then I recommend using jax-ws (metro implementation, already included by default in Java 6) for two reasons:
It is easy and more intuitive than the alternatives.
It is faster, and you mentioned that performance is important. See here a very recent article about performance.
To prototype quickly:
Python (scripting lauange like Ruby which may help you learn quickly)
or JSP since you've learned Java before.
It depends on the rest of your requirements.
For example, if you want to use .NET then you may want to use F# for your backend. If you use
Expert F#
the author will show how to use F# in web pages.
If you want to use something like Java then look at Scala as an option.
Or, if you want very scalable, where, if you add new machines you don't have to change any code, then you can look at Erlang.
You can get threading to work with OOP languages but it won't tend to be as efficient, as the test and set way of locking may not be as efficient as desired.
There is nothing wrong with spawning Ruby processes for this. As long as you design them to be independent (from each other and from the database), your scalability will be ok. You can get higher performance from the same hardware with other languages and environments, but introducing a new language in an open source project is a big no-no. It will basically reduce the number of available developers too much.
I'm planning to develop a web-services (SOAP to C++ client) in Java with Metro/Hibernate and front it up with a web-site written in JRuby on Rails, connecting Java modules through JRuby and generally through a database. I already wrote some code and set up everything.
Now, I've heard that .NET 3.5 is really powerful and after some reading I acknowledged that to be true. However, would it make sense to drop this monstrous yet curious hybrid of Java and RoR to switch everything to .NET? Everything: services, database connection (linq for objects), web-front, ajax stuff -- everything in one huge .NET 3.5 solution.
I am also looking to have fun but not as much fun as, say, in C++ for server-side :)
I know that with the power of RoR it doesn't really matter whether it's either side. However, whether I'm all set up for .NET or Java, I still have the feeling I'm doing it wrong and I should just switch to the not-side-I'm-currently-on.
I have a very limited experience with web development, I've only written an ASP.NET web-service once and supported Java web-service so I have a real OCD with the choice of platforms here.
.NET 3.5 is loads of fun (among mainstream platforms), but in my personal opinion Ruby is as much fun as if not more fun than .NET 3.5.
About the capabilities, they are also roughly equivalent, you certainly can make a SOAP web services application in both without problems.
About the "monstrous hybrid", there's no such thing, it's just a (very active) port, like IronRuby or IronPython in .NET land.
There will be more of a coherent whole if you stick in .NET and write in, say, C# than if you mix and match Ruby and Java, of course. But you certainly can use only JRuby.
Given that the fun and capability factors are more or less equal, I'd pick JRuby, just in case I happen to have to deploy on Linux, Solaris or something that's not Windows in the future.
If you are certain you'll want to stick to Windows forever, then pick whatever's most fun for you.
I'm sorry, but what you are doing sounds like a big ball o' mud. Doesn't matter to me what path you take, but I'd simplify the architecture by reducing the number of technologies/frameworks that you are using. If you can find a way to do it in Ruby/Rails without reference to Java (although you may need to keep the C++ client-side), that would work. Obviously, working in .NET (my preferred platform) is another choice. Windows Communication Foundation makes it much easier to write web services that are lighter weight than the old ASP.NET web services -- including RESTful web services using JSON.
If I were doing it today I'd use ASP.NET MVC for the web front-end, WCF (for web services), and either eliminate the C++ client or consider writing it in C# with .NET or Mono.
It sounds to me like you are over planning or over engineering a little bit here. I don't quite have a clear picture of your architecture by reading, but I see many words like .NET, Java, SOAP, C++, JRuby on Rails, RoR, web services, Hibernate, ajax, linq, etc, are being thrown around, so I just wonder how they are all going to fit together. Here are some simplified architectures that might or not fit your needs since I don't quite understand your problem. I also do not see that there is any question from your post, so given the circumstance, I would suggest:
Web front end: RoR with Ajax.
Web services: .NET.
Data access: Linq.
What this means is your .NET web services would use Linq for accessing the data and expose via SOAP which would be consumed by the front end Ror.
Alternatively, replace .NET by Java and Linq by Hibernate.
If the above is useless, then my other suggestion is you don't have to combine all those technologies in one solution.
I'd rather move to FreeBSD or Debian in the future... I sure don't want to stay on Windows forever. But there is Mono, right?