"php beans"

Wednesday 12 January 2005 8:44:14 pm

This might better fit the suggestions topic, but...

I wonder if anyone thinks this is a radical new tool or if it has some application or usefulness for the eZ publish architecture.

http://www.phpbeans.com/index/news-app/story.4

http://www.phpbeans.com/index/news-app/story.3

The basic concept of phpBeans is a client/server model, where objects that live on the server are accessible to the client via a TCP/IP-based protocol.

phpBeans uses a single TCP/IP connection for an entire client/server session, whereas the others offer a stateless execution model, where each request to the server is an independent connection. This allows XML-RPC, SOAP, and REST to potentially change the underlying communication layer (ie. SOAP over HTTP over TCP/IP, or SOAP over SMTP over TCP/IP), whereas phpBeans is restricted to phpBeans over TCP/IP.

This means that XML-RPC, SOAP, and REST apply to a wider variety of situations than phpBeans. It also means that the phpBeans protocol is faster than any of them.

Calling objects via the phpBeans client API is almost completely transparent, the only difference being the way the objects are instantiated within the client (via the phpBeans API instead of with the usual $instance = new ObjectName () syntax).

Similarly on the server-side, creating objects (called 'beans' in phpBeans terminology) is simply a matter of writing an ordinary PHP class, with the only difference being that these classes extend a generic PHP_Bean class, and there are a few simply lines to be copied into the constructor method of each class.

With that small of a difference, your PHP applications have instantly gained a host of benefits, including:

* Increased scalability. A true separation of your application logic (beans) and your publishing code (the client, usually -- but not necessarily -- a web server serving a web-based application) enables you to better scale your applications by inserting redundancies, such as load-balancing, extra hardware, optimized operating systems, into each stage of the application execution. This is referred to as an n-tier application architecture.
* Increased security. By keeping your business logic a layer away from your public-facing servers, you gain more control over who can access your code and how.
* Increased flexibility. Having a solid, standards-based foundation to build on means more options as your application and company needs grow. And having a well architected application structure allows you to get more out of your code, without the worries of it growing into unmanageable spaghetti code that are often associated with Open Source technologies.

Some additional benefits offered specifically by the phpBeans specification include:

* Passworded access control based on a client's username and hostname/IP. You can also restrict any user to specific objects.
* Introspection and auto-discovery of object and method names and descriptions.
* Beans are simply ordinary PHP classes, nothing fancy or new to learn. The client API transparently mimicks the remote objects, so there really is nothing fancy or new to learn.
* Beans are documented using standard phpDoc documentation syntax. Methods are only published which have an @access public tag. And because phpDoc is used by the server itself, it encourages class writers to better document their code for use by others.
* Very simple object persistence layer, which enables storing and restoring of live objects in a single line of code.
* Built-in access log API for better visibility into your applications and their day-to-day real-world usage.
* The communication protocol is both very simple and very lightweight. Clients pass the server URI-formatted requests, and the server responds with serialized PHP data structures.
* While phpBeans is admittedly a PHP-centric specification, by no means does that exclude other languages and technologies, nor does it imply that either the client or the server must be written in PHP. In fact, projects are being planned that will expand the phpBeans compatibility to other languages as well.

Thursday 13 January 2005 12:58:55 am

Hi Björn,

I didn't know the project, too. When I looked on the page, I didn't consider to use it instead of using Soap. I think, like Tom C wrote, it could be an additional layer in the eZ publish structure: you have your webserver (the client, probably in a DMZ) and in another - better secured - section of your network you place the bean server (written in C!).

I think this could

- increase security, because you do not have the database password saved on the public webserver; if someone logs in, you send a request to the bean server. So someone needs to crack the webserver and the bean server to reach the site data

- decrease response time, because (probably) the server caches the content and the bean client (eZ publish) is much simpler; eventually the hole persistence layer and more could be transfered to the bean server.

And in this point I see the problems: probably it is not so easy to migrate eZ publish to work with the bean server. There is so much program logic in the CMS that must be rewritten.

Perhaps it is easier with Derick's Scritp Running Machine, but I don't belive so. In my opinion, something like this would benefit the enterprise segment and would be a great plus to eZ publish. Perhaps this could be an option, when rewritting for eZ Publish version 4 with PHP 5 (and perhaps some PEAR-Packages?).

Another question/problem is the professional license...

Many greetings form Freiburg/Germany

Thomas

Friday 14 January 2005 11:02:25 am

This sound a lot like a (simpler) port of Enterprise Java Beans to php. IMHO (and I'm far from there) EJB has never been a got idea. It's slow (distributed systems are always victim to that because of the serialization going on) and overly complex to program too. I wouldn't want to introduce that to PHP (many Java developers are avoiding EJB if at all possible).

Visit http://triligon.org

Saturday 15 January 2005 3:06:05 am

Hello,
here are my thoughts if any is interesting

I think ezPublish should think about it a lot before considering using such concepts in the internal mechanisms of ezPublish. (I'm sure they will ;-) )

I'm sure phpbean is interesting as a project, and in some case can be use as an interoperability layer (with some very limitating prerequisites) but i don't think it's a good strategy for PHP and EzPublish to adopt those kind of design.

Even J2EE is now trying to evolve to concepts that are simpler. EJB, RMI and before , Corba, were far too complicated for building web application.

I'm sure both PHP and ezPublish have to go to Enterprise solutions.
But not copying J2EE, simply improving quality and still relying on the strength of PHP : simple to use, build for Web (and not for highly transactionnal back en d systems), simple to learn, simple to set up (no compilations, no Ant scripts for deployment ...)

They are to many projects trying to port J2EE to PHP. They are interesting as experiments, i don't think more.
I've look at this Phing project, it is porting well known Java tools "ANT" to PHP. For me, this is a "non sense" even if Phing is really a nice piece of code.

If ever anyone is interesting in looking at those kind of work, there is the Mojavi project, wich is an MVC implementation for PHP5, that could be really interesting, even when working on the port of ezPublish to PHP5.
http://www.mojavi.org/