developers familiar with CORBA?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I am aware that PHP can access the CORBA framework using PHP-ORBit or
Universe. But how many developers or companies would feel comfortable
developing a fully client-server application this way?

To be more specific, assume the following scenario. I wish to build a
web application and want to outsource the front-end design (HTML, CSS,
text, graphics) and related technical functionality (sessions, user
login), but keep all of the business object logic internal to my
company. I would spec a unified service interface so that all requests
to my internal code would be standardised.

How many of you are comfortable working that way?

Please note that is not yet a job posting. :-) I'm just doing some

-- Robin Parmar

Re: developers familiar with CORBA?

robin wrote:
Quoted text here. Click to load it

Personally, I believe this is the exactly right approach. However, I'm all
for using SOAP or at least XML-RPC rather than CORBA, especially as PHP5 has
a native support for SOAP and also because PHP, as a stateless language, is
much more suited to work with HTTP-based protocols.


Re: developers familiar with CORBA?

Quoted text here. Click to load it

I hope you are not trying to imply that php is like finite state automata or
less, since all those jsp and asp advocates would be all over us very
quickly ;)

Your argument of SOAP being built in is valid and important. With argument
that SOAP fits more naturally, I dissagree, since I do not see any important
aspect where SOAP more naturaly fits than CORBA since they both issue remote
calls. And lastly SOAP is a very spoiled pig for resources. I can hardly
imagine efficient site built in a way that for each page displayed, php
calls out server with SOAP, waits for response, renders output and displays

-- / /

Re: developers familiar with CORBA?

rush wrote:
Quoted text here. Click to load it

I'm not sure what you mean by "finite state automata"; by stateless, I mean
that PHP has no internal mechanism for keeping keeping track os objects and
their states. Each time a PHP script is invoked it has to rebuild its
environment all over again from scratch, using mechanisms such as
serialization, cookies and databases to keep track of objects' states. While
Java servlets and ASP both have "application-scoped" objects, PHP's approach
is more natural when it comes to serving data over HTTP (what it's mostly
used for), which itself has no state tracking.

Quoted text here. Click to load it

But you can easily imagine an efficient site built in a way that for each
page displayed, php calls out a database, waits for response, renders output
and displays it?

IMO, SOAP server/client communication between elements of a single
application/site adds only a small overhead above what we usually see in
other types of communication, while adding significant flexibility in data
sources on one hand and serving own data to other clients on the other.


Re: developers familiar with CORBA?

Quoted text here. Click to load it

sure, but while the script runs (and issues remote calls) it has a tons of
state, and that is what it counts in this particular case. No matter if you
issue SOAP or CORBA call, your php script will marshall request, send it
over the wire, wait for response, unmarshal response, continue with
execution of the script. Fact that one usually uses text based protcol over
http messages, and another usually uses binary format over the raw socket
connection is in both cases transparent to the programming language user, so
izt makes no sense to claim (on that basis at least) that one is better fit.
As a matter of fact from, the language interface point of view, one could
implement SOAP calls over binary sockets, and CORBA with text protocol on
http messages,and they would remain the same semantics, and language
interface (but different performance).

One should not mix nature of http protocol, with nature of the language.

Quoted text here. Click to load it

sure, since calls to database are reasonably efficiently implemented. Calls
to the SOAP are on the other hand impractical for each and every page
display, unless you have a very small number of patient users and oversized

-- / /

Site Timeline