You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@ws.apache.org by Sanjiva Weerawarana <sa...@watson.ibm.com> on 2001/03/27 05:07:00 UTC
CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
"Sebastian Andersson" <sa...@hogia.net> writes:
>
> RPC by any other name is still RPC in my book, so I compare SOAP with
> CORBA and Sun-RPC. I accessed filesystems 7 years ago via NFS over
> Sun-RPC where the NFS server was in USA and the client was in Europe.
> We didn't call it web service then, but I guess today that would have
> been a press release and a great win for the "new technology". I seem
> to recall something about XML-Store together with the .NET press
> releases from MS.
You're right in saying that there's nothing fundamentally new in
the Web services stack that didn't exist in the OMG OMA. What is new
is that its another turn of the crank .. and as technology goes, we
know that it takes a few iterations to get it just right and to solve
the problem to the "right" level. Java (the concept) was invented back
in about 1970 (P-Code) .. but it took several iterations (emacs, NeWS,..)
before it was the "right technology at the right time."
Similarly CORBA does some things really well, but it didn't really make
it as a universal distributed computing platform. All this Web services
stuff (IMO) is just another crank at getting it better so that it'll
have "better" unversality. Nothing more, nothing less.
> I fail to see whats new and great with SOAP that Sun-RPC didn't have
> almost a decade ago. Maybe the new idea is that we put a file on
> a webserver which tells the clients were the server is and how the IDL
> looks like? The NFS server I used, was found by a document on an ftp
> site. Previous you got an IDL together with the documentation (or a
> link to it) since you usualy only needed it while implementing
> the client/server. Today you don't get documentation? Formerly we
> found the server by quering the DNS for a name and asked a naming
> server where the service was. Today we query the DNS for the name of
> a http-server which will tell us the name of the service & server-proxy
> so we can query the DNS for the name of the service-proxy so we can
> tell it the name of the service we want to talk to. Maybe its easier
> for windows programmers to set up their own http server (or get access
> to one) than it is for them to set up their own name server or get
> access to one?
>
> Currently SOAP are availible for less languages/platforms than CORBA
> or Sun-RPC are so SOAP holds no advantage there.
>
> The IDLs for Sun-RPC and CORBA are a lot easier to read and understand
> compared to XML Schemas.
>
> You can buy mature bridges between many protocols and CORBA
> (ie DCOM). There are firewalls today that understands CORBA.
>
> CORBA & Sun-RPC are faster to (de)marshall and they use less bandwidth
> which leads to higher performance.
As the next iteration, we will get some things done better than the
older iteration (hopefully) and make fewer poor choices (hopefully).
The overriding theme of this iteration is a looser coupling than the
OMA and interaction via SOAP-like protocols which are (hopefully) more
malleable than GIOP. Is it going to succeed for sure? I doubt anyone
knows .. if the balance between good choices vs. poor choices is
just right (w.r.t. solving the real problems and not imaginery ones)
then it will. If not we'll try again another day under another name!
> CORBA also provides a whole lot of the infrastructure you might need
> together with your "web services", ie transactions.
Some of these infrastructure services will need to evolve for the
Web services stack too before all is said and done.
> But I expect SOAP to "win" anyway via the VS tools and all
> the developers on the MS platforms. The customers sees a lot of
> buzzwords and they want it. The CORBA implementators have mostly
> given the users power and robustness instead of an quick and easy
> way to implement simple clients & servers which has put a lot of
> developers in dummy mode when they look at CORBA.
> Some of the langauge bindings for CORBA has not been the best either.
The OMA has a lot to offer in terms of evolving the Web services
stack. Learning from past experience is essential to have any hope
of succeeding this time around!
Sanjiva.
p.s.: Before anyone wonders, I'm speaking for myself .. not the company
I work for. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by David Forslund <dw...@lanl.gov>.
At 09:16 AM 3/27/2001 -0500, Silvio Fiorito wrote:
> >I find that writing a SOAP interface is a lot harder than a CORBA one,
>which is
> >pretty much done automatically. Perhaps there are or will be SOAP tools
>that
> >automatically create object stubs, but I haven't seen them yet.
I agree that .NET will make this easy but not necessarily for non NET
platforms.
The IdooXoap looks very nice but since it creates interfaces from an
implementation language,
it still comes from the world that I don't need to worry about standard
interfaces for services.
I guess what I want is the ability to create a WSDL file automatically from
an ISO IDL and then
automatically generate the language stubs needed. Is this available
somewhere? That,
along with a SOAP/CORBA bridge should allow interoperability between the
numerous existing CORBA
services and SOAP. It doesn't deal with the fact that many new SOAP
services which duplicate
existing CORBA services are coming into existence. This is equivalent to
having to have multiple
non-interoperable DNS services to look up machine names and locations on
the Internet before
being able to talk to the system.
Thanks,
Dave
>Well, on the Windows side MSFT has the WSDL generator which simply takes a
>COM object and creates the WSDL and ASP files for it. There are similar
>tools for the Java side as well: IdooXoap has a Java2WSDL generator and a
>ServiceCompiler that creates Java proxy objects from WSDL (I was able to use
>this to hit against one of my MSSOAP endpoints). I believe in the upcoming
>VisualStudio.NET you'll be able to make an object SOAP accessible simply by
>setting a property in the IDE and the compiler will take care of the rest.
>For client-side code, I think I remember reading that it'll support SOAP
>"natively" allowing you to set references to WSDL files as you would a COM
>object and just make SOAP completely transparent. Obviously the majority of
>people on this list don't really care about VisualStudio.NET, but I'm just
>using it as an example. I'm sure the Java IDE's will have similar support
>(hopefully).
>
>Silvio
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
>For additional commands, email: soap-user-help@xml.apache.org
David W. Forslund dwf@lanl.gov
Computer and Computational Sciences http://www.acl.lanl.gov/~dwf
Los Alamos National Laboratory Los Alamos, NM 87545
505-665-1907 FAX: 505-665-4939
RE: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by David Forslund <dw...@lanl.gov>.
At 09:16 AM 3/27/2001 -0500, Silvio Fiorito wrote:
> >I find that writing a SOAP interface is a lot harder than a CORBA one,
>which is
> >pretty much done automatically. Perhaps there are or will be SOAP tools
>that
> >automatically create object stubs, but I haven't seen them yet.
I agree that .NET will make this easy but not necessarily for non NET
platforms.
The IdooXoap looks very nice but since it creates interfaces from an
implementation language,
it still comes from the world that I don't need to worry about standard
interfaces for services.
I guess what I want is the ability to create a WSDL file automatically from
an ISO IDL and then
automatically generate the language stubs needed. Is this available
somewhere? That,
along with a SOAP/CORBA bridge should allow interoperability between the
numerous existing CORBA
services and SOAP. It doesn't deal with the fact that many new SOAP
services which duplicate
existing CORBA services are coming into existence. This is equivalent to
having to have multiple
non-interoperable DNS services to look up machine names and locations on
the Internet before
being able to talk to the system.
Thanks,
Dave
>Well, on the Windows side MSFT has the WSDL generator which simply takes a
>COM object and creates the WSDL and ASP files for it. There are similar
>tools for the Java side as well: IdooXoap has a Java2WSDL generator and a
>ServiceCompiler that creates Java proxy objects from WSDL (I was able to use
>this to hit against one of my MSSOAP endpoints). I believe in the upcoming
>VisualStudio.NET you'll be able to make an object SOAP accessible simply by
>setting a property in the IDE and the compiler will take care of the rest.
>For client-side code, I think I remember reading that it'll support SOAP
>"natively" allowing you to set references to WSDL files as you would a COM
>object and just make SOAP completely transparent. Obviously the majority of
>people on this list don't really care about VisualStudio.NET, but I'm just
>using it as an example. I'm sure the Java IDE's will have similar support
>(hopefully).
>
>Silvio
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
>For additional commands, email: soap-user-help@xml.apache.org
David W. Forslund dwf@lanl.gov
Computer and Computational Sciences http://www.acl.lanl.gov/~dwf
Los Alamos National Laboratory Los Alamos, NM 87545
505-665-1907 FAX: 505-665-4939
RE: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by graham glass <gr...@mindspring.com>.
check out GLUE at
http://www.themindelectric.com/products/glue/userguide.html
it does everything dynamically at runtime based on java interfaces,
and doesn't even need stub/WSDL generators. that's simpler than
any CORBA implementations that i'm aware of, or even RMI for that matter.
cheers,
graham
-----Original Message-----
From: Silvio Fiorito [mailto:silvio@ntr.net]
Sent: Tuesday, March 27, 2001 8:17 AM
To: soap-user@xml.apache.org
Subject: RE: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
>I find that writing a SOAP interface is a lot harder than a CORBA one,
which is
>pretty much done automatically. Perhaps there are or will be SOAP tools
that
>automatically create object stubs, but I haven't seen them yet.
Well, on the Windows side MSFT has the WSDL generator which simply takes a
COM object and creates the WSDL and ASP files for it. There are similar
tools for the Java side as well: IdooXoap has a Java2WSDL generator and a
ServiceCompiler that creates Java proxy objects from WSDL (I was able to use
this to hit against one of my MSSOAP endpoints). I believe in the upcoming
VisualStudio.NET you'll be able to make an object SOAP accessible simply by
setting a property in the IDE and the compiler will take care of the rest.
For client-side code, I think I remember reading that it'll support SOAP
"natively" allowing you to set references to WSDL files as you would a COM
object and just make SOAP completely transparent. Obviously the majority of
people on this list don't really care about VisualStudio.NET, but I'm just
using it as an example. I'm sure the Java IDE's will have similar support
(hopefully).
Silvio
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by graham glass <gr...@mindspring.com>.
check out GLUE at
http://www.themindelectric.com/products/glue/userguide.html
it does everything dynamically at runtime based on java interfaces,
and doesn't even need stub/WSDL generators. that's simpler than
any CORBA implementations that i'm aware of, or even RMI for that matter.
cheers,
graham
-----Original Message-----
From: Silvio Fiorito [mailto:silvio@ntr.net]
Sent: Tuesday, March 27, 2001 8:17 AM
To: soap-user@xml.apache.org
Subject: RE: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
>I find that writing a SOAP interface is a lot harder than a CORBA one,
which is
>pretty much done automatically. Perhaps there are or will be SOAP tools
that
>automatically create object stubs, but I haven't seen them yet.
Well, on the Windows side MSFT has the WSDL generator which simply takes a
COM object and creates the WSDL and ASP files for it. There are similar
tools for the Java side as well: IdooXoap has a Java2WSDL generator and a
ServiceCompiler that creates Java proxy objects from WSDL (I was able to use
this to hit against one of my MSSOAP endpoints). I believe in the upcoming
VisualStudio.NET you'll be able to make an object SOAP accessible simply by
setting a property in the IDE and the compiler will take care of the rest.
For client-side code, I think I remember reading that it'll support SOAP
"natively" allowing you to set references to WSDL files as you would a COM
object and just make SOAP completely transparent. Obviously the majority of
people on this list don't really care about VisualStudio.NET, but I'm just
using it as an example. I'm sure the Java IDE's will have similar support
(hopefully).
Silvio
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by Silvio Fiorito <si...@ntr.net>.
>I find that writing a SOAP interface is a lot harder than a CORBA one,
which is
>pretty much done automatically. Perhaps there are or will be SOAP tools
that
>automatically create object stubs, but I haven't seen them yet.
Well, on the Windows side MSFT has the WSDL generator which simply takes a
COM object and creates the WSDL and ASP files for it. There are similar
tools for the Java side as well: IdooXoap has a Java2WSDL generator and a
ServiceCompiler that creates Java proxy objects from WSDL (I was able to use
this to hit against one of my MSSOAP endpoints). I believe in the upcoming
VisualStudio.NET you'll be able to make an object SOAP accessible simply by
setting a property in the IDE and the compiler will take care of the rest.
For client-side code, I think I remember reading that it'll support SOAP
"natively" allowing you to set references to WSDL files as you would a COM
object and just make SOAP completely transparent. Obviously the majority of
people on this list don't really care about VisualStudio.NET, but I'm just
using it as an example. I'm sure the Java IDE's will have similar support
(hopefully).
Silvio
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by Silvio Fiorito <si...@ntr.net>.
>I find that writing a SOAP interface is a lot harder than a CORBA one,
which is
>pretty much done automatically. Perhaps there are or will be SOAP tools
that
>automatically create object stubs, but I haven't seen them yet.
Well, on the Windows side MSFT has the WSDL generator which simply takes a
COM object and creates the WSDL and ASP files for it. There are similar
tools for the Java side as well: IdooXoap has a Java2WSDL generator and a
ServiceCompiler that creates Java proxy objects from WSDL (I was able to use
this to hit against one of my MSSOAP endpoints). I believe in the upcoming
VisualStudio.NET you'll be able to make an object SOAP accessible simply by
setting a property in the IDE and the compiler will take care of the rest.
For client-side code, I think I remember reading that it'll support SOAP
"natively" allowing you to set references to WSDL files as you would a COM
object and just make SOAP completely transparent. Obviously the majority of
people on this list don't really care about VisualStudio.NET, but I'm just
using it as an example. I'm sure the Java IDE's will have similar support
(hopefully).
Silvio
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by David Forslund <dw...@lanl.gov>.
At 10:39 PM 3/26/2001 -0500, you wrote:
> > It isn't clear that SOAP is actually "better" than CORBA. It is a little
> > different,
> > but a lot of things seem to keep being reinvented by the next generation.
>UDDI
> > seems to be creating replacements for the OMG Trader, but without learning
> > a lot from the Trader service, itself.
>
>"Different" is an attempt at better. You do have to accept that being
>able to interact from an app written in VBScript and running inside
>a browser to an app written in Java as an EJB is pretty useful. SOAP
>lets you do that today. Doing that in CORBA is pretty hard, even today.
It isn't that hard to have VBScript talk to CORBA, but the vendors that do
that charge a lot of money.
It is pretty hard to have SOAP work with existing standards such as a
standard IDL for a service.
That, too, is being worked on, but SOAP is far less powerful than CORBA is
(and has been
for some time). When it gets as powerful as CORBA, it will be at least as
complex. Also, if people are
mapping OMG Trader concepts to UDDI, it would be nice to see this
relationship. If I have some time
I might try to provide some of that mapping, as I see it.
>In some ways SOAP* is not any better than CORBA (in performance, for
>example). However, in other ways my intuition is that it is. Technical
>people often disagree on many things :-).
I find that writing a SOAP interface is a lot harder than a CORBA one,
which is
pretty much done automatically. Perhaps there are or will be SOAP tools that
automatically create object stubs, but I haven't seen them yet. I'm not sure
what intuition has to do with the technology. I've been trying to get
higher level
standards in place (such as standard IDL for domain services), and with XML we
have to start some of that work over and getting interoperability between
XML specifications and
IDL specifications may not be all that easy. (But then I don't really
think interoperability is
the goal of many of the XML vendors).
> > I have some doubts that people are really learning from the past, but
> > rather want to have their shot at inventing something that has already been
>
>If you think that those of us helping to define the stack aren't learning
>from the past then please help get it right!
It is hard to get excited about people reinventing things that already
exist. I
only have so much bandwidth to spend. I would like to do things new, not
over again.
However, I try to participate in them as much as I can. Since XML is more of
a data model, it is a little awkward to support objects with XML (but can
be done).
But putting pure ASCII on the wire as a protocol seems a little contrived,
in my opinion,
and certainly not something that one would design from scratch.
> > invented. I don't really see the advantage of SOAP, either, in terms
> > of its "loose coupling". CORBA can be quite loosely coupled or tightly
> > coupled. It is a matter of style, not technology.
>
>Style plays a big role in how technology is adopted .. sort of like
>how syntax plays a big role in how programming languages are adopted. So
>I wouldn't dismiss the value of the implied (or maybe perceived) style
>of a programming model.
I agree that it is good to support a lot of different styles. But style
doesn't necessarily imply
a particular technology. I'm hoping that the SOAP/CORBA bridge standard
that is
being worked on will enable these different styles to work together
transparently. What
is really important is that the underlying models (such as UML models) can
be represented
in various technologies (and this is the goal of the new Model Driven
Architecture effort of the OMG)
and made to work interoperably
Thanks for the discussion,
Dave
>Sanjiva.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
>For additional commands, email: soap-user-help@xml.apache.org
David W. Forslund dwf@lanl.gov
Computer and Computational Sciences http://www.acl.lanl.gov/~dwf
Los Alamos National Laboratory Los Alamos, NM 87545
505-665-1907 FAX: 505-665-4939
Re: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Hi Oisin,
> Not wanting to extend this thread, but unable to hold back my
> two cents...
That makes two of us .. :-).
> Sanjiva, this is a bogon. You can't compare SOAP and CORBA. You can
> compare SOAP and IIOP and you can compare WSDL and IDL. But there's
> too much of an impedence mismatch to compare a simple XML based protocol
> with a distributed object system with services!
You're right, of course. I wasn't comparing SOAP to CORBA; I was
comparing the Web services stack to CORBA (to OMA actually), with
exactly the mapping you said.
> And BTW, if I wanted to do what you suggest, then there is no way I
> would use CORBA or RMI and if there was no SOAP, I'd invent it, or
> use something a little more sophisticated like BEEP. It's
> horses for courses, people.
BEEP? BEEP doesn't compare with SOAP .. BEEP is like HTTP .. an alternate
transport protocol. APEX (if I remember right) is what I would compare
to SOAP. SOAP can easily be carried over BEEP if you wanted to.
> >In some ways SOAP* is not any better than CORBA (in performance, for
> >example). However, in other ways my intuition is that it is. Technical
> >people often disagree on many things :-).
>
> Again, can't compare these two things. Use SOAP and IIOP and it will
> make more sense!
Note that I said "SOAP*" .. I meant SOAP family in a broad sense.
> When you start doing things like defining a naming service, transaction
> services, security services, traders, fault tolerance and failover services,
> object models, notification services, etc *then* you will be not learning
> from the past.
Yes and no .. I agree that some things should not be repeated; however,
there's lots of (very) good ideas in the OMA that need to be brought
forward. Otherwise you're effectively leaving it to each app developer
to re-invent those infrastructure layers as they need them.
> You are both right - although the 'loose coupling' thing as it applies to
> SOAP is a bit of a red herring. Its considered to advance 'loose coupling'
> because it is simply a protocol spec, with no dependence on interchange
> patterns - it's an XML datagram and you don't get much looser than that.
> However, bind it to HTTP and you are connection coupled on a per message
> basis. Bind it to, say, IIOP, and you are connection coupled for a
> 'session'.
> Bind it to some message queuing system and you are not coupled at all.
You're right; SOAP doesn't inherently buy you loose coupling; its the
intended usage pattern that does.
Bye,
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Hi Oisin,
> Not wanting to extend this thread, but unable to hold back my
> two cents...
That makes two of us .. :-).
> Sanjiva, this is a bogon. You can't compare SOAP and CORBA. You can
> compare SOAP and IIOP and you can compare WSDL and IDL. But there's
> too much of an impedence mismatch to compare a simple XML based protocol
> with a distributed object system with services!
You're right, of course. I wasn't comparing SOAP to CORBA; I was
comparing the Web services stack to CORBA (to OMA actually), with
exactly the mapping you said.
> And BTW, if I wanted to do what you suggest, then there is no way I
> would use CORBA or RMI and if there was no SOAP, I'd invent it, or
> use something a little more sophisticated like BEEP. It's
> horses for courses, people.
BEEP? BEEP doesn't compare with SOAP .. BEEP is like HTTP .. an alternate
transport protocol. APEX (if I remember right) is what I would compare
to SOAP. SOAP can easily be carried over BEEP if you wanted to.
> >In some ways SOAP* is not any better than CORBA (in performance, for
> >example). However, in other ways my intuition is that it is. Technical
> >people often disagree on many things :-).
>
> Again, can't compare these two things. Use SOAP and IIOP and it will
> make more sense!
Note that I said "SOAP*" .. I meant SOAP family in a broad sense.
> When you start doing things like defining a naming service, transaction
> services, security services, traders, fault tolerance and failover services,
> object models, notification services, etc *then* you will be not learning
> from the past.
Yes and no .. I agree that some things should not be repeated; however,
there's lots of (very) good ideas in the OMA that need to be brought
forward. Otherwise you're effectively leaving it to each app developer
to re-invent those infrastructure layers as they need them.
> You are both right - although the 'loose coupling' thing as it applies to
> SOAP is a bit of a red herring. Its considered to advance 'loose coupling'
> because it is simply a protocol spec, with no dependence on interchange
> patterns - it's an XML datagram and you don't get much looser than that.
> However, bind it to HTTP and you are connection coupled on a per message
> basis. Bind it to, say, IIOP, and you are connection coupled for a
> 'session'.
> Bind it to some message queuing system and you are not coupled at all.
You're right; SOAP doesn't inherently buy you loose coupling; its the
intended usage pattern that does.
Bye,
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
RE: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by Oisin Hurley <oh...@iona.com>.
Not wanting to extend this thread, but unable to hold back my
two cents...
>"Different" is an attempt at better. You do have to accept that being
>able to interact from an app written in VBScript and running inside
>a browser to an app written in Java as an EJB is pretty useful. SOAP
>lets you do that today. Doing that in CORBA is pretty hard, even today.
Sanjiva, this is a bogon. You can't compare SOAP and CORBA. You can
compare SOAP and IIOP and you can compare WSDL and IDL. But there's
too much of an impedence mismatch to compare a simple XML based protocol
with a distributed object system with services!
And BTW, if I wanted to do what you suggest, then there is no way I
would use CORBA or RMI and if there was no SOAP, I'd invent it, or
use something a little more sophisticated like BEEP. It's
horses for courses, people.
>In some ways SOAP* is not any better than CORBA (in performance, for
>example). However, in other ways my intuition is that it is. Technical
>people often disagree on many things :-).
Again, can't compare these two things. Use SOAP and IIOP and it will
make more sense!
[another person says]
>> I have some doubts that people are really learning from the past, but
>> rather want to have their shot at inventing something that has
>> already been invented
SOAP is not going to replace CORBA - they are not even playing in the
same area. Web Services is not going to replace CORBA or J2EE or ACE
or custom infrastructures. The latter are implementation technologies,
the former is a presentation technology (for the moment at least).
>If you think that those of us helping to define the stack aren't learning
>from the past then please help get it right!
When you start doing things like defining a naming service, transaction
services, security services, traders, fault tolerance and failover services,
object models, notification services, etc *then* you will be not learning
from the past.
>> I don't really see the advantage of SOAP, either, in terms
>> of its "loose coupling". CORBA can be quite loosely coupled or tightly
>> coupled. It is a matter of style, not technology.
>
>Style plays a big role in how technology is adopted .. sort of like
>how syntax plays a big role in how programming languages are adopted. So
>I wouldn't dismiss the value of the implied (or maybe perceived) style
>of a programming model.
You are both right - although the 'loose coupling' thing as it applies to
SOAP is a bit of a red herring. Its considered to advance 'loose coupling'
because it is simply a protocol spec, with no dependence on interchange
patterns - it's an XML datagram and you don't get much looser than that.
However, bind it to HTTP and you are connection coupled on a per message
basis. Bind it to, say, IIOP, and you are connection coupled for a
'session'.
Bind it to some message queuing system and you are not coupled at all.
cheers
--oh
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by David Forslund <dw...@lanl.gov>.
At 10:39 PM 3/26/2001 -0500, you wrote:
> > It isn't clear that SOAP is actually "better" than CORBA. It is a little
> > different,
> > but a lot of things seem to keep being reinvented by the next generation.
>UDDI
> > seems to be creating replacements for the OMG Trader, but without learning
> > a lot from the Trader service, itself.
>
>"Different" is an attempt at better. You do have to accept that being
>able to interact from an app written in VBScript and running inside
>a browser to an app written in Java as an EJB is pretty useful. SOAP
>lets you do that today. Doing that in CORBA is pretty hard, even today.
It isn't that hard to have VBScript talk to CORBA, but the vendors that do
that charge a lot of money.
It is pretty hard to have SOAP work with existing standards such as a
standard IDL for a service.
That, too, is being worked on, but SOAP is far less powerful than CORBA is
(and has been
for some time). When it gets as powerful as CORBA, it will be at least as
complex. Also, if people are
mapping OMG Trader concepts to UDDI, it would be nice to see this
relationship. If I have some time
I might try to provide some of that mapping, as I see it.
>In some ways SOAP* is not any better than CORBA (in performance, for
>example). However, in other ways my intuition is that it is. Technical
>people often disagree on many things :-).
I find that writing a SOAP interface is a lot harder than a CORBA one,
which is
pretty much done automatically. Perhaps there are or will be SOAP tools that
automatically create object stubs, but I haven't seen them yet. I'm not sure
what intuition has to do with the technology. I've been trying to get
higher level
standards in place (such as standard IDL for domain services), and with XML we
have to start some of that work over and getting interoperability between
XML specifications and
IDL specifications may not be all that easy. (But then I don't really
think interoperability is
the goal of many of the XML vendors).
> > I have some doubts that people are really learning from the past, but
> > rather want to have their shot at inventing something that has already been
>
>If you think that those of us helping to define the stack aren't learning
>from the past then please help get it right!
It is hard to get excited about people reinventing things that already
exist. I
only have so much bandwidth to spend. I would like to do things new, not
over again.
However, I try to participate in them as much as I can. Since XML is more of
a data model, it is a little awkward to support objects with XML (but can
be done).
But putting pure ASCII on the wire as a protocol seems a little contrived,
in my opinion,
and certainly not something that one would design from scratch.
> > invented. I don't really see the advantage of SOAP, either, in terms
> > of its "loose coupling". CORBA can be quite loosely coupled or tightly
> > coupled. It is a matter of style, not technology.
>
>Style plays a big role in how technology is adopted .. sort of like
>how syntax plays a big role in how programming languages are adopted. So
>I wouldn't dismiss the value of the implied (or maybe perceived) style
>of a programming model.
I agree that it is good to support a lot of different styles. But style
doesn't necessarily imply
a particular technology. I'm hoping that the SOAP/CORBA bridge standard
that is
being worked on will enable these different styles to work together
transparently. What
is really important is that the underlying models (such as UML models) can
be represented
in various technologies (and this is the goal of the new Model Driven
Architecture effort of the OMG)
and made to work interoperably
Thanks for the discussion,
Dave
>Sanjiva.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
>For additional commands, email: soap-user-help@xml.apache.org
David W. Forslund dwf@lanl.gov
Computer and Computational Sciences http://www.acl.lanl.gov/~dwf
Los Alamos National Laboratory Los Alamos, NM 87545
505-665-1907 FAX: 505-665-4939
RE: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by Oisin Hurley <oh...@iona.com>.
Not wanting to extend this thread, but unable to hold back my
two cents...
>"Different" is an attempt at better. You do have to accept that being
>able to interact from an app written in VBScript and running inside
>a browser to an app written in Java as an EJB is pretty useful. SOAP
>lets you do that today. Doing that in CORBA is pretty hard, even today.
Sanjiva, this is a bogon. You can't compare SOAP and CORBA. You can
compare SOAP and IIOP and you can compare WSDL and IDL. But there's
too much of an impedence mismatch to compare a simple XML based protocol
with a distributed object system with services!
And BTW, if I wanted to do what you suggest, then there is no way I
would use CORBA or RMI and if there was no SOAP, I'd invent it, or
use something a little more sophisticated like BEEP. It's
horses for courses, people.
>In some ways SOAP* is not any better than CORBA (in performance, for
>example). However, in other ways my intuition is that it is. Technical
>people often disagree on many things :-).
Again, can't compare these two things. Use SOAP and IIOP and it will
make more sense!
[another person says]
>> I have some doubts that people are really learning from the past, but
>> rather want to have their shot at inventing something that has
>> already been invented
SOAP is not going to replace CORBA - they are not even playing in the
same area. Web Services is not going to replace CORBA or J2EE or ACE
or custom infrastructures. The latter are implementation technologies,
the former is a presentation technology (for the moment at least).
>If you think that those of us helping to define the stack aren't learning
>from the past then please help get it right!
When you start doing things like defining a naming service, transaction
services, security services, traders, fault tolerance and failover services,
object models, notification services, etc *then* you will be not learning
from the past.
>> I don't really see the advantage of SOAP, either, in terms
>> of its "loose coupling". CORBA can be quite loosely coupled or tightly
>> coupled. It is a matter of style, not technology.
>
>Style plays a big role in how technology is adopted .. sort of like
>how syntax plays a big role in how programming languages are adopted. So
>I wouldn't dismiss the value of the implied (or maybe perceived) style
>of a programming model.
You are both right - although the 'loose coupling' thing as it applies to
SOAP is a bit of a red herring. Its considered to advance 'loose coupling'
because it is simply a protocol spec, with no dependence on interchange
patterns - it's an XML datagram and you don't get much looser than that.
However, bind it to HTTP and you are connection coupled on a per message
basis. Bind it to, say, IIOP, and you are connection coupled for a
'session'.
Bind it to some message queuing system and you are not coupled at all.
cheers
--oh
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
> It isn't clear that SOAP is actually "better" than CORBA. It is a little
> different,
> but a lot of things seem to keep being reinvented by the next generation.
UDDI
> seems to be creating replacements for the OMG Trader, but without learning
> a lot from the Trader service, itself.
"Different" is an attempt at better. You do have to accept that being
able to interact from an app written in VBScript and running inside
a browser to an app written in Java as an EJB is pretty useful. SOAP
lets you do that today. Doing that in CORBA is pretty hard, even today.
In some ways SOAP* is not any better than CORBA (in performance, for
example). However, in other ways my intuition is that it is. Technical
people often disagree on many things :-).
> I have some doubts that people are really learning from the past, but
> rather want to have their shot at inventing something that has already been
If you think that those of us helping to define the stack aren't learning
from the past then please help get it right!
> invented. I don't really see the advantage of SOAP, either, in terms
> of its "loose coupling". CORBA can be quite loosely coupled or tightly
> coupled. It is a matter of style, not technology.
Style plays a big role in how technology is adopted .. sort of like
how syntax plays a big role in how programming languages are adopted. So
I wouldn't dismiss the value of the implied (or maybe perceived) style
of a programming model.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
> It isn't clear that SOAP is actually "better" than CORBA. It is a little
> different,
> but a lot of things seem to keep being reinvented by the next generation.
UDDI
> seems to be creating replacements for the OMG Trader, but without learning
> a lot from the Trader service, itself.
"Different" is an attempt at better. You do have to accept that being
able to interact from an app written in VBScript and running inside
a browser to an app written in Java as an EJB is pretty useful. SOAP
lets you do that today. Doing that in CORBA is pretty hard, even today.
In some ways SOAP* is not any better than CORBA (in performance, for
example). However, in other ways my intuition is that it is. Technical
people often disagree on many things :-).
> I have some doubts that people are really learning from the past, but
> rather want to have their shot at inventing something that has already been
If you think that those of us helping to define the stack aren't learning
from the past then please help get it right!
> invented. I don't really see the advantage of SOAP, either, in terms
> of its "loose coupling". CORBA can be quite loosely coupled or tightly
> coupled. It is a matter of style, not technology.
Style plays a big role in how technology is adopted .. sort of like
how syntax plays a big role in how programming languages are adopted. So
I wouldn't dismiss the value of the implied (or maybe perceived) style
of a programming model.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
For additional commands, email: soap-user-help@xml.apache.org
Re: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by David Forslund <dw...@lanl.gov>.
At 10:07 PM 3/26/2001 -0500, Sanjiva Weerawarana wrote:
>"Sebastian Andersson" <sa...@hogia.net> writes:
> >
> > RPC by any other name is still RPC in my book, so I compare SOAP with
> > CORBA and Sun-RPC. I accessed filesystems 7 years ago via NFS over
> > Sun-RPC where the NFS server was in USA and the client was in Europe.
> > We didn't call it web service then, but I guess today that would have
> > been a press release and a great win for the "new technology". I seem
> > to recall something about XML-Store together with the .NET press
> > releases from MS.
>
>You're right in saying that there's nothing fundamentally new in
>the Web services stack that didn't exist in the OMG OMA. What is new
>is that its another turn of the crank .. and as technology goes, we
>know that it takes a few iterations to get it just right and to solve
>the problem to the "right" level. Java (the concept) was invented back
>in about 1970 (P-Code) .. but it took several iterations (emacs, NeWS,..)
>before it was the "right technology at the right time."
>
>Similarly CORBA does some things really well, but it didn't really make
>it as a universal distributed computing platform. All this Web services
>stuff (IMO) is just another crank at getting it better so that it'll
>have "better" unversality. Nothing more, nothing less.
It isn't clear that SOAP is actually "better" than CORBA. It is a little
different,
but a lot of things seem to keep being reinvented by the next generation. UDDI
seems to be creating replacements for the OMG Trader, but without learning
a lot from the Trader service, itself.
> > I fail to see whats new and great with SOAP that Sun-RPC didn't have
> > almost a decade ago. Maybe the new idea is that we put a file on
> > a webserver which tells the clients were the server is and how the IDL
> > looks like? The NFS server I used, was found by a document on an ftp
> > site. Previous you got an IDL together with the documentation (or a
> > link to it) since you usualy only needed it while implementing
> > the client/server. Today you don't get documentation? Formerly we
> > found the server by quering the DNS for a name and asked a naming
> > server where the service was. Today we query the DNS for the name of
> > a http-server which will tell us the name of the service & server-proxy
> > so we can query the DNS for the name of the service-proxy so we can
> > tell it the name of the service we want to talk to. Maybe its easier
> > for windows programmers to set up their own http server (or get access
> > to one) than it is for them to set up their own name server or get
> > access to one?
> >
> > Currently SOAP are availible for less languages/platforms than CORBA
> > or Sun-RPC are so SOAP holds no advantage there.
> >
> > The IDLs for Sun-RPC and CORBA are a lot easier to read and understand
> > compared to XML Schemas.
I agree.
> >
> > You can buy mature bridges between many protocols and CORBA
> > (ie DCOM). There are firewalls today that understands CORBA.
> >
> > CORBA & Sun-RPC are faster to (de)marshall and they use less bandwidth
> > which leads to higher performance.
>
>As the next iteration, we will get some things done better than the
>older iteration (hopefully) and make fewer poor choices (hopefully).
>The overriding theme of this iteration is a looser coupling than the
>OMA and interaction via SOAP-like protocols which are (hopefully) more
>malleable than GIOP. Is it going to succeed for sure? I doubt anyone
>knows .. if the balance between good choices vs. poor choices is
>just right (w.r.t. solving the real problems and not imaginery ones)
>then it will. If not we'll try again another day under another name!
>
> > CORBA also provides a whole lot of the infrastructure you might need
> > together with your "web services", ie transactions.
>
>Some of these infrastructure services will need to evolve for the
>Web services stack too before all is said and done.
>
> > But I expect SOAP to "win" anyway via the VS tools and all
> > the developers on the MS platforms. The customers sees a lot of
> > buzzwords and they want it. The CORBA implementators have mostly
> > given the users power and robustness instead of an quick and easy
> > way to implement simple clients & servers which has put a lot of
> > developers in dummy mode when they look at CORBA.
> > Some of the langauge bindings for CORBA has not been the best either.
>
>The OMA has a lot to offer in terms of evolving the Web services
>stack. Learning from past experience is essential to have any hope
>of succeeding this time around!
I have some doubts that people are really learning from the past, but
rather want to have their shot at inventing something that has already been
invented. I don't really see the advantage of SOAP, either, in terms
of its "loose coupling". CORBA can be quite loosely coupled or tightly
coupled. It is a matter of style, not technology.
>Sanjiva.
>p.s.: Before anyone wonders, I'm speaking for myself .. not the company
>I work for. :-)
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
>For additional commands, email: soap-user-help@xml.apache.org
David W. Forslund dwf@lanl.gov
Computer and Computational Sciences http://www.acl.lanl.gov/~dwf
Los Alamos National Laboratory Los Alamos, NM 87545
505-665-1907 FAX: 505-665-4939
Re: CORBA vs. SOAP stuff (was: Re: Microsoft, IBM and SOAP)
Posted by David Forslund <dw...@lanl.gov>.
At 10:07 PM 3/26/2001 -0500, Sanjiva Weerawarana wrote:
>"Sebastian Andersson" <sa...@hogia.net> writes:
> >
> > RPC by any other name is still RPC in my book, so I compare SOAP with
> > CORBA and Sun-RPC. I accessed filesystems 7 years ago via NFS over
> > Sun-RPC where the NFS server was in USA and the client was in Europe.
> > We didn't call it web service then, but I guess today that would have
> > been a press release and a great win for the "new technology". I seem
> > to recall something about XML-Store together with the .NET press
> > releases from MS.
>
>You're right in saying that there's nothing fundamentally new in
>the Web services stack that didn't exist in the OMG OMA. What is new
>is that its another turn of the crank .. and as technology goes, we
>know that it takes a few iterations to get it just right and to solve
>the problem to the "right" level. Java (the concept) was invented back
>in about 1970 (P-Code) .. but it took several iterations (emacs, NeWS,..)
>before it was the "right technology at the right time."
>
>Similarly CORBA does some things really well, but it didn't really make
>it as a universal distributed computing platform. All this Web services
>stuff (IMO) is just another crank at getting it better so that it'll
>have "better" unversality. Nothing more, nothing less.
It isn't clear that SOAP is actually "better" than CORBA. It is a little
different,
but a lot of things seem to keep being reinvented by the next generation. UDDI
seems to be creating replacements for the OMG Trader, but without learning
a lot from the Trader service, itself.
> > I fail to see whats new and great with SOAP that Sun-RPC didn't have
> > almost a decade ago. Maybe the new idea is that we put a file on
> > a webserver which tells the clients were the server is and how the IDL
> > looks like? The NFS server I used, was found by a document on an ftp
> > site. Previous you got an IDL together with the documentation (or a
> > link to it) since you usualy only needed it while implementing
> > the client/server. Today you don't get documentation? Formerly we
> > found the server by quering the DNS for a name and asked a naming
> > server where the service was. Today we query the DNS for the name of
> > a http-server which will tell us the name of the service & server-proxy
> > so we can query the DNS for the name of the service-proxy so we can
> > tell it the name of the service we want to talk to. Maybe its easier
> > for windows programmers to set up their own http server (or get access
> > to one) than it is for them to set up their own name server or get
> > access to one?
> >
> > Currently SOAP are availible for less languages/platforms than CORBA
> > or Sun-RPC are so SOAP holds no advantage there.
> >
> > The IDLs for Sun-RPC and CORBA are a lot easier to read and understand
> > compared to XML Schemas.
I agree.
> >
> > You can buy mature bridges between many protocols and CORBA
> > (ie DCOM). There are firewalls today that understands CORBA.
> >
> > CORBA & Sun-RPC are faster to (de)marshall and they use less bandwidth
> > which leads to higher performance.
>
>As the next iteration, we will get some things done better than the
>older iteration (hopefully) and make fewer poor choices (hopefully).
>The overriding theme of this iteration is a looser coupling than the
>OMA and interaction via SOAP-like protocols which are (hopefully) more
>malleable than GIOP. Is it going to succeed for sure? I doubt anyone
>knows .. if the balance between good choices vs. poor choices is
>just right (w.r.t. solving the real problems and not imaginery ones)
>then it will. If not we'll try again another day under another name!
>
> > CORBA also provides a whole lot of the infrastructure you might need
> > together with your "web services", ie transactions.
>
>Some of these infrastructure services will need to evolve for the
>Web services stack too before all is said and done.
>
> > But I expect SOAP to "win" anyway via the VS tools and all
> > the developers on the MS platforms. The customers sees a lot of
> > buzzwords and they want it. The CORBA implementators have mostly
> > given the users power and robustness instead of an quick and easy
> > way to implement simple clients & servers which has put a lot of
> > developers in dummy mode when they look at CORBA.
> > Some of the langauge bindings for CORBA has not been the best either.
>
>The OMA has a lot to offer in terms of evolving the Web services
>stack. Learning from past experience is essential to have any hope
>of succeeding this time around!
I have some doubts that people are really learning from the past, but
rather want to have their shot at inventing something that has already been
invented. I don't really see the advantage of SOAP, either, in terms
of its "loose coupling". CORBA can be quite loosely coupled or tightly
coupled. It is a matter of style, not technology.
>Sanjiva.
>p.s.: Before anyone wonders, I'm speaking for myself .. not the company
>I work for. :-)
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: soap-user-unsubscribe@xml.apache.org
>For additional commands, email: soap-user-help@xml.apache.org
David W. Forslund dwf@lanl.gov
Computer and Computational Sciences http://www.acl.lanl.gov/~dwf
Los Alamos National Laboratory Los Alamos, NM 87545
505-665-1907 FAX: 505-665-4939