We're currently working on an application that enable the user to register with one or more email account so that his emails could be automatically classified. The front-end has been implement using Ruby, however, the back-end (email classifier) is written in java and uses the WEKA API. The question is how could we integrate the front-end (Web interface written in Ruby) with the back-end (email classifier written in java) in a scalable way (handling large number of users simultaneously..
I am not sure what is an email classifier. But in any similar problem, the best solution I recommend creating a RESTful API for your java service. This can be done very elegantly with the right tools. The API should be over HTTP which returns JSON. Use a library like Jackson that serialize to JSON.
On the ruby side, you an easily parse that JSON and deserialize.
This is a very scalable solution because HTTP calls are stateless and already scalable. Thread is used and thrown away. If you need more power, then just add more machines.
The Rails app can also start caching some calls. But that is premature optimization.
If there is no logic and only a common database, then just share that common database between the two apps. But it sounds like the Java app needs to do some work. This is a common approach with APIs. It also doesn't limit you to Ruby. You can create JSONP service for AJAX or any other client that can understand JSON.
If you want a new email alert just reverse which RESTful API you are exposing. Instead of exposing the Java app as a RESTful API, expose the Rails app API. For example /user/ID/newmail.
The Java app would then call the Rails app when a new email arrives.
Btw:
How did you implement a scalable system in Java for checking 1000s of email accounts?
As the amount of data you're using to train the classifier with grows, you may find that you might want to use ensemble algorithms (where a group of n nodes form the ensemble) and split the training data up over each of the n nodes.
To classify a new datapoint, you can use a voting system where each of the n nodes gets to "vote" on what the new datapoint should be classified as. The classification with the most votes wins.
Related
I have a quick architecture question as this is one of my first web applications.
On the frontend I have an Angular2 NodeJS app, backend I have a Java server aggregating some data for me in a MongoDB.
My question is simple. Should I create REST controllers in my java server to get data from the database? Or call the database directly from the Angular app.
I am leaning towards the Java REST idea. I just feel it is more secure, easier to do, and when I scale I can have processing done in Java when a rest call is made.
But I am worried this may slow things down too much? I can directly call the database and get info to put on my angular site. Does anyone know if this is a real concern for speed?
Keep in mind the data returned from the calls could be thousands of lines of JSON and hundreds of objects.
I think you can benefit from checking out this link:
https://www.mongodb.com/blog/post/building-your-first-application-mongodb-creating-rest-api-using-mean-stack-part-1
or
https://www.mongodb.com/blog/post/the-modern-application-stack-part-1-introducing-the-mean-stack?jmp=blog
As a side note - maybe it's just me - but I prefer Elastic to MongoDB - as it comes with Java-based REST API out of the box, and handles all the complexities of scalability and load balancing among nodes in the cluster.
I am exploring the possibility of using a RESTful API as the backend for an Android application.
I previously have simply been using socket programming to have my clients connect to server application but since I intend to develop a web application (with the admin functionalities for the android app) I figured this may be a good option.
My backend will be required to pull data from a nosql database and run a machine learning algorithm periodically on the data. The android app will, amongst other things, query the results of the computations and provide additional information to the algorithm.
Is it possible for me to use Spring to expose some of the application functionality through a REST API while still having other functions and tasks running in the background? Basically, can I design an application that will query multiple web services and perform various scheduled computations and query and expose only some of those functions through an API ?
Am I approaching this completely the wrong way?
Your approach sounds fine to me. Your REST API could just call internal backend methods as needed and return their output as JSON or XML formatted data.
I recommend you, if you haven't already looked at them, to go through the Spring "Getting Started" guides for building a RESTful web service and scheduling tasks.
On the Android side I'd recommend you to look into Retrofit.
I have read lot a whats are difference b/w soap and restful web services. I have got specific doubts for which i did not get answers. Here they are :-
What goes in favor of Restful web services
In nutshell everybody seems to be preferring Restful web services over soap. main reason behind it easy to develop and understand. Also faster mainly because of light weight data exchange format like json. Also in Performance in restful web services is better because less data is traveled over network(Soap involves extra layer of saop message under http request). So far so good.
Accepted answer at how is Restful web services better than SOAP based webservices also says
REST naturally fits for Web/Cloud API's, whilst SOAP fits for
distributed computing scenarios.
I did not get whats the difference between Web and distributed computing scenarios. Web is also case of distributed computing scenarios. Is n't it ? so how come one is better for web while another is for distributed scenarios ? (Q1)
What goes in favor of SOAP :-
Same answer also says that SOAP caters for stateful operations. As per my understanding its not true. If you need to maintain the state you need to maintain thru you code like sending some unique ID in both request/response that relates them Is n't it? (Q2) If thats the case that can be done in restful web services also.
Some says SOAP is better in terms of security. I don't what security soap provides that rest does not? (Q3)
Soap is probably is better in one sense that it has WSDL(that too generated by tools) doc thru which clients can generate their respective stubs. In restful webservices developer has to create the comprehensive doc himself so that client knows about the input request parameters. correct ? (Q4)
Note :- I have referred Q for question(Q1 is Question1)
There are 3 reasons to prefer REST over SOAP
Resources have URLS that identify them. If you want to share the result of some API operation with a friend, then you don't have to instruct them verbally on which API method to call and which parameters to pass. Instead, you can just share with him the URL. (for safe operations only). A great example is restaurant sites that are built in flash. If you just want to share with a friend the menu of the restaurant, you can't do that very easily. You can only tell him which buttons to press when the flash page loads.
With REST you can take advantage of the existing HTTP infrastructure on the internet to do a lot of work, i.e. caching, resource conflict management, and so on. You don't have to reinvent the wheel.
Related to #2, many developers are already used to working with REST architectures. If you use REST you significantly cut down on the learning curve that new devlopers will have to incur when learning how to use your service.
REST is cache-able for GET request. For SOAP, when using HTTP as the transfer mechanism, is sent via HTTP POST requests which are not cache-able.
I am going to make a small trade management system. I want to make a independent database service to which all the other client connect. The database will be MYSQL and I will be using Java for making the service. The client can either be a Web Application or a desktop application using Java Swing (has not decided yet). There will be another layer sit between the client and the database service to handle the business logic (I call it trade service).
The architecture is something like: Client -> Trade Service -> Database Service.
My questions is that what client/service communication technology is the best suitable one for client->Trade Service and the best suitable one for Trade service -> Database.
Shall I make it s RESTful service? SOAP? Using RPC? Or any other technologies?
Many thanks for your help. Any idea or suggestions are welcome.
Take a look at RabbitMQ, A pool messaging service
http://www.rabbitmq.com/
It's Robust, flexible, fast and scalable and you can use it to communicate in Java, PHP, or whatever technologies ou want.
Shall I make it s RESTful service? SOAP? Using RPC?
These are all very similar approaches in that they are over HTTP so - assuming that's what you want; I would recommend using RESTful. You'll have lot's of examples to work with and it will allow you flexibility in the future to do things like switching out the UI layer for a smart phone app or desktop app.
Regardless of what model you pick you should understand how it works first and build in things like security and guidelines early. Do your homework now. Trying to change the middle layer of a design like this is a pain.
There is no blanket answer to your question, there are instead options based on your skill set. Do you conceptually understand the HTTP spec completely and be able to extend it to REST, that works very closely with HTTP (common creation ancestor). Do you better understand the traditional method invocation of SOAP? Are you tied in your ecosystem to a specific language, as this can impact which tools you choose from.
If you were paying me to write a service based on the simple requirements you have given (which is nearly impossible), I would create a domain driven design service (your business layer) with a RESTful interface and Spring JDBC for data access. That is me, and what I work in most often. My partner in crime at work would probably choose SOAP and Hibernate.
I think what you're taking about is Queues, and I'm guessing you need a managed service for that. Queues can be the glue between your micro-services. Some of the vendors I know which have Queue as a Service are :
CloudBoost.io : https://www.cloudboost.io
Check out https://tutorials.cloudboost.io/en/queues/basicqueues for documentation.
Iron.io : https://www.iron.io
P.S : I work at CloudBoost
im starting with web services. I'm working in a project that needs to communicate Android with a web server and I'd like to save some time chosing the appropriate protocol for the communication.
Between JSON ,REST and SOAP:
Which ones can I run in a non-dedicated server?
Whats the best choice for a high trafic server?
Thanks in advance
JSON and REST are not mututally exclusive. JSON is a data format that the REST interface can return.
You may run either on a non dedicated server. I would personally choose REST for rapid prototyping on Android as it is easier to get up and running. (With SOAP you will probably want to have a schema which takes time to put together)
There's a good comparison between REST and SOAP on the REST wiki article: http://en.wikipedia.org/wiki/Representational_State_Transfer#Concept
REST is more of a framework than a communications protocol. JSON and SOAP could be use to create a RESTful application.
If you're writing something with many resources, I'd use REST as it is far more structured. There are also a lot of libraries that will set most of things up for you. I find JSON and SOAP are better for custom functionality that you want to hack together quickly. They can be lightweight, but less structured.