Comparison between CORBA and Web Services (SOAP etc.): discussion ?
Irmen de Jong
I've been using CORBA a few years back (not anymore recently ) but the recent
'hype' about so-called 'web-services' has triggered my memory a bit.
I would like to give some comments and ask a few questions, and I'm very
interested what you have to say about this.
I was wondering what the big deal is. After a little thinking, isn't it that
we could compare CORBA and Web Services (SOAP etc.etc.) like this:-
Web Services: SOAP , HTTP CORBA: IIOP
Web Services: URLs CORBA: IORs
Web Services: WSDL CORBA: IDL
Web Services: UDDI CORBA: Naming Service/Interface Repository
Is this comparison sound? To me it seems that the 'web services' are just a
new form of various things we have had since CORBA 2.0! Have I missed
something?
CORBA also defines strict language mappings between IDL and your language
of choice, while Web Services (SOAP) leave the developer in the dark about
how to map SOAP data to implementation data and vice versa.
A little research on the subject brings up some comments on the difference.
Usually the comments are about the fact that CORBA IIOP is 'firewall- and
internet- unfriendly'. I don't know what the fuss is because IIOP runs over
TCP/IP and can be tunneled over HTTP port 80, can't it? CORBA is also often
referred to as being 'heavy-duty'. Not sure what they mean exactly, but I
think they find that it is complex and large (also the software requirements).
Another comment is that it is usually not the case that an ORB is present
on all machines that want to use CORBA (IIOP). I think they have a point
here. It really is easier to realize a SOAP/HTTP client than a CORBA/IIOP
client. Just pipe some XML to port 80 and listen for the reply, voila.
Are there recent developments in the CORBA field that somehow improves this
situation? (Server-side is another story, a web service server will have to
have a web server installed with some sort of SOAP/web services toolkit.
This is comparable to the CORBA ORB that needs to be present on the server
machine.)
www.webservices.org even say that "Another issue faced by organizations is
a mismatch between the skills of Web developers and authors, and the skills
required to build even a simple CORBA client.", and they continue that a
"typical B2B developer" is a mainstream developer using Visual Basic,
and while able to build B2B web services, is "often not qualified to build
CORBA clients". I find that comment rather silly. How do you feel about this?
My conclusion would be that Web Services are easier to build with less
(and less complex) software requirements. However you have to solve the
SOAP-to-imlementation data mapping problem. CORBA's IDL is clear and because
the language mapping is standardized you know exactly what your program
should look like.
Recently I saw a graph (from Gartner, I think) that predicts a steady
downfall of CORBA market share and a big growth of Java Enterprise / .NET
applications with web services. Is CORBA dying?
To the people that have been using both CORBA and Web Services (SOAP etc.):
how would you compare both of them, what were your experiences?
Thanks a lot!!
Irmen de Jong
Mark Woyna
No, I believe you've hit the nail pretty much on the head. Web
Services are basically a reinvention of the CORBA wheel, with
most of the important pieces, i.e. security, notification,
missing or under-specified. It *kills* me to see articles referring
to Web Services/SOAP as "being built on internet standards." That's
funny, I thought CORBA *was* an internet standard. Doesn't IIOP
stand for *Internet* Interoperable Protocol? :-(
More comments below.
Irmen de Jong wrote:
>
> Hello all,
>
> I've been using CORBA a few years back (not anymore recently ) but the recent
> 'hype' about so-called 'web-services' has triggered my memory a bit.
I've been using CORBA for nearly 7 years, and I currently use it at
work, as well as teach a distributed objects course.
>
> I would like to give some comments and ask a few questions, and I'm very
> interested what you have to say about this.
>
> I was wondering what the big deal is. After a little thinking, isn't it that
> we could compare CORBA and Web Services (SOAP etc.etc.) like this:-
>
> Web Services: SOAP , HTTP CORBA: IIOP
> Web Services: URLs CORBA: IORs
> Web Services: WSDL CORBA: IDL
> Web Services: UDDI CORBA: Naming Service/Interface Repository
Web Services: ??? CORBA: Notification Service
Web Services: ??? CORBA: Portable Server Code (POA Spec)
>
> Is this comparison sound? To me it seems that the 'web services' are just a
> new form of various things we have had since CORBA 2.0! Have I missed
> something?
What you're missing is the fact that the Web Services/SOAP camp is
highly fractured at this time. Interoperability is on-par with CORBA
around 1994. Bleeechhh! :-( CORBA has had 10 years to mature. While
I don't believe Web Services will take 10 years to mature, it still
has a ways to go.
> CORBA also defines strict language mappings between IDL and your language
> of choice, while Web Services (SOAP) leave the developer in the dark about
> how to map SOAP data to implementation data and vice versa.
Give them time. They'll rediscover this, too.
>
> A little research on the subject brings up some comments on the difference.
> Usually the comments are about the fact that CORBA IIOP is 'firewall- and
> internet- unfriendly'. I don't know what the fuss is because IIOP runs over
> TCP/IP and can be tunneled over HTTP port 80, can't it? CORBA is also often
> referred to as being 'heavy-duty'. Not sure what they mean exactly, but I
> think they find that it is complex and large (also the software requirements).
I'll be the first to say that the OMG screwed up on the whole firewall
thing. It's 2002 already, and we *still* don't have a widely accepted
firewall specification! Didn't firewalls exist when IIOP was invented?
How can you have an *Internet* standard without addressing firewalls.
Hopefully, the latest work will address the shortcomings.
However, to simply assume that life will be dandy running everything
through port 80 is a laugh. The first virus that's propagated through
a SOAP call will result in a very tight lock down of the port.
Yes, CORBA is heavy duty because distributed applications require it.
Once the Web Services community discovers all the missing pieces, it
will be heavy duty also.
>
> Another comment is that it is usually not the case that an ORB is present
> on all machines that want to use CORBA (IIOP). I think they have a point
> here. It really is easier to realize a SOAP/HTTP client than a CORBA/IIOP
> client. Just pipe some XML to port 80 and listen for the reply, voila.
> Are there recent developments in the CORBA field that somehow improves this
> situation? (Server-side is another story, a web service server will have to
> have a web server installed with some sort of SOAP/web services toolkit.
> This is comparable to the CORBA ORB that needs to be present on the server
> machine.)
But you don't *really* need an ORB on the client to do simple CORBA
request. If you're a *real* programmer, you can use IIOP directly! ;-)
The client side ORB is there to provide a level of abstraction/
indirection. When it all boils down to it, you're still doing
request/reply.
So, what's the SOAP client programmer going to do? Are they really
going to use raw sockets and craft XML by hand, or are they going to
use a SOAP toolkit/framework that provides all the heavy lifting?
If so, it sounds like the same problem.
I recently posted an example showing the amount of coding required
by a CORBA client vs. a client using a SOAP framework. Not only did
the CORBA client have significantly fewer lines of code, the level of
abstraction was much higher. The client simply invoked an operation
on the stub/proxy just like it was a local object. The SOAP programmer,
however, has to construct a message, put the arguments in the message,
and then send the message. Now, I know it will be possible to provide
greater abstraction, but then isn't this basically what the IDL
compiler-generated stub classes provide?
>
> www.webservices.org even say that "Another issue faced by organizations is
> a mismatch between the skills of Web developers and authors, and the skills
> required to build even a simple CORBA client.", and they continue that a
> "typical B2B developer" is a mainstream developer using Visual Basic,
> and while able to build B2B web services, is "often not qualified to build
> CORBA clients". I find that comment rather silly. How do you feel about this?
It *is* silly. It takes *6* lines of code to locate the Name Service,
construct a query, narrow the result, and invoke an operation on the
resulting object:
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);
org.omg.CORBA.Object rootObj =
orb.resolve_initial_references("NameService");
NamingContextExt root = NamingContextExtHelper.narrow(rootObj);
org.omg.CORBA.Object object =
root.resolve(root.to_name("AcmeCountService"));
CountService countService = CountServiceHelper.narrow(object);
int currentCount = countService.getCurrentCount();
Distributed programming is not the hardest thing on earth, but it
does require above-average skills regardless of the underlying
technology. In the end, it's the *tools* that are provided to the
programmer that makes the job easier/harder.
>
> My conclusion would be that Web Services are easier to build with less
> (and less complex) software requirements. However you have to solve the
> SOAP-to-imlementation data mapping problem. CORBA's IDL is clear and because
> the language mapping is standardized you know exactly what your program
> should look like.
I agree that *very* simple interactions may be easier to *build*,
but debugging will definitely be harder. The IDL language bindings
support type safety. Static stub classes provide compile-time type
checking. With SOAP, you won't get a type error until the XML message
is validated on the *server* at *runtime*. Unless of course you use
a SOAP framework on the client, which will basically duplicate the
functionality of the ORB in this regard.
>
> Recently I saw a graph (from Gartner, I think) that predicts a steady
> downfall of CORBA market share and a big growth of Java Enterprise / .NET
> applications with web services. Is CORBA dying?
No, it's quietly being used in a variety of industries. However,
given that it's a stable (read: boring) technology, it doesn't get
the press that Web Services do. The same thing could be said for EDI.
Remember, publishers have to sell magazines, stable technologies
aren't very interesting to read about.
>
> To the people that have been using both CORBA and Web Services (SOAP etc.):
> how would you compare both of them, what were your experiences?
In the long run, they'll both have they're place, just as CORBA
and COM, and for that matter RMI, coexist(ed). When necessary, bridges
will be used to tie the 2 together. For extra credit last semester,
I had my students implement their CORBA objects (services) as web
services using a web services framework of their choice. It didn't
take much effort to generate a new proxy class that accepted SOAP
messages, and invoke a CORBA operation on the target object.
In addition, since the business logic was implemented behind the
CORBA Tie classes, it wouldn't have been all that difficult to
implement a SOAP Tie class that utilized the same business logic
using delegation.
In the short term, I believe it will take a number of years for
SOAP to mature, and the *missing* pieces to be (re)defined.
Also, the business issues (security, QoS, licensing, etc.)
surrounding the use of Web Services still has a lot of questions
to be answered. Architecting a system to utilize a third-party
web service will be a difficult business decision. Would you bet
you business on an untrusted web service? What happens if the
company shuts down? Has a bug in their implementation? Will the
service scale? Will web service hosting companies allow *anyone* to
invoke their services? How will they get paid?
Lastly, we can't forget the 57 variety of XML schemas being
developed. I believe there will never be a single schema defined
for most vertical industries that is accepted by all parties. What
happens when your company chooses the *wrong* definition of a
purchase order? What if you're potential business partner has
selected the *other* definition? I spent too many years of my
career trying to unify disjoint schemas being pushed by business
groups with lots to lose if their schema didn't win.
Mark Woyna
Dan Kegel
> I recently posted an example showing the amount of coding required
> by a CORBA client vs. a client using a SOAP framework. Not only did
> the CORBA client have significantly fewer lines of code, the level of
> abstraction was much higher. The client simply invoked an operation
> on the stub/proxy just like it was a local object. The SOAP programmer,
> however, has to construct a message, put the arguments in the message,
> and then send the message. Now, I know it will be possible to provide
> greater abstraction, but then isn't this basically what the IDL
> compiler-generated stub classes provide?
What's the URL for that example? I'd love to see it.
- Dan
Rosimildo daSilva
news:3C34F266...@argonne.com...
>
> No, I believe you've hit the nail pretty much on the head. Web
> Services are basically a reinvention of the CORBA wheel, with
> most of the important pieces, i.e. security, notification,
> missing or under-specified. It *kills* me to see articles referring
> to Web Services/SOAP as "being built on internet standards." That's
> funny, I thought CORBA *was* an internet standard. Doesn't IIOP
> stand for *Internet* Interoperable Protocol? :-(
>
> More comments below.
This is not true. I have written an article comparing both development
styles. They're similar. I have put a copy of article here.
http://www.quakersoft.com/ctel/soap_corba.html
Rosimildo.
Mark Woyna
What's not true? Can you please point out the specific points
of my post that you find "not true"? Also, please post the relevant
text from your article, as your server is not currently responding.
Mark
Rosimildo daSilva
>
> What's not true? Can you please point out the specific points
> of my post that you find "not true"? Also, please post the relevant
> text from your article, as your server is not currently responding.
>
> Mark
That SOAP requires much more coding. It is basically the same
amount of coding.
I just looked at the page, and it looks fine from here.
Rosimildo.
Mark Woyna
The server is still not responding. Perhaps it's a firewall
problem on my side. Could you *please* post the relevant example
SOAP code that shows a simple web service invocation? It shouldn't
be more than 5 or 6 lines of code, right?
Here are the basic steps for creating a client which interacts
with a SOAP RPC-based service as described in the Apache SOAP v2.2
Documentation:
1. Obtain the interface description of the SOAP service.
2. Make sure that there are serializers registered for all
parameters which you will be sending, and deserializers for
all information which you will be receiving back.
3. Create the org.apache.soap.rpc.RPCMessage.Call object.
4. Set the target URI into the Call object using the
setTargetObjectURI(...) method.
5. Set the method name that you wish to invoke into the Call
object using the setMethodName(...) method.
6. Create any Parameter objects necessary for the RPC call and set
them into the Call object using the setParams(...) method.
7. Execute the Call object's invoke(...) method and capture the
Response object which is returned from invoke(...).
8. Check the Response object to see if a fault was generated using
the generatedFault() method.
9. If a fault was returned, retrieve it using the getFault(...)
method, otherwise extract any result or returned parameters using
the getReturnValue() and getParams() methods respectively.
Here's some simplified code from:
http://www.javaworld.com/javaworld/jw-04-2001/jw-0427-soap.html
URL url = new
URL("http://localhost:8080/apache-soap/servlet/rpcrouter");
Call call = new Call();
call.setTargetObjectURI("urn:Hello");
call.setMethodName("sayHelloTo");
call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);
Vector params = new Vector();
params.addElement(new Parameter("name", String.class, "Mark",
null));
call.setParams(params);
Response resp = null;
try {
resp = call.invoke(url, "");
if ( !resp.generatedFault() ) {
Parameter ret = resp.getReturnValue();
Object value = ret.getValue();
System.out.println(value);
}
else {
Fault fault = resp.getFault();
System.err.println("Generated fault!");
}
}
catch (Exception e) {
e.printStackTrace();
}
Please tell me how you can conclude that the above *nine* steps and
*20* or so lines of code are "basically the same" as the 10 or so
lines of code required to invoke a CORBA operation using the
static/stub approach? In fact, once the reference to the service is
obtained and narrowed, any additional invocation is *one* line of
code, whereas SOAP requires the construction of a new Call object for
each new request on a different operation!
try {
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);
org.omg.CORBA.Object rootObj =
orb.resolve_initial_references("NameService");
NamingContextExt root = NamingContextExtHelper.narrow(rootObj);
org.omg.CORBA.Object object =
root.resolve(root.to_name("AcmeMyService"));
MyService myService = MyServiceHelper.narrow(object);
int ret = myService.sayHelloTo("Mark");
} catch (MyServiceException e) {
System.err.println("Generated fault!");
} catch (Exception e) {
e.printStackTrace();
}
The CORBA approach is clearly closer to the programming style
of the host language, and doesn't require the programmer to fiddle
with Call objects, set method names, provide serializers and
deserializers, individually set parameters, extract results, check
for faults, etc.
Doesn't the fact that you claim that it's "basically the same
amount of coding" indicate that the claims that CORBA programming
is more difficult, or more "heavy weight" are bogus? As an OO
programmer, I conclude that the CORBA approach is much *easier*
than the SOAP approach, since it *exactly* matches the invocation
style of the host language.
Mark
Duncan Grisby
Mark Woyna <wo...@argonne.com> wrote:
>The server is still not responding. Perhaps it's a firewall
>problem on my side. Could you *please* post the relevant example
>SOAP code that shows a simple web service invocation? It shouldn't
>be more than 5 or 6 lines of code, right?
The server isn't responding to me either. It looks like the web server
isn't running, since if I do
$ telnet www.quakersoft.com http
Trying 24.93.59.7...
it sits there for ever, but if I do
$ telnet www.quakersoft.com
Trying 24.93.59.7...
Connected to cs9359-7.austin.rr.com (24.93.59.7).
Escape character is '^]'.
Red Hat Linux release 7.2 (Enigma)
Kernel 2.4.7-10 on an i686
login:
so it's clearly there.
Cheers,
Duncan.
--
-- Duncan Grisby \ Research Engineer --
-- AT&T Laboratories Cambridge --
-- http://www.uk.research.att.com/~dpg1 --
Rosimildo daSilva
>
> The server is still not responding. Perhaps it's a firewall
> problem on my side. Could you *please* post the relevant example
> SOAP code that shows a simple web service invocation? It shouldn't
> be more than 5 or 6 lines of code, right?
Sorry. It looks like there is a firewall problem. I've put it here:
http://www.quakersoft.net/rosimildo/articles/soap_corba.html
Please take a look and let me know.
> Please tell me how you can conclude that the above *nine* steps and
> *20* or so lines of code are "basically the same" as the 10 or so
> lines of code required to invoke a CORBA operation using the
> static/stub approach? In fact, once the reference to the service is
> obtained and narrowed, any additional invocation is *one* line of
> code, whereas SOAP requires the construction of a new Call object for
> each new request on a different operation!
Yes, the Apache SOAP is not what I call "user friendly". Look at
GLUE or WASP if you need something easier.
> Doesn't the fact that you claim that it's "basically the same
> amount of coding" indicate that the claims that CORBA programming
> is more difficult, or more "heavy weight" are bogus? As an OO
> programmer, I conclude that the CORBA approach is much *easier*
> than the SOAP approach, since it *exactly* matches the invocation
> style of the host language.
Look at the article that I wrote. Hopefully you can see for youself.
SOAP can be made easy. Some SOAP stacks give you lots of
flexilibity, but they very diffcult to program. Apache is one of them.
I have put the code with a "batch" file:
http://www.quakersoft.net/rosimildo/articles/soap_corba.zip
BTW, esoap java is only 60K. Very nice for Applets.
Please, let me know what you think.
If you find any spelling, forgive me. I am NOT a english native speaker.
Rosimildo.
Rosimildo daSilva
news:a14pct$f0t$1...@pea.uk.research.att.com...
> In article <3C35E683...@argonne.com>,
> Mark Woyna <wo...@argonne.com> wrote:
>
> it sits there for ever, but if I do
Looks like I have a "firewall" problem on this server. I need to
check it again. I have place the article on another server.
Rosimildo.
Mark Woyna
The key to your article is in the first 2 paragraphs. SOAP is a
wire protocol, as is IIOP. A *significant* shortcoming of SOAP
at this time is the lack of standard language bindings, as you point
out. As a result, client and server code *IS NOT PORTABLE*! You
state below that the Apache framework is not "user friendly," but
I think you're missing the bigger picture. If I, as a developer,
commit to any particular framework, I've just locked myself into
a proprietary solution, whereas the OMG has spent considerable time
standardizing both the client and server side libraries. As long
as I stick to the standard, I can easily switch ORBs on both the
client and server side. How long are we going to have to wait for
standard SOAP language binding?
While I appreciate the power of XML, the syntax still leaves
something to be desired. While web masters might have no problem
reading it, I believe your average C, C++, or Java programmer is
going to have have difficulties with the syntax. 'Just as the
Smalltalk community how difficult it's been to persuade users
C-style programmers to accept a different syntax! ;-) Let's compare
the following 2 examples:
struct EchoData {
long aLong;
boolean aBool;
string aString;
};
<esd:CType name="EchoData" >
<esd:item name="aLong" type="xsd:int" builtin="true"
array="false" inout="false"/>
<esd:item name="aBool" type="xsd:boolean" builtin="true"
array="false" inout="false"/>
<esd:item name="aString" type="xsd:string" builtin="true"
array="false" inout="false"/>
</esd:CType>
EchoData getData( in long l, in boolean b, in string s );
<esd:Method name="getData">
<esd:InParam name="GetDataRequest">
<esd:item name="l" type="xsd:int" builtin="true"
array="false" inout="false"/>
<esd:item name="b" type="xsd:boolean" builtin="true"
array="false" inout="false"/>
<esd:item name="s" type="xsd:string" builtin="true"
array="false" inout="false"/>
</esd:InParam>
<esd:OutParam name="GetDataResponse">
<esd:item name="return" type="typens:EchoData"
builtin="false" array="false" inout="false"/>
</esd:OutParam>
</esd:Method>
Are you *still* trying to tell us that the SOAP approach is the
same or easier?
The eSoap toolkit does appear to be much easier than the Apache
toolkit, but this is only because they've basically re-implemented
the same stub-based framework as specified by the CORBA spec,
only *PROPRIETARY* manner. I'm sorry for shouting, but you're
proving my point for me.
1. Depending on the framework selected, SOAP programming is
no easier, and possibly more work than the equivalent
CORBA approach.
2. Regardless of the framework selected, the resultant code
*is not portable* between frameworks.
So, as I stated before, as far as ease of use and portability
is concerned, SOAP is basically where CORBA was *in 1995*, and is
missing *many* key features and services, e.g. notification. I
haven't mentioned the bulkiness of XML as a wire protocol, either.
It's amazing that many in the SOAP community have basically
dismissed CORBA/IIOP as being too "difficult" to use, and not
suitable for the internet. They state that XML is *so* much
easier to use, but yet they don't actually expose the XML to
the programmer. Instead, they develop incompatible, proxy-based
frameworks based on the same designs as the CORBA vendors.
Mark
P.S. By the way, your English is fine! :-)
Rosimildo daSilva
>
> The key to your article is in the first 2 paragraphs. SOAP is a
> wire protocol, as is IIOP. A *significant* shortcoming of SOAP
> at this time is the lack of standard language bindings, as you point
> out. As a result, client and server code *IS NOT PORTABLE*!
Yes. I have been *beating the horse* on the SOAP/WSDL mailing-lists
about this topic. I do believe that a standard mapping for programming
languages, such as CORBA POA, is necessary at the WSDL level.
> You
> state below that the Apache framework is not "user friendly," but
IBM is working in WSDL toolkit that would read a java class or
interface and create the WSDL file. I do not like this approach,
but many toolkits works like that. GLUE does the same thing.
In my view, the design of a Web Service should start with the
"contract" ( IDL for CORBA, WSDL for SOAP ).
> I think you're missing the bigger picture. If I, as a developer,
> commit to any particular framework, I've just locked myself into
> a proprietary solution, whereas the OMG has spent considerable time
> standardizing both the client and server side libraries.
Could be. But, unfortunately on software, we need *cooperation* of the
"big boys" ( IBM, MS, ORACLE, SUN, etc ).
>As long
> as I stick to the standard, I can easily switch ORBs on both the
> client and server side. How long are we going to have to wait for
> standard SOAP language binding?
I think "binding" for WSDL is necessary, and eventually will come.
See this:
http://www.xml.com/pub/a/2001/12/19/wsdlwg.html
Some of you, might be registered with the soapbuilders list, and know
that I am one that criticize many things on SOAP/WSDL. I think they
are much more complex that they should be, and simplication is a must.
> While I appreciate the power of XML, the syntax still leaves
> something to be desired. While web masters might have no problem
> reading it, I believe your average C, C++, or Java programmer is
> going to have have difficulties with the syntax. 'Just as the
> Smalltalk community how difficult it's been to persuade users
> C-style programmers to accept a different syntax! ;-) Let's compare
> the following 2 examples:
I do not deny that. I just think that CORBA/SOAP can live together.
One would complete the other.
> Are you *still* trying to tell us that the SOAP approach is the
> same or easier?
I do believe it is the same. Sometimes a feel CORBA is cleaner,
because the technology is much more mature.
> The eSoap toolkit does appear to be much easier than the Apache
> toolkit, but this is only because they've basically re-implemented
> the same stub-based framework as specified by the CORBA spec,
> only *PROPRIETARY* manner. I'm sorry for shouting, but you're
> proving my point for me.
Thanks for saying that. eSoap was a man job ( a contract project ),
and just "borrowed" some ideas from many years of doing
CORBA/COM/RPC.
> 1. Depending on the framework selected, SOAP programming is
> no easier, and possibly more work than the equivalent
> CORBA approach.
>
> 2. Regardless of the framework selected, the resultant code
> *is not portable* between frameworks.
I agree with this, so far. My hope is that the W3C start listening to the
small folks like many of us, and add standard bindings for SOAP/WSDL.
> So, as I stated before, as far as ease of use and portability
> is concerned, SOAP is basically where CORBA was *in 1995*, and is
> missing *many* key features and services, e.g. notification. I
> haven't mentioned the bulkiness of XML as a wire protocol, either.
Yes. Search the "soapbuilders" list, and you find posts from me, saying the
same thing.
http://groups.yahoo.com/group/soapbuilders/message/4165
http://groups.yahoo.com/group/soapbuilders/message/6275
> It's amazing that many in the SOAP community have basically
> dismissed CORBA/IIOP as being too "difficult" to use, and not
> suitable for the internet. They state that XML is *so* much
> easier to use, but yet they don't actually expose the XML to
> the programmer. Instead, they develop incompatible, proxy-based
> frameworks based on the same designs as the CORBA vendors.
SOAP has a nice momentum, and support of the "big boys".
From a technology standpoint, CORBA is *way* ahead,
specially on the "standard services" aspect.
Anyway, I only claimed that the lines of code written by
a developer to write a CORBA service and a Web Service is
basically the same. I stand on that claim, but I agree that the
end result CORBA based application would be more easily portable from
one vendor to the next.
> P.S. By the way, your English is fine! :-)
Thanks, Rosimildo.
Michi Henning
> "Mark Woyna" <wo...@argonne.com> wrote in message
> news:3C39C7F0...@argonne.com...
> >
> > The key to your article is in the first 2 paragraphs. SOAP is a
> > wire protocol, as is IIOP. A *significant* shortcoming of SOAP
> > at this time is the lack of standard language bindings, as you point
> > out. As a result, client and server code *IS NOT PORTABLE*!
>
> Yes. I have been *beating the horse* on the SOAP/WSDL mailing-lists
> about this topic. I do believe that a standard mapping for programming
> languages, such as CORBA POA, is necessary at the WSDL level.
One of the initial arguments in favour of SOAP was its simplicity. About
three years ago, I had a long discussion with Don Box about this. The
argument Don presented basically was that you don't need a programming
platform (along the lines of the CORBA run time). Instead, you just cobble
SOAP requests and replies together using Perl, or whatever. Now that people
are beginning to realize that doing this isn't quite as easy as one would
like, the calls for language mappings appear. Of course, by the time you
have a language mapping with portable APIs, you will have rebuilt much of
the CORBA run time, or something similar...
> > You
> > state below that the Apache framework is not "user friendly," but
>
> IBM is working in WSDL toolkit that would read a java class or
> interface and create the WSDL file. I do not like this approach,
> but many toolkits works like that. GLUE does the same thing.
The problem with all generated code is that it is ugly. This is true in
particular when you try to bridge object models. I have seen many attempts
at such automatic mappings: Java to IDL, IDL to GDMO and vice versa, the
COM-CORBA mapping, the CORBA-DCE mapping, etc. They all suffer from the
same problem: minor mismatches in the type system, scoping rules, and
object model semantics lead to generated code that looks like a dog's
breakfast and is so ugly that no-one wants to use it.
> In my view, the design of a Web Service should start with the
> "contract" ( IDL for CORBA, WSDL for SOAP ).
What, you want to establish a type model before you make an RPC call?
What a strange notion... ;-)
As many proponents of SOAP and web services will tell you, the strict
typing model of CORBA is undesirable and gets in the way and SOAP is so
much better because, after all, you can ignore what you don't understand;
never mind that, not having understood half of what you just said to me,
I'm unlikely to return a useful reply... :-(
The whole "loosely coupled" argument around web services is just a lot of
hot air. When you think about it, the only way you can have reliable
communication between two parties at the semantic level is if they agree
on a common and complete type system. (But, of course, as soon as you
have such a type system, the whole notion of "loosely coupled" goes out
the window because changes in the conversation (surprise, surprise) require
a change in the type system (and, even for loose typing, changes to the
source code). In fact, what people think of when they say "loosely coupled"
requires wetware: human insight is what we use to make up for the lack
of a strict type system in human interactions. Unfortunately, computers
are nowhere near getting such capabilities. It follows that "loosely coupled"
as far as type systems are concerned will remain a pipe dream for many more
years.
> Some of you, might be registered with the soapbuilders list, and know
> that I am one that criticize many things on SOAP/WSDL. I think they
> are much more complex that they should be, and simplication is a must.
The interesting thing is that, as soon as you beef up a the protocol to
the level where it meets real-life functional and performance demands,
you end up with something complex, like it or not. The reason that RPC
protocols are complex is not because the people who designed them were
idiots or technocrats who like complexity, but because the functionality
you need to build forces the complexity on you. (Plus some complexity added
through design by committee, but that's a different story...)
> I just think that CORBA/SOAP can live together.
> One would complete the other.
Right. Run SOAP with the outside world and run CORBA on the inside.
> > Are you *still* trying to tell us that the SOAP approach is the
> > same or easier?
>
> I do believe it is the same. Sometimes a feel CORBA is cleaner,
> because the technology is much more mature.
It's also *much* more functional and at a higher level of abstraction.
SOAP and CORBA are the same only if you compare them at the protocol level:
both can be used to do RPC. (But, even there, look closely: where is
polymorphism in SOAP? In fact, where are the objects in SOAP?)
> > The eSoap toolkit does appear to be much easier than the Apache
> > toolkit, but this is only because they've basically re-implemented
> > the same stub-based framework as specified by the CORBA spec,
> > only *PROPRIETARY* manner. I'm sorry for shouting, but you're
> > proving my point for me.
>
> Thanks for saying that. eSoap was a man job ( a contract project ),
> and just "borrowed" some ideas from many years of doing
> CORBA/COM/RPC.
Hmmm... So what will SOAP give you that CORBA doesn't? The way I see it,
SOAP *may* one day become a lingua franca for RPC, and that is useful. But
the price you pay in terms of diminished functionality, lower abstraction
level, and performance is high. In particular, the performance of SOAP
is nothing short of staggeringly bad. The wasted bandwidth and CPU cycles
are simply breath-taking.
> > 1. Depending on the framework selected, SOAP programming is
> > no easier, and possibly more work than the equivalent
> > CORBA approach.
> >
> > 2. Regardless of the framework selected, the resultant code
> > *is not portable* between frameworks.
>
> I agree with this, so far. My hope is that the W3C start listening to the
> small folks like many of us, and add standard bindings for SOAP/WSDL.
Don't hold your breath. From the time a standards body first looks at
a language mapping to the time that mapping is commercially
available from a number of vendors (and actually portable), several years
elapse. In the mean time, it's vendor lock-in and non-portable code.
> > So, as I stated before, as far as ease of use and portability
> > is concerned, SOAP is basically where CORBA was *in 1995*, and is
> > missing *many* key features and services, e.g. notification. I
> > haven't mentioned the bulkiness of XML as a wire protocol, either.
>
> Yes. Search the "soapbuilders" list, and you find posts from me, saying the
> same thing.
> http://groups.yahoo.com/group/soapbuilders/message/4165
> http://groups.yahoo.com/group/soapbuilders/message/6275
And the answer is that we re-invent all those wheels yet again? And there
I am, thinking that it would nice to actually make progress for a change...
Cheers,
Michi.
--
Michi Henning +61 7 3324 9633
Chief CORBA Scientist +61 4 1118 2700 (mobile)
IONA Technologies +61 7 3324 9799 (fax)
Total Business Integration http://www.ooc.com.au/staff/michi
Jesper Ladegaard
"Michi Henning" wrote:
[snip]
> The whole "loosely coupled" argument around web services is just a lot of
> hot air. When you think about it, the only way you can have reliable
> communication between two parties at the semantic level is if they agree
> on a common and complete type system. (But, of course, as soon as you
> have such a type system, the whole notion of "loosely coupled" goes out
> the window because changes in the conversation (surprise, surprise)
require
> a change in the type system (and, even for loose typing, changes to the
> source code). In fact, what people think of when they say "loosely
coupled"
> requires wetware: human insight is what we use to make up for the lack
> of a strict type system in human interactions. Unfortunately, computers
> are nowhere near getting such capabilities. It follows that "loosely
coupled"
> as far as type systems are concerned will remain a pipe dream for many
more
> years.
Granted, but what about something like the DARPA DAML initiative?
http://www.daml.org/
I mean, accessing some web service, i.e. over a high-latency low-bandwidth
WAN, by means of a set of RPC invocations sent back and forth a server
though a primitive IDL or WSDL interface, who want's to do such kind-of
communication style in the first place?
IMO, instead of using traditional RPC, a better (say, flexible and scalable)
way is that of creating script's or "mobile agents" containing instructions
and possible state/data, i.e. a packet/script defining some transaction, and
send it around the network to accomplish the task. The agent/script must be
intelligent enough to be able to interact with the different server nodes
locally (i.e. through local IDL interfaces), and return to the sender when
it's done, minimising network latency and request contention, and freeing
the architecture from the tyrany of traditional RPCs.
DAML is an attempt to build a framework for modelling/execution web-services
using such style of communication in a standard way. IMHO, there's much more
depth in this DAML-way, compared to the traditional RPC-way of building
services many developer uses today, i.e. services modelled using static and
pretty dumb (say, semantic dumb, at least the behaviourl/workflow aspect)
WDSL or IDL interfaces.
/Jesper
Rosimildo daSilva
news:Pine.HPX.4.05.10201081550520.10176-
> One of the initial arguments in favour of SOAP was its simplicity. About
> three years ago, I had a long discussion with Don Box about this. The
> argument Don presented basically was that you don't need a programming
> platform (along the lines of the CORBA run time). Instead, you just cobble
> SOAP requests and replies together using Perl, or whatever. Now that
people
> are beginning to realize that doing this isn't quite as easy as one would
> like, the calls for language mappings appear. Of course, by the time you
> have a language mapping with portable APIs, you will have rebuilt much of
> the CORBA run time, or something similar...
It could have been that way, if the SOAP spec had been a simple 3 pages one,
like XMP-RPC is. Overtime, it became complex, Section 5 is like hell with
all kinds of un-necessary rules.
>
> The problem with all generated code is that it is ugly. This is true in
> particular when you try to bridge object models. I have seen many attempts
> at such automatic mappings: Java to IDL, IDL to GDMO and vice versa, the
> COM-CORBA mapping, the CORBA-DCE mapping, etc. They all suffer from the
> same problem: minor mismatches in the type system, scoping rules, and
> object model semantics lead to generated code that looks like a dog's
> breakfast and is so ugly that no-one wants to use it.
I ageee.
> > In my view, the design of a Web Service should start with the
> > "contract" ( IDL for CORBA, WSDL for SOAP ).
>
> What, you want to establish a type model before you make an RPC call?
> What a strange notion... ;-)
I was not clear here. I do not like the notion that people should write
code in java and C#, and process these files and generate the WSDL
file to describe your service. :-)
I like the notion that my team write the WSDL, and say: "Let's write
a service that conforms with this contract".
> As many proponents of SOAP and web services will tell you, the strict
> typing model of CORBA is undesirable and gets in the way and SOAP is so
> much better because, after all, you can ignore what you don't understand;
> never mind that, not having understood half of what you just said to me,
> I'm unlikely to return a useful reply... :-(
Ok. I might have been unclear. :-)
> It's also *much* more functional and at a higher level of abstraction.
> SOAP and CORBA are the same only if you compare them at the protocol
level:
> both can be used to do RPC. (But, even there, look closely: where is
> polymorphism in SOAP? In fact, where are the objects in SOAP?)
I agree.
> Hmmm... So what will SOAP give you that CORBA doesn't? The way I see it,
> SOAP *may* one day become a lingua franca for RPC, and that is useful. But
> the price you pay in terms of diminished functionality, lower abstraction
> level, and performance is high. In particular, the performance of SOAP
> is nothing short of staggeringly bad. The wasted bandwidth and CPU cycles
> are simply breath-taking.
+ Reuse of the big infra-structure built for the HTTP.
+ Support of the big companies
SOAP performance s*cks. Not doubt about it.
> Don't hold your breath. From the time a standards body first looks at
> a language mapping to the time that mapping is commercially
> available from a number of vendors (and actually portable), several years
> elapse. In the mean time, it's vendor lock-in and non-portable code.
We never know. :-)
Rosimildo.
Jacob Jose Cherackal
I find your observations very helpful and intriguing ;-)
Here are some notes from my side (I tend to tell my version of the story).
>
> One of the initial arguments in favour of SOAP was its simplicity. About
> three years ago, I had a long discussion with Don Box about this. The
> argument Don presented basically was that you don't need a programming
> platform (along the lines of the CORBA run time). Instead, you just cobble
> SOAP requests and replies together using Perl, or whatever. Now that
people
> are beginning to realize that doing this isn't quite as easy as one would
> like, the calls for language mappings appear. Of course, by the time you
> have a language mapping with portable APIs, you will have rebuilt much of
> the CORBA run time, or something similar...
SOAP's greatest advantage and disadvantage is its lack of standard above it
and below it. SOAP is as simple as the implementer of the middleware wants
it to be. I find CORBA very simple while working on certain ORBs and pretty
nasty on certain ones. It all depends on how good SOAP can be implemented as
a tool.
The other advantage I see in SOAP is ubiquity. As it stands, IIOP has not
penetrated the internet as HTTP has. If SOAP can run on HTTP or any other
Internet Protocol, I would say that it is bound to enter the domain the IIOP
has not. Another major criticism on IIOP is its lack of support for
Asynchronous Messaging capability. AMI does address this, but its a very
week implementation of asynchrony. This is where SOAP can help, provided it
can be built on a reasonable protocol like BEEP and a good messaging
middleware can use SOAP for messaging.
SOAP's lack of standards above and below it makes it one of the most
bastardized message transportation 'standards'. In addition to this, there
is a greater chance of people misusing it, leading to greater on the wire
latency.
Overall, I find SOAP, a messaging protocol, if used correctly will provide
one with great deal of dynamism that the Internet will demand of it.
>
> The problem with all generated code is that it is ugly. This is true in
> particular when you try to bridge object models. I have seen many attempts
> at such automatic mappings: Java to IDL, IDL to GDMO and vice versa, the
> COM-CORBA mapping, the CORBA-DCE mapping, etc. They all suffer from the
> same problem: minor mismatches in the type system, scoping rules, and
> object model semantics lead to generated code that looks like a dog's
> breakfast and is so ugly that no-one wants to use it.
I quiet agree with you on the fact that generated code is ugly. However, if
generated the right way, with industry standard patterns and idioms, I find
it the most useful. For this, a good framework based approach is required
which is extensible to suit any particular type system, not just two of
them. I find the MDA based approach most satisfying in this regard. It makes
the world close to platform and technology independent.
>
> > In my view, the design of a Web Service should start with the
> > "contract" ( IDL for CORBA, WSDL for SOAP ).
I would say, anything and everything after a good requirement capture is to
be *Software Architecture*. Never jump directly to IDL or WSDL. The RM-ODP
approach of defining five view points to a system helps capture more that
what constrained languages like IDL and WSDL can capture.
>
> What, you want to establish a type model before you make an RPC call?
> What a strange notion... ;-)
How true ;-))
>
> As many proponents of SOAP and web services will tell you, the strict
> typing model of CORBA is undesirable and gets in the way and SOAP is so
> much better because, after all, you can ignore what you don't understand;
> never mind that, not having understood half of what you just said to me,
> I'm unlikely to return a useful reply... :-(
>
> The whole "loosely coupled" argument around web services is just a lot of
> hot air. When you think about it, the only way you can have reliable
> communication between two parties at the semantic level is if they agree
> on a common and complete type system. (But, of course, as soon as you
> have such a type system, the whole notion of "loosely coupled" goes out
> the window because changes in the conversation (surprise, surprise)
require
> a change in the type system (and, even for loose typing, changes to the
> source code). In fact, what people think of when they say "loosely
coupled"
> requires wetware: human insight is what we use to make up for the lack
> of a strict type system in human interactions. Unfortunately, computers
> are nowhere near getting such capabilities. It follows that "loosely
coupled"
> as far as type systems are concerned will remain a pipe dream for many
more
> years.
You are quiet right and this is where I find standards as most useful. Most
of the people who use CORBA lack a through knowledge of CORBA Services
(horizontal standards) and CORBA Domains (vertical standards). A good
solution to any problem should be based on both domain standard and industry
standards. Where CORBA failed was in driving the importance and active use
of the important services and domains. This I would attribute to people who
have taught and evangelized CORBA to prospective users. Well, don't you
think so ;-)
> > I just think that CORBA/SOAP can live together.
> > One would complete the other.
>
> Right. Run SOAP with the outside world and run CORBA on the inside.
Well, that needs some more explanation. There are instances where SOAP can
be used for inter component RPC. As long as there is no standard from
CORBA's end to a particular solution, you will see WSDL/SOAP exploiting that
area, unfortunately though ;-(.
As it stands, SOAP is here to stay. It depends on how people use it as a
tool to attain its purposes. Experts like you can address most of the
advantages and disadvantages and provide a path to the right use of SOAP and
CORBA and a lot more technologies to come. From my side, I would say that a
deep understanding of Software Architecture would provide you with the true
benefits and disadvantages of the platforms and technologies of the past,
the present and the future.
So long,
Jacob.
Rosimildo daSilva
news:a1f28d$q7mmf$1...@ID-74226.news.dfncis.de...
> Hi Michi,
> > > In my view, the design of a Web Service should start with the
> > > "contract" ( IDL for CORBA, WSDL for SOAP ).
>
> I would say, anything and everything after a good requirement capture is
to
> be *Software Architecture*. Never jump directly to IDL or WSDL. The RM-ODP
> approach of defining five view points to a system helps capture more that
> what constrained languages like IDL and WSDL can capture.
>
Just to clarify:
My point was not captured on this context. I totally agree with you.
My point was/is that I do not like the idea of *reverse engineering"
the interface from some classes ( C++ and Java ) after the system
is built, as some toolkits let you export the WSDL.
Rosimildo.
Michi Henning
> > > In my view, the design of a Web Service should start with the
> > > "contract" ( IDL for CORBA, WSDL for SOAP ).
> >
> > What, you want to establish a type model before you make an RPC call?
> > What a strange notion... ;-)
>
> I was not clear here. I do not like the notion that people should write
> code in java and C#, and process these files and generate the WSDL
> file to describe your service. :-)
No, you were quite clear. It's just that I was being sarcastic :-)
> I like the notion that my team write the WSDL, and say: "Let's write
> a service that conforms with this contract".
Sounds suspiciously similar to writing IDL first, and an implementation
second :-) But some people apparently prefer to write an implementation
first and then, later, to find out what the interfaces look like :-)
> > Hmmm... So what will SOAP give you that CORBA doesn't? The way I see it,
> > SOAP *may* one day become a lingua franca for RPC, and that is useful. But
> > the price you pay in terms of diminished functionality, lower abstraction
> > level, and performance is high. In particular, the performance of SOAP
> > is nothing short of staggeringly bad. The wasted bandwidth and CPU cycles
> > are simply breath-taking.
>
> + Reuse of the big infra-structure built for the HTTP.
> + Support of the big companies
>
> SOAP performance s*cks. Not doubt about it.
I agree. SOAP will be used *if* it becomes ubiquitous (to me, whether that
will happen is still an open question), and it will be used where no
better alternative is available (much like comma-separated data for
exchanging spreadsheet files).
Michi Henning
> The other advantage I see in SOAP is ubiquity. As it stands, IIOP has not
> penetrated the internet as HTTP has. If SOAP can run on HTTP or any other
> Internet Protocol, I would say that it is bound to enter the domain the IIOP
> has not.
I agree. SOAP has the potential to become a lingua franca that you can fall
back on when all else fails.
> Another major criticism on IIOP is its lack of support for
> Asynchronous Messaging capability. AMI does address this, but its a very
> week implementation of asynchrony. This is where SOAP can help, provided it
> can be built on a reasonable protocol like BEEP and a good messaging
> middleware can use SOAP for messaging.
I see these issues as completely orthogonal. SOAP or IIOP have nothing to do
with messaging capabilities. The protocols are just a means of carrying a
payload. If you feel that AMI isn't powerful enough, I think that's a
criticism that should be leveled at the CORBA messaging spec, quite
independently of the underlying protocol.
> SOAP's lack of standards above and below it makes it one of the most
> bastardized message transportation 'standards'. In addition to this, there
> is a greater chance of people misusing it, leading to greater on the wire
> latency.
Not just that -- interoperability is the real issue here, I think. Looking
at how long it took for various protocol implementations (including IIOP)
to mature to the point where they were interoperable and reliable, I wouldn't
hold my breath for that to happen with SOAP any time soon.
> Overall, I find SOAP, a messaging protocol, if used correctly will provide
> one with great deal of dynamism that the Internet will demand of it.
I honestly don't see what would make SOAP a "messaging" protocol any more
than IIOP. Both are protocols that you can use for RPC. You can layer
messaging semantics on top of either.
> > The problem with all generated code is that it is ugly. This is true in
> > particular when you try to bridge object models. I have seen many attempts
> > at such automatic mappings: Java to IDL, IDL to GDMO and vice versa, the
> > COM-CORBA mapping, the CORBA-DCE mapping, etc. They all suffer from the
> > same problem: minor mismatches in the type system, scoping rules, and
> > object model semantics lead to generated code that looks like a dog's
> > breakfast and is so ugly that no-one wants to use it.
>
> I quiet agree with you on the fact that generated code is ugly. However, if
> generated the right way, with industry standard patterns and idioms, I find
> it the most useful.
I am very sceptical here. The only cases where code generation works is
when the generated code isn't directly called by application programmers.
Examples are GUI generators and parser generators, for which code generation
has been highly successful. However, as soon as code generation is used
for bridging (to adapt one API to another or, worse, to adapt one type
system to another), experience shows that code generation is unsuccessful
because it lacks the human insight that is necessary for crafting
ergonomic and efficient APIs.
> For this, a good framework based approach is required
> which is extensible to suit any particular type system, not just two of
> them. I find the MDA based approach most satisfying in this regard. It makes
> the world close to platform and technology independent.
Yes, but only once these problems are solved. There is a lot of work still
to be done before we reach that point.
> > > In my view, the design of a Web Service should start with the
> > > "contract" ( IDL for CORBA, WSDL for SOAP ).
>
> I would say, anything and everything after a good requirement capture is to
> be *Software Architecture*. Never jump directly to IDL or WSDL. The RM-ODP
> approach of defining five view points to a system helps capture more that
> what constrained languages like IDL and WSDL can capture.
Nothing wrong with architecture. The point is, you should first work out
what it is you want to say before saying it :-)
> > > I just think that CORBA/SOAP can live together.
> > > One would complete the other.
> >
> > Right. Run SOAP with the outside world and run CORBA on the inside.
>
> Well, that needs some more explanation. There are instances where SOAP can
> be used for inter component RPC. As long as there is no standard from
> CORBA's end to a particular solution, you will see WSDL/SOAP exploiting that
> area, unfortunately though ;-(.
Yes. As I said, it's a bit like comma-separated spreadsheet files. You use
them when you have to.
> From my side, I would say that a
> deep understanding of Software Architecture would provide you with the true
> benefits and disadvantages of the platforms and technologies of the past,
> the present and the future.
Unfortunately, we are so busy continuously reinventing the wheel that there
rarely is time to actually evaluate the architectural aspects of a system
and learn from them :-(
Michi Henning
> Just to clarify:
>
> My point was not captured on this context. I totally agree with you.
> My point was/is that I do not like the idea of *reverse engineering"
> the interface from some classes ( C++ and Java ) after the system
> is built, as some toolkits let you export the WSDL.
Yes. I always find reverse engineering quite funny. You have the code and
you get UML out of it. Using such a tool is like saying "Well, let's see
what it actually is that we have built..." Or a bit like drawing the
plans for a house after the house is finished...
Irmen de Jong
a fruitful discussion emerged, thanks to all who responded to my original
posting.
I think I will collect the important points and make a summary on my homepage
somewhere.
I find this subject very interesting and amusing on certian points.
Anyway, there are a few points I'm still struggling with:
How is it possible that -again- a RPC-ish mechanism is hyped and attracts all
attention?
I wasn't in the field when SUN RPC emerged, or OSF/DCE, but I suspect at that
time
they got the same amount of attention versus raw socket communication.
I was there when CORBA arrived, was hyped, then attention dimmed again and
currently isn't "in the picture" anymore because it's fairly commonplace, stable
and accepted.
Java RMI plays a role on the side, because of RMI over IIOP (i.e. CORBA).
And now we have Web Services / SOAP. "There we go again" was my reaction.
All arguments pro and con notwithstanding, the SOAP hype will fade soon enough
and attention will shift to the next "interesting thing" that comes along. SOAP
will
still be there, like CORBA, out of sight, but it's there.
What do you think? What part do all these code-generating IDE 'Wizards' / tools
play in this? If they're good enough, they will shield the developer completely
from the
underlying technology (f.ex. Caffeine from Visibroker?). Is this technology
becoming ubiquitous this way?
I find it interesting that the call for a strict language mapping / type system
in SOAP is getting louder, and it appears that eventually we'll have
these, including proxy/skeleton standards and well-defined services.
In fact, we've re-invented the ORB, but it's a SOAP-ORB this time.
(can you wash with that??? :-)
Anyway, I really want to know some more about your opinions and experience
with the skills/qualifications of your regular CORBA developer, and Web-service
developer (remember the comment I mentioned in my first posting about the
supposed difference in skills, on www.webservices.org).
Should a CORBA developer really have high qualifications and be thoroughly
educated? Why shouldn't (or should!) a web services developer be?
My updated conclusion is that Web Services are still easier to build with less
(and less complex) software requirements, debugging is harder.
Your code is likely to be committed to a specific implementation
toolkit/library.
And, in the end, you're gonna need all kinds of things that CORBA already has
(language mapping, type system, services, reliability!!).
As a last point, the economic, business and human factors concerning web
services
are not to be neglected. Indeed, why would I want to access the web-service
of a competing business? How do they get paid? Are they reliable?
Is their server reliable/scalable? Who do I turn to when they go belly-up?
Why won't I rather build the service myself and tune it to my exact needs?
(because more often than not you'll find that a third party service doesn't
quite fullfill your requirements).
Note: this isn't only about SOAP, ofcourse it counts for all third-party
"components"
or "services".
Again, thanks a lot for your comments and opinions.
Irmen de Jong
Don Box
> One of the initial arguments in favour of SOAP was its simplicity. About
> three years ago, I had a long discussion with Don Box about this. The
> argument Don presented basically was that you don't need a programming
> platform (along the lines of the CORBA run time).
I definitely said this!
> Instead, you just cobble
> SOAP requests and replies together using Perl, or whatever.
This is somewhat out of context.
I claimed then (and now) that SOAP and XML succeed because one CAN
cobble up messages using Perl. Not that that was necessarily the
preferred model.
> The problem with all generated code is that it is ugly. This is true in
> particular when you try to bridge object models. I have seen many attempts
> at such automatic mappings: Java to IDL, IDL to GDMO and vice versa, the
> COM-CORBA mapping, the CORBA-DCE mapping, etc. They all suffer from the
> same problem: minor mismatches in the type system, scoping rules, and
> object model semantics lead to generated code that looks like a dog's
> breakfast and is so ugly that no-one wants to use it.
I totally agree. This was true with COM when used from C++. This was
true for CORBA when used with ANY language.
Translating type systems always makes the 20% edge case hideous. The
80% common case can often look reasonable if not completely
transparent. Tim Ewald coined the term "translucent proxies" to
illustrate the futility of 100% transparency.
I think the interesting bits are what happens when XML types are
integrated into the programming language. XSLT is one example of this.
XML Query is another. These languages leave the messages in the XML
type system.
> What, you want to establish a type model before you make an RPC call?
> What a strange notion... ;-)
Hey, I was arguing that we needed metadata before wire protocol back
in 1998 when this whole thing started...
> As many proponents of SOAP and web services will tell you, the strict
> typing model of CORBA is undesirable and gets in the way and SOAP is so
> much better because, after all, you can ignore what you don't understand;
I would never make this argument and many consider me a proponent of
SOAP.
> never mind that, not having understood half of what you just said to me,
> I'm unlikely to return a useful reply... :-(
>
> The whole "loosely coupled" argument around web services is just a lot of
> hot air.
The term is thrown around way too much. I think the world will
converge on strongly typed XML over loosely coupled communication
media.
> When you think about it, the only way you can have reliable
> communication between two parties at the semantic level is if they agree
> on a common and complete type system. (But, of course, as soon as you
> have such a type system, the whole notion of "loosely coupled" goes out
> the window because changes in the conversation (surprise, surprise) require
> a change in the type system (and, even for loose typing, changes to the
> source code). In fact, what people think of when they say "loosely coupled"
> requires wetware: human insight is what we use to make up for the lack
> of a strict type system in human interactions. Unfortunately, computers
> are nowhere near getting such capabilities. It follows that "loosely coupled"
> as far as type systems are concerned will remain a pipe dream for many more
> years.
See above. Semantics need to be agreed upon a priori. Syntax usually
does too, but a certain amount of negotiation can be automated (see
the transfer syntax UUID in DCE for example).
> > Some of you, might be registered with the soapbuilders list, and know
> > that I am one that criticize many things on SOAP/WSDL. I think they
> > are much more complex that they should be, and simplication is a must.
>
> The interesting thing is that, as soon as you beef up a the protocol to
> the level where it meets real-life functional and performance demands,
> you end up with something complex, like it or not. The reason that RPC
> protocols are complex is not because the people who designed them were
> idiots or technocrats who like complexity, but because the functionality
> you need to build forces the complexity on you. (Plus some complexity added
> through design by committee, but that's a different story...)
FWIW, I would argue that the PDU format of SOAP/1.1 roughly as complex
as IIOP or DCE if you include the schema stuff, which you really have
to do at this point.
> > I just think that CORBA/SOAP can live together.
> > One would complete the other.
>
> Right. Run SOAP with the outside world and run CORBA on the inside.
That's certainly one way to do things, and will be a common deployment
scenario in shops that have already invested in CORBA.
> > > Are you *still* trying to tell us that the SOAP approach is the
> > > same or easier?
> >
> > I do believe it is the same. Sometimes a feel CORBA is cleaner,
> > because the technology is much more mature.
>
> It's also *much* more functional and at a higher level of abstraction.
> SOAP and CORBA are the same only if you compare them at the protocol level:
> both can be used to do RPC. (But, even there, look closely: where is
> polymorphism in SOAP? In fact, where are the objects in SOAP?)
Whoa! Polymorphism is there. Note that many "services" can export a
given "portType". This is no different than multiple CORBA objects
supporting a given interface.
As for "where are the objects," object-orientation shouldn't be the
universal litmus test one runs a technology through.
I thought we hashed this out years ago on this very list. IIOP and
SOAP are more or less isomorphic.
Both support strongly-typed endpoints.
Both support marshal-by-value in a very similar fashion.
Neither one has a great story for cross-language objects-by-value or
polymorphism for objects-by-value.
> Hmmm... So what will SOAP give you that CORBA doesn't?
Stronger support from IBM.
Stronger support from Microsoft.
Stronger support from the open source community.
Stronger support for languages people use NOW (e.g., python, perl,
etc).
Most importantly (IMHO), SOAP-based platforms are more likely to
evolve to solve people's needs than the OMG CORBA standards will. From
talking to Jon Seigel, the OMG seems preoccupied with MDA, not CORBA.
Can IONA evolve the Orbix product line to adapt to customer needs?
Definitely! Will this adaptation be considered OMG CORBA? No, at least
not until it gets sufficiently OMG'ed.
> The way I see it,
> SOAP *may* one day become a lingua franca for RPC, and that is useful. But
> the price you pay in terms of diminished functionality,
Bullshit.
> lower abstraction
> level,
This is totally a programming model/platform issue, not a protocol
issue.
> and performance is high.
> In particular, the performance of SOAP
> is nothing short of staggeringly bad. The wasted bandwidth and CPU cycles
> are simply breath-taking.
I agree that the state of the art performance-wise is sub-par.
> > > 1. Depending on the framework selected, SOAP programming is
> > > no easier, and possibly more work than the equivalent
> > > CORBA approach.
> > >
> > > 2. Regardless of the framework selected, the resultant code
> > > *is not portable* between frameworks.
> >
> > I agree with this, so far. My hope is that the W3C start listening to the
> > small folks like many of us, and add standard bindings for SOAP/WSDL.
>
> Don't hold your breath. From the time a standards body first looks at
> a language mapping to the time that mapping is commercially
> available from a number of vendors (and actually portable), several years
> elapse. In the mean time, it's vendor lock-in and non-portable code.
I too am skeptical that "language bindings" are the right approach.
> And the answer is that we re-invent all those wheels yet again? And there
> I am, thinking that it would nice to actually make progress for a change...
I am astonished at the range of work being done. I agree however that
a lot of it is derivative.
Cheers,
DB
http://www.donbox.com/
Rosimildo daSilva
news:2d3a5b34.02010...@posting.google.com...
> Michi Henning <mi...@ooc.com.au> wrote in message
news:<Pine.HPX.4.05.102010...@bobo.ooc.com.au>...
>
>
> Stronger support from IBM.
> Stronger support from Microsoft.
> Stronger support from the open source community.
> Stronger support for languages people use NOW (e.g., python, perl,
> etc).
>
I totally agree with this. Support from the "big boys" is extremely
important for large scale adoption of a technology.
SOAP has momentum, and the community is doing wonderful things.
I remember joinning the SOAP builders list a year ago, and I am
amazed by the amount of development done so far.
Rosimildo.
Michi Henning
> > Instead, you just cobble
> > SOAP requests and replies together using Perl, or whatever.
>
> This is somewhat out of context.
>
> I claimed then (and now) that SOAP and XML succeed because one CAN
> cobble up messages using Perl. Not that that was necessarily the
> preferred model.
Hmmm... I distinctly remember you saying that "programming platforms
are evil." (San Jose, 1999)
> > minor mismatches in the type system, scoping rules, and
> > object model semantics lead to generated code that looks like a dog's
> > breakfast and is so ugly that no-one wants to use it.
>
> I totally agree. This was true with COM when used from C++. This was
> true for CORBA when used with ANY language.
Hmmm... For C++, I'm the first to admit that there would have been prettier
options. However, for Python and Java, things seem to be working quite
well, so I wouldn't say ANY language.
> > As many proponents of SOAP and web services will tell you, the strict
> > typing model of CORBA is undesirable and gets in the way and SOAP is so
> > much better because, after all, you can ignore what you don't understand;
>
> I would never make this argument and many consider me a proponent of
> SOAP.
No, and I didn't mean to imply that you did! (But I've heard *many* other
people pose this line of reasoning.)
> > The whole "loosely coupled" argument around web services is just a lot of
> > hot air.
>
> The term is thrown around way too much. I think the world will
> converge on strongly typed XML over loosely coupled communication
> media.
In other words, XML with a message queue (or XML via e-mail, if you like :-)
> > It follows that "loosely coupled"
> > as far as type systems are concerned will remain a pipe dream for many more
> > years.
>
> See above. Semantics need to be agreed upon a priori.
Yes.
> Syntax usually
> does too, but a certain amount of negotiation can be automated (see
> the transfer syntax UUID in DCE for example).
I see this as one of the advantages of XML: for once, we have a universal
syntax, so we can get rid of the proliferation of little data description
languages. But, as you say, the semantics still need a priori agreement.
> > The interesting thing is that, as soon as you beef up a the protocol to
> > the level where it meets real-life functional and performance demands,
> > you end up with something complex, like it or not. The reason that RPC
> > protocols are complex is not because the people who designed them were
> > idiots or technocrats who like complexity, but because the functionality
> > you need to build forces the complexity on you. (Plus some complexity added
> > through design by committee, but that's a different story...)
>
> FWIW, I would argue that the PDU format of SOAP/1.1 roughly as complex
> as IIOP or DCE if you include the schema stuff, which you really have
> to do at this point.
Well, I guess you made my point :-)
> > > > Are you *still* trying to tell us that the SOAP approach is the
> > > > same or easier?
> > >
> > > I do believe it is the same. Sometimes a feel CORBA is cleaner,
> > > because the technology is much more mature.
> >
> > It's also *much* more functional and at a higher level of abstraction.
> > SOAP and CORBA are the same only if you compare them at the protocol level:
> > both can be used to do RPC. (But, even there, look closely: where is
> > polymorphism in SOAP? In fact, where are the objects in SOAP?)
>
> Whoa! Polymorphism is there. Note that many "services" can export a
> given "portType". This is no different than multiple CORBA objects
> supporting a given interface.
>
> As for "where are the objects," object-orientation shouldn't be the
> universal litmus test one runs a technology through.
Possibly not. But it's definitely handy to have built-in support for
down-casting, and static type checking for call dispatch. These are possible
only if polymorphism is built into the platform as a first-class concept.
Yes, I can implement polymorphism over SOAP (just as I can implement it
in C), but I shouldn't have to as an application developer.
> I thought we hashed this out years ago on this very list. IIOP and
> SOAP are more or less isomorphic.
More less than more? :-) I think we are talking disjoing subsets here.
SOAP has support for some data types that don't exist in IIOP and vice versa.
> Both support strongly-typed endpoints.
>
> Both support marshal-by-value in a very similar fashion.
>
> Neither one has a great story for cross-language objects-by-value or
> polymorphism for objects-by-value.
Agreed, on the whole. It's the minor differences that tend to make a mess
of automatic translation though.
> > Hmmm... So what will SOAP give you that CORBA doesn't?
>
> Stronger support from IBM.
Yes.
> Stronger support from Microsoft.
Yes.
> Stronger support from the open source community.
Maybe? Support for CORBA is quite strong in that community too.
> Stronger support for languages people use NOW (e.g., python, perl,
> etc).
Standardized support? I don't think so, at least not in the near future.
> Most importantly (IMHO), SOAP-based platforms are more likely to
> evolve to solve people's needs than the OMG CORBA standards will. From
> talking to Jon Seigel, the OMG seems preoccupied with MDA, not CORBA.
Some people are, others aren't. It depends on whom you talk to.
> Can IONA evolve the Orbix product line to adapt to customer needs?
> Definitely! Will this adaptation be considered OMG CORBA? No, at least
> not until it gets sufficiently OMG'ed.
Well, when we have what we think is a good idea, we put it up for
standardization wherever possible.
> > The way I see it,
> > SOAP *may* one day become a lingua franca for RPC, and that is useful. But
> > the price you pay in terms of diminished functionality,
>
> Bullshit.
Why is that? Right now, if you compare SOAP with CORBA, that is a correct
statement, I believe. If you are talking about comparing CORBA with SOAP
as it will have evolved in a few years time, sure. But right now, I don't
think there can be any doubt that CORBA is way ahead of SOAP in terms
of functionality and abstraction level.
> > lower abstraction
> > level,
>
> This is totally a programming model/platform issue, not a protocol
> issue.
Exactly. So, comparing SOAP and CORBA is meaningless, in the sense that
SOAP corresponds to IIOP, and IIOP is only a small part of CORBA.
> > Don't hold your breath. From the time a standards body first looks at
> > a language mapping to the time that mapping is commercially
> > available from a number of vendors (and actually portable), several years
> > elapse. In the mean time, it's vendor lock-in and non-portable code.
>
> I too am skeptical that "language bindings" are the right approach.
But what's the alternative if I'm interested in portable code? I definitely
don't want to go back to the days where I have to throw myself in with
one particular vendor and be at that vendor's mercy when it comes to
upgrading, getting new feature support, or being shielded from that vendor's
decision to pull out of this particular market...
> > And the answer is that we re-invent all those wheels yet again? And there
> > I am, thinking that it would nice to actually make progress for a change...
>
> I am astonished at the range of work being done. I agree however that
> a lot of it is derivative.
So far, I don't think I've seen a single thing that could be called
innovation in the entire SOAP and Web Services area. It's just repackaging
of already solved problems and, unfortunately, with many mistakes of the
past being repeated.
Jim Melton
"Rosimildo daSilva" <rdas...@connecttel.com> wrote:
> "Don Box" <db...@donbox.com> wrote in message
> news:2d3a5b34.02010...@posting.google.com...
> > Michi Henning <mi...@ooc.com.au> wrote in message
> news:<Pine.HPX.4.05.102010...@bobo.ooc.com.au>...
> >
> > > Hmmm... So what will SOAP give you that CORBA doesn't?
> >
> > Stronger support from IBM.
> > Stronger support from Microsoft.
> > Stronger support from the open source community.
> > Stronger support for languages people use NOW (e.g., python, perl,
> > etc).
> >
>
> I totally agree with this. Support from the "big boys" is extremely
> important for large scale adoption of a technology.
I totally disagree with this. Microsoft doesn't know the meaning of
"standard". Look at what they did to/with Java. Find an ANSI-compliant
C++ compiler for Windows? If Microsoft can't drive (own) the standard,
they won't want to play.
I'm not sure I'd call IBM a "big boy" these days. I am at a loss to see
where they have market dominance (relevant to this discussion).
The open-source community seems to be pretty well behind CORBA. I wonder
on what basis a claim for greater open-source support for SOAP was made.
The languages people use NOW are Java and C++. In any event, there are
python mappings for CORBA (standards compliant?) available today. Can
SOAP make the same claim? I doubt it, since it's still a work in
progress.
> SOAP has momentum, and the community is doing wonderful things.
> I remember joinning the SOAP builders list a year ago, and I am
> amazed by the amount of development done so far.
SOAP has hype. SOAP has energy. The question is: is the community
extending the state of the art, or merely re-inventing the wheel?
--
Jim Melton, novice guru | So far as we know, our
e-mail: Jim.M...@Technologist.com | computer has never had
v-mail: (303) 971-3846 | an undetected error.
Michi Henning
> The languages people use NOW are Java and C++. In any event, there are
> python mappings for CORBA (standards compliant?) available today.
Yes, the Python mapping is standardized.
Richard Hardgrave
Pardon me for implying anything negative, but it seems there is some
lack of perspective with regards to the general business strategy of
"the big boys".
History lessons are important ... IBM made its name by "bullying" the
market by totally disregarding standardization. When networking
came along, IBM thought the network of the future was a "mainframe"
with a bunch of terminal servers.
When the stock took a "header" in the mid nineties, that, apparently,
issued a wake-up call. They've been trying to scratch their way back
into a fraction of their previous market position ever since. And, how
are they doing it? I can't remember an IBM commercial in the last
8 months that isn't touting its new Linux-based network server.
The "big boys" are not about "technology" (well, software technology,
anyway). They are about making a fast buck and crushing the "little
guys"
in the process.
Richard
Rosimildo daSilva
news:Jim.Melton-7D7C3...@netnews.attbi.com...
> I'm not sure I'd call IBM a "big boy" these days. I am at a loss to see
> where they have market dominance (relevant to this discussion).
IBM is by far, the largest company in the software industry. Much larger
than MS.
So, I think it is pretty big. <g>
Sometimes hype is important to give that "push" to the technology. Look at
java.
It has made serious inroads, and has established itself as a big player on
the server
side. XML is very important, but the hype is high.
What is wrong with that ?
We are developers, and we should develop the best solution for our clients.
<g>
Rosimildo.
Rob Ratcliff
> So far, I don't think I've seen a single thing that could be called
> innovation in the entire SOAP and Web Services area. It's just repackaging
> of already solved problems and, unfortunately, with many mistakes of the
> past being repeated.
>
>
I'm so happy that people like Michi are digging their heels in on issues like this.
I've also been very disappointed over the last 10 years with the
lack of progress made, especially with the internet, due in part
to many "technologies" that were driven more by marketing, hype and NIH
rather than sound technical decisions that would encourage incremental
progress. The motivation for many organizations to push these
new "technologies" is to level the playing field so that brand new
software, books, and services can be sold. An incremental improvement to
an existing technology can't be marketed as well even though it would be
much more beneficial to society as a whole.
As for the argument about CORBA's overwhelming complexity, that reminds me
of the argument I heard from one of the architects of the HTML spec. who said that
initially crude HTML was picked as the markup language for the internet rather than
a more
mature language like LaTeX/TeX because LaTeX was much too complex and required
all those bit mapped fonts and it didn't have hypertext capability. Plus, why would
would you
want so much control over the layout of your document, only content matters right?
I argued that you didn't need the fonts and why not just take a subset of LaTeX
markup as the first step rather
than reinventing an entirely new markup language. Also, people added hypertext
capability to
LaTeX within months of HTML coming out.
Well, you all know what happened. Through a very painful process, the simple HTML
spec blossomed into a more
complex markup language with all kinds of accompanying
"technologies" to assist like: CSS, XSL, Javascript, VBScript, and XML and many
other
half-baked mutant programming languages. It took many years for HTML Web
pages to come even close to layouts possible in the 80's. We took a 10 year step
backwards in document
quality by creating an entirely new markup language for the Web.
One still cannot even produce a nicely typeset book with a table of contents
and index from a web site like you could've if LaTeX had've been used.
(BTW, the over hyped MathML is also an atrocity compared to LaTeX.)
Based on experiences like this, I'm a little hesitant to embrace a new hyped up
technology like web services
without a careful look at the true motivations of those promoting the new
technology and the real benefits
that it can bring. Hopefully we will all remember some of the painful lessons from
the 90s.
Rather than reinventing the wheel or throwing out the baby with the bath water,
why not fix what's "wrong" with CORBA?
Here are some of the arguments that I've heard:
"CORBA is too complex"
If CORBA is too complex, take a subset or create a simpler higher-level API.
There is no sense
in throwing years of development out the window due to some perceived
superficial "flaws".
For example, I've been using a very nice CORBA 2.3 ORB written completely in
Tcl called
Combat. (http://www.fpx.de/Combat/) Combat brings CORBA to the masses. It's
about the simplest
API I've seen for IPC. I think it's an outstanding example of making CORBA
simple. It's obvious that
simplicity is possible with CORBA with a correct design.
"CORBA is too expensive"
Unlike a few years ago, there are many fully compliant free ORBs available
these
days written in C++, Java, Tcl and other languages. When you need the extra
power you can upgrade to
commercially supported ORBs. (It would be nice if all OS's supported a CORBA
environment
so one could depend on it like ftp, http, ipc, telnet or NFS for instance.)
"IIOP doesn't work through firewalls or proxy web servers"
Standardize the use of HTTP protocols for CORBA or hide SOAP beneath the covers
using
something like the SOAP2CORBA bridge:
http://sourceforge.net/projects/soap2corba/. There is nothing
magical about using SOAP over HTTP compared to other solutions I've seen for
RMI or CORBA.
You still will not be be able to perform callbacks through a proxy web server.
Again, there is no reason to invent a whole new paradigm just because a current
technology has a shortcoming,
especially when the shortcoming can be easily fixed.
"I can't read IIOP like I can XML"
Again, use some type of human readable protocol like SOAP when performance
isn't an issue to make it
easier for tool developers. (I'd rather not see the underlying communication
protocol myself.) HTTP became
dominant on the internet due to it's simplicity and human readability even
though the performance was poor.
Maybe there is a lesson there.
I also think that some more descriptive features could be added to the IDL spec
like human readable
descriptions of functions, interfaces and constants. When I browse an interface
repository I'd like to be able
to read what this interface does for me for instance. That's one feature that
WSDL and such has over IDL.
(I hacked this with my IDL by creating munged string constants like
myfunction_description to allow the retrieval
of the function descriptions from the IFR.)
"CORBA isn't being hyped by IBM and MS"
Should we really be making decisions driven by marketing rather than striving
for incremental progress of existing
technologies? Will we benefit from such decisions in the long run?
Personally, I think life is much too short to take too many steps backwards.
JMHO,
Rob
Gerald Brose
>
> "IIOP doesn't work through firewalls or proxy web servers"
That's a known problem.
> Standardize the use of HTTP protocols for CORBA or hide
> SOAP beneath the covers using something like the
> SOAP2CORBA bridge: http://sourceforge.net/projects/soap2corba/.
> There is nothing magical about using SOAP over HTTP
> compared to other solutions I've seen for RMI or CORBA.
> You still will not be be able to perform callbacks
> through a proxy web server. Again, there is no reason
> to invent a whole new paradigm just because a current
> technology has a shortcoming, especially when the
> shortcoming can be easily fixed.
Well, there are better options for fixing that shortcoming:
build proper IIOP application-level firewalls that allow IIOP
to pass into and out of local domain boundaries. Tunneling
is undesirable not only because of the performance penalty,
but also because it opens a host of other potential security
holes.
Pardon the commercial plug, but easy-to-use IIOP firewalls
(that do not require applications to change) do exist. My
company builds them :-).
Cheers, Gerald.
--
Dr. Gerald Brose, Software Architect mailto:br...@xtradyne.com
Xtradyne Technologies AG http://www.xtradyne.com
Schoenhauser Allee 6-7, Phone: +49-30-440 306-27
D-10119 Berlin, Germany Fax : +49-30-440 306-78
Rob Ratcliff
firewalls.
The only issue I see is that they are not ubiquitous like proxy web
servers
are especially for the larger (more paranoid)
corporations. Most larger corporations allow HTTP traffic but almost
nothing else.
So either the security divisions of every corporation have to be
convinced to
add an IIOP firewall or have a standardized alternative solution (albeit
slow and crippled)
such as IIOP over HTTP or SOAP over HTTP or whatever. (It'd probably be
nice to
have a stateless version of communication available anyway for better
scalability.)
Here are some related projects:
RMI and SOAP: (similar problem)
http://www.extreme.indiana.edu/soap/
http://sourceforge.net/projects/soap-rmi/
Some observations on performance:
http://www.extreme.indiana.edu/soap/sc00/paper/node13.html#observations
Utilizing mature message passing technologies with SOAP:
http://soap2corba.sourceforge.net/
Has it been your experience that more of the larger corporations are
buying into
IIOP firewalls?
Thanks,
Rob
Tim Ward
news:3C3F44D8...@futuretek.com...
>
> The only issue I see is that they are not ubiquitous like proxy web
> servers
> are especially for the larger (more paranoid)
> corporations. Most larger corporations allow HTTP traffic but almost
> nothing else.
> So either the security divisions of every corporation have to be
> convinced to
> add an IIOP firewall or have a standardized alternative solution (albeit
> slow and crippled)
> such as IIOP over HTTP or SOAP over HTTP or whatever. (It'd probably be
> nice to
> have a stateless version of communication available anyway for better
> scalability.)
Any sane firewall manager would prefer to enable IIOP traffic in a
controlled manner rather than have people tunnelling all sorts of
heaven-knows-what through port 80, shurely??
--
Tim Ward - posting as an individual unless otherwise clear
Brett Ward Ltd - www.brettward.co.uk
Cambridge Accommodation Notice Board - www.brettward.co.uk/canb
Cambridge City Councillor
Jim Murphy
> than MS.
> So, I think it is pretty big. <g>
What are talking about?
Market Cap Total Cash
MSFT: 369.5B 36.2B
IBM: 207.3B 4.01B
Paul Campbell
> requires wetware: human insight is what we use to make up for the lack
> of a strict type system in human interactions. Unfortunately, computers
> are nowhere near getting such capabilities. It follows that "loosely
coupled"
> as far as type systems are concerned will remain a pipe dream for many
more
> years.
Precisely - its a pot of gold at the end of the rainbow, and probably no
closer to reality to systems that can compile natural language into
working programs. Bassically if computers ever get this smart we
wont need programmers at all for anything.
Anyway if untyped interfaces were so useful then DII/DSI would be
used much more widely than it is now ...
> The interesting thing is that, as soon as you beef up a the protocol to
> the level where it meets real-life functional and performance demands,
> you end up with something complex, like it or not.The reason that RPC
> protocols are complex is not because the people who designed them were
> idiots or technocrats who like complexity, but because the functionality
> you need to build forces the complexity on you. (Plus some complexity
added
> through design by committee, but that's a different story...)
Indeed . Some problem spaces simply cant be "dumbed down" beyond
a certain point. Network programming is one of them. Data persitence
is another (which is why xml is also flawed as a persitence mechanism).
The other supposed advantage of soap is the "human readability" but
really and truely what real use is that ?. In any inter-corporation
data exchange scenario its only going to have to encrypted anyway.
Paul C.
Paul Campbell
>
> > Just to clarify:
> >
> > My point was not captured on this context. I totally agree with you.
> > My point was/is that I do not like the idea of *reverse engineering"
> > the interface from some classes ( C++ and Java ) after the system
> > is built, as some toolkits let you export the WSDL.
>
> Yes. I always find reverse engineering quite funny. You have the code and
> you get UML out of it. Using such a tool is like saying "Well, let's see
> what it actually is that we have built..." Or a bit like drawing the
> plans for a house after the house is finished...
Its nothing more than expressing the same information in a different form.
The old blueprint/building analogy is IMO a very poor one for software
systems because the involvement of people is 100% in the design activity
- the compiler does the "building" bit.
To make the process analagous we would have to have some sort of
engine that we could feed in minutely detailed plans (down to individual
brick level) for a building and have it "compile" that into a real building.
Paul C.
Rob Ratcliff
Paul Campbell wrote:
> "Michi Henning" <mi...@ooc.com.au> wrote in message
> news:Pine.HPX.4.05.102010...@bobo.ooc.com.au...
> >In fact, what people think of when they say "loosely coupled"
> > requires wetware: human insight is what we use to make up for the lack
> > of a strict type system in human interactions. Unfortunately, computers
> > are nowhere near getting such capabilities. It follows that "loosely
> coupled"
> > as far as type systems are concerned will remain a pipe dream for many
> more
> > years.
>
> Precisely - its a pot of gold at the end of the rainbow, and probably no
> closer to reality to systems that can compile natural language into
> working programs. Bassically if computers ever get this smart we
> wont need programmers at all for anything.
>
> Anyway if untyped interfaces were so useful then DII/DSI would be
> used much more widely than it is now ...
>
Looks like a great use of DII/DSI is to create CORBA interfaces for
various untyped scripting languages like Tcl and Perl such as:
http://www.fpx.de/Combat/
http://sourceforge.net/projects/corba-mico/
I think these types of capabilities will help further increase
CORBA's popularity and ease of use.
Gerald Brose
>
> So either the security divisions of every corporation have
> to be convinced to add an IIOP firewall or have a standardized
> alternative solution (albeit slow and crippled) such as IIOP
> over HTTP or SOAP over HTTP or whatever.
Slow and crippled, exactly.
> Has it been your experience that more of the larger
> corporations are buying into IIOP firewalls?
The enterprise security market is conservative and hence slow
to adapt "new" solutions sold by non-IBM companies, but when
you explain it, most people understand it right away. You have
to do the explaining, however.
Paul Campbell
> > Anyway if untyped interfaces were so useful then DII/DSI would be
> > used much more widely than it is now ...
> >
>
> Looks like a great use of DII/DSI is to create CORBA interfaces for
> various untyped scripting languages like Tcl and Perl such as:
OK so how many systems do you know that use DII to dynamically adjust
themselves to invoke an interface that they had no prior knowledge of , and
then make sensible use of that interface without any human intervention ?.
And I mean invoke an interface that supports a specific business function -
not perform some generic processing on it like bridging or browsing.
Even in an untyped scripting language you have to know what the interface
looks like and what its behaviorr is to be able to utilise any specific
business
functionality. In this context DII/DSI is just saving you the trouble of
compiling
stubs and skeletons - nothing more.
Paul C.
Jason Voegele
I'm not sure I follow your argument. Is a programmer writing a script
considered human intervention? What kind of things are you imagining
that could be accomplished with a better DII mechanism? Or are you
saying that these dynamic mechanisms are of limited utility? (Just
trying to clarify your point here.)
To clarify the point that Rob Ratcliff was trying to make, I'll give
an example.
I'm writing a CORBA client for the Ruby language, which is of course a
very dynamic language. Thanks to the DII, I can do this:
class CorbaObject
# initialize is analagous to a constructor
def initialize(ior)
# use the naming service to lookup the
# object with specified ior
...
end
# method_missing is called by Ruby if an object
# doesn't understand a message
def method_missing(method_name, *args)
# use the DII to lookup and invoke the method
...
end
end
Assume we have a CORBA calculator:
interface Calculator {
long add(in long number1, in long number2);
long multiply(in long number1, in long number2);
};
Now, using the simple CorbaObject class, I can do this:
calc = CorbaObject.new("IOR for calculator object")
print calc.add(2, 4) # prints 6
print calc.multiply(2, 4) # prints 8
Since the CorbaObject class does not understand the "add" or
"multiply" messages, Ruby calls "method_missing" which invokes the
appropriate methods using DII. Thanks to this mechanism, the script
writer is freed not only from having to compile stubs and skeletons,
but also from having write any CORBA code at all, since the
CorbaObject class constructs any arbitrary invocation automatically.
I hope that clarifies Rob Ratcliff's point. Could you clarify yours?
Thanks,
Jason Voegele
Paul Campbell
"Jason Voegele" <ja...@jvoegele.com> wrote in message
news:91acf731.02011...@posting.google.com...
> > Even in an untyped scripting language you have to know what the
interface
> > looks like and what its behaviorr is to be able to utilise any specific
> > business
> > functionality. In this context DII/DSI is just saving you the trouble of
> > compiling
> > stubs and skeletons - nothing more.
>
> I'm not sure I follow your argument. Is a programmer writing a script
> considered human intervention? What kind of things are you imagining
> that could be accomplished with a better DII mechanism?
> Or are you
> saying that these dynamic mechanisms are of limited utility? (Just
> trying to clarify your point here.)
Yes.
>
> To clarify the point that Rob Ratcliff was trying to make, I'll give
> an example.
>
> Assume we have a CORBA calculator:
>
> interface Calculator {
> long add(in long number1, in long number2);
> long multiply(in long number1, in long number2);
> };
>
> Now, using the simple CorbaObject class, I can do this:
>
> calc = CorbaObject.new("IOR for calculator object")
> print calc.add(2, 4) # prints 6
> print calc.multiply(2, 4) # prints 8
>
> Since the CorbaObject class does not understand the "add" or
> "multiply" messages, Ruby calls "method_missing" which invokes the
> appropriate methods using DII. Thanks to this mechanism, the script
> writer is freed not only from having to compile stubs and skeletons,
> but also from having write any CORBA code at all, since the
> CorbaObject class constructs any arbitrary invocation automatically.
>
> I hope that clarifies Rob Ratcliff's point. Could you clarify yours?
Fundamentally you are still writing code to the specific interface i.e. the
knowledge that the interface has methods called "add" and "multiply"
and what the intent of those methods is, is emodied in your client code.
This no different conceptually from just compiling the above IDL
into stubs and then calling it in say C++ (although its certainly easier).
Thats what I mean when I say its nots really "dynamic" in the sence
that was being discussed earlier in this thread. Its not adaptive at
all.
A true dynamic client (again in the context of the earler posts) would
be able to discover and use *any* calculator interface. My point is that
DII/DSI takes us no closer *this* level of adaptiveness (sic) - that
"dynamic discovery and use" of business interfaces is essentially
impossible to automate.
Paul C.
Steinar Bang
[...]
> I'm writing a CORBA client for the Ruby language, which is of course a
> very dynamic language. Thanks to the DII, I can do this:
> class CorbaObject
> # initialize is analagous to a constructor
> def initialize(ior)
> # use the naming service to lookup the
> # object with specified ior
> ...
> end
Just to pick a nit with the above comment: if you already have an IOR
(Interoperable Object Reference) for an object, there is no need to
look it up through the naming service.
If you have an IOR, you just let your ORB provide a connection to the
object.
Jason Voegele
Of course. My mistake. I had mentally merged two separate examples.
Thanks,
Jason Voegele
Jason Voegele
> A true dynamic client (again in the context of the earler posts) would
> be able to discover and use *any* calculator interface. My point is that
> DII/DSI takes us no closer *this* level of adaptiveness (sic) - that
> "dynamic discovery and use" of business interfaces is essentially
> impossible to automate.
Thanks for the clarification. Is "dynamic discovery and use of
business interfaces" a claim made by SOAP proponents/marketers?
Thanks,
Jason Voegele
Paul Campbell
I'm sure it will be, just as some Corba proponents hinted at the possibility
of being able to do so in the early days. Implying that you can build
systems without rigourous interface specification is always a powerful
selling
technique to the clueless.
Paul C.