php-based J2EE approach?
I was a little puzzled by this, after reading and getting excited about the direction of ActiveGrid, and the concept of lamp5 and Web Services in general. apparently, Simian is attempting to create a J2EE-like server based on php.
the phpBeans (similar to EJB's - Enterprise Java Beans), the phpBeans Object Server, and phpBeans Client API allow php objects to be encapsulated in such a way that they may invoke one another on remote machines and all that jazz.
what I find particularly puzzling is that Web Services enable the same kind of thing. you wrap up your php classes and expose them with WSDL's, and I use SOAP clients to invoke them from anywhere else in the world. but the use of a phpBean and phpBean Object Server takes that cool concept OFF of standardized protocols like SOAP, HTTP, etc and puts it into a client API.
but exposing your php classes/objects as web services means ANY program on ANY platform can use them. exposing your php classes by making them phpBeans and putting them on a phpBeans Object Server means only other php classes that use the phpBeans Client API can use them.
though both ActiveGrid and phpBeans are in their infancy (though they are more mature than lamp5!), I would like to see developers embrace the ActiveGrid approach more than the phpBeans approach. I think web services are being adopted by enterprises in place of approaches like J2EE and CORBA and other language-oriented integration methods.
the phpBeans (similar to EJB's - Enterprise Java Beans), the phpBeans Object Server, and phpBeans Client API allow php objects to be encapsulated in such a way that they may invoke one another on remote machines and all that jazz.
what I find particularly puzzling is that Web Services enable the same kind of thing. you wrap up your php classes and expose them with WSDL's, and I use SOAP clients to invoke them from anywhere else in the world. but the use of a phpBean and phpBean Object Server takes that cool concept OFF of standardized protocols like SOAP, HTTP, etc and puts it into a client API.
but exposing your php classes/objects as web services means ANY program on ANY platform can use them. exposing your php classes by making them phpBeans and putting them on a phpBeans Object Server means only other php classes that use the phpBeans Client API can use them.
though both ActiveGrid and phpBeans are in their infancy (though they are more mature than lamp5!), I would like to see developers embrace the ActiveGrid approach more than the phpBeans approach. I think web services are being adopted by enterprises in place of approaches like J2EE and CORBA and other language-oriented integration methods.
posted by luke @ 3:56 PM
2 Comments:
Hi Luke, thanks for the post about my new project (I'm the developer of phpBeans). I thought it might help to clarify a couple of things about the software, which will hopefully dispell a few fears you and others might have about it:
First, phpBeans is meant to fill a space that SOAP and XML-RPC aren't completely appropriate for. This space is much more akin to Java's RMI and OMG's Corba technologies. Figuring that people would compare phpBeans most often to SOAP and XML-RPC, I wrote an article comparing and contrasting it with them, in the hopes of better explaining where each of them is most appropriate:
http://www.phpbeans.com/index/news-app/story.4
Second, what I am trying to do primarily is not to create new software but to create a new standard. While this standard is PHP-oriented, it is not at all PHP-only. In fact, there is already a Ruby client library available, and we hope to offer many more soon:
http://www.phpbeans.com/index/client_for_ruby
So the only way the phpBeans protocol limits you is in the same way that SOAP limits you from using Corba or Java RMI limits you from XML-RPC.
Third, what phpBeans does is different from ActiveGrid as well (as far as I've read about ActiveGrid), since phpBeans is intended to sit behind the publishing layer of the application. phpBeans would contain the business logic of an application, while an HTTP web server would call the business logic layer then compile it into whatever format is requested (HTML, XML, RSS, SOAP, etc.). In MVC terms, phpBeans contains the Model.
We're also planning ways of making phpBeans interoperate better with other standards like SOAP (probably via the idea of "connectors"), but keep in mind that we're trying to do so with the emphasis on creative specifications first, software second. As I said in our press release: in order for PHP to gain acceptance [at the enterprise level] it needs to increase its focus on web standards. When an existing standard doesn't adequately cover a certain area, the axiom "the right tool for the job" would suggest that we create a new standard or a new tool that solves it best. And SOAP is definitely not a one-size-fits-all solution. ;)
I hope this helps clarify where our project is coming from, as I really do think this is one of the things PHP needs in order to be taken seriously.
Cheers,
Lux
thanks for coming by my blog, and thanks for leaving the links and the info. I think there is a place for phpBeans and other RMI-style distributed computing, and the solution would be very beneficial for distributed computing projects that will be written under a controlled architecture.
most of my interest in Web Services is focused on the B2B integration area, where a person may have little or no control over the architecture and language of the systems they'll be interacting with. for example, to process an inbound order, we might have to hit a 3rd party inventory management program, like GAINS, written in Java, and we also need to update our own Informix database, and interact with our custom-built credit checking program written in ColdFusion, then use an online currency converter, etc, etc.
if the interactions between these very heterogenous systems can be standardized using a SOAP client that hits all their WSDL's, it's almost simple to work with them all.
I can see phpBeans architecture being very well suited for, as you say, an enterprise looking to take their php scripts up a notch to get scalability, reliability, redundancy, and all the benefits that come with having a good distributed platform. but I would think they need to have a good deal of control over how their code interacts with the phpBeans, which is not really possible in the kind of environment I described above.
Post a Comment
<< Home