There are already a few posts on SO discussion whether this architecture is a good idea or bad idea. For many reasons within our company including the existing programming talent, we've decided to use Java for the backend and PHP for the front end. Our objective is something like...
Java - Models/Controllers
PHP - Views
We're working on building a prototype of the interaction between Glassfish and Apache. One thing we're still working on is when a user visits http://domain.com/login.html and they login, that login will be sent to the Glassfish controller which exists somewhere like /login.java. We can do that no problem, the trouble is getting the view to be rendered at that URL.
Has anyone does this with PHP or any other technologies?
Have you considered setting up a soap/rest server in java and having PHP talk to that? I imagine that would be much simpler than what you're trying to achieve.
I am sorry to bring this up but it seems like it would make things a lot simpler to stick with just one of these languages. If you are using PHP to add more logic into your view, it might be worth taking a look at Velocity. It allows you to access and create variables, iterate through lists, use conditionals, define macros, make method calls, etc. This seems like it might make things much cleaner. However, it is usually a good idea to try to keep as much logic out of your templates as possible.
If you would like to use PHP because that is what is required I would suggest taking a look at using web services to communicate. Take a look at Googles GSON library. It is really nice tool (on the java side) for mapping JSON Objects to your model (and vice versa).
On your front-end, it might also be worth taking a look at Backbone. It is a tool that makes it simple to mock up your model Objects and bind events to them, or add tie them directly to fields, etc.
I've had first hand experience at two companies that use the Java Service layer and PHP Client layer technology stack, although it was not used exclusively. To clearly separate the layers a well-defined JSON REST API was built so each layer had a contract it could code to.
The Java layer used SpringMVC in-between the persistence layer to generate JSON views with well-defined routes (i.e. URL structure) in order for the PHP layer to GET/PUT/POST/DELETE resources.
Regarding the login issue specifically, there were actually two Java services, one specifically for login/logout and the other for the regular backend.
When visiting /login which I assume would be a .php file. A submit of the login <form> to the "Login" service resulted in a session cookie being added but also an encrypted "user ID" cookie. The encrypted cookie could then be used to protect access to the Java Service layer for the product. Each REST request from PHP to Java would have access to the cookie, and the Java layer could then decrypt the "user ID" and respond to the PHP REST call if it was valid. The Java layer would then have access to the real user ID in order to return user-specific data from the persistent store.
Related
It's not a very concrete question. I created a simple project with a help of this tutorial, it's really fine. All the GWT code samples related to JSON I saw so far seem to work with a JSON (or immitate this work with some mock-up JSON), that is retrieved and processed in GWT. I'm a newbie in GWT, and I wonder, what are the cases of interacting with services that return JSON (services are mentioned in the same tutorial) and what are the pros and cons of such interaction.
I thought about two options (well, service is an overloaded term):
everything that is mentioned in these JSON GWT tutorials is about the third-party services, like GData and Yahoo! Web Services mentioned here, which would make sense, cause it's about retrieving some data and processing in the app,
and the second option is about services, that are created within the confines of a project (and, if there are some cases, and definitely there are some, my question is about them).
It's probably can't be fully explained in the answer, so a link (or a few) would be appreciated. Thanks in advance.
Your question is really quite generic. But here are some pointers:
JSON is just a data interchange format similar to XML or Protocol Buffers or some other proprietary format.
They are necessary in modern web applications because the UI is entirely controlled by the javascript code running in the browser.
However the data that a web application presents to the user usually resides on the backend. In order to get the data from the backend to the frontend you have to use some data interchange format like JSON or XML.
The advantage of JSON is, that is fairly efficient compared to XML and well accepted.
As you mentioned there are third party services that rely on JSON. These are very useful when you want to include the services in your applications.
The biggest advantage of applying this service oriented approach to your own project is that you decouple your components (frontend and backend). By doing this you achieve following things:
Make your services available to other (web-)applications and users because your service exposes a specific API/data exchange format that they can use.
Easily replace or add another frontend (for example create a desktop application in addition to your GWT application) that can work with your data (display or modify).
We are green fielding a mobile web app against an existing Java web app --the database of that app, at least.
We are only using the database of the original app because the original app is built on a custom ORM solution and Struts 1.1 that is showing its age. So this is going to be a bit of a proof of concept for what can be done with modern tools.
We have decided to utilize JQuery mobile on the front end to leverage device cross compatibility. On the back end we are going to go with JPA for now...maybe moving to Hibernate down the road. But we'd like to expose our model with a RESTful service to kill two birds with one stone (the original app interfaces with a number of third party's that we'd like to give access over a simple REST interface that happens to have a lot of overlap, data wise, with the mobile module.)
So, the question is which controller layer will best tie the JQuery mobile front end with the RESTful back end?
We'd like a controller framework that:
Is not too intrusive. i.e. we don't have to lock ourselves into that particular implementation because of hard set dependencies spread all over the code.
Is annotation based or heavy on convention over config. or both so we are not writing reams of XML glue
Doesn't bring along cruft that we won't be using... i.e. it sticks to the controller layer as much as possible
Can handle REST from one end and AJAX from the other without too much trouble
The larger the community the better
The simpler to get up an running without compromising any of the other points, the better.
We've begun exploring Struts2, SpringMVC, Stripes, Play! etc. but I am hoping for some sage advice from the erudite SO community to help narrow the field.
If you need anything clarified, I will be happy to do that.
It seems to me that you're searching in the wrong direction.
Your Java App is producing JSON/XML through REST web services.
Your jQuery client is consuming those web services to publish them to an interface
You seem to search a controller server side. Why? Producing REST web services is not the only goal of a REST server?
Take a look at BackboneJS — it's not the only one in the category, but the one I know better — it's a client-side controller. It fits perfectly with jQuery and allows to access REST resources with HTTP verb — GET, PUT, DELETE, POST — in a compact and generic way.
If you choose so, I'll help you further.
I have existing Java application that is using Acegi for authentication/authorization. Our new web interface would be preferably written in Django. I would like Django to maintain users - registration etc. Django would either share or update Acegi authentication data so the older application still works and users don't have to use two sets of credentials (maybe even share authentication cookie). I was wondering if someone was already dealing with similar issue and if yes which approach was chosen.
Thanks
Just remember whatever you do with Django, it is still Python, therefore just because Django doesn't have it/doesn't do it that way, doesn't mean you can't. Also, from another point of view, there is nothing stopping you using bits of the Django framework from outside the traditional Django application.
I don't particularly like the admin interface to Django although I do use Form and ModelForm a lot outside of it. I actually implemented my own authentication system - all you need are functions that let you log in/out etc and an interface to that data. It (users/groups etc) doesn't have to be represented as a Django model although that's what I did for ease. There is nothing stopping you hooking in another ORM or writing your own for acegi. Alternatively, if writing your own layer is simple enough, do that.
I'd recommend hooking into the context processors for Django and the Django middleware and library-ising your work simply because it'll make re-use a breeze and it will act in a similar manner to the existing authentication framework. Here's an example context processor I use to allow me to write {{ username }} in my template without having to get it out of every request object in every view method:
def Authentication(request):
if AuthenticationCheck(sess=request.session, timeofaction=datetime.datetime.now(), ipaddress=request.META['REMOTE_ADDR']) == True:
return dict(username=request.session["username"])
else:
return dict(username='')
Also, Django Middleware Documentation
I'm developing a REST webservice (Java, Jersey). The people I'm doing this for want to directly access the webservice via Javascript. Some instinct tells me this is not a good idea, but I cannot really explain that instinct. My natural approach would have been to have the webservice do the real logic and database access, but also have some (relatively thin) server-side script layer (e.g. in PHP). Clients would talk to the PHP layer which in turn would talk to the webservice. (The webservice would be pretty local to the apache/PHP server and implicitly trust calls from the script layer. The script layer would take care of session management.)
(Btw, I am not talking about just hiding the webservice behind an Apache which simply redirects calls.)
But as I find myself at a lack of words/arguments to explain my instinct, I wonder whether my instinct is right - note that while I have been developing all kinds of software in all kinds of languages and frameworks for like 17 years, this is the first time I develop a webservice.
So my question is basically: what are your opinions? Are there any standard setups? Is my instinct totally wrong? Or partially? ;P
Many thanks,
Max
PS: I might add a few bits of information about the planned usage of the whole application:
will be accessed by different kinds of users, partly general public, partly privileged
thus, all major OS/browser combinations can be expected as clients
however, writing the client is not my responsibility
will potentially have very high load/traffic
logic of webservice will later be massively expanded for another product which is basically a superset of the functionality of the current project
there is a significant likelihood that at some point an API should be exposed which can be used by 3rd party developers - obviously, with some restrictions
at some point, the public view of the product should become accessible via smartphones, too (in other words, maybe a customized version of the site to adapt to the smaller display and different input methods)
I don't think that accessing a REST webservice directly via e.g. JavaScript is
generally a bad idea, because that what the REST architecture is designed
for. For your usecase you might have some implications to consider:
Your webservice will have to take care of user management. Since the REST architecture does not support a server side session state you will have to do authentication and authorization on every request. Users will have to maintain their state on the client side.
Your webservice implementation will have to take care of issues like caching and load balancing and all the other things you might have assigned to e.g. the PHP "proxy" script
For your requirements:
all major OS/browser combinations can
be expected as clients
Since you webservice will only deliver data (e.g. JSON or XML) this should not be a problem. The JavaScript part just has to take care to issue the correct requests.
will potentially have very high
load/traffic
If you strictly follow the REST architecture you can make use of http caches. But keep in mind that the stateless nature will always cause more traffic.
logic of webservice will later be
massively expanded for another product
which is basically a superset of the
functionality of the current project
The good thing about open webservices is that you can loosely couple them together.
there is a significant likelihood that
at some point an API should be exposed
which can be used by 3rd party
developers - obviously, with some
restrictions
Again, with RESTful webservice you already have an API exposed for developers. It is on your clients to decide if this is a good or a bad thing.
at some point, the public view of the
product should become accessible via
smartphones
Another pro for making your REST webservice publicly accessible. Most smartphone APIs support HTTP requests, so you will just have to develop the GUI for the specific smarphone platform that makes direct calls to the webservice.
Firstly I am just extending on what Daff replied above. I am extending Daff's answer from the point of my learning or designing and implementing RESTful WebServices and please note that I am still learning.
When I started learning RESTful WS with Java, Jersey (0.3 IIRC), I had similar questions and the primary cause for that is "Total" mis-conception about RESTful Architecture. The most "Grave" mistake I performed was using JAXB for XML and Jackson for JSON (de)serialization directly from/to the persistence beans. This totally violates the REST principal and hence creating some vital issues in creating a high performance, highly available, scalable web service.
My mistake was, thinking in terms of API a.k.a Service, when we think RESTful WS we should forget "API" and think Resources. We should take great care in interlinking resources. My understanding of this only came after reading this, I suggest it to anyone wanting to create their own web service. My conclusion is what is Resource is to RESTful WS/Architecture what API to a native interface or SOAP Web Service. So I would suggest design your resources with care and understand that there is no limit in how resources your WebService may have.
So here comes how I concluded in implementing systems exposing an "API" through RESTful WS. I create an API which deals communicating with business entities, for example, PersistentBook, which contains either Id of PersistentAuthor or the object itself. All business logic considering persistent entities lie in the API implementation layer.
The web service layer uses the API layer to perform its operations on resources. Web service layer uses persistent entities to generate representations of beans and vice versa, the key feature here would be PersistentBook's representation would have a URI to the PersistentAuthor. If I want to use automated (de)serialization I create another domain layer, e.g. Book, Author etc.
Now as Daff mentioned caching would be inevitable, my checkpoints for them are -
Support for 'Cache-Control', 'Last-Modified', 'ETag' response headers and 'If-Modified-Since', 'If-Match-None' request headers are key. Note from my more recent learnings - use 'Vary' header in case of varying representations (content negotiation) based on 'Accept' header.
Using a server side caching such as Squid, Varnish in case clients do not use caching. One thing I learnt having all the right header support counts for nothing if clients do support them and in fact increases the cost in terms of computation and badnwidth ;)
Use of Content-Encoding.
I have a small project where I would like to generate dynamic data entry forms with a little bit of logic behind them.
A simple use case might be
a Football resulting form, so you have a button for a goalscorer, and when clicked the user will be prompted for a player. The form will then send a message (probably to a webservice, but maybe a JMS queue) with the event data. eg Barcelona, Goal, Henry.
Then I want to create a similar form for tennis...
My idea was that I would create a webservice, where you define business logic. (events, components, actions you take etc.) Initially I thought I would send the sport definition from the webservice in xml. Then write an app to parse the xml and dynamically create the data entry screen.
I was initially thinking of writing a webservice and returning a xml data. (which will look awful) the rendering technology could then be flex/ flash and be a thin client.
Then I thought it would just as easy to create the forms as a java app using the swing application framework and that was the way to go.
Then I thought, well, rather than write a xml schema to describe the java forms, can I just serialise a java class and send that across the wire.
Once on that path, I am now wondering if should just a java framework, and the dynamic forms become class that are called by reflection.
I would love feedback on the above approaches, and how people on stackoverflow would solve this problem.
thanks
David.
I would avoid serialisation because it is a bit fragile, difficult to do safely and difficult to diagnose.
You say it's a small project, so does the metadata really have to pass from client to server? Would you not be much better off very simply writing the metadata (really code) as Java code?
(FWIW, my first commercial Java project was creating forms dynamically from a database specification (with regular additions). Previous to that I working with C++ running an interpreter for training systems. In both cases I would now (and for the last decade), have written them as Java. Don't be put off by people mumbling disapprovingly about "hardcoded".)
I would consider XForms as well. It allows you to define both the data model and the UI as XML, and all you need to render it on the client side is a web browser. I assume the event would be submitted to a remote server, which makes the web browser as a natural choice.
This would enable you to generate the UI on the server based on what kind of sport event the user wants to report about, so you can easily add new forms, fix bugs, etc. without ever having to update the client software.
By the way, I don't understand your concerns about using XML. In my opinion it's a viable option for your use case.