I have worked mostly with PHP and to some extent with Java. And currently looking at Python and Django. When a Django project is deployed on production, it is required to choose one of servers that implement wsgi specification.
The definition is pretty straight forward as well as history. Looking back at php world I don't see a parallel with wsgi and that creates some confusion and probably an opportunity to learn more about it.
So the questions is what makes python application special that they require (frameworks as well as servers) to implement wsgi specification ?
Do we have similar specification for php ? any reasons for having/having not ? Probably a unique issue with python ? however, I see we can use uWSGI with php applications also.
Is wsgi is something similar to Java Servlet specification ? and uWSGI server is like Tomcat i.e Application Server.
If we consider a wsgi server as Application Server, what services it does provide e.g manage security, transaction processing, resource pooling, and messaging or more/all of them ?
Related
I am relatively new to web development, but I have some C++/Java experience. I have got the following conversion to do:
Current:
Desktop Application (Automation Software) developed in C# that communicates with remote PLC (Controller that overlooks different sensors in realtime) using TCP Sockets over the Web.
My Idea:
Convert the application into a server side software that will still communicate with the PLC over TCP/Socket. And use a browser to operate it, so the remote site can be monitored and controlled from any computer in our Intranet (possibly Tablets in the future).
Motive for doing it:
We had a computer fault which left the operators without control.
The new app:
I am planning on writing the server app using Java and OOP (so far no problem). And use HTML/CSS/Javascript for the WebApp and AJAX to update the page.
But I am still lost at how can I transport all this data between them in a proper and decent manner. I have read about SOAP and JSON in this Post. Although, I am not sure if I need to use them at all, is it a good solution to use either JSON or SOAP? Or is there any other solution that you may recommend?
Cheers,
Leo
If you consider skipping the development work to convert your app into a server-side software and just go for a third party solution, I suggest you take a look to Thinfinity VirtualUI.
"...offers a GUI remoting solution for in-house Windows desktop
developments, allowing them to be delivered as Windows/HTML5 dual-platform applications
simply by adding one line of code.
These Windows applications can keep their standard desktop environment behavior and,
alternatively, be accessed remotely from any modern web browser in a multi-user,
multi-instance fashion when hosted on a Thinfinity VirtualUI Server environment."
https://www.cybelesoft.com/docs/thinfinity_virtualui_whitepaper.pdf
SOAP is for defining public APIs that are published on the internet for other people to use, which does not seem like your use case. It is not particularly awesome to have to deal with it from inside a browser either, although there are javascript SOAP-client libraries. There is also going to be a fair bit more overhead on the server side parsing and validating XML than de/serializing between JSON and POJOs.
JSON is much easier to deal with in a browser, being natively understood and all that. Everything you need is built into the core of jQuery, no dependence on plugins that may have unknown levels of future support.
Where, when and why did you use ESB in a PHP-project?
Where, when and why do you think that it would make sense to use ESB in a PHP-project?
Does ESB (and ESB-facilitators like Mule) do provide any capability PHP and native LAMP-technologies are lacking?
Edit
My motivation for this question is stemming from my assumption that you actually never really need Mule. Mule will facilitate communication with external services which you could handle without mule. At the end of the day also Mule will create costs and overhead. So my question is steering at having somebody tell me about scenarios where you really benefit of ESB and tools like Mule or to second my guess with solid knowledge.
Edit 2
regarding Houcem's reply to my comment to his post ... what would be a native LAMP-answer to ESB/Mule?
Edit 3
Seems like Tuxedo might be a more PHP-native alternative to Mule/ESB. Somebody got experience using this tool?
ESB could be used in different ways :
Providing asynchronous processing : Example : If you have a web site that does a lot of emailing .. and sending an email takes a lot of time which may block the execution of your page : you may use an ESB to send the email data to Mule and route it to an Email outbound channel, this way you can say that you have implemented a mail message queue. Another form of asynchronous processing : using mule to execute php scripts (using command line) in a non blocking way.
Integration with java applications : You can send Messages to mule using php and implement some java business using mule API in java, php messages will be received by your java business components. This is used in big web sites which does a lot of complex processing and need flexible and powerful language like java.
What you need to know : ESB should be used like a Bus which means collecting data from heterogenous environments in a standard form (Mule messages) .. do business logic and then output data (after routing) to different environment
There is no native php integration with Mule in PHP world. To do it you should use web services (SOAP)
An ESB is a general solution to a scalability problem; a problem in managing the overhead, cost and complexity of a large number of application interfaces. I wrote a short article about the rationale for ESB/EAI solutions at http://psicom.com.au/solutions/eai
Admittedly, most PHP sites are small scale and would usually find it difficult to justify the administrative and technological overhead of an ESB. But it is now quite feasible to meet all of a business's application needs with OSS PHP products, and there is also increasing cost pressure on organisations, so I expect there will be increasing numbers of PHP shops that will start to feel the kinds of growing pains that I wrote about. This may make them re-evaluate their application integration issues, and an ESB is a good solution to that problem.
As far as I know there are no ESB products developed in PHP, and I don't expect to see this in the near future. But FWIW, many ESB products provide bindings for PHP and other OSS platforms, so the platform that the ESB runs on isn't crucial.
The ESB (Enterprise Service Bus) is a kind of backbone for the integration of the several heterogeneous applications of the enterprise, that may originate from different vendors, technologies, and even be redundant.
The fact it seems more linked to Java world than PHP or any other language is that usually big companies information systems are made of :
Mix of opensource development and software editors tools (including ERPs). Development are often made using Java EE in order to rely on Java EE stacks (and its vendors IBM, Oracle, ...)
Full Microsoft (no need of ESB, Microsoft provide EAI/ESB like tools)
PHP is most used for web application (even for big companies, but web oriented).
An ESB is a big cost, and is only usefull/needed when the number of interconnected application is raising.
When you have only few connections (between Java, PHP or whatever), you can handle it at a network level, using DNS, and at application level using configuration keys and performing protocol exchanges and small business integration for each point to point connection.
A potential use case for a PHP application would be an internet site of a travel agency quering multiple flight/train/hotels companies. And even in a such case, it won't be mad to develop a full cross quering system since it is the core of the business for such a site/company.
I would recommend Windows Azure Service Bus, which provides a PHP SDK here
https://github.com/WindowsAzure/azure-sdk-for-php
service bus is great but maintaining one is not. Windows Azure Service Bus solved all the maintenance overhead for you, and it is PHP compatible. You can even communicate with apps that are written in Java, C#, VS C++ from PHP easily.
I'm carrying out a feasibility study on writing, let's say it's a lightweight run-in-browser MMORPG. (It's not exactly an MMORPG, but would take longer to explain, and the requirements are similar.) I'm trying to figure out the required technology stack.
Client side, it runs in the browser, so the client is Javascript. That was nice and easy :-)
Server side, I'm looking at Java. The common Lamp stack was designed for RESTful applications, as I gather were typical Java web frameworks, and this application is different - it needs a continual stream of data going back and forth between the server and all the clients. I think what I need in this case is Java of the non-framework, full no-holds-barred Java EE variety, someone please correct me if my understanding is incorrect or incomplete? I would need something that is commonly available on reasonably cheap hosting, Java EE fits this description, right?
(Figuring on using MySQL for the database, as this is what's most commonly available. Also I might actually write the code in Scala, being a Java-compatible but supposedly slightly nicer language. I assume neither of these makes any difference?)
Supposing I were writing a website in Lamp, doing at least the initial development on Windows, then I'd install Xamp, which gives you a running copy of the entire server stack right there on your desktop, so you can just alt-tab back and forth between your editor/IDE and browser for testing.
Now my question is: What's the best equivalent setup for Java, for developing something like this on Windows?
Right, in a sense it is. What I think I'm really saying is that almost all discussion of server-side Java seems to talk about JSP, EJB, Glassfish, Google app server etc which are frameworks in the sense that they put restrictions on what your code can do, whereas Java EE puts no such restrictions, you can use as much or as little of the standard library as you want, but it doesn't stop you running arbitrary persistent Java code. Is that correct?
You've thrown out a bunch of terms there:
Glassfish is an application server that implements (all of) Java EE.
JSP is a specification that is part of Java EE, and implemented by application servers such as Glassfish as well as web servers such as Tomcat and (I think) Jetty.
EJB is another specifications that are part of Java EE. It is typically implemented by application servers.
"Google app server" is really "Google Application Engine" (GAE), and is really a platform for implementing web servers in a cloud computing environment. If that's not what you want / need to do, GAE is probably a blind alley for you.
Glassfish, JBoss, Tomcat, Jetty and so on are all platforms that implement some or all of Java EE. None of them stop you implementing arbitrary persistent Java code.
GAE on the other hand does restrict what you can run, because the platform only allows you to run standard Java classes in a whitelist. If your "arbitrary" code depends on other standard Java classes, you are out of luck. (And hence my warning about blind alleys.)
And of course, there are various other Java-based frameworks that are targeted at web development in one form or another. Some are compatible with Java EE servlets and other EE technology, and some have gone off in a different direction.
My recommendation would be to start with something straight forward using plain servlets on a stock platform. Only look at the high performance stuff if and when performance looks like it will be a real concern (not just a "nice to have"). It is better to have a simple and non-scalable prototype, than a high performance solution that you don't have the time and skills to get working. And you can treat the prototype as a learning exercise.
A little hard to tell from the requirements given, but I would look at the following based on your description:
http://www.playframework.org/
http://www.zkoss.org/
http://code.google.com/webtoolkit/
Play Framework is a nice web-centric framework that provides a complete stack (you can code in Java or Scala). ZKoss (ZK) and GWT both provide user interface frameworks. ZK, GWT, and Play all run nicely in Tomcat/MySQL and should work just fine in typical Java/MySQL hosting environment.
... not sure what your definition of 'cheap' is but, that and 'no holds barred Java EE' don't exactly go together. Also, 'frameworks' by themselves don't put restrictions on running any arbitrary java on the server side. When I say 'frameworks' I mean Spring, Struts, etc. Servers will be a little different story. If you need EJBs you'll need Glasfish or JBoss or another EJB compliant container. Hosting with these will be more expensive compared to getting by with Tomcat. IMHO easiest and quickest way to get started is with NetBeans. Comes with Tomcat and / or Glassfish out of the box, all you need is a db.
We are occasionally in a position to take over PHP based projects, but as we are a Java-house we are searching for ways to turn a PHP-project (or codebase) into a Java-project.
The approaches we came up to work in a mixed Java/PHP context are :
PHP in frontend and Java in backend with separate front (PHP+JavaScript) and back (Java+SQL) teams
using both technologies in a Java webapp, for example via Quercus with one or multiple teams
migrating everything to Java
We haven't tried any of these approaches as we've been lucky enough to have enough Java-only projects to work on.
Do you see other approaches, or have you tried any of the described approaches?
I've used Quercus. I think that if it supports something like Drupal then it's probably fairly mature. If your PHP app works out of the box, then it offers you a very gradual upgrade path to Java since you can write your own plugins in Java and expose them to the PHP layer, such as using a JDBC back-end.
How easy it is all depends on how well separated the layers are in the PHP application. For example, if the view layer is well separated, you might be able to replace both controller and model logic with a Spring MVC application that uses a 'QuercusView' for the view - you may be able to re-use a lot of the PHP view logic.
You should also consider how you can make a survey of the PHP code - maybe a script that extracts all the function calls, imports etc. so you can quickly test the Quercus support for them.
Sorry, I haven't used the PHP-Java bridge, but I think the Quercus library is pretty mature these days, so that would be my first choice for a staged migration.
My experiences with Querces are not so good. Maybe it has improved, but when I tried it something like two years ago (a long time, I know) it was far from complete and did not support all functions yet. Also, if your application is using some extensions (e.g. from PECL) you will experience difficulties getting this up and running under Querces.
We're currently in the process of migrating a web application from PHP to Java. We're designing a SOA and we'll probably replace some data access objects in the PHP application with a version that talks to internal webservices. Currently we're using Thrift as protocol for our internal webservices, a framework that also has a client available for PHP. We expect this to increase flexibility during migration (allowing us to do step-by-step migration, rather than all-at-once)
PHP/Java Bridge may be of your interest:
The PHP/Java Bridge is an
implementation of a streaming,
XML-based network protocol, which can
be used to connect a native script
engine, for example PHP, Scheme or
Python, with a Java virtual machine.
It is up to 50 times faster than local
RPC via SOAP, requires less resources
on the web-server side. It is faster
and more reliable than direct
communication via the Java Native
Interface, and it requires no
additional components to invoke Java
procedures from PHP or PHP procedures
from Java.
NUMITON may be useful for you:
http://java.dzone.com/announcements/automated-translations-php-jav
The shortest route from PHP to Java
Numiton offers an automated alternative to migrating PHP codebase. This way,
established applications can benefit from the advantages offered by Java in its
enterprise-level capacity.
Some of the risks inherent to any software migration are avoided by using an automated
translation tool. Our PHPtoJava product performs variable type inference,
objectualization and other operations in a uniform manner, the resulting appearance and
behavior being identical to what the users already know.
Of course, the human factor still plays an important role in the post-translation
phases: application fine-tuning and functional testing. The speed and accuracy of the
entire process surpass however those of a manual translation.
One of the applications we have migrated this way is the well-known forum engine
phpBB. The translation result, nBB2, powers our own forum and was recently donated to the
open-source community as a SourceForge project.
PHP in frontend and Java in backend
with separate front (PHP+JavaScript)
and back (Java+SQL) teams
This is technically feasible using SOAP.
using both technologies in a Java
webapp, for example via Quercus with
one or multiple teams
I have no idea about this
migrating everything to Java
This is better option, but it will take time depending on the size & complexity of your project.
I do not have any experience running PHP inside a JVM, but I am betting that IBM does. :)
You might consider Project Zero.
http://www.projectzero.org/php/
Seems similar to Querces or that other thing someone linked. The only other thing that you didn't mention that I can think of is to refactor the PHP code because I'm assuming that its an older codebase written in a PHP 4 manner.
I know this is 2 years old question but i still want to contribute. We are migrating from full java portal to php+java. We have 14 million users. This design doesn't need web services because we use java as json provider for php and js. We will see the result soon...
PHP in frontend and Java in backend with separate front
(PHP+JavaScript) and back (Java+SQL) teams
Are there any what in the Java community would be called "application servers" for .NET? Similar to Tomcat, Resin, and Jetty. I'm not interested in a JSP equivalent, I'm looking for a servlet-based technology for XML/HTTP transaction processing (no UI).
If there is not a product like this, what would a good stack be to emulate this?
Microsoft appears to have dodged this by saying that Window Server + .NET + IIS + your code = app server, but it seems there is a lot of plumbing code that has to be written in order to get to an equivalent place as say Tomcat.
WCF or web services (ASMX) both seem like good candidates for what you want. WCF is probably more appropriate if you don't want to go the full SOAP route. You can host WCF in IIS, a console app, or a windows service. Depending on what you need it can use SOAP, simple XML, or even Json for encodings. As for transports you can use HTTP, IP, or Message Queues.
Dublin will be what you’re looking for, I guess.
I think you are looking for Http Handlers. You can handle the request at a low level without an aspx page. MSDN Reference
Since Microsoft enteprise applications are not targeted to run on any platform like Java, there is less of a need for a .NET equivalent to the Java app server like WebLogic or WebSphere. Many of the technologies provided by the Java app server are provided by either the Windows operating system or the .NET core library. You can draw direct comparisons between individual technologies such as JMS vs. MSMQ, but less so in the overall architecture.
I'm not interested in a JSP equivalent, I'm looking for a servlet-based technology for XML/HTTP transaction processing (no UI).
Sounds like what I do all the time. I use WCF for communication and host the program as a Windows Service. Windows Services have lots of nice things like remote monitoring and the ability to automatically restart in the unlikely event it crashes.