SitePoint Sponsor

User Tag List

Results 1 to 10 of 10

Thread: phpBeans

Hybrid View

  1. #1
    SitePoint Enthusiast hantu's Avatar
    Join Date
    Oct 2004
    Location
    Berlin
    Posts
    54
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    phpBeans

    Just as an information, in case it hasn't been noticed:

    Take a look at http://www.phpbeans.com/, a RMI implementation for PHP.

  2. #2
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Oklahoma
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Is there a reason you chose to use TCP/IP sockets and a proprietary protocol for the transfer? I would think that leveraging existing tech such as web-services would make this a far simpler project. I would also imagine you would actually see performance gains, not losses, since you gain the ability to use Apache to load balance the traffic on both ends.

  3. #3
    SitePoint Member
    Join Date
    Oct 2003
    Location
    winnipeg
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Smile phpBeans explanation

    Hi Sgarissta,

    I'm the developer of phpBeans. I'll try to explain why I did things the way I did, which will hopefully clear up some confusion about the project.

    HTTP is simply an added layer over TCP/IP which went against the goal one of the features of the protocol, which is that it is stateful. Meaning that you connect once, make several queries, then disconnect, as opposed to connecting and disconnecting for each query, as is generally the case with web services over HTTP. So phpBeans going straight to TCP/IP is actually faster than doing it over HTTP.

    Also, I didn't start from scratch, I used the Net_Server package from PEAR, which makes it very easy to write a TCP/IP daemon. The protocol itself is also pretty much stock PHP functions: parse_url() for parsing client requests, and serialize() for sending server responses.

    As for using web services (ie. SOAP or XML-RPC), please take a look at this article for a comparison of phpBeans against the two:

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

    I'm working on another comparing it to Java RMI, EJB, and Corba, since phpBeans is much more akin to those in both structure and purpose.

    Hope this clarifies a few of my phpBeans design decisions.

    Cheers,

    Lux

  4. #4
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    While I do se the point of using a constant connection as opposed to the stateless HTTP, I'm a bit curious why you didn't just use some kind of session-id to emulate state, witch seems to be the common solution ?
    I recognize the effeciency gain, but it might have been better to follow the trail of XML-RPC et al and make a layered protocol, so that it could be run either over TCP/IP or HTTP (or anything else for the matter). It could perhaps be made as an extension to the current project ?

    On a sidenote, I was wondering while reading the comparison to XML-RPC and SOAP - how well does phpbeans cope with non-ascii characters ? Is all data send as UTF-8 or do you use something like base64 to protect exotic chars ?

  5. #5
    SitePoint Member
    Join Date
    Oct 2003
    Location
    winnipeg
    Posts
    5
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Smile protocols and i18n

    Quote Originally Posted by kyberfabrikken
    While I do se the point of using a constant connection as opposed to the stateless HTTP, I'm a bit curious why you didn't just use some kind of session-id to emulate state, witch seems to be the common solution ?
    I recognize the effeciency gain, but it might have been better to follow the trail of XML-RPC et al and make a layered protocol, so that it could be run either over TCP/IP or HTTP (or anything else for the matter). It could perhaps be made as an extension to the current project ?
    One of the future goals of the project is to build "connectors" to other service types, kind of like how Jabber servers have transports to the other IM services out there. The idea will hopefully allow a phpBeans server to talk to clients of any type, as long as the connector for those clients is installed.

    Quote Originally Posted by kyberfabrikken
    On a sidenote, I was wondering while reading the comparison to XML-RPC and SOAP - how well does phpbeans cope with non-ascii characters ? Is all data send as UTF-8 or do you use something like base64 to protect exotic chars ?
    The server seems to handle non-ascii characters just fine (I just sent it some Russian, which it sent back unharmed). However, the client doesn't automatically decode Unicode-encoded values (ie. %u043F%u0440%u0438%u0432%u0435%u0442 is not decoded to привет as it should be). However, urldecode() and rawurldecode() don't handle these either, which means people would need a custom function to decode them. I'll have to include that in an update for the client libraries.

    Cheers,

    Lux

  6. #6
    SitePoint Wizard silver trophy someonewhois's Avatar
    Join Date
    Jan 2002
    Location
    Canada
    Posts
    6,364
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    While I do se the point of using a constant connection as opposed to the stateless HTTP, I'm a bit curious why you didn't just use some kind of session-id to emulate state, witch seems to be the common solution ?
    I recognize the effeciency gain, but it might have been better to follow the trail of XML-RPC et al and make a layered protocol, so that it could be run either over TCP/IP or HTTP (or anything else for the matter). It could perhaps be made as an extension to the current project ?

    On a sidenote, I was wondering while reading the comparison to XML-RPC and SOAP - how well does phpbeans cope with non-ascii characters ? Is all data send as UTF-8 or do you use something like base64 to protect exotic chars ?
    Why would you "emulate" state when it's fairly easy to write your own? Standards can be limiting, can be hard to implement, can be a pain to expand off of. If you write your own protocol, you're pretty much gauranteed to be scalable, as you (should) have stuff planned out.

  7. #7
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Oklahoma
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by someonewhois
    Why would you "emulate" state when it's fairly easy to write your own? Standards can be limiting, can be hard to implement, can be a pain to expand off of. If you write your own protocol, you're pretty much gauranteed to be scalable, as you (should) have stuff planned out.
    I wouldn't exactly say that a socket server written in PHP is going to be more scalable than an apache setup. While the native TCP/IP may be fine in small situations, do you have it threaded to help with large load?

    I also noticed that you have (or plan on having) several clients available for other languages, to me this seems like exact case for SOAP or XML-RPC, communication between disparate environments, while preserving types.

  8. #8
    SitePoint Wizard silver trophy someonewhois's Avatar
    Join Date
    Jan 2002
    Location
    Canada
    Posts
    6,364
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Sgarissta
    I wouldn't exactly say that a socket server written in PHP is going to be more scalable than an apache setup. While the native TCP/IP may be fine in small situations, do you have it threaded to help with large load?

    I also noticed that you have (or plan on having) several clients available for other languages, to me this seems like exact case for SOAP or XML-RPC, communication between disparate environments, while preserving types.
    It's MUCH easier to expand off of your own protocol, due the basic principal that can add commands. I'll agree, XML-RPC is another way to go, but personally I'd probably chose sockets. It's just easier, especially when you're starting out. Standards make senes. I don't hate standards, I just feel it's easier to develop with my own stuff. Obviously if it's a single client->server single-message, XML-RPC is definitely the easiest way to go... but persistant connections have their places, and HTTP doesn't do that. I've never threaded in PHP (not true, I have in testing, but nothing full scale). If I have to write a real server, it would be done in C. For personal projects that sometimes hold connections open, I do use unthreaded persistant connections, as it's not expecting more than 1 person on at once.

  9. #9
    SitePoint Zealot
    Join Date
    Jul 2004
    Location
    Oklahoma
    Posts
    119
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by someonewhois
    It's MUCH easier to expand off of your own protocol, due the basic principal that can add commands. I'll agree, XML-RPC is another way to go, but personally I'd probably chose sockets. It's just easier, especially when you're starting out. Standards make senes. I don't hate standards, I just feel it's easier to develop with my own stuff. Obviously if it's a single client->server single-message, XML-RPC is definitely the easiest way to go... but persistant connections have their places, and HTTP doesn't do that. I've never threaded in PHP (not true, I have in testing, but nothing full scale). If I have to write a real server, it would be done in C. For personal projects that sometimes hold connections open, I do use unthreaded persistant connections, as it's not expecting more than 1 person on at once.
    I fully understand the ease of expanding a home-grown protocol as opposed to an inherited one. But during the early phases of a project especially there are huge gains in using established protocols with large support bases. Also, I find if I pick a mature and stable protocol from the start, rarely should I need to make a major expansion of it. XML-RPC and SOAP both are just basic transport mechanisms, and in a tightly controlled environment can be ridiculously flexible. And obviously for a multi-threaded server PHP would be the wrong choice, but can you beat the flexibility and stability of Apache ?

    I just find that when working on large demanding projects, leveraging existing stable technologies tends to give me a boost in productivity and let me focus more on the product itself, and not the "support" code.

    All of this is purely academic argument as I fully understand (and more often than not do) the fun of writing things just to say you've done it. Or to write something in a way, or using an inefficient method just for the sake of learning. I just tend not to make those projects I share

  10. #10
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This looks very interesting, thank you for the link. I have a feeling this project is going places

    If its not too much to ask, can you summarize the differences or similarities between JavaBeans and phpBeans?
    Garcia


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •