To preface I am new to web development. I am looking at creating a core set of RESTful web services around a valuable document library of sorts (initial CRUD abilities). In doing so I am theoretically creating a perfectly re-usable and scalable back-end to be used by unanticipated applications in the future.
My question centers around the best practice for doing this. My initial requirement has me also creating a unique front end. Would I make the front end and back end completely separate projects to enhance the re-usability. It would increase overhead.
Looking at using GWT, Restlet, and the Java EE technology stack if this influences the setup at all.
Most important is design a clean Java API - independent of REST, RMI, or whatever protocol you want to use. From a clean Java API, you can support any access method.
Unless you have a use case for these other access methods, don't build them now. You can build it when you need it.
The easiest interface to add initially is a web based interface where your web app runs in the same JVM as your core API. I'd do this if this works for your use case. Building a separate console application that accesses your core API via a REST (or whatever) protocol is a lot more work..
Martin Fowler wrote a very nice article about the basics of REST short time ago: Richardson Maturity Model. Found it very helpful to understand the principles of REST.
If you want to use REST based backend services, you should use the RestyGWT project which allows you you to use a GWT-RPC programing style to access your JSON based restful services.
The nice thing about using REST based JSON services over traditional GWT-RPC services is that those services can then be used by other clients or even in mashups more easily.
You may want to consider using GWT-RPC instead of REST if you know you're going to be using GWT for the frontend. More discussion here.
However, if you think you might want to eventually expose your data via a REST API, or use a different technology on the frontend, REST may be a better choice.
The gwt-rest project may also be helpful.
A colleague and I have written a GWT system using separate projects for front and back ends. It has been helpful to keep things quite clear about where the code is executing. But I'm not sure that I would bother separating things in a future system.
Also, given you're new to web development, I don't think you should be expecting to make a perfectly re-usable backend. You will learn lots of things as you go. I think that agile coders would recommend an iterative approach of (a) getting a small aspect working, and then (b) refactoring it to make it beautiful.
Related
I have applications that have been written in Java, .NET and C++. They all use a common database.
Each app has it's own way of accessing the database, and so things are quite inconsistent.
I was thinking of writing a Data Access Layer using a ORM and having all applications use that.
The question is how to implement this ORM Data Access Layer:
Make a Java package using Hibernate;
use the Java package from the .NET and C++ apps
Make a .NET class library using Entity Framework;use the class library from the Java apps
In either case, is it easy to access the package/class library from the other platform? Any suggestions on the path to take?
Is communicating via XML between the two platforms the best way?
Ps. I have already seen this question, but I think my question is a super-set of that one.
Ps. Making a web-service is an option, but I would prefer not to write/use a web-service.
iKVM
This will allow you to share code between .NET and Java. I like most sane people in the world prefer to write data access bits in .NET, but if you've got existing code in Java you want to make available for .NET services this is available
http://www.ikvm.net/
RESTful Web Service++
This is the most sane and obviously the quickest way to get up and running. Again, you could use something like Jersey, ASP.NET MVC, NancyFx or whatever REST application server you wanted to get up and running.
I would recommend you use NancyFx and ServiceStack.Text. These are two very simple very pure implementations and are extremely fast, which is what you want if you're using it as a unified DAL on top of your database.
Nancy: https://github.com/NancyFx/Nancy/
ServiceStack.Text: https://github.com/ServiceStack/ServiceStack.Text
Jersey: http://jersey.java.net/
ZOMG T3h H0rror - COM+ / DCOM
This is actually a viable possibility if you can't use RESTful web services, and also assuming you're exclusively on Windows. This will also be the most troublesome depending on how insane your requirements are. That being said, I've seen this done before and seen it work quite well especially when you have legacy C/C++ components living inside different segments if your infrastructure.
Is communicating via XML between the two platforms the best way?
This will have a performance issue - but will provide a unified data layer in a language independent maner. You can consider the open source WSO2 Data Services Server, if you select to go ahead with this approach...
Thanks...
It sounds a bit like the database can be thought of as a service that your various apps consume to different extents.
What about writing a web service layer to wrap all access operations to and service-enable the database? You could use ORM in that layer and have all of your applications interact with the web service wrapper. If you can deploy it on the same server as the database you won't get much extra network overhead.
I think this would be a decent cross platform approach where you don't have to depend on libraries across platform boundaries, and you've provided a standard way of talking to the DB for all current/future apps.
I think the title says it clearly. I am no scalability guru. I am on the verge of creating a web application which needs to scale to large data sets and possibly many (wont exaggerate here, lets say thousands of) concurrent users.
MongoDB is the data repository and i am torn between writing a simple Play! webapp talking to MongoDB versus Play! app talking to a REST service app (in Scala) which does the heavy lifting of all business logic and persistence.
Part of me thinks that having the business logic wrapped as a service is future proof and allows deploying just the webapp in multiple nodes (scaling). I come from Java EE stack and Play! is a rebel in java web frameworks. This approach assures me that i can move away from Play! if needed.
Part of me also thinks that Play! app + Scala service app is additional complexity and mayn't be fruitful in the long run.
Any suggestions are appreciated.
NOTE: I am a newbie to Scala, MongoDB and Play!. Pardon me if my question was silly.
Scalability is an engineering art. Which means that you have lots of parameters and apply your experience to specific values of these parameters to come to a solution. So general advice, without more specific data about your problem, is hard.
Having said that, from experience, some general advice:
Keep your application as clean and simple as possible. This allows you to keep your options open. In your case, start with a simple Play app. Concentrate on clean code so you can easily rework what you have into a different architectural model (with clean code, that's simpler than you'd think :-))
Measure, not guess, where the bottlenecks are. It's simple enough to flood a server with requests. Use profiling, memory dumps, whatever, to pinpoint your bottleneck in scalability.
Only then, with a working app in hand (which you could launch early with) and data on where your scaling bottlenecks are, you can make decisions on what to split off in (horizontally scalable) services.
On the outset, services look nice and scalable, but they often get you in an early mess - services need to communicate with each other, so you start introducing messaging, etcetera. Keep it simple, measure, optimize.
The question does not appear to be silly . For me encapsulating your data access behind the rest layer does not directly improve the scalability of the application.(significantly, ofcourse, there is the server that can perform http caching and handle request queues etc.., but from your description, your application looks small enough). You can achieve similar scalability without the Rest layer. But having said that, the Service layer could have a indirect impact.
First it makes your application cleaner. (UI Talking to db is messy.). It helps make the application maintainable. (Multi folds). Rest layer could provide you with middle tier that you may need in your application. Also a correctly designed Rest Layer will have to be Resource Driven . In my experience a Resource Driven Architecture is a good middle ground between ease of implementation and highly scalable design.
So I strongly suggest that you use the Service layer (Rest is the way to go :) ), but scalability in itself cannot justify the decision.
Putting the service between the UI and data source encapsulates the data source, so the UI need not know the details of how data is persisted. It also prevents the UI from reaching directly into the data source. This allows the service to authenticate, authorize, validate, bind, and perform biz logic as needed.
The downside is a slight speed bump for the app.
I'd say that adding the service has a small cost and a big upside. I'd vote for that.
The answer, as usual, is. It depends.
If there is some heavy-lifting involved and some business logic: Yup, that is best put into its own layer and if you add a RESTful interface to it, you can serve that up to whatever front-end technology you want.
Nowadays, people are often not bothering with having a separate web app layer, but serve the data via AJAX directly to the client.
You might consider adding a layer, if you either need to maintain a lot of user session state or have an opportunity to cache data on the presentation layer. There are more reasons why you would want a presentation layer, for example, serving out different presentations to different devices/clients.
Don't just add layers for complexities sake, though.
I might add that you should try to employ the HATEOAS principle. That will ease things significantly when scaling out the solution.
I'm trying to figure out wether I should use SOAP or REST for a specific project. I will explain what the project is or needs to do, and I hope some of you will give me useful information about why I should use one over the other.
The project I need to work on is totally web service based. Every frond end implementation needs to access webservices to get all the information it needs. But Beyond that, we also have an Indesign plugin that talks to these webservices to upload documents and check validations on the document etc.
So to make it short, I need to access the web services via front end web gui's and via an indesign plugin. The latter makes me wonder wether I should use REST or SOAP.
Thanks alot for reading this and posting you feedback.
I found this really great article on the advantages and disadvantages of SOAP vs REST: http://geeknizer.com/rest-vs-soap-using-http-choosing-the-right-webservice-protocol/
And my own humble opionion:
I don't like SOAP, I never did. It's been great at the time, but it just never felt "right". If you've ever tried to read one of these huge overloaded XML-documents and compared it to the REST output (which is JSON most of the time) you know what I mean. IMHO just feels "better".
One problem is that you have to document your REST API better, but that shouldn't be that big problem as long as it is not open to everyone.
Especially if you handle all your data with Webservices, I think you should go with the lighter and less bandwith consuming option: REST.
Also REST is the new and hip technology that everyone uses at the moment... ;)
About your indesign plugin: You should be able to include any library you want, so that shouldn't be a problem.
Does anyone have a real-world experience in building such a project? I'd like to move away questions about "is it good idea or not", but focus on possible solutions. I see one simple way - HTTP GET/POST + xml/json - and one more elegant - AJAX/DWR. As for the first one - I understand that it is possible, but needs quite a lot coding. As for second way - is it possible to use Java DWR engine with PHP front-end? Is DWR language-independent for client side (as it uses just JavaScript)?
Would it be a problem, that client page was generated by one web server (for example, apache+php) and served on server-side by another (for example, tomcat)? I suspect, that Tomcat will complain about sessions. Can this problem be fixed with allowing cross-domain AJAX?
Thank you in advance.
Denis.
If what you want to do is (as I suspect) to use PHP to assemble your web pages while the "business logic" is written in Java, I would suggest using PHP/Java Bridge (LGPL and MIT licenses)
Both Java and PHP are server-side technologies. Your "front-end" will be written using HTML, CSS, and JavaScript - although you could certainly use PHP (or JSP) templates to render portions of the front-end.
If you are using PHP as the "front-end", then you would need it to act as a proxy, passing requests back to the Java web server.
I've worked on a project that uses a Java 'backend' and a mod_perl 'frontend'. For the naysayers, this is because the Java is providing service/API facilities, it's not and shouldn't be involved in dealing with UI, be they HTML, WAP, SMTP, SOAP, etc.
For historical reasons the mod_perl talks XML-RPC. It's not a route I'd recommend at this stage. Java, Perl and PHP can quite happily handle far more JSON type transactions due to lower encoding/decoding overhead. Also, in a mod_perl (though not PHP) environment it's possible to run JSON-RPC easily over a persistent connection, reducing the overhead even further.
There are plenty of benefits to this approach, including separate upgrades to the various UIs, stability of the service layer, and distinct responsibilities for each layer.
Downsides include delays getting service improvements live, more complicated development, staging and test environments, a taller barrier to entry for new developers, more documentation and management.
For the "Java front to back" guys, this is a similar type approach to using an OSGi container, only using more domain suitable languages; Java for heavy lifting, scripts for more fluid, text based interfaces.
I have a rather large (80k loc) java desktop app that talks to a database. We're now looking at exposing some parts of the database via a web application, using the existing codebase and preferably not having to modify it.
I have good separation between the data access, business logic and presentation layers, but we haven't used enterprise java beans or anything like that (if that's important).
What's the best way forward? Which of the java web frameworks will be best suited to the problem? Learning curve isn't terribly important, since I haven't done any java development on the web...
To be true, it depends what you already have, and how well is the design of your current desktop application. You might not be able to use any or may be minimal of your existing code without modifying it, if its designed badly, and everything is tightly coupled.
Assuming that you are having a system with a good design, everything is de-coupled well enough. You can look into Stripes to make your presentation for the web, and use your existing data access and business code. I wish you all the luck.
Few other goodies to look into are, Groovy on Grail, Wicket.
I don't recommend anything like Seam and Spring they are more of a container and sophisticated large frameworks, which give you almost everything, solution for almost all of your problems. As you mentioned that you already have a complete system, and you just need to make a web interface to publish it for the web, these are not recommended, IMO.
JSF, is a good framework, but it might drive you nuts and has a big learning curve, according to few folks.
The two frameworks I would recommend would be Grails and Struts 2.
Grails comes with a whole bunch of stuff that it configures under the covers including Hibernate and Spring. It makes generating dynamic pages to send to the browser ridiculously easy. What you are probably going to need to do is set up controllers that call Grails services which reference your existing code as you probably don't want Grails managing your database interactions. The disadvantage with Grails is not so much that it is written in Groovy, which is easy to learn for Java programmers, but that the IDE support for Groovy is still maturing. Still if you want quick productivity this is the route to go down.
Struts 2 offers a clean command pattern framework implementation that talks to JSPs (or velocity or FreeMarker templates) on the front end. To use this you would configure actions to call your existing code. You may want to investigate adding Spring to the mix depending on what you need to do.
There are other choices but these are two that I have had some success with.