Discussions

News: Programming Legends Debate .Net, J2EE

  1. Programming Legends Debate .Net, J2EE (95 messages)

    At a session entitled "The Great J2EE vs. Microsoft .Net Shootout" at the OOPSLA conference here this week, software development superstars debated the relative strengths and weaknesses of .Net and Java. The debate showed mutual respect, with just a few jabs from each side.

    One interesting quote came from Alan Knight, a SmallTalker who was on the panel to offer some independant thoughts:
    "I would certainly be willing to agree that both Java and Microsoft have both gone off in the wrong direction and to some extent are following each other in circles. But there are positives and negatives. The positive is they are learning from each other and gaining best practices. The negative is they are chasing each others' tails to get feature checklists matched up, regardless of value to developers."

    Dynamic languages were also brought up:
    IBM has an interest in dynamic languages, said High. He said IBM is looking at making some provisions for languages like JavaScript and others, including Groovy, a dynamic language for the Java Virtual Machine (JVM).

    Crupi said that although there is no plan to add dynamic languages to the Java platform, there is a Java Specification Request for Groovy, JSR-241, "and I anticipate there will be more of these dynamic languages in the future."

    Knight said there seems to be a certain amount of confusion about what constitutes dynamic languages. He said one thing these languages do is provide "the ability to execute half-formed thoughts." In response, Box quipped, "Microsoft has been accused of shipping half-formed thoughts" for a long time.

    And then it got a bit more serious as Don Box said:
    "I'm much more interested in functional languages than dynamic languages. The brevity of having the compiler do more of the work is a good thing."

    Regarding the object-relational mapping issue, Hejlsberg said, "This is one of my pet peeves – the enormous impedance mismatch between databases and enterprise programming languages. I'm amazed at how much progress we can make by integrating the two worlds and O/R [object-relational] mappings are the first stop along that path… I'm spending a large portion of my time trying to figure out how to solve these problems."

    Microsoft is at work on an object-relational mapping technology effort known as ObjectSpaces that was slated to be delivered with the upcoming Longhorn operating system.

    Meanwhile, Box took a swipe at the Java camp. "I marvel at how many O/R layers there are on the Java side," he said. "The thing that scares me about a lot of their O/R approaches is it's basically going back to the early '90s model… I hope the Java community keeps putting more troops into the Vietnam that is O/R."

    Read Programming Legends Debate .Net, J2EE

    Threaded Messages (95)

  2. Programming Legends Debate .Net, J2EE[ Go to top ]

    Don Box basically invented SOAP, the most inefficient and verbose marshalling format in the history of computer science.

    So, pleeeeze, don't let the guy out on the language arena.
  3. Don Box basically invented SOAP, the most inefficient and verbose marshalling format in the history of computer science.So, pleeeeze, don't let the guy out on the language arena.
    Just so this thread doesn't start degenerating into a litany of misinformation, it'd be great if you can first look at A Brief History of SOAP
  4. Don Box basically invented SOAP, the most inefficient and verbose marshalling format in the history of computer science.So, pleeeeze, don't let the guy out on the language arena.
    Just so this thread doesn't start degenerating into a litany of misinformation, it'd be great if you can first look at A Brief History of SOAP

    What are you talking about? Don Box os one of the inventors of the original RPC SOAP spec, and the article you refer doesn't dispute that.

    This interview with Don Box says it all: http://www.sys-con.com/story/?storyid=45908&DE=1

    The first SOAP spec was written by Don Box and Dave Winer in *two days*.

    While I think Don Box is a clever guy, SOAP isn't his best work...
  5. Don Box basically invented SOAP, the most inefficient and verbose marshalling format in the history of computer science.So, pleeeeze, don't let the guy out on the language arena.

    If you see SOAP exclusively as a marshalling format for method calls between objects, you're missing the point. If you want heterogenious systems to communicate in a loosely coupled fashion, you inevitably have to transmit a lot more meta data than you would need for closely coupled systems based on RMI or CORBA. So to call it "most inefficient" doesn't mean a lot if you don't compare it with other protocols that have similar objectives.
  6. Don Box basically invented SOAP, the most inefficient and verbose marshalling format in the history of computer science.So, pleeeeze, don't let the guy out on the language arena.
    If you see SOAP exclusively as a marshalling format for method calls between objects, you're missing the point. If you want heterogenious systems to communicate in a loosely coupled fashion, you inevitably have to transmit a lot more meta data than you would need for closely coupled systems based on RMI or CORBA. So to call it "most inefficient" doesn't mean a lot if you don't compare it with other protocols that have similar objectives.

    You know, there's a difference between sending meta data and sending it for each field, each time you refer to the field. That's just plain stupid.

    It's the natural thing to do when you use XML, but XML is simply not appropriate for this kind of stuff. But XML was in the news. It was hot. And Don Box et.al. sure likes to be buzzwork compliant, like everybody else.

    SOAP, from an engineering standpoint, is a complete disaster.
  7. It's the natural thing to do when you use XML, but XML is simply not appropriate for this kind of stuff. But XML was in the news. It was hot. And Don Box et.al. sure likes to be buzzwork compliant, like everybody else.

    I accept that the XML is not the best when u think of the communication overhead. But XML has become a main standerd for data oriented operations. Going againt the standerds had became total failures in the history many times. Just think why people still use "HTML". Also we know use of XML has allowed wide support of tools to work on SOAP.
  8. Hasith,

    Just what are you talking about ?
    Who's going against the standards ? RPC, DCE, CORBA, RMI all have serialisation protocols that are well documented and standardised. XML has not benefit whatsoever, au contraire.
    Writing a binary format parser is not very easy, granted, but neither is writing a compliant XML parser. Choosing to implement a tool for SOAP because the underlying format is XML - what are you talking about here ? All ORBs, from C to C++ to Eiffel and Java ship with "idlc" compilers, that write marshalling code for you, that in turn uses a library for CDR.

    If you have to get into debugging XML repr. when doing RPC, you're wasting your time already. Low-level serialisation should just work. As a programmer you should be as oblivious to whether it's XML or XDR or CDR or Hessian, the point is that is should be compact, versatile and fast, which XML is _not_.
  9. Who's going against the standards ? RPC, DCE, CORBA, RMI all have serialisation protocols that are well documented and standardised. XML has not benefit whatsoever, au contraire.

    How many of u actually believe web services will get this popularity if it was based on yet another protocol which is not based on XML? Does CORBA stands at this position today??? This is the point what I want to bring up.

    This is where a marketing factors over ahadows a perfect engineering solution. I believe having a wide accepted protocol which allows some level of interoperability (like SOAP) is better than not having a one at all.
  10. I believe having a wide accepted protocol which allows some level of interoperability (like SOAP) is better than not having a one at all.

    Hasith, the discussion is about the engineering aspect (and Don Box'es abilities as an engineer), not the marketing aspect.
  11. I accept that the XML is not the best when u think of the communication overhead.

    The problem is not that is not the best. The problem is that the overhead is HORRIBLE. I have a recent hands-on experience with an application that usually sent just integer identifiers over the network. Other times complex object graphs (but rarely).

    We had to reimplement the whole thing (a hired consultant made the brilliant decision of using SOAP) and that took the overhead down from 1.5 MB per call to 65 Kbyte on average(!!!)

    Also, the server CPU got much healthier (no more Apache server to drive the marshalling around, no more crazy xml parsing + better control over threading.)

    For anything but the simplest integration scenario, SOAP, WebServices and SOA is just a god damned joke.

    When are people gonna learn that network bandwidth and latency are going to be the limiting factor for decades to come?
  12. Programming Legends Debate .Net, J2EE[ Go to top ]

    For anything but the simplest integration scenario, SOAP, WebServices and SOA is just a god damned joke.When are people gonna learn that network bandwidth and latency are going to be the limiting factor for decades to come?

    But SOA isn't about web services...really...that's just the glue. As I understand it, the real work is in course-grained objects that are exposed as WSDL and web services.

    It'd be foolish to build a whole system based on web services, but these course grained objects can do JDBC, CORBA, JMS, JCA, or even make a binary call to some windows service...right?

    So the premise that SOAP is bloated, I agree with.

    I agree that SOAP will be widely mis-applied, doing fine-grained things, or not dropping down to more performant techniques within these course-grained biz components.

    But using SOAP in a very thin layer, only at integration points, etc...it becomes very much a matter of best practices...right?

    Anyway, skepticism is healthy, we're definately climbing the hype curve!

    Regards,
    Mike
  13. Programming Legends Debate .Net, J2EE[ Go to top ]

    .When are people gonna learn that network bandwidth and latency are going to be the limiting factor for decades to come?

    I doubt very much that the use of a few (or even many) XML tags is going to have any impact at all over networks which are increasingly being used for voice-over-IP and streaming video. Even if XML was being used in volume, its a highly compressible format.
  14. total failures?[ Go to top ]

    I accept that the XML is not the best when u think of the communication overhead. But XML has become a main standerd for data oriented operations. Going againt the standerds had became total failures in the history many times. Just think why people still use "HTML". Also we know use of XML has allowed wide support of tools to work on SOAP.

    On my current project I decided to go against "standards". No EJB, no Web Services. Instead of standards, the Hessian protocol. It works like a champ.
  15. Don Box basically invented SOAP, the most inefficient and verbose marshalling format in the history of computer science.So, pleeeeze, don't let the guy out on the language arena.
    If you see SOAP exclusively as a marshalling format for method calls between objects, you're missing the point. If you want heterogenious systems to communicate in a loosely coupled fashion, you inevitably have to transmit a lot more meta data than you would need for closely coupled systems based on RMI or CORBA. So to call it "most inefficient" doesn't mean a lot if you don't compare it with other protocols that have similar objectives.
    You know, there's a difference between sending meta data and sending it for each field, each time you refer to the field. That's just plain stupid.It's the natural thing to do when you use XML, but XML is simply not appropriate for this kind of stuff. But XML was in the news. It was hot. And Don Box et.al. sure likes to be buzzwork compliant, like everybody else.SOAP, from an engineering standpoint, is a complete disaster.

    I disagree. To have the metadata in each message makes the message self-contained to some degree. And that enables you to interpret the message along a whole chain of systems that would otherwise have to act in a much more closely coupled and predefined way. You can store and forward XML messages asynchronously. You can define rules for their dispatching and so on, without distributing the metadata to all those systems and keep it up to date all the time. For example, there could be one system along the chain, that only understands one particular SOAP header and acts upon it. If that system would receive a serialized Java class, it couldn't just use one particular field of that class. It would need to have access to exactly the same version of the class file as the sender. That's why I say it is closely coupled.
  16. I disagree. To have the metadata in each message makes the message self-contained to some degree.

    Sure. But that doesn't mean repeating the meta data for a field each that that field is use, does it? At any rate, XML is way to verbose, meta data or not.
  17. I also disagree.
    What you're talking about goes by the names of notification service, jms, mom, *mq.
    Most of these little dudes doing message filtering, routing, persistence and guaranteed delivery do not use XML. Why would they ?
    What the hell is wrong with the world today ? What's this "let's just use XML 'cause XML allows us to put in tons of metadata and if we screw it up we'll just add more metadata on top and with XML we're gonna be soo loosly coupled" nonsense ?

    Did I fall asleep and miss something ? Where did the idea that metadata is XML and XML is metadata came from ? That SOAP headers are the right and natural way to do it ?!
    What is the relation between XML and asynchronous processing ? Rules ? Dispatching ?
    And why would you ever think that the alternative is bytecodes in .class format ?!
  18. Most of these little dudes doing message filtering, routing, persistence and guaranteed delivery do not use XML. Why would they ?

    I have never managed to understand why there is so much objection to XML! For decades I have had to deal with obscure text formats or platform and system-dependent binary formats. I have had to interpret data and information with differing word lengths and byte endian-ness. XML is a great way to interchange data and to store data - it's text (so we can read it, and so data can outlive the software), it's international, and it's extensible (someone else can add to your XML file or data without preventing you from reading it).

    What's the big deal? Would you rather be hacking bytes into binary messages? If so, why?
  19. I have never managed to understand why there is so much objection to XML!
    The objection is no so much towards XML, but the sheer amount of XML and differing schemas - I have no problem with using XML, but don't just use it for the sake of it. It's more to do with the developer's tendency to blindly use it, rather than with XML itself.
    For decades I have had to deal with obscure text formats or platform and system-dependent binary formats. I have had to interpret data and information with differing word lengths and byte endian-ness.
    This is what XML is good for, getting rid of platform-dependent byte format. It is not good, however, as a replacement for every possible place you might ever use data - there was talk a while back that XML would replace you're favourite programming language - would you like to write xsl tests for the rest of your career?

    As a question, how would you optimise XML for transferring across the wire? Shorten the tag and attribute names perhaps? Then provide a detailed spec of your tage and attributes and their meanings? Congratulations, you've just built a protocol. Every XML schema and DTD is a protocol - XML has not got rid of network or data protocols, it's just made it more high level and more accessible to the Average Joe programmer, which has resulted in an explosion of protocols.
  20. As a question, how would you optimise XML for transferring across the wire? Shorten the tag and attribute names perhaps? Then provide a detailed spec of your tage and attributes and their meanings? Congratulations, you've just built a protocol.

    Why would anyone bother doing that when there are extant compression algorithms that work perfectly well with XML data? A good summary of some of the options is here: http://xml.coverpages.org/xmlAndCompression.html

    What I would like to see is further thought given to something like passing the XML parse tree around along with the XML itself (a bit like what Tuxedo does with FML buffers). <tongue firmly in cheek> Oh wait! We can't learn anything from 1980s technology can we? ;-) </tfic>

    Seriously though, assuming something like this is practical, it could elminate a lot of the parsing costs associated with XML, while still being efficient over the wire (by virtue of compression). Plus the parse tree could be rebuilt from scratch at any time by any system that either didn't receive it or doesn't understand it.
  21. would you like to write xsl tests for the rest of your career?

    Heh - absolutely not!
    As a question, how would you optimise XML for transferring across the wire? Shorten the tag and attribute names perhaps? Then provide a detailed spec of your tage and attributes and their meanings?

    No. I would run a compression on it. All those repeated tag and attribute names would reduce to very little.
    XML has not got rid of network or data protocols, it's just made it more high level and more accessible to the Average Joe programmer, which has resulted in an explosion of protocols.

    These things *should* be accessible!
  22. XML is a flexible way to structure data. It's not intended to be used as a serialisation layer. Where it is, you either don't care about performance and overhead (which is not bad in itself, if you don't *need to* care), or you're simply doing it wrong. It's that simple.

    Moreover, people have been exchanging properly structured documents, with CRC's and all, in financial applications since the 60's. I've seen it, it's old, it smels like dusty transistors, but gets the job done and gets it done good.
    Yes, plain text format, fixed sizes, control checksums. For bank transfers. It just works. No need for pointy angles and superfluous, repetitive names.

    Also have a look a S-expressions. Please.

    I find the human-readable argument ridiculous. As I said before, your job as a programmer is one of:
    - build a communication protocol and data format;
    - use an existing framework that does that for you.
    I've never had to debug CDR when doing CORBA. That's the ORB programmers' job. And they did it well.
    I've also never had to debug XML-RPC when doing... XML-RPC.
    I've had to debug Hessian, but that's because I've implemented the protocol. And with good programming skills and a few prints into files and a hex editor, I was able to implement a C++ version in a few days work. Granted, the effort to make it into a framework was larger, but completely un-related to the binary layer of Hessian. That just worked. Take at look at that, it's simple. And fast.

    As for editing XML files concurently, I'm sure I'm missing your point there. Definitely.

    And no, the big deal is that XML is human readable when the only requirement is machine readabale, so that's a no-no when it comes to using it as part of a fast protocol.
    Also I'd rather be doing my job, not hacking bytes nor xml, and I am doing my job regardless of whichever I choose, but I tend sleep better when messages do not take 100 bytes to say "2".
  23. XML is a flexible way to structure data. It's not intended to be used as a serialisation layer.

    Agreed. We should use it for messaging in heterogenous distributed systems, not for fine grained RPC.
    Where it is, you either don't care about performance and overhead (which is not bad in itself, if you don't *need to* care), or you're simply doing it wrong. It's that simple.Moreover, people have been exchanging properly structured documents, with CRC's and all, in financial applications since the 60's. I've seen it, it's old, it smels like dusty transistors, but gets the job done and gets it done good.Yes, plain text format, fixed sizes, control checksums. For bank transfers. It just works.

    No it doesn't. It's one of the reasons why such systems are notoriously hard to change. If you invent a proprietary text format for each particular application, you reinvent the wheel over and over. XML comes with query languages (XPath, XQuery), transformation (XSLT), Schema languages (XSD, Relax-NG) and things like security, routing, transactions, etc is being standardised right now. For proprietary formats even the character encoding has to be agreed separately and there is usually no way to formally express what a valid message has to look like. It's an aberration from ancient times.
  24. If you invent a proprietary text format for each particular application,
    What is proprietary in CORBA?
     you reinvent the wheel over and over.
     XML based stack is THE wheel reinvention, but XML wheels are square and made from wood for easy repair by humans... ooops I meant debugging and readability of course
    For proprietary formats even the character encoding has to be agreed separately and there is usually no way to formally express what a valid message has to look like. It's an aberration from ancient times.

    Please stop talking about abstract proprietary formats, which can be very bad of course.
     
    IDL defines message far more precisely than DTD or Schema.
  25. If you invent a proprietary text format for each particular application,
    What is proprietary in CORBA?

    I was referring to Radu-Adrian's hint at ancient text formats:
    Yes, plain text format, fixed sizes, control checksums.

    CORBA is fine if you want to do closely coupled distributed objects.
    &nbsp;you reinvent the wheel over and over.
    &nbsp;XML based stack is THE wheel reinvention, but XML wheels are square and made from wood for easy repair by humans... ooops I meant debugging and readability of course

    What in particular was reinvented with XPath for example?
    For proprietary formats even the character encoding has to be agreed separately and there is usually no way to formally express what a valid message has to look like. It's an aberration from ancient times.
    Please stop talking about abstract proprietary formats, which can be very bad of course.&nbsp;

    I don't stop because that's exactly what Radu-Adrian has promoted in his posting (See quote above).
    IDL defines message far more precisely than DTD or Schema.

    I don't think that's correct. Look at XML Schema's data type support for example. You can even use regular expressions to create new datatypes. You can define number ranges and so on. CORBA IDL didn't support that when I last checked (but that's admittedly a quite a few years back)
  26. Alexander,

    I did NOT advocate use of ancient message formats for whatever reason.
    I said that, beyond all criticism, they are still in place and they still work.
    Do read carefully: I advocate compact, standard, performant formats.
  27. Alexander,I did NOT advocate use of ancient message formats for whatever reason.I said that, beyond all criticism, they are still in place and they still work.

    Well, what you said was this:
    Moreover, people have been exchanging properly structured documents, with CRC's and all, in financial applications since the 60's. I've seen it, it's old, it smels like dusty transistors, but gets the job done and gets it done good.
    Yes, plain text format, fixed sizes, control checksums. For bank transfers. It just works. No need for pointy angles and superfluous, repetitive names.

    What you say is that, you don't need any metadata inside the message, because you can use fixed size columns. And I say that's advocating a cumbersome ancient model that was used in the 60ies because of the memory and bandwidth constraints of that era.
    Do read carefully: I advocate compact, standard, performant formats.

    Which standard do you mean?
  28. Alexander,
    Because I don't take as much pleasure in running around one's tail as you do, read the following carefully:
    [Steve Zara]
    For decades I have had to deal with obscure text formats or platform and system-dependent binary formats.[...]XML is a great way to interchange data and to store data - it's text (so we can read it, and so data can outlive the software), it's international, and it's extensible[...]
    This is what I was reffering to when saying - yes, so what, XML is text, big deal, so are the banking files still in use after so many decades, I've seen those and they're not that "obscure" at all, but contrary, much simpler than a lot of other standard, text-based formats.
    However, I have NEVER said "it is good to do plain text fixed size crc-ed" messaging.
    Which standard do you mean ?

    Do you even read the posts at all ?! I make plenty of references to CORBA and Hessian, and claim the use of XML for any application that strives for performance is stupid.

    I have repeatedly said, thanks to your lacking reading skills, that message processing is very well defined without the use XML or SOAP headers or ws-transfer and horde of friends. Also properly structured text formats have been available way before XML came by (s-expressions (year 1972)), and SOAP is not an evolution, but a regression driven by business considerations.
  29. Which standard do you mean ?
    Do you even read the posts at all ?! I make plenty of references to CORBA and Hessian, and claim the use of XML for any application that strives for performance is stupid.I have repeatedly said, thanks to your lacking reading skills, that message processing is very well defined without the use XML or SOAP headers or ws-transfer and horde of friends. Also properly structured text formats have been available way before XML came by (s-expressions (year 1972)), and SOAP is not an evolution, but a regression driven by business considerations.

    It seems the problem goes deeper than your reading skills. It's more a question of if you can follow your own lines of reasoning. I have brought up some characteristics of the XML webservices technology stack but you never bothered to go down to that technical level. Then I said most Java people bring up CORBA in the context and you said this was an insult. Now you bring up CORBA yourself although it does not have any of the characteristics I was talking about. And Hessian which is not a standard (a word you also used) by any definition.

    And honestly, I don't much use in any further debate if you refuse to talk about the specific technical benefits and drawbacks of the various technologies. I never said that XML was tremendously efficient in terms of bandwidth use and actually nobody says that. But interconnecting heterogeneous systems is not primarily a performance problem. Think about what loose coupling might mean, then you will see that CORBA is not the answer. Think about what formal contracts mean and you will see the s-expressions are not the answer.


    I'm
  30. Alexander,

    You really do have a problem following up on things, let me give you a hand here:

    Your words:
    If that system would receive a serialized Java class, it couldn't just use one particular field of that class. It would need to have access to exactly the same version of the class file as the sender.

    To which I reply:
    And why would you ever think that the alternative is bytecodes in .class format ?!

    To which you reply:
    Because that's what most people from the Java community tend to come up with in these kinds of debates.

    I do follow my line of reasoning, it's you who doesn't, otherwise how can you claim:
    "Then I said most Java people bring up CORBA in the context and you said this was an insult." ??

    The above shows that you're either spending time with the wrong crowd or simply making unfounded allegations. People who do Java and get to make decisions regarding inter-systems communication are not that narrow minded.

    Clearly there's nothing to debate here. You seem to think that CORBA is useful for "small" systems, while loosely coupled ones deserve something better. OK, fine, you may have a point there, but it sure as hell the answer is NOT SOAP.

    Also do you care to elaborate on "Think about what formal contracts mean and you will see the s-expressions are not the answer." ?

    Regards,

    Radu
  31. The above shows that you're either spending time with the wrong crowd or simply making unfounded allegations. People who do Java and get to make decisions regarding inter-systems communication are not that narrow minded.

    Well, that's my experience, and if you search for it in the archives of this site you will find out. But that's probably not the most interesting question here.
    Clearly there's nothing to debate here. You seem to think that CORBA is useful for "small" systems, while loosely coupled ones deserve something better. OK, fine, you may have a point there, but it sure as hell the answer is NOT SOAP.

    My problem with your anti SOAP stance is that all you offer as an argument is that it has too many pointy brackets, or if I leave the polemics aside for a moment, that it is inefficient, because each message carries too much metadata. That doesn't only rule out SOAP but all other XML based data exchange as well. So if you concede that CORBA is not the right technology to create loosely coupled systems, what is the right technology in your opinion? So far you have come up with fixed column size text records and Hessian. I'm just trying to understand, what you actually recommend for use in a distributed heterogeneous environment without central control.

    And just so you don't get me wrong: I'm not arguing that XML is tremendously efficient or that there are no other ways to build distributed systems. I'm arguing that XML scales in a social sense, because it makes very little assumptions about the way a message is handled on either side of a communication channel. And for a format to have that property, it inevitably has to carry a lot of metadata with it at all times. That's a trade off we have to live with I'm afraid.
  32. I agree that XML scales - as you well put it - "in a social sense", especially if you use document-oriented communication between parties. I've seen it in practice, but it feels like something's amiss; I do wish for strongly-typed IDL interfaces.

    Do you still care to explain the "Think about what formal contracts mean and you will see the s-expressions are not the answer." assertion ? I'd be genuinely interested.

    (And for the love of god, do not put words in my mouth. The fixed column text files was a counter example to previous comment. I did not and do not endorse it as a way to save the world and build flexible communication protocols along the way. I do like Hessian very much though.)
  33. Do you still care to explain the "Think about what formal contracts mean and you will see the s-expressions are not the answer." assertion ? I'd be genuinely interested.
    I'd be interested in an explanation too. Before we get into an all-too-familiar territory let me pre-empt by saying I am not challenging your position. Some days ago even Don Box seemed to wonder if in hindsight S-Expressions would've been better (http://pluralsight.com/blogs/dbox/archive/2004/10/03/2591.aspx).
    Search for S-Expressions in that post.
  34. As I understand XML is more than just text file. It must be possible to send XML message without metadata too. Metadata and mapping to transform binary data to SAX events can be cached on client and on server, It needs a version number in message to purge cache on schema change. It is not the rocket science, but I am not sure some SOAP implementation uses this workaround.
  35. What in particular was reinvented with XPath for example?
    Tree Query language: see LDAP querying for example. I would not say that I like LDAP QL, but use it as illustration of reinvention.
    I have nothing against improvements and always advocate learning from the past, but XML zealots too proud of their ‘invention’ to really study past achievements and other approaches.
  36. What in particular was reinvented with XPath for example?
    Tree Query language: see LDAP querying for example. I would not say that I like LDAP QL, but use it as illustration of reinvention.

    How would I use LDAP queries for messaging?
  37. What in particular was reinvented with XPath for example?
    Tree Query language: see LDAP querying for example. I would not say that I like LDAP QL, but use it as illustration of reinvention.
    How would I use LDAP queries for messaging?
    The same way as your bellowed Xpath can be used to query java object graph (JXPath http://jakarta.apache.org/commons/jxpath/ )
    XPath is a Tree Query language (not bad one). But it does not mean it is only one of such kind.
  38. Shouldn't we taking more about .Net vs. J2EE instead of SOAP?
  39. What in particular was reinvented with XPath for example?
    Tree Query language: see LDAP querying for example. I would not say that I like LDAP QL, but use it as illustration of reinvention.
    How would I use LDAP queries for messaging?
    The same way as your bellowed Xpath can be used to query java object graph (JXPath http://jakarta.apache.org/commons/jxpath/ ) XPath is a Tree Query language (not bad one). But it does not mean it is only one of such kind.

    I'm not sure if I get what you mean. As you probably remember, XML started out as a simplified variant of SGML, which is much older than LDAP. XPath is based on the XML infoset (which is the normalized abstract form of the XML document). Even though I don't know the LDAP query language, it is hard to believe that it is completely compatible with the XML infoset, including namespaces, unicode, etc. XML, XPath, XQuery, XSD as a whole, form a pretty coherent technology stack. All those standards refer to each other. I'm not sure, how I could bring LDAP into that picture or why I would want to do that.
  40. I don't think that's correct. Look at XML Schema's data type support for example. You can even use regular expressions to create new datatypes. You can define number ranges and so on. CORBA IDL didn't support that when I last checked (but that's admittedly a quite a few years back)
    It must be better to keep constraints in database than to validate data at protocol level. Nobody needs this stuff in IDL and it doe's not exist for this reason.
  41. I don't think that's correct. Look at XML Schema's data type support for example. You can even use regular expressions to create new datatypes. You can define number ranges and so on. CORBA IDL didn't support that when I last checked (but that's admittedly a quite a few years back)
    It must be better to keep constraints in database than to validate data at protocol level. Nobody needs this stuff in IDL and it doe's not exist for this reason.

    Nobody needs to specify that a particular number has to be between 1 and 5 or that an order number has a length of 10 and starts with a capital E or something like that? I think that's pretty useful. I use it, and therefore I use XML instead of IDL.
  42. Nobody needs to specify that a particular number has to be between 1 and 5 or that an order number has a length of 10 and starts with a capital E or something like that? I think that's pretty useful. I use it, and therefore I use XML instead of IDL.

    It is usefull, but I prefer to define it using DDL.
  43. Nobody needs to specify that a particular number has to be between 1 and 5 or that an order number has a length of 10 and starts with a capital E or something like that? I think that's pretty useful. I use it, and therefore I use XML instead of IDL.
    It is usefull, but I prefer to define it using DDL.

    That would only make sense if your idea of a "web service" is to give your client a JDBC connection URL and tell them to write directly into you database.

    What I want to do is tell the developers in some other organisation what kinds of messages they can send me and what they can expect in return. And therefore I need a language that lets me specify as exactly as possible how those messages have to be structured, what is valid data and what is not.
  44. That would only make sense if your idea of a "web service" is to give your client a JDBC connection URL and tell them to write directly into you database. What I want to do is tell the developers in some other organisation what kinds of messages they can send me and what they can expect in return. And therefore I need a language that lets me specify as exactly as possible how those messages have to be structured, what is valid data and what is not.

    There are nothing wrong to validate data, but I do not think it is a good idea to repeat data definition in interface definition and to validate it two times. It is very usefull if
    you edit XML manualy, editor can help to validate using schema. I think service must be as performant as possible, probably it is a good idea to send XML as binary file, It is possible to implement SAX adapter for any format.
  45. Programming Legends Debate .Net, J2EE[ Go to top ]

    I'm using the most powerful computer on the earth to type this message and this particular computer doesn'teven have an API in the tradtional sense. What am I? :)
  46. Programming Legends Debate .Net, J2EE[ Go to top ]

    I'm using the most powerful computer on the earth to type this message and this particular computer doesn'teven have an API in the tradtional sense. What am I? :)

    A terminal without tradition?
  47. That would only make sense if your idea of a "web service" is to give your client a JDBC connection URL and tell them to write directly into you database. What I want to do is tell the developers in some other organisation what kinds of messages they can send me and what they can expect in return. And therefore I need a language that lets me specify as exactly as possible how those messages have to be structured, what is valid data and what is not.
    There are nothing wrong to validate data, but I do not think it is a good idea to repeat data definition in interface definition and to validate it two times.

    XML Schema's are not only about validation. I need a way to tell the people who build that software that calls my service, what the message should look like. I don't care if they validate befoer sending it, and I might not even validate it on the server side if I know that it is checked later on anyway and I'm still able to produce a meaningful error message. The Schema is there to formally communicate the interface contract. If a certain number range is part of that contract, I need to be able to say so.
  48. XML Schema's are not only about validation. I need a way to tell the people who build that software that calls my service, what the message should look like. I don't care if they validate befoer sending it, and I might not even validate it on the server side if I know that it is checked later on anyway and I'm still able to produce a meaningful error message. The Schema is there to formally communicate the interface contract. If a certain number range is part of that contract, I need to be able to say so.
    Yes, documentation is a good thing. There are tools to generate documention, it can be generated form DB too. PDF or HTML is more readable and printable is not it ?
  49. XML vs DB vs IDL[ Go to top ]

    Yes, but you can't run an automatic validator that reads the generated documentation or PDF and validates your data against it before it enters your system or, even better, before the sender even tries to send it to you.

    A database schema can be pretty precise in defining the data just like XML Schema, and you can code whatever complex logic you like in triggers and by far surpass the capabilities of XML Schema for validation. But you won't define the database schema, then make a dump, send it over to the other party, have them install the same database software that you use, restore the database from the dump, populate it with the data that they want to exchange, then make a dump and send it back, then you restore it.

    Nor you would give them a connection to your database and tell them to populate it in a given sequence. So database schema validation is not the answer when you try to exchage valid data with another system.

    Nor is IDL that good, because IDL is oriented towards defining a programming interface, while XML and Schema is about defining data. Exchanging data is simpler than calling APIs. That is why XML is easy and popular, and IDL and CORBA are obscure. Moreover, business people can (almost) read XML schemas and instance documents and participate closely in defining precise requirements.
  50. XML comes with query languages (XPath, XQuery), transformation (XSLT), Schema languages (XSD, Relax-NG) and things like security, routing, transactions, etc is being standardised right now. For proprietary formats even the character encoding has to be agreed separately and there is usually no way to formally express what a valid message has to look like. It's an aberration from ancient times.

    Yes, there are a lot of cool buzzwords around XML, but plain text files do not need buzzwords because it they are readable by awk,sed,grep,perl, sort, join , ...
    http://howtos.linux.com/guides/abs-guide/textproc.shtml
     I am afraid XML become popular just because it looks like HTML ... .
  51. XML comes with query languages (XPath, XQuery), transformation (XSLT), Schema languages (XSD, Relax-NG) and things like security, routing, transactions, etc is being standardised right now. For proprietary formats even the character encoding has to be agreed separately and there is usually no way to formally express what a valid message has to look like. It's an aberration from ancient times.
    Yes, there are a lot of cool buzzwords around XML, but plain text files do not need buzzwords because it they are readable by awk,sed,grep,perl, sort, join , ... http://howtos.linux.com/guides/abs-guide/textproc.shtml&nbsp;I am afraid XML become popular just because it looks like HTML ... .

    "readable by awk,sed,grep,perl, sort, join" -- there are xml equivalent tools too -- see xmlstarlet(http://xmlstar.sourceforge.net/) -- set of command line utilities (tools) which can be used to transform, query, validate, and edit XML documents and files using simple set of shell commands in similar way it is done for plain text files using UNIX grep, sed, awk,....
  52. I also disagree.What you're talking about goes by the names of notification service, jms, mom, *mq.Most of these little dudes doing message filtering, routing, persistence and guaranteed delivery do not use XML. Why would they ?

    I'm afraid you mix up infrastrucure and content there. Of course you can send XML/SOAP over JMS. The two are orthogonal.
    What the hell is wrong with the world today ? What's this "let's just use XML 'cause XML allows us to put in tons of metadata and if we screw it up we'll just add more metadata on top and with XML we're gonna be soo loosly coupled" nonsense ?Did I fall asleep and miss something ?

    Apparently.
    Where did the idea that metadata is XML and XML is metadata came from ? That SOAP headers are the right and natural way to do it ?!

    It's one way to do it. It's broadly supported by infrastrucures and tools, so why not use it?
    What is the relation between XML and asynchronous processing ? Rules ? Dispatching ?

    The relation is that an XML message contains enough metadata to define a dispatching (or even transformation) rule based on its content and structure. The relation to asynch is that an XML message can easily be stored and later forwarded, something that you can't do as easily with a traditional RPC method call in an ORB.
    And why would you ever think that the alternative is bytecodes in .class format ?!

    Because that's what most people from the Java community tend to come up with in these kinds of debates.
  53. Alexander,

    Please go and re-read my post, it was a reply to someone claiming that XML as metadata is proper for the things that messaging systems do.
    I'm not mixing anything, I'm well aware of where say XML and JMS stand in relation to each other. The original poster apparently does not, and that's what I was trying to say.

    It also looks like you've been sleeping on this one :). In case an explanation is needed, the point was: "since when is XML the answer to problems such as metadata and filtering and whatnot, these things have existed since well before XML was created as a standard; did I wake up in another century and people have forgotten ?".

    As for SOAP headers, of course it's there, the point was - again please read the post I was answering to - that this is not something that we gained as a by-product of XML nor SOAP.

    As for your comments on regarding the storage and dispatching thing, you're mistaken. If you want XML to be your hero, just go ahead, belive what you will. But message persistence, filtering, forwarding, dispatching, encapsulation has existed long before the first MOM to use XML as it's native format.

    As for your last point, I think a lot of people would take that as a personal offense, as do I.
  54. "since when is XML the answer to problems such as metadata and filtering and whatnot, these things have existed since well before XML was created as a standard;

    Alright, so what technologies are you talking about. In another post you speak of proprietary text formats. Is that what you mean here?
    did I wake up in another century and people have forgotten ?"

    Well, I was around in the last century as well, and I haven't forgotten anything.
    .As for SOAP headers, of course it's there, the point was - again please read the post I was answering to - that this is not something that we gained as a by-product of XML nor SOAP.

    SOAP headers are not a by-product of SOAP? I'm afraid re-reading doesn't help me to understand that.
    As for your comments on regarding the storage and dispatching thing, you're mistaken.

    How am I mistaken?
    If you want XML to be your hero, just go ahead, belive what you will. But message persistence, filtering, forwarding, dispatching, encapsulation has existed long before the first MOM to use XML as it's native format.

    Sure, but there was no standardised way to express formal requirements regarding the messages and the processing of the messages beyond a single MOM product and processing environment.
    As for your last point, I think a lot of people would take that as a personal offense, as do I.

    You take it as an offence when I tell you that many Java people I have talked to about this, present RMI and CORBA as an alternative?
  55. This is getting a bit too long.
    I was not saying that proprietary text formats are a technology for doing filtering, how aberrant is that ?
    My points are:
    - XML is not a requirement for serious business message exchange;
    - XML is hardly revolutionary as a way to express formal requirements, as that can be achieved with binary formats and message properties; it's not even revolutionary, but just human readable;
    - I have yet to find reasons for using XML instead of CDR or Hessian, in the layer where CDR and Hessian belong.
    Please note that CORBA is about interoperability and it's a sad mistake to offer RMI as an alternative in the same sentence with IIOP. The "Java people" doing that simply don't know what they're talking about, or just care about java-to-java exchange.
    There's certain assumptions made in RMI that prevent it from being shared among different platforms, or at least that was the case last time I checked.

    As for the "header" point, soap headers are obviously part of soap, duh, but it's ignorance to make it look like without them people would simple have no means to implement message properties.

    that's it... atone me to throes curtail.
  56. To reply to my own post, because this was left out, Juozas Baliuka and Konstantin are right, of course.

    There's perfectly sensible ways of achieving anything and everthing using *better* technologies than XML, except for human-readable-over-the-wire-format, which is of course, useless.

    And regarding the last century, check this out: http://www-formal.stanford.edu/jmc/cbcl.html
    Read the pdf paper, it has some valuable insights apart from the S-expressions versus XML thing.
  57. Programming Legends Debate .Net, J2EE[ Go to top ]

    You know, there's a difference between sending meta data and sending it for each field, each time you refer to the field. That's just plain stupid.It's the natural thing to do when you use XML, but XML is simply not appropriate for this kind of stuff.

    Why is it stupid? What is the point of having metadata that then has to specify the format of all the data, including separators etc? Also, what about sparse data, in which not every row of data has non-null values for every field? Its hugely more efficient in XML, as you need only specify the data present.
    SOAP, from an engineering standpoint, is a complete disaster.

    Well, that's news to developers like me who have been running effective SOAP services for a long time.
  58. Programming Legends Debate .Net, J2EE[ Go to top ]

    I have to disagree with the point about Java and .Net matching up features. Sun has been very cautious with adding features to Java: the extensions in 1.5 were discussed for a long time.
  59. entire transcript?[ Go to top ]

    Does anyone know where a complete transcript of the talk is available?

    Box's comment about "concurrency" as the problem developers are trying solve is interesting. I don't necessarily agree that ORM is a mis-representation/mis-indentification of concurrency management. I see them as two separate problems, which affect each other.

    scaling systems that have to support several hundred concurrent users is difficult, but one can solve the problem without involving ORM at all. based on the apps I've worked on, ORM is there to help me take data from the database and make it easier to use for business logic.

    obviously I can hardcode the data access, but that makes life difficult when the business guys change the requirements. If I had static requirements, I wouldn't bother using ORM. Since business requirements don't remain static, I find using ORM saves some work.

    even if I were to code all the business logic as triggers and stored procedures, internally the database still creates some sort of object graph. whether one calls it a struct, object, entity or database row, the basic problem I think is there's some data which is used by some business logic. If an application is written in an object oriented language, there needs to be a way to get data in and out of the database into the application layer.

    I can use an ORM without having to worry about concurrency issues. But that's my bias perspective.
  60. (.NET + J2EE) vs Open Source[ Go to top ]

    I would certainly be willing to agree that both Java and Microsoft have both gone off in the wrong direction and to some extent are following each other in circles.
    +1
    Although Java is more off track IMO. .Net is a new OS from MS (DOS->Win->.NET), but Java wasn't supposed to be OS, but a glue. Nowadays it tries to be full OS but will inevitably fail as such.

    >> But there are positives and negatives. The positive is they are learning from each other and gaining best practices.

    Really?!

    >>The negative is they are chasing each others' tails to get feature checklists matched up, regardless of value to developers.
    +1
    Although it depends on sort of developers: seasoned developers can deliver long lasting solutions with using available technologies easily and they really do not need much (smart BAs would not harm). But this situation is bad for vendors and greenhorns alike: vendors need to sell something and greenhorns want to become experts quickly, which is much easier by riding 'new' wave when everybody is a greenhorn (that is main driver of SOAP opera IMO).

    Do not forget about ever increasing human population: everybody wants a job, therefore high productivity is bad and should be artificially limited by inventing 'better' languages and 'efficient' protocols which will require new tools and more and more people will be busy rewriting systems all over again, more people will sell and support it... more people do not go hungry..
  61. (.NET + J2EE) vs Open Source[ Go to top ]

    Net is a new OS from MS (DOS->Win->.NET), but Java wasn't supposed to be OS, but a glue.

    .Net is not an OS. Its a combination of a VM and a set of APIs, just like Java. .Net uses a lot of the underlying OS - the Win32 API, for example. If .Net or Java were trying to be operating systems, they would have features such as device drivers, file systems etc.
    therefore high productivity is bad and should be artificially limited by inventing 'better' languages and 'efficient' protocols which will require new tools and more and more people will be busy rewriting systems all over again, more people will sell and support it... more people do not go hungry..

    Vendors can add all the features they like, but developers only use what they find useful. For example SOAP may be slow, but many developers like me like it because its very, very easy to install and use.
  62. (.NET + J2EE) vs Open Source[ Go to top ]

    but developers only use what they find useful.
     For example SOAP may be slow, but many developers like me like it because its very, very easy to install and use.

    LOL! Sorry, but have you ever tried using sometning else than SOAP? http://kgionline.com/articles/protocol_compare/doc/index.jsp

    Even SOAP zealots do not dare to spell SOAP as "Simple Object Access Protocol" anymore, they call it "Service Oriented Access Protocol" :)!
  63. (.NET + J2EE) vs Open Source[ Go to top ]

    LOL! Sorry, but have you ever tried using sometning else than SOAP?
    Yes. I have a habit of posting on matters of which I have experience. SOAP may not be the simplest of protocols in terms of how its implemented, but using a good SOAP implementation (like Apache Axis) is very, very easy. You put a Java source file into a directory on the server. That's it! That's your SOAP service installed.
  64. (.NET + J2EE) vs Open Source[ Go to top ]

    SOAP may not be the simplest of protocols in terms of how its implemented, but using a good SOAP implementation (like Apache Axis) is very, very easy. You put a Java source file into a directory on the server. That's it! That's your SOAP service installed.
    Now try to return complex objects from methods in jws ...
    Ooops, need to define serializer... where?... hmm.. ooops need to tweak config files, damn! it is not _that_ simple.
  65. (.NET + J2EE) vs Open Source[ Go to top ]

    Now try to return complex objects from methods in jws ... Ooops, need to define serializer... where?... hmm.. ooops need to tweak config files, damn! it is not _that_ simple.

    True. But having a simple system that needs tweaking to do something more complex is far preferable to having something proprietary and complex for even the simplest operations.
  66. Why .net and Java are different[ Go to top ]

    Why people see difference between jvm and .net.
    Both are very similar. Apart from language differences (C# and Java) underlying technology is almost identical.
    Even we discuss for days I dont think nothing worthy will come out.

    Instead there should be healthy discussion about why xml should be used at all.

    Only problems xml is really solving is Big-endian and small endian and size of primitives(int long...) and might be providing some human readability.

    For solving small set of problems big set of problem creator is chosen.

    Is there a better way of solving above problems with out XML??? Any suggestions
  67. Why people see difference between jvm and .net. Both are very similar.
    +1
    Even goals are similar: lock developers into platform: Java or .Net
  68. Why .net and Java are different[ Go to top ]

    1Even goals are similar: lock developers into platform: Java or .Net

    Strange. I have always found the benefit of Java to be its platform independence.
  69. Why .net and Java are different[ Go to top ]

    1Even goals are similar: lock developers into platform: Java or .Net
    Strange. I have always found the benefit of Java to be its platform independence.
    What do you mean saying 'platform'?
    If you mean hardware, than Linux API gives much greater hardware independence.
    If you mean 'OS', than I would say that coding against Java API is not different than coding against any other OS because Java has limited portability: JVMs do not exist for everything, J2SE, JME differences etc.

    Binary or Source code compatibility - Java 5 on java 1 jvm anybody?
  70. Strange. I have always found the benefit of Java to be its platform independence.

    What do you mean saying 'platform'?If you mean hardware, than Linux API gives much greater hardware independence. If you mean 'OS', than I would say that coding against Java API is not different than coding against any other OS because Java has limited portability: JVMs do not exist for everything, J2SE, JME differences etc. Binary or Source code compatibility - Java 5 on java 1 jvm anybody?

    Others seem to have better luck than you, Konstantin. For example, the code that was written for JDK 1.02 is still running today fine on Java 5. Similarly, Java code written for one version of an OS running on one hardware platform is running fine (without recompilation, relinking, or any change whatsoever) on every OS on every hardware platform. While you incessantly sneer at it, it goes on running and running well.

    As for "the Linux API," there is no such thing, although there is more portability for Linux than any OS project before it.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  71. As for "the Linux API," there is no such thing, although there is more portability for Linux than any OS project before it.Peace,Cameron Purdy

    Yes, there is set of APIs and little of Linux specific here, mostly GNU-Unix
    Similarly, Java code written for one version of an OS running on one hardware platform is running fine (without recompilation, relinking, or any change whatsoever) on every OS on every hardware platform.
    I do not think "without recompilation, relinking, or any change whatsoever" is such a good thing. Take GNU-Linux applications: they run fine after recompillation and that gives certain advantages, consider Gentoo distro as an example: emerge can take sources and then compile and optimize them for _the_ particular machine: http://www.gentoo.org/main/en/performance.xml
  72. I do not think "without recompilation, relinking, or any change whatsoever" is such a good thing. Take GNU-Linux applications: they run fine after recompillation and that gives certain advantages, consider Gentoo distro as an example: emerge can take sources and then compile and optimize them for _the_ particular machine:

    Um, that is exactly why there are various VM's built for the particular OS's so that OS specific optimzations can be abstracted to the VM itself, not the Java code running on the VM. You seem to be confusing Java bytecode with the VM that *runs* that bytecode.
  73. I do not think "without recompilation, relinking, or any change whatsoever" is such a good thing. Take GNU-Linux applications: they run fine after recompillation and that gives certain advantages, consider Gentoo distro as an example: emerge can take sources and then compile and optimize them for _the_ particular machine:
    Um, that is exactly why there are various VM's built for the particular OS's so that OS specific optimzations can be abstracted to the VM itself, not the Java code running on the VM. You seem to be confusing Java bytecode with the VM that *runs* that bytecode.
    Nope, I am making the point: JVM seems unnecessary because GNU-Linux is a VM that abstracts code from underlying hardware and capable of optimizing runtime code for the platform…..
    Iron -GNULinux VM-JavaVM- J2EE container virtualization –Web Container virtualization: isn’t that too much of virtualization?

    .NET seems more natural:
    Iron - [Win] - .NET and as I suspect that .NET is next generation OS from MS, future architecture seems even better:
    Iron - .NET

    (PS: I am silent regarding quality of implementation from MS, but idea seems healthy)
  74. Nope, I am making the point: JVM seems unnecessary because GNU-Linux is a VM that abstracts code from underlying hardware and capable of optimizing runtime code for the platform…..Iron -GNULinux VM-JavaVM- J2EE container virtualization –Web Container virtualization: isn’t that too much of virtualization?.NET seems more natural:Iron - [Win] - .NET and as I suspect that .NET is next generation OS from MS, future architecture seems even better:Iron - .NET (PS: I am silent regarding quality of implementation from MS, but idea seems healthy)

    .NET also runs in a VM.

    Iron - WIN - CLR/VM - .NET

    A VM is more then simply abstracting the hardware. It also provides a run-time sandbox that is designed to protect the OS and the iron by limiting the way developers and users can interact with the underlying OS. If the VM dies it is not the same as the OS dieing and obviously doesn't have the same potentially catostrophic effects on the system.

    One ancedote might be the difference between getting anti-lock brakes for your car and not. Sure, both will stop you and both should be reliable in normal situations. However, in a crisis situation, which would you rather have on your car?

    The VM provides an extra layer of protection and while certainly not perfect, it goes along way in promoting stability, security, and in the case of Java, portability.

    These features, and I'm sure others, are exactly why Microsoft adopted the managed VM/CLR approach themselves. Although, they do allow for, and make easy, the ability to side-step the managed environment simply because they have to in order to get 3rd party applications to adopt their new VM based approach to application development.

    It is understandable because it is a much easier transition for those countless numbers of big applications who still use C++ and Win32/DirectX/COM/etc. to write commercial applications. However, if it is easy to do, and you can do it, and it isn't frowned upon, then people still make direct system calls instead of staying within the bounds of what the VM provides as access to the physical OS and system. So the effectiveness of Microsoft's adoption of a CLR in terms of providing better stability and security, may not pan out unless they can get majority adoption.

    Also, a J2EE or Web container are not virtualizations in the same sense as a VM. J2EE or Web containers do not create multiple VMs to execute in. They typically run in a single VM. So it isn't another full virtualization layer in the sense that you are trying to make it with your example by comparing it to the virtualization that a VM does.
  75. .NET also runs in a VM. Iron - WIN - CLR/VM - .NET
    For a while, then they will eliminate Win.
    Also, a J2EE or Web container are not virtualizations in the same sense as a VM. J2EE or Web containers do not create multiple VMs to execute in.
    They do it in a sense of VM: ear/war deploys run inside of sandboxes, sometimes very restrictive when JVM controls whenever the code can execute certain instructions or code.

    Basically j2ee containers try to provide separation of processes pretty much like OS separates user processes and prevents them from crushing core OS and affecting each other.

    IMO conceptually OS == VM and one above another is a temporary state, VM will be eliminated or become full OS.

    Java is not good candidate for a full OS therefore it should not even try, it should go back on track and excel as a glue framework for writing business applications, not databases, not mail servers.
  76. Why .net and Java are different[ Go to top ]

    IMO conceptually OS == VM

    Not at all. The VM is an emulation of a processor, and that is all. An operating system is what runs on the processor. They are fundamentally different things.
    VM will be eliminated or become full OS.

    By definition, this is impossible. If you have an emulator, you have to have some software to run it! If not, you have to have the code run by hardware, but then its not a VM - its a real machine!
    Java is not good candidate for a full OS therefore it should not even try, it should go back on track and excel as a glue framework for writing business applications, not databases, not mail servers.

    Why on Earth not? As Java can give high performance, why not write critical applications using this safe and portable language?
  77. Has been done[ Go to top ]

    By definition, this is impossible. If you have an emulator, you have to have some software to run it! If not, you have to have the code run by hardware, but then its not a VM - its a real machine!

    And there are quite a few implementations of java machines running on hardware. Check out http://www.ibutton.com/TINI/index.html and also http://lejos.sourceforge.net for the lego fans
  78. Has been done[ Go to top ]

    By definition, this is impossible. If you have an emulator, you have to have some software to run it! If not, you have to have the code run by hardware, but then its not a VM - its a real machine!
    And there are quite a few implementations of java machines running on hardware. Check out http://www.ibutton.com/TINI/index.html and also http://lejos.sourceforge.net for the lego fans

    Yes, but then its not 'Virtual'.. its a JRM - Java Real Machine!
  79. Why .net and Java are different[ Go to top ]

    Java is not good candidate for a full OS therefore it should not even try, it should go back on track and excel as a glue framework for writing business applications, not databases, not mail servers.
    Why on Earth not? As Java can give high performance, why not write critical applications using this safe and portable language?
    Simply because one size does not fit all. I am well aware of plenty of other languages for JVM, but still *nix supports more and more complete. There are things that JVM simply does not support ( direct memory manipulation for example ).

    >>As Java can give high performance.
    It still slower than native *nix applications. Please do not point me on various microbenchmarks, I use Java all the time and it is slower overall ( although acceptable ).
  80. There are things that JVM simply does not support ( direct memory manipulation for example )

    I would say that an amazing feature of Java (and several other effective high level languages / platforms) is that you don't need direct memory access, and it protects you from such a barbaric approach to software development .. ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  81. Why .net and Java are different[ Go to top ]

    Simply because one size does not fit all. I am well aware of plenty of other languages for JVM, but still *nix supports more and more complete. There are things that JVM simply does not support ( direct memory manipulation for example ).>>As Java can give high performance. It still slower than native *nix applications. Please do not point me on various microbenchmarks, I use Java all the time and it is slower overall ( although acceptable ).

    Java is not slower than Perl, TCL, Python, Ruby or many other languages that are used for native unix applications. I have always thought that the 'one size does not fit all' principle is simply bad software engineering practice and naive. The best approach is to find a language that is general purpose and develop in that as much as possible. Having something that is a bit slower is nothing compared to the organisational nightmare of trying to develop, test and deploy an application with different parts in different languages. Using just one language allows a high level of developer mobility and code re-use.
  82. Why .net and Java are different[ Go to top ]

    Having something that is a bit slower is nothing compared to the organisational nightmare of trying to develop, test and deploy an application with different parts in different languages. Using just one language allows a high level of developer mobility and code re-use.
    I easily trade slowness for convenience, but convenience is a very personal thing (and slowness could become in-convenience).
    We do not want only one sedan car, one TV model, one jet model, hell we do not want only one type of hammer!

    Why such a pipe dream about a language that fits all?!

    Get real: we need diversity; we cannot live without diversity. Any attempt to come up with THE thing is doomed from the beginning.

    PS: My posts may sound like I am against Java. Not at all, improvements start from admitting shortcomings therefore I just advocate pragmatic approach.
  83. .NET also runs in a VM. Iron - WIN - CLR/VM - .NET
    For a while, then they will eliminate Win.
    If that's the case, then why did they go through the trouble of creating their own VM in the first place if their intention was to ultimately remove the VM and have .NET code interact directly with the OS? Doesn't make sense to do that.
    They do it in a sense of VM: ear/war deploys run inside of sandboxes, sometimes very restrictive when JVM controls whenever the code can execute certain instructions or code. Basically j2ee containers try to provide separation of processes pretty much like OS separates user processes and prevents them from crushing core OS and affecting each other.

    While what you say is true in a sense, I still think the comparison to a VM is a bit of an over-simplification. Using your logic, I could say the same thing about SQL Server. For example, having database connection limits prevents users from crushing the OS. This doesn't make SQL Server a VM though.
    IMO conceptually OS == VM and one above another is a temporary state, VM will be eliminated or become full OS.

    I disagree. I think it would be unwise for Microsoft to eliminate their CLR.

    I think the biggest point you are missing is that Microsoft wants that VM because it makes it alot easier for them to refactor the underlying OS without worrying as much about how all the different vendors are using their system/core APIs. This abstract is a big benefit for them in terms of lifecycle managment of their OS and the software that runs on top of it. You can be sure that the CLR will never go away or at least it will be around for a very long time.
  84. Why .net and Java are different[ Go to top ]

    1Even goals are similar: lock developers into platform: Java or .Net
    Strange. I have always found the benefit of Java to be its platform independence.
    What do you mean saying 'platform'?If you mean hardware, than Linux API gives much greater hardware independence. If you mean 'OS', than I would say that coding against Java API is not different than coding against any other OS because Java has limited portability: JVMs do not exist for everything, J2SE, JME differences etc. Binary or Source code compatibility - Java 5 on java 1 jvm anybody?

    This is just nonsense. Java is not an OS. JVMs are available for almost every system, and to talk about running Java 5 on Java 1 VM is a meaningless point - you can't run linux programs on a machine with an older version of libc... so what?

    There are differences between J2SE and J2ME, but there are also differences between full and embedded Linux - so what?
  85. Platform independence[ Go to top ]

    Sure, Java is harware-platform-independent and OS-independent. But it is not language-independent, application-server-platform-independent, and skillset-independent. Nor is .NET. They are two competing (pretty successfully) new types of platforms. What's wrong with that?
    The closer they are to each other, the better off we are when we have to switch between the two, which happens to some of us, like it or not, from time to time.
  86. Programming Legends Debate .Net, J2EE[ Go to top ]

    "I would certainly be willing to agree that both Java and Microsoft have both gone off in the wrong direction and to some extent are following each other in circles. But there are positives and negatives. The positive is they are learning from each other and gaining best practices. The negative is they are chasing each others' tails to get feature checklists matched up, regardless of value to developers."

    Couldn't agree more. Java was such a cleaner language before C#, but now just for the sake of competition it started deviating from it's original goal; simpler and cleaner. BTW the balme goes to Java developer community too, who for no valid reason want to have all the fancy features existed in any language as part of Java.
  87. Oh good grief. The election is about Vietnam and now O/R to.

    O/R is not that complicated it's just that the whole data model represents a graph, and that leaves an infinite number of solutions to the same problem. It’s all about the relationships for each node. This problem is not solvable in all time.

    As a result many O/R solutions exist. I have my own that only I use. Sure we will soon have sophisticated GUIs that generate code from diagrams, but the code generated could be anything. The conclusion is that MDA will eventually provide a general standard for a graphical representation of a data model while the resulting code could use any number of different O/Rs. For example I create an Entity/Table/Scheme/Object in a MDA tool and code could be generated into Hibernate, the ORM I created, or any number of others.

    It's just data. Argh.

    It's the whole MVC thing over again.

    Presentation != Data
    Business Logic != Data
    Data == Information

    It's the programmers job to create the relationships between and for data. How you save the data is not that hard to figure out. Use LDAP, DBMS, OODBMS, XML, FS, or other for the specific processing needs.

    Presentation != MVC War
    Business Logic != Enterprise War
    Data != O/R War

    Peace is only obtained in victory, but these wars are meant to be won by each individual. So it is the Anti-Vietnam where victory is not mandated, but won by people’s hearts and minds. The Vietnam War has been over for a long time.

    The industry and government will not and should not mandate how to represent data.

    ITS OVER ALREADY. LOVE THEY NEIGHBOR.
  88. Interesting that Microsoft recognizes O/R mapping as one of the biggest areas for developer productivity improvements.

    When JDO is coupled with a modern web framework like Tapestry or Wicket it is astonishing how productive you can be, without tool/vendor lock-in. If we want to seriously compete with M$ in productivity, best practices are going to have to move off struts/EJB and refocus on Tapestry/JDO. Otherwise to lose to M$.

    -geoff
  89. Interesting that Microsoft recognizes O/R mapping as one of the biggest areas for developer productivity improvements. When JDO is coupled with a modern web framework like Tapestry or Wicket it is astonishing how productive you can be, without tool/vendor lock-in. If we want to seriously compete with M$ in productivity, best practices are going to have to move off struts/EJB and refocus on Tapestry/JDO. Otherwise to lose to M$.-geoff
    :) Folks, we could be even more productive with normal component oriented clients like Swing Java Web Start applications. Not to mention saved bandwidth and less demand on server power.
    In 96 creating nice responsive UI was no-brainer with Delphi or VB, after full cycle it is time to regain sanity.

    I wish Sun reconsider Applets and make them startable via JavaWebStart, that would be killer approach!
  90. Interesting that Microsoft recognizes O/R mapping as one of the biggest areas for developer productivity improvements. When JDO is coupled with a modern web framework like Tapestry or Wicket it is astonishing how productive you can be, without tool/vendor lock-in. If we want to seriously compete with M$ in productivity, best practices are going to have to move off struts/EJB and refocus on Tapestry/JDO. Otherwise to lose to M$.-geoff

    You can use struts/EJB, Tapestry/JDO, or other with MDA. Just plug in the specific Presentation, ORM, or other component with XMI to generate the code. Microsoft will not take that market. M$ gave all its money back to its stock holder because they know software is now a commodity and their lawyers are the only thing keeping their profits up. They will soon end up making the same low profits of other multinational corps like Coke when MDA takes hold over the next few years. They could have made a proprietary MDA tool, but it wouldn't be excepted despite the productivity improvements. They know they have lost. Winners use profits for research. Lossers throw investment away. MDA will break down the walls between components, and increase competition to a complete worldwide frenzy by 2007. Don't waste your time choosing components just wrap them with XMI. That way you can always change to the best component in the future.
  91. Unfortunately, it's pretty easy to respect Microsoft when you see the mistakes that serverside java has made from an architectural standpoint. EJB has made easy tasks way too hard, for years.

    The irony will hit home especialy hard when microsoft ORM technology (most likely copied from JDO and Hibernate) eats our lunch after our own “side” has spent years trying to bury these simple developer friendly technologies.

    Will we still be telling developers to build a website with EJB's when Microsoft introduces a kick-ass ORM product? Will we still have a collective head in the sand? How much research and community feedback does it take before we wake up?

    Vendors need to take a view longer than 12 months and realize that if we continue to sell unwarranted complexity to the wrong tasks we’re going to keep losing the benchmarks to microsoft, were going to keep losing the developers who are sick and tired of being sold a container, and we're eventually going to lose the war.

    All of the solutions are already out there in Java, Open Source, which makes one of the most compelling arguments against m$. Obviously vendors are not going to give voice to these solutions, but if vendors fight our effective grass roots technologies they only win a short-term battle, and lose the war to Microsoft.

    If we are going to prevail against M$, the Java community needs to get honestly introspective and stop bs’ing ourselves about “rigged” benchmarks every time enterprise java loses to Microsoft in a website benchmark. As a developer, you should be downright pissed each time that you hear about an EJB petstore losing a benchmark.

    When we complain about this or that setting not being right in the benchmark it's like complaining that the chains on our leg irons were the wrong length. We're not seeing the elephant in the room here, and if we don't snap out of it fast, we are going to be very, very sorry.

    -geoff
  92. Microsoft is not dumb ... are we?[ Go to top ]

    What is with all this doom and gloom? Exactly when did the Java world collectively declare war against Microsoft? As a Java developer, I certainly don't look at it in that fashion at all and I don't understand why people spending so much time fretting over winning/losing wars.

    Look at all the things that have come into the Java space in the last few years. For example, tons of innovative solutions in the Open Source space. Many of which are being either copying or embraced by commercial vendors.

    Java itself has been embraced by the open source community and I certainly don't see an end to that even if Microsoft surplants alot of Java enterprise apps. So what exactly are you worried about?

    Everything is cyclical. I'll remind you of the days when Win32 programming with VB, C++, etc. was going to rule the world, and lo and behold 10 years later, it's all being replaced.

    So take a few deep breaths and calm down. It will all be ok.
  93. XML-over-http is the way[ Go to top ]

    This is like the Nth time I'll make the same point, but since there was so much SOAP chatter on this thread I couldn't resist. Here goes:

    SOAP is to XML what EJB is to Java. A heavy handed, over applied behemoth. SOAP is usurping the "web service" definition. SOAP is supposed to make systems interoperable, but in *every* deployment, or contemplated deployment I have seen, where interoperability was crucial, SOAP had the effect of reducing interoperability.

    I'm right now seeing an organization (won't say which) on the verge of making a fateful commitment to SOAP, even though its own internal experiments showed that SOAP actually reduced the interoperability in contrast to XML-over-http.

    A blind reliance on tools (Axis and .Net) combined with relentless "web service" marketing spin has the entire organization hypnotized.

    In contrast, a simple, well-crafted XML schema combined with HTTP is the paragon of simplicity and interoperability. A custom XML schema can produce document instances with very high signal-to-noise ratios, but also excellent human readability.

    SOAP is a red herring. XML schema + binding tools is the path of the righteous.


    -geoff
  94. Microsoft is not dumb ... are we?[ Go to top ]

    The irony will hit home especialy hard when microsoft ORM technology (most likely copied from JDO and Hibernate) eats our lunch after our own “side” has spent years trying to bury these simple developer friendly technologies

    Who has been trying to bury ORM? JDO is an official Java standard - that's the exact opposite of trying to bury ORM.

    As for Microsoft, they can produce what they like in terms of software tools, but until they convince me and others that Windows should be the only operating system in my server room, it will have no effect on what I do, and they are certainly having none of my lunch.
  95. Hey where's Rolf ?[ Go to top ]

    I do hope he's OK !
  96. Hey where's Rolf ?[ Go to top ]

    He's over posting on Javalobby ..