developers familiar with CORBA?

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
research!

-- Robin Parmar

robin wrote:
> 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
> research!

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.

Berislav

"Berislav Lopac" <berislav.lopac@lopsica.com> wrote in message
news:cpke6c$kf6$1@garrison.globalnet.hr...

> a native support for SOAP and also because PHP, as a stateless language,
is

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
it.

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/

rush wrote:
> "Berislav Lopac" <berislav.lopac@lopsica.com> wrote in message
> news:cpke6c$kf6$1@garrison.globalnet.hr...
>
>> a native support for SOAP and also because PHP, as a stateless
>> language, is
>
> 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 ;)

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.

> 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 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.

Berislav

"Berislav Lopac" <berislav.lopac@lopsica.com> wrote in message
news:cpkfsq$l0q$1@garrison.globalnet.hr...
> 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.

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.

> 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.

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
servers.

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/