We currently have a web application which should be accessible from multiple sub-domains and from multiple actual domains. E.g. clients sign up and if they want to they can use their own domains. As far as I know this would be achieved by them pointing that domains A record at us and then our web server, which would have to be embedded so we can update at run-time, adding a virtual host dynamically.
Our web application is written in PHP (although playing around with HipHop to convert to C++) with static HTML and CSS. This web application communicates with a back-end Java API that uses the Restlet framework.
Does anyone know of a web server that could be embedded that will work with PHP (and would work with HipHop if we used that)? I have had a look at AppWeb but I wondered if there were any others.
I wonder if maybe I would be better moving my web app to something like Java and using Jetty?
Thanks,
If I understand your question correctly, all you need is to lookup the
$_SERVER['SERVER_NAME']
which would be different as clients uses different domains.
Regarding minimalistic webserver, I've found mongoose to flexible and easy to setup.
(uses php-cgi).
http://code.google.com/p/mongoose/
regards,
//t
This can be done by accepting wildcard subdomains in apache, and dispatching based on the server name in PHP.
An example apache configuration can be found here.
Not sure if I get correctly where you want to embed it. But if PHP is a requirement, there is the option of using http://pear.php.net/package/HTTP_Server. It's rather minimalistic, but should thus be easily adaptable and have less issues with a HipHop transformation.
The second alternative would be Nanoweb. While that's designed as a real webserver and feature-wise comparable to Apache, it's not suitable for embedding. But there are probably others, if you want to go that particular route.
Related
I am having a Java application and a .NET application both residing in two different machines and need to design a communication layer between these two applications. Any inputs or ideas would be really helpful. Below mentioned is the nature of interaction between these two applications.
Java applications sends large amounts of data to the .NET application
Data latency should be kept to a minimum
.NET application should also be able to request for some data (synchronously/asynchronously)
The easyest way .Net and Java can talk is using Web-Services - we have done in my company with much success (using apache's cxf and standard code on the .Net side).
But if latency and size are the main requirements, you should use Sockets - both platforms offer a pretty extensive socketing frameworks and it would give you the best performance possible.
I think this can be done by setting up an xml webservices layer on the java side. You can use RestEasy for restful web services. Just my .2 cents.
Another alternative is some form of MOM (Message Oriented Middleware). There are a lot of implementations, but one to look at first might be ActiveMQ as it has both Java and C# bindings (among others).
I'm not saying this is better than using a web-service, it entirely depends on what your requirements are.
We have had good experiences with providing web services with JAX-WS (part of standard runtime in Java 6). They explicitly list .NET compatibility as a goal and is well supported in IDE's.
The Endpoint.publish() mechanism allow for small, simple deployments.
You can use Web Services. Jax-WS is the API in java that allow you to use it. As the implementation of this API I recommend metro (http://metro.java.net/), this already came with the SDK, and has a great integration with netbeans.
As already someone referred yet, you can use a socket, and create a communication channel on that, but this have some problems, starting with security. Don´t use this in real life applications.
If you need help with this subject you can start reading this:
Getting started with JAX-WS
It really depends on your requirements. The simple way is generally Web services. However, if you want higher performance, or more fine-grained access to the API on the other platform, you might want to consider JNBridgePro (www.jnbridge.com).
Disclosure: I work for JNBridge.
I have made a Java Swing application. Now I would like to make it a Client-Server application. All clients should be notified when data on the server is changed, so I'm not looking for a Web Service. The Client-Server application will be run on a single LAN, it's a business application. The Server will contain a database, JavaDB.
What technology and library is easiest to start with? Should I implement it from scratch using Sockets, or should I use Java RMI, or maybe JMS? Or are there other alternatives that are easier to start with?
And is there any server library that I should use? Is Jetty an alternative?
Given that you have the application already, perhaps the simplest thing to do is to identify the interface that you require between the client and server, and first of all to refactor your application to use that interface to talk between the back-end/front-end within the same process.
Then you can start to split this apart. A simple solution would be to split this apart using RMI (since you're talking Java objects and have Java method calls). Spring contains useful tools to simplify/automate the RMI exposure of interfaces.
For the notification requirement, a simple UDP multicast (or broadcast) would suffice.
Note that as soon as you split your application up, you have issues re. maintaining consistent views of data, managing timely updates, handling cases when the server is down, possible loading issues when you get lots of clients etc. In a sense, splitting the application up into a client and server is just the start of a new architecture process.
Mina is a good choice as a network application framework for building a simple server for this purpose - it's a much better option than using raw sockets.
http://mina.apache.org/
If you really need an application server then you could take look at JBoss. It also provides a remoting component (as an alternative to something like Mina):
http://www.jboss.org/jbossremoting
You probably won't have much need for Enterprise Java Beans though. In most cases a simple POJO based framework is more than sufficient - you could tie this altogether with a dependency injection framework such as Guice:
http://code.google.com/p/google-guice/
or Spring. Keep it simple, don't use a J2EE server unless you really need to. Hope that helps.
This is much of what J2EE does, but it's a whole new learning curve because they have pre-solved many of the problems you will run into and many you may not and therefore add on a lot of new technologies.
But at it's most basic, J2EE answers just that question.
I worked in a project like this. We implemented Client-Side Swing and Server side with J2EE. We used EJB,Stateless beans and Message Driven Beans.Also I have been in a device tracking, management project. Our clients were trucks+Swing users and We have used Servets+TCP/UDP,Apache Mina framework to handle and keep connections.
I have been working in Java Swing Client/Server applications for almost 3 years. I would suggest you to go for RMI/EJBs. The initial application that we developed was doing this using RMI/EJB for client-server communication with WebLogic being the server.
But we later found out that there are lot of "browser-like" features to be included to the application such as session-timeout etc., So, we used the BrightSide Framework which wraps the RMI calls through HTTP. One more enhancment we made is that we replaced Weblogic with the open source JBoss server.
The wrapping of calls with HTTP will become very handy and you can make your swing applications really rich. Later, when the situation demands for you to use a website strictly, you can deploy your swing using jnlp.
Hope this helped.
Is it possible to build a Java web application which has a PHP front end ?
I want all my web pages to be coded in PHP. Most of them will be forms.
I want all the data submitted by a form to go to a Java Code.
I want to do all manipulation in back end and all rendering of web content on the front end.
This is just a general question as I was probing for different options for my java web application.
You might also want to take a look at php-java bridge
A web application, by definition is already a frontend (or at least includes it).
If you meant a PHP webapp built on top of a Java backend, sure, that's possible. If you use SOAP or REST for communication between the layers, it's actually relatively easy. The only drawback compared to a pure Java (or pure PHP) app would be the overhead of those protocols, so you have to be careful to avoid too fine-grained service interfaces.
It depends on where the two meet. You could have, for example, have Java backend and PHP frontend communicating via web services. I however see no benefit in such a combination.
You can use Quercus, a Java implementation of PHP, to run PHP from within Java (and thus have easy access to Java classes).
According to your edition, it looks like you don't need PHP at all. You confused it with HTML.
Yes. You can build a java web-application which has php front end.
it is possible even with C++ backend. but why?
I want to create a webservice that allows users to enter the longitude and latitude for a particular building. Buildings will belong to a broader category called a Region. If a specific building does not exist in a region the user could add the longitude and latitude data through the webservice. Similarly if a user finds data to be inaccurate, they could update it.
This webservice would not need to have a web front-end only a RESTful API that would only be accessible to my application(s). I want the webservice to be able to accept new and updated data (as described above) and also print out relevant data (in xml format) based on the appropriate API calls.
I need to ensure that this data would be secure - i.e. nobody would be able to gain access to the data i have accumulated.
What is the best way to do this? I have familiar with client side Java and not much server side technology (not familiar with server-side Java, rails, django, etc...). What language/frameworks should i use that would accomplish my needs with the shallowest learning curve?
You can just use basic authentication (username/pw) with ssl enabled. That way you are encrypting the connection and providing a broadly supported means of authentication. I believe apache Axis will take care of most of it for you.
I've used the Restlet framework to deploy web services that are password protected. It supports basic authentification and several others out of the box. You can also set up your services behind an https "server connector".
Another approach is to run your application in a Java EE application server which supports JSR 196 (eg, Glassfish or JBoss). You would then use the server's facilities to establish the authentication.
Here is the Glassfish security page.
If you have never programmed server-side code you will be facing a pretty steep learning curve, I'm afraid. If you are comfortable with Java then the Restlet framework mentioned by another commenter is a good choice. It is easy to use, includes both client and server tools, and has pretty decent documentation. The video screencasts are very good.
Another option is Ruby on Rails. I am currently implementing something very similar to what you are planning and Rails has worked extremely well. Rails has built-in support for XML output through both the ActiveRecord class and XML Builder templates. I used Atom Authentication (http://www.xml.com/pub/a/2003/12/17/dive.html) between the client and server and it is working beautifully. There is a learning curve for both Ruby and Rails but the power of the framework makes it worth it. I am partial to the Ruby and Rails books at The Pragmatic Programmer but O'Reilly has some good ones, too.
I've been using the following web development stack for a few years:
java/spring/hibernate/mysql/jetty/wicket/jquery
For certain requirements, I'm considering switching to a NoSQL datastore with an AJAX frontend. I would probably build the frontend with jQuery and communicate with the web application middleware using JSON. I'm leaning toward MongoDB because of more dynamic query capabilities, but am still considering CouchDB.
I'm not sure what to use in the middle. Probably something RESTful? My preference is to stick with Java (or maybe Scala or Groovy) since I'm using tools like Drools for rules and Shiro for security. But then again, I want to pick something that is quick an easy to work with, so I'm open to other solutions.
If you are building ajax/json/nosql solutions, I'd like to hear details about what tools you are using and any pros/cons you've found to using them.
Pick whichever middleware you are most comfortable with.
CouchApp is very experimental at the moment. The main issue is being able to add security to your app without having a standard HTTP pop-up box. This is obviously a big issue for standard web apps.
Try and avoid parsing each DB request in the middleware and rebuilding the query for couchdb. You can make your middleware act like a proxy so most requests are forwarded on without modification. You can also add a security layer in the middlelayer on top of all requests that need authentication.
Pick a middleware/framework with good URL routing capabilities. For example you could route all requests that go to mydomain.com/db/ to couchdb.
If you go with CouchDB, you can use CouchApp which is a set of scripts for deploying an application directly to a CouchDB database. In essence, you skip the middleware and use CouchDB's views, lists, and show functions along with clientside JavaScript to implement the whole app. If your app works in this architecture, it's surprisingly refreshing, simple and cool.
Also if you like the idea of JSON/REST and sticking to JavaScript client to server, the newer generation of Persevere's core, Pintura is pure JS JSON/REST framework that is designed specifically to work well with NoSQL DBs.
I've been tinkering with a few. Ultimately, I'd like to move my controller layer of MVC to the jQuery/javascript frontend and use pure JSON/REST to talk with the backend. Though the backend will need strong security and, for my application some ability to do workflow, queries, and rules.
You also might want to look at:
1) Couldkit, which runs on Tokyo Cabinet. Supports JSONQuery and OAuth. Runs on Ruby/Rack may have enough functionality. Loks like a strong REST implementation.
2) Persevere, which is Java based and strongly supported in Dojo. It is REST-ish but also has some RPC type calls. Seems very powerful overall, with server-side java scripting, etc.
I wouldn't mind hearing how you're coming along.
Cheers,
Alex
I wrote a gem called Rack::JSON for exactly this purpose, it acts as a basic REST interface to a MongoDB db. It was inspired by Cloudkit and supports JSONQuery and also runs on Ruby/Rack. It allows you to store and then access/query JSON documents.