Ted Neward addresses "Web + Services"

Discussions

News: Ted Neward addresses "Web + Services"

  1. Ted Neward addresses "Web + Services" (73 messages)

    Ted Neward has written a blog entry titled "Web + Services" summarizing web services and the "massive amounts of confusion that seem to be surrounding the whole subject," in an attempt to clarify the issues that the web services community is trying to address, as well as why they're facing those issues.
    The gist of the idea is simple: that in the term "Web services", there are two basic concepts we keep mixing up and confusing. "Web", meaning interoperability across languages, tools and platforms, and "services", meaning a design philosophy seeking to correct for the flaws we've discovered with distributed objects and components. These two ideas, while definitely complementary, stand alone, and a quick examination of each reveals this.
    As a part of his summary, he offers the following:
    ...if there is distinction between them, why bring them together into the same space? And the short answer is, "Because individually, each are interesting; collectively, they represent a powerful means for designing future systems." By combining interoperability with services, we create "things" that can effectively stand alone for the forseeable future.
    This view of web services can clarify the reasoning behind the growing number of specifications and APIs that seem to be surrounding web services, by offering a classification of a given specification into something that affects interoperability, or the service aspect.

    His closing question, with context restored, is:
    By combining interoperability with services, we create "things" that can effectively stand alone for the foreseeable future.

    And in the end, isn't that what we're supposed to be doing?
    What do you think? Is he writing to the web services community, or to a broader group of developers? If he's writing to a larger group, is his summary valid? Should we all be thinking of development in terms of "things that can effectively stand alone for the foreseeable future?" What does that mean to you?

    Threaded Messages (73)

  2. Not sure I agree[ Go to top ]

    I don't agree that there's some inherent flaw in distributed objects or that loosely coupled services is inherently better. Just because people mis-use distributed objects does not make it inherently bad. It does indicate the technique is hard to learn and use. If the argument is that web+services is easier to learn and therefore better, that may be true of some cases. Thrashing distributed objects because of bad programmers doesn't help solve complex problems. It just creates more confusion about when webservices should be use and when distributed objects should be used.

    I really wish this webservices hype would go away and die already. webservices are useful, but it's not a hammer for all problems.

    peter
  3. Speaking about "future" again[ Go to top ]

    I start having a problem when people start talking about the technologies that will start working, or that will help build us a systems in the future.

    First - web services as we know them today are too over engineered to be of any value "in the future".

    Second - if we want to be futuristic, than I think that web services are already too much of an archaic technology to be a future "winner".

    Third - Lets first specify what are the web services exactly, which problem they are solving better than any other technology. Please do not tell me that interoperability is such a bad problem. There are many, many ways how to solve the cross language interoperability.
  4. Please do not tell me that interoperability is such a bad problem. There are many, many ways how to solve the cross language interoperability.

    Like what?
  5. Please do not tell me that interoperability is such a bad problem. There are many, many ways how to solve the cross language interoperability.
    Like what?

    Read the article you are commenting on:
    ...interoperability is easy if we use text-based protocols, since everybody knows how to read and write text; hence, HTTP and SMTP and POP3 are highly-interoperable protocols...Interoperability isn't necessarily a hard thing to achieve, but it requires an attention to low-level detail that most developers want to avoid.

    I think the point is that you or I could come up with an interoperable protocol with our hands tied behind our back. For example, passing comma-separated files between systems. The greater point would be that we should prefer XML Web Services for our protocol because it has been accepted by the the software development community at large. So even though other methods exist, CORBA et al, it probably doesn't make sense to use them.
    ________________
    George Coller
    Consultant
  6. Speaking about "future" again[ Go to top ]

    Second - if we want to be futuristic, than I think that web services are already too much of an archaic technology to be a future "winner".

    +1
  7. Speaking about "future" again[ Go to top ]

    Second - if we want to be futuristic, than I think that web services are already too much of an archaic technology to be a future "winner".
    +1

    +1

    In fact, the WebServices protocol and standards stack is now so complex that CORBA appears as a straigthforward standard (and its not!)

    Don't expect different WebServices servers and clients to interoperate easily in the future...
  8. Not sure I agree[ Go to top ]

    Just because people mis-use distributed objects does not make it inherently bad...Thrashing distributed objects because of bad programmers doesn't help solve complex problems.

    I've seen this line of argument a lot on tech-related threads, even coming from myself, and the underlying meaning that technology x isn't bad just because other developers can't figure it out doesn't seem to wash. First, it is more of a self-serving statement which tends to imply, "I would never mis-use technology x, unlike all the other boobs in my field". Second, I believe it is exactly because even talented and experienced people got into trouble on distributed object projects that the idea of web-services gained ground. In many cases it is simply easier to use stateless RPC-style method calls using xml to glue together parts of a system than other methods.

    We were all "bad" developers at some point and are continuously becoming newbies every time a new technology comes down the pipe. I'll take the easier, less optimal, solution over the more complex solution almost every time since it isn't the highly skilled that tend to maintain and enhance these systems over time.
    ________________
    George Coller
    Consultant
  9. Not sure I agree[ Go to top ]

    Second, I believe it is exactly because even talented and experienced people got into trouble on distributed object projects that the idea of web-services gained ground. In many cases it is simply easier to use stateless RPC-style method calls using xml to glue together parts of a system than other methods.

    I think the reason they have gained ground has more to do with the fact that it made it easier to expose your system to external applications. Once the web became so popular, people started to come with ways to do RPC over the web without requiring the clients to use a complicated RPC protocol. SOAP and XML-RPC were a result of that. Once the protocol was formalized, web services became more of a convention of how you actually interact with the remote system beyond just the protocol.

    Now that so many people know how to use this hammer, they are looking for more nails.
  10. Not sure I agree[ Go to top ]

    I think the reason they have gained ground has more to do with the fact that it made it easier to expose your system to external applications. Once the web became so popular, people started to come with ways to do RPC over the web without requiring the clients to use a complicated RPC protocol. SOAP and XML-RPC were a result of that. Once the protocol was formalized, web services became more of a convention of how you actually interact with the remote system beyond just the protocol.Now that so many people know how to use this hammer, they are looking for more nails.

    Ok, I'll buy that.
  11. Not sure I agree[ Go to top ]

    Just because people mis-use distributed objects does not make it inherently bad...Thrashing distributed objects because of bad programmers doesn't help solve complex problems.
    I've seen this line of argument a lot on tech-related threads, even coming from myself, and the underlying meaning that technology x isn't bad just because other developers can't figure it out doesn't seem to wash. First, it is more of a self-serving statement which tends to imply, "I would never mis-use technology x, unlike all the other boobs in my field". Second, I believe it is exactly because even talented and experienced people got into trouble on distributed object projects that the idea of web-services gained ground. In many cases it is simply easier to use stateless RPC-style method calls using xml to glue together parts of a system than other methods. We were all "bad" developers at some point and are continuously becoming newbies every time a new technology comes down the pipe. I'll take the easier, less optimal, solution over the more complex solution almost every time since it isn't the highly skilled that tend to maintain and enhance these systems over time.________________
    George CollerConsultant

    I didn't mean to imply I don't make mistakes using distributed objects, because I sure have. I see value in both distributed objects and webservices. I can think of several real-time examples where distributed objects works better than webservices. I think it's pretty safe to say everyone makes mistakes, so whether a programmer makes mistakes or not does not validate/invalidate a specific technology.

    the issues I find annoying with webservices is the current trend of forcing webservices for processes that really should maintain some state. If stateless remote calls are fine, then use it. On the otherhand, if I need to make 4 calls to 4 different systems and I need the ability to roll-back the transaction in a controlled manner, webservices is a poor fit. That's my bias opinion.

    Of course, one can decide to handle this type of problem using reconciliation, instead of real-time transactions. But using reconciliation to sync up 4 different systems and resolve conflicts isn't necessarily easier. It's just a different problem. What's worse is there are federal laws regarding when money can/should be transfered. Not every problem fits webservices, but the WSI sure is forcing webservices on the world.

    peter
  12. Webservices - statefull[ Go to top ]

    Yeah, I agree. I think once you start moving beyond stateless RPC-style calls, web services become closer or surpass the complexity of other common methods.
  13. RE: Not sure I agree[ Go to top ]

    I don't agree that there's some inherent flaw in distributed objects

    Here's the flaw: Distribution is optimal when performed with coarse granularity. Fowler et al explain this. However, in designing OO models, this granularity won't be obtained as a proper OO design won't contain such bulk objects with low cohesion & high coupling. For optimal distribution with minimal communication one needs a transfer vector that is coarse grained. Whether this involves loosely coupled services, XML or whatever, it won't show up in a purist RUP-style object model (an older legacy methodology called Shlaer-Mellor did actually design these).
  14. RE: Not sure I agree[ Go to top ]

    I don't agree that there's some inherent flaw in distributed objects
    Here's the flaw: Distribution is optimal when performed with coarse granularity. Fowler et al explain this. However, in designing OO models, this granularity won't be obtained as a proper OO design won't contain such bulk objects with low cohesion & high coupling. For optimal distribution with minimal communication one needs a transfer vector that is coarse grained. Whether this involves loosely coupled services, XML or whatever, it won't show up in a purist RUP-style object model (an older legacy methodology called Shlaer-Mellor did actually design these).

    I'm a little curious as to how many people actually think of "distributed objects" as taking a typical OO design for an application and just distributing it across a network. I don't think I have ever encountered this idea in practice. I could see that thought occurring with respect to Entity beans, but the common practice has been to access those locally and access them through a session bean, I don't recall many/any designed that just spread entity beans around the network, either.

    Most(?) people doing distributed object systems 10+ years ago would have told you that you wanted medium- or coarse-grained interfaces for high-volume applications. The appeal of distributed objects wasn't that you could just take your OO design and dump it onto the network, it was that you could create distributed designs that had inheritance, polymorphism and encapsulation - things that were more difficult to do with straight RPC systems.
  15. RE: Not sure I agree[ Go to top ]

    "well-designed distributed objects are just a contradiction in terms".

    This is like the other, currently popular theory that OODBMSs are inherently flawed. Most business applications will definitely benefit much more from a relational approach than an OO one in the DB. But not all software is a business application. Try network surveillance and management with a relational approach and then tell me.

    Business applications written in COBOL have been working for years on reticular DBs, that are much more closely related to an OO design than to SQL. RDBMSs are now preferred over hyerarchical DBs, and O/R mappings over OODBMSs, sure, but reticular and OO DBs have proved their usefulness in some areas.
    I don't agree that there's some inherent flaw in distributed objects
    Here's the flaw: Distribution is optimal when performed with coarse granularity.
    I'm a little curious as to how many people actually think of "distributed objects" as taking a typical OO design for an application and just distributing it across a network. I don't think I have ever encountered this idea in practice.

    But I have, in fact. And performance was awful. A service approach was definitely needed in that case. But again, that was a business application using technology borrowed from telco-oriented concepts (CORBA). The fact that 80%, or more, of business application requirements are better addressed by choosing a stateless approach does not mean that stateless, service-oriented interactions are always the best solution. Which is what was stated in the article.
    The appeal of distributed objects wasn't that you could just take your OO design and dump it onto the network, it was that you could create distributed designs that had inheritance, polymorphism and encapsulation - things that were more difficult to do with straight RPC systems.

    +1

    Try that with SOAP...
  16. I'm a little curious as to how many people actually think of "distributed objects" as taking a typical OO design for an application and just distributing it across a network.

    I find that it is a surprisingly popular opinion for people who have not had to build a distributed system ;-)

    It is very rare to find an example of such an architecture that will provide any scalability or performance benefits whatsoever. As I recently responded on a different discussion:
    IMHO, if the approach to distribution involves a concept of "running objects in a distributed way", it is already breaking the first rule of distributed objects, i.e. "don't".

    Scalable, reliable distributed systems require designs in which objects run where they run and operate on data that is located in the same place. The coupling of these distributed systems is where the magic occurs, and is typically the reflection of a good architecture, not one particular technology or another.

    To the extent that [..] (pick your favorite form of RMI) support the deterministic behavior of that coupling, they can be a valuable part of building a distributed system. However, taking a system and pushing parts of it in a distributed manner out over the same is not "making a distributed system", it is rather just sowing the seeds of a systems nightmare.

    Unfortunately, I don't think that most of the people that talk about distributed systems have ever actually built one, or have ever built one that fits those characteristics (scalable, reliable). While things like "discovery" and "remoting" are possibly "cool", they have absolutely nothing to do with the important part of distributed systems.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  17. from experience[ Go to top ]

    I liked cameron's response, but I thought I'd add my 2 bits. I've primarily worked on two types of distributed systems:

    1. distributed data
    2. distributed processing

    In the first case, the typical scenario I've dealt with is multiple copies of the same data in multiple sessions. When the data is changed by any session, the changes are propogated to the other copies. This kind of scenario happens in real-time or near real-time applications. Though the term real-time is kind of loaded and varies depending on who you talk to. Back when i worked on wireless stuff, we had to provide a way of updating calendar, schedule and address data with minimal latency. Minimal in this case varies, since everyone knows how reliable cell coverage is. For example, say my wireless service provides monitoring of my travel plans. If a flight is delayed or cancelled, I want a timely message telling me "flight blah has been delayed for x reason." In these cases, timely is key. If I get the message after you arrive at the airport, it doesn't do me much good. Since cell coverage is spotty at best, the message has to small (under 1k) and the message has to be reliable.

    The second type is where a process is distributed across several systems. One example of this is google. When a search goes out, it is sent to multiple clusters. In this case, there's multiple copies of "read-only" data. This approach is also applied to things like performing distributed queries where the data is partitioned across multiple systems. The second case fits well into Cameron's response about working with local data. The real challenge with building these types of systems is figuring how to break down a task to separate atomic processes. This type of process is similar to SPMD (Single Process Multiple Data).

    What I've seen first hand is someone new to distributed systems believes that cache data is bad; therefore the individual decides they want to use RPC as a mechanism to synchronized a large set of data across multiple systems by iterating over the data. In practice and theory, using distributed data in this fashion is horrible. Blindly taking an OO application and distributing it has a high chance of failure. In my bias opinion, this is one of the reasons for stateful servers. If I have 20 sessions to update, that process has to maintain some state. Doing this from the database in many cases is a bad idea and slows down the DB.
    Stateful server need not be an EJB container. Without maintaining state on the server, it would be rather difficult to know which sessions were updated and what to do in the even to failure. Often, when the data is distributed, people struggle with keeping the data in sync. For me, bottom line is to take time to understand the problem and distribute when it makes sense.

    end of my 2 bits.

    peter
  18. Web services seem more useful for giving external customers some limited form of programmatic access to your system without having to invent your own specific protocol.

    I don't see them as a magic bullet for solving the problems encountered with distributed systems. The idea of reducing dependancies between objects has been around a while, and so has the recognition that a network call is several orders of magnitude more expensive than a local function call. If you couldn't solve these problems with CORBA or RMI, I don't really see how you are going to solve them with web services.

    I have seen web services proposed for some pretty odd things, too. For example, sending log messages to a centralized logging service. Can you imagine having to invoke a web service from a Perl script every time you wanted to log a message? I think that some of these automatic wrappers for stateless session beans help contribute to this. Java developers are happy because they have their nice RMI interface, and the lesser languages can just use a web service.

    In general, I don't see web services as a replacement for technologies like RMI in a homogenous Java environment or CORBA (or MOM) in a heterogeneous environment. I have a hard time picturing an application pushing through hundreds of transactions a second using web services. I can envision those transactions initially coming in via web services, however.
  19. Web services seem more useful for giving external customers some limited form of programmatic access to your system without having to invent your own specific protocol.

    +1
    There's the meat. Everything else is gravy.
  20. Web services seem more useful for giving external customers some limited form of programmatic access to your system without having to invent your own specific protocol.
    +1There's the meat. Everything else is gravy.
    Does not CORBA do exactly the same and much more? There is protocol and everything else working for all languages, no need to invent/redo/tweak - it simply works stable for decades already.
    Jus expose necessary parts as CORBA services and enjoy.

    PS: People, lets rice and stop that port 80 firewall stupidity: more controlled open ports mean more security - not less.
  21. Web services seem more useful for giving external customers some limited form of programmatic access to your system without having to invent your own specific protocol.
    +1There's the meat. Everything else is gravy.
    Does not CORBA do exactly the same and much more? There is protocol and everything else working for all languages, no need to invent/redo/tweak - it simply works stable for decades already.Jus expose necessary parts as CORBA services and enjoy.PS: People, lets rice and stop that port 80 firewall stupidity: more controlled open ports mean more security - not less.

    It does appear that as more features are added to web services, there is more and more overlap with CORBA. Technically, there isn't really a problem with exposing your CORBA services to clients, plenty of companies do that today. When you do this, though, your client needs at least some portion of the ORB code installed. When you have a few trading partners, this isn't so bad. I can't imagine Amazon telling everyone that they need CORBA or RMI in order to access their services.

    You can write a web service client in minutes using the vanilla installation of most of the popular scripting languages - that's without any built-in support for web services. It's just not that easy to do with CORBA.

    On the other hand, if you want to develop your services using CORBA, you can always wrap a web service around them (using an ESB, for example).
  22. I can't imagine Amazon telling everyone that they need CORBA or RMI in order to access their services.You can write a web service client in minutes using the vanilla installation of most of the popular scripting languages - that's without any built-in support for web services. It's just not that easy to do with CORBA.
    I tend to disagree.
    I think your example of writing WS client in plain vanilla installation is a stretch.
    Yes, for a very simple request-response interaction even plain HTTP will suffice, but as we start demanding more control and robustness, and reliability, then we start bringing WS frameworks like SOAP:Lite for Perl, or Axis for Java, etc. In the instant whole stack become complex, inconvenient and inefficient. Then we start hearing oxymoron like binary XML, wheel reinvention begins.

    Actually using CORBA on client is not that different from using another library, lets say http, or tcp/ip, etc.
  23. I can't imagine Amazon telling everyone that they need CORBA or RMI in order to access their services.You can write a web service client in minutes using the vanilla installation of most of the popular scripting languages - that's without any built-in support for web services. It's just not that easy to do with CORBA.
    I tend to disagree. I think your example of writing WS client in plain vanilla installation is a stretch. Yes, for a very simple request-response interaction even plain HTTP will suffice, but as we start demanding more control and robustness, and reliability, then we start bringing WS frameworks like SOAP:Lite for Perl, or Axis for Java, etc. In the instant whole stack become complex, inconvenient and inefficient. Then we start hearing oxymoron like binary XML, wheel reinvention begins.Actually using CORBA on client is not that different from using another library, lets say http, or tcp/ip, etc.

    I think we are pretty well along the next cycle of wheel-reinvention. The very simple request-response interaction is the kind of place where web services seem to make sense. HTTP is fine, but how do you indicate what operation you want? How do you pass parameters? How do you structure data? Those are the questions that SOAP was intended to answer. I agree that when you start piling things on to give it the same feature set as CORBA, it does get more complex.

    CORBA on the client is different from using another library like http or tcp/ip in that you usually have to install CORBA separately, while many languages have tcp and http APIs by default. As you pointed out, though, if you start using more complex features of web services, you have to install extra packages as well. While I don't think many people are going to just write web service clients from scratch, the fact that is so easy to do so suggests that it is easier to write web service client libraries than it is to write CORBA client libraries, giving you more choices.

    With CORBA, you also run into more firewall issues (I'm not the person to argue with about the port 80 stuff, I just know the network guys don't like to open ports without good reason), naming issues, load balancing issues. You can resolve these issues with a little work, but why not avoid them in the first place if you can?

    I don't see this as an either/or question. Web services have their place, so do CORBA and RMI services. I wouldn't try to do a commodities trading system based entirely on web services, but I'd probably put a web service in front of it.
  24. Ted Neward has written a blog entry titled "Web + Services" summarizing web services and the "massive amounts of confusion that seem to be surrounding the whole subject," in an attempt to clarify the issues that the web services community is trying to address, as well as why they're facing those issues

    Who is confused, Vednors, pundit's or the gurus who taught us webservices fad? Or is Ted accusing us programmers of being confused:-) No Ted we are not; we have a job to do my friend and that is wrting software that works per business requirements...
  25. to get to the bone of it[ Go to top ]

    Riddle: "Why do people keep grumbling about Web-services?" (that has already become widely used and is incredible easy)

    Answer:
    1) It is not OO (makes the OO purist angry)
    2) It is not Java (makes the "Java everywhere" people angry)
    3) Is too easy to learn (makes the "fake computer-scientist" angry)
    4) Comes from MS (comment unnecessary)
    We use the SOAP protocol daily, with good results.

    On the other hand, I remember the last time we tried to open ports both at the server and clients for our "distributed objects" and shiver - it was cold - it was mean, above all in the end it didn't work!.

    Thank you, Evolution
    Rolf Tollerud
  26. to get to the bone of it[ Go to top ]

    Riddle: "Why do people keep grumbling about Web-services?" (that has already become widely used and is incredible easy)Answer:
    1) It is not OO (makes the OO purist angry)2) It is not Java (makes the "Java everywhere" people angry)3) Is too easy to learn (makes the "fake computer-scientist" angry)4) Comes from MS (comment unnecessary)
    We use the SOAP protocol daily, with good results.On the other hand, I remember the last time we tried to open ports both at the server and clients for our "distributed objects" and shiver - it was cold - it was mean, above all in the end it didn't work!.Thank you, EvolutionRolf Tollerud

    I'll ignore the obvious trolling aspects of this post, and keep on topic. People often grumble about web services because of performance. The business of building data into XML - a potentially bulky format - and then transmitting that volume of information and then parsing that XML on the server, means that SOAP is not appropriate for the small, lightweight RPC that many applications need (in these circumstances APIs such as RMI are more suitable).

    SOAP can be very easy to use, which means that some developers try and use it where it should not be used.

    (Of course SOAP is neither pro or anti objects or OOP).
  27. made by a committee[ Go to top ]

    I don't get it. CORBA have had its chance but never recovered from IBM's San Francisco projects fiasco back in 97-98. After that it had 5 years to grow but never got any traction. The different vendor’s implementation was not compatible. So now when Web Services is in place, then will CORBA be successful? Where is the logic?

    This whole discussion is a very good example on the ivory tower approach of the J2EE impractical computer scientists. Not only do they abstract themselves away from the mainstream everyday problems, but they also does not keep up with modern technology (Indigo anyone?). That doesn’t bode well, not at all. Ability to learn from past mistakes is the smallest common denominator that is needed in this world.

    Regards
    Rolf Tollerud
  28. Oh please[ Go to top ]

    I don't get it. CORBA have had its chance but never recovered from IBM's San Francisco projects fiasco back in 97-98. After that it had 5 years to grow but never got any traction. The different vendor’s implementation was not compatible. So now when Web Services is in place, then will CORBA be successful? Where is the logic? This whole discussion is a very good example on the ivory tower approach of the J2EE impractical computer scientists. Not only do they abstract themselves away from the mainstream everyday problems, but they also does not keep up with modern technology (Indigo anyone?). That doesn’t bode well, not at all. Ability to learn from past mistakes is the smallest common denominator that is needed in this world.

    Regards
    Rolf Tollerud

    seriously, you're gonna have to back that up with specifics and show how webservice can handle this scenario. You have a travel booking application.
    1. it has to be able to place order to multiple companies. be it car rental, hotel, motel, train, taxi or airline
    2. it has to support 1-phase and 2-phase commit
    3. it has to support complex scenarios. For example, say the system has to book: car rental, airline, hotel, and a second hotel. if the first three succeed, but the last fails, the booking should go through. if the car rental fails, a suitable substitution can be replaced without approval. if the hotel fails, the entire order is cancelled.
    4. the transaction from the order perspective must be reliable.

    Try to do that with stock webservices and tell me again how corba failed. By the way, corba is working just fine. Why do you think WSI is pushing for reliable messaging? Oh that's right, it's because current webservices suck at the traveling booking scenario I just described.

    have fun :)

    peter
  29. your scenario is 1000 times more easy with Indigo:

    Avalon and Indigo Beta1 RC

    "Indigo fully supports WS-AtomicTransactions and WS-Coordination. WS-AtomicTransactions has a protocol framework to enable 2 phase commit protocol between different parties. You start the transactions via MSDTC and then the same transactions can be sent via a Web Service to a foreign transaction manager and still will be a part of the same transaction."

    Web Services Atomic Transaction (WS-AtomicTransaction)

    Regards
    Rolf Tollerud
  30. P.S.[ Go to top ]

    But I guess it is no fun when every Tom, Dick and Harry can do it, right? You will have to invent something new then. Maybe 2 phase commit with AOP?

    hi hi (i pronounced like - bah, you know by now)
  31. your scenario is 1000 times more easy with Indigo:Avalon and Indigo Beta1 RC"Indigo fully supports WS-AtomicTransactions and WS-Coordination. WS-AtomicTransactions has a protocol framework to enable 2 phase commit protocol between different parties. You start the transactions via MSDTC and then the same transactions can be sent via a Web Service to a foreign transaction manager and still will be a part of the same transaction." Web Services Atomic Transaction (WS-AtomicTransaction)RegardsRolf Tollerud

    Thank you, Rolf. You really helped make the original points much clearer by showing a good example of heaping more features provided by CORBA and J2EE on top of web services. You just added a few additional wrinkles by limiting it to a Microsoft-only framework, and by implying that it is new (if that's why you meant by your suggestion that we do not keep up with "modern technology"). I'm not really sure it is a good example of "learning from past mistakes".
  32. Rolf:
    your scenario is 1000 times more easy with Indigo:

    Avalon and Indigo Beta1 RC

    "Indigo fully supports WS-AtomicTransactions and WS-Coordination. WS-AtomicTransactions has a protocol framework to enable 2 phase commit protocol between different parties. You start the transactions via MSDTC and then the same transactions can be sent via a Web Service to a foreign transaction manager and still will be a part of the same transaction."

    Web Services Atomic Transaction (WS-AtomicTransaction)

    I don't get it. Microsoft have had its chance but never recovered from their J++ projects fiasco back in 97-98. After that it had 5 years to grow but never got any traction. The different vendor’s implementation was not compatible. So now when J2EE is in place, then will .NET be successful? Where is the logic?

    This whole discussion is a very good example on the ivory tower approach of the Microsoft impractical computer scientists. Not only do they abstract themselves away from the mainstream everyday problems, but they also does not keep up with modern technology (AJAX anyone?). That doesn’t bode well, not at all. Ability to learn from past mistakes is the smallest common denominator that is needed in this world.

    Peace.
  33. "J++ projects fiasco"

    Microsoft J++ was no fiasco, according to you (Cameron Purdy) "it is still the best Java IDE".
    Do you deny that you have said that? :)

    "After that it had 5 years to grow but never got any traction"

    It was destroyed by a sneak attack.

    "The different vendor’s implementation was not compatible"

    What have you been taken?

    "So now when J2EE is in place, then will .NET be successful?"

    .NET already is more successful..

    "Where is the logic?"

    Above.

    "This whole discussion.. AJAX..

    AJAX is more used in the .NET world.

    Anything else?

    Regards
    Rolf Tollerud
  34. Cameron February 01, 2002[ Go to top ]

    I still use J++ ... it's a fine tool
  35. Cameron February 01, 2002[ Go to top ]

    I still use J++ ... it's a fine tool

    And believe it or not, I still use it occasionally .. it's a nice editor ;-)

    Rolf, thank you for taking the time to make a point by point rebuttal; I am sure in some sick way that redeems a few minutes of Steve Zara's or Peter Lin's life for having attempted to answer your rambling accusations.

    As for my post, I was just using your own words. It's amazing how capricious the arguments were, isn't it?

    (At this point, Rolf fails to utilize that part of the human mind that allows most of us to appreciate humor and irony. In frustration, he lashes out instead ..)

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  36. So, instead of discussing the merits of Corba vs Indigo the thread disintegrated. You destroyed it and I will get the blame. (again)

    The little trick in best Cameron spirit will not make Corba any more undead though.
  37. First you post:

    Microsoft J++ was no fiasco, according to you (Cameron Purdy) "it is still the best Java IDE".
    Do you deny that you have said that? :)


    ant then you post:
    I still use J++ ... it's a fine tool

    I thought it was OUR job to contradict your BS, but you seem to be doing it fine on our own. Just leave some for us too, don't take the fun all to yourself. :)
  38. Have you read those specs?[ Go to top ]

    your scenario is 1000 times more easy with Indigo:Avalon and Indigo Beta1 RC"Indigo fully supports WS-AtomicTransactions and WS-Coordination. WS-AtomicTransactions has a protocol framework to enable 2 phase commit protocol between different parties. You start the transactions via MSDTC and then the same transactions can be sent via a Web Service to a foreign transaction manager and still will be a part of the same transaction." Web Services Atomic Transaction (WS-AtomicTransaction)RegardsRolf Tollerud

    I attempted to read those specs, but quite honestly I couldn't get through them. I actually enjoy reading specs and read many of them for fun. Have you tried those new features? the developer preview only came out a few months back and it's not even official release. If I want to build something today, what official release supports it? Has it WS-Atomic Transaction proved itself and shown to be reliable and mature? Has WS-Coordination or the various attempts at coreography proven they are mature?

    I tried to use MSDTC, but I found the API no different than existing tools in the same space. To be blunt, I didn't give it enough time to really know it, and gave up rather quickly, so it's my own limitation in this case. It just feels much better to use JMS style distributed transactions, since I've used JMS before.

    It's clear you haven't had to deal with coordinating multiple transaction managers, since it's actually quite tricky and resolving differences in state transition is actually rather hard to get right. What happens if a system that doesn't support 2-phase commit has to communicate with a system that only supports 2-phase transactions?

    peter
  39. equally complex[ Go to top ]

    your scenario is 1000 times more easy with Indigo:Avalon and Indigo Beta1 RC"Indigo fully supports WS-AtomicTransactions and WS-Coordination. WS-AtomicTransactions has a protocol framework to enable 2 phase commit protocol between different parties. You start the transactions via MSDTC and then the same transactions can be sent via a Web Service to a foreign transaction manager and still will be a part of the same transaction." Web Services Atomic Transaction (WS-AtomicTransaction)RegardsRolf Tollerud

    In case you didn't notice the Irony, the whole point of SOAP webservices in the beginning is that "it is simpler" and therefore some how better. Now that WSI is adding more and more specifications on top to address all the limitations, it is becoming just as complex, but with the added bonus of being slow. The only real difference once all those new specs are declared final, is that Corba/RMI use binary, and webservices use Text. Though that might change if binary XML gets approved.

    So in the end, it comes full circle. I like public standards, but at some point, it creats more noise than measurable benefit.

    peter
  40. We have something in common you and I Peter, we both want to download Indigo and play with it, learn it, study it. I haven't succeeded yet either, with the march CTP I had it working but no documentation - guess we both have to wait until the final release.

    But there is enough information and samples around so you can get a good feel of it, (even if it's like swimming on dry land). Indigo is not only about Web Services, Indigo embraces all distributed protocols, text or binary. Change a descriptor in an XML file and the application use a different protocol.

    The examples I have seen are sound and follow "the principle of least surprise". In short it is so far away from “design by committee” as possible. Moreover you know Microsoft dedication "once something has got their attention". (Remember the 1000 persons on the IE team?).

    I only wanted to praise the simple SOAP protocol, which has been incredible useful for us. It was you that brought 2-phase commit and all the other heavy stuff into the picture. Your opinion is as I understand is this: "Once Web Services can do everything Corba can do it will be equally complicated and heavy". You will be wrong. What Indigo will be showing is that you have been selling snake-oil all along.

    Regards
    Rolf Tollerud
    (soon to become Indigo expert)
  41. .NET more successful than Java?[ Go to top ]

    Rolf,

    first, i truly do appreciate your persistence over the years, you do in fact serve a very useful role by providing the "jab" and "barb" to the assumptions and biases that are continuously propagated in the java community, in fact all communities are equally subject to breathing in their own exhaust, and it is healthy to have radically differing opinions as part of the continuing discussion.

    you used to irritate me in the extreme, but as i have gotten older and matured, i am much more open to your postings, so hey, you helped me grow, and for that i thank you.

    it isn't easy being the lone wolf that everyone loves to hate, unless of course you get off on that, but something tells me you don't, and that instead you do what you do because you want java to improve and grow and to encourage the java community towards less arrogance.

    however, sometimes, your postings lean more towards pontification of .NET as being superior to Java, as opposed to simply offering alternatives, and in your previous posting the statement that .NET is already more successful than Java, is both meaningless and rather silly.

    rolf, i for one, perhaps the only one (?), value your contributions, but please, stay focussed.

    with respect.
    Peter
  42. We have something in common you and I Peter, we both want to download Indigo and play with it, learn it, study it. I haven't succeeded yet either, with the march CTP I had it working but no documentation - guess we both have to wait until the final release.But there is enough information and samples around so you can get a good feel of it, (even if it's like swimming on dry land). Indigo is not only about Web Services, Indigo embraces all distributed protocols, text or binary. Change a descriptor in an XML file and the application use a different protocol. The examples I have seen are sound and follow "the principle of least surprise". In short it is so far away from “design by committee” as possible. Moreover you know Microsoft dedication "once something has got their attention". (Remember the 1000 persons on the IE team?). I only wanted to praise the simple SOAP protocol, which has been incredible useful for us. It was you that brought 2-phase commit and all the other heavy stuff into the picture. Your opinion is as I understand is this: "Once Web Services can do everything Corba can do it will be equally complicated and heavy". You will be wrong. What Indigo will be showing is that you have been selling snake-oil all along.

    Regards
    Rolf Tollerud(soon to become Indigo expert)

    The only benefit of WSAtomic Transaction and WSC gives you better chance of integrating across systems. Since my previous response wasn't clear.

    The hardest part about the travel booking scenario isn't the protocol. The hard part is that each business has their own way of doing things and the number of states a transaction goes through rarely matches 1 to 1. So I applaud standards and an effort to work together, but that's a minimum requirement. corba specification and WS-A specification both describe the necessary semantics to build clients or server side services for transactions. It doesn't solve the human issue. At the end of the day, most of the integration challenges are the result of each group having their own way of doing things. Finding an acceptable compromise and writing a clear functional spec for the integration isn't easy. With mature toolkits, the job is easier, but far from easy. I've lost count how many times things break because of lack of communication between parties. Managing the change is one of the hardest parts of integration. I'd recommend reading the specs. both are well written and make it sound easy. It's also very easy to write simple examples and make it "appear" easy. Reality is quite different.

    Here is a blunt question. Have you ever had to integrate with third party systems and make multiple calls for a single transaction?

    I have and it's not easy. I'm definitely not an expert in this field, since the types of integration I've done are either portal related or compliance systems. Some of my friends work with mainframes and the stuff they have to do is far more complex.

    peter
  43. I rest my case for now[ Go to top ]

    Peter,

    "I've lost count how many times things break because of lack of communication between parties"

    I can appreciate the difficulties with having to take into consideration communication breakdown; "should I try again and how long to wait how many times to try", etc. It’s definitely not easy.

    But at the same time it must be possible to abstract to a higher level so you don't have to make all low level calls by hand. I prefer to rest my case until I have a working environment. I have no real proof at the moment other than respect for Microsoft's "wealth and power and general ingenuity". There have been over 20 such cases (wars) through the years and MS has always won…

    Regards
    Rolf Tollerud
  44. The dilemma[ Go to top ]

    I have no real proof at the moment other than respect for Microsoft's "wealth and power and general ingenuity". There have been over 20 such cases (wars) through the years and MS has always won…RegardsRolf Tollerud

    You see, this is the sort of statement that I find problematic. It is backed by no evidence but adds to a drip-feed of FUD. I occasionally come into contact with clueless and lazy IT people who take such FUD as if it were true and this can be a real nuisance sometimes. (This is why I have often been so persistent in trying to counteract such FUD).

    I see two ways to proceed. The first is to leave such statements unchallenged. The problem is that it may seem to the casual reader that a lack of challenge may imply agreement. The second is to debate about it, but experience leads me to believe that this will get nowhere as we will get sidetracked into arguments about what 'war' means in this case, how many there have been, and whether or not Microsoft has 'won' them. Eventually, someone will mention 'Big Elephant J2EE' and then quotes from philosophers will turn up and it will descend into a farce that I am sure a considerable number of readers will not find entertaining.

    Needless to say, you are wrong, but what to do? That is the dilemma...
  45. The dilemma[ Go to top ]

    Needless to say, you are wrong, but what to do? That is the dilemma...

    Here is a suggestion. I don't work in the Java world (completely into .NET) but I have a healthy respect for technology in general and am not religious about any particular language. You could simply pick Rolf's statements line by line and rebut them easily because if you look closely precious little of what he says actually makes any sense. He apparently does not want to exhibit any technical depth preferring instead to post copious links from MSDN and myriad other sites -- suggests to me he lacks any independant opinion. Before you know what hit you he will be quoting countless statements from Kant to Hume to Don Box; whether or not they are relevant to the discussion is secondary. As Cameron has repeatedly called out, with friends like these, who needs enemies? I tend to concur.
  46. can you finish sometime?[ Go to top ]

    For heavens sake, I never intended to get into this discussion I only wanted to put forward the simple and practical SOAP protocol workhorse.

    But now that we are here anyway, if you want "java to improve and grow and to encourage the java community towards less arrogance", as Peter put it, why don't you propose that the J2EE world could use a "Indigo type of universal communication kit" instead of buying MQSeries, Tibco, Tuxedo, etc, etc, hire a bunch of consultants with 20+ years of experience and build custom solutions for millions of dollars.

    You don't need Kant or Hume or Don Box to understand that.
  47. Universal communication[ Go to top ]

    why don't you propose that the J2EE world could use a "Indigo type of universal communication kit"

    It is about 20 years, in fact, that I hear countless promises of "universal communication", the last one being called "Enterprise Service Bus". You can believe that Indigo is the ultimate solution that solves this problem, at last. Nobody can tell you are wrong.

    But I tend to not agree with any solution that is labeled as "universal". Both CORBA and WS were presented as such, and it appears that, beside the fact that they both have their value, none of the two is in fact the universal solution.

    I do not know if I should admire your capacity to still believe in the ultimate solution to all issues. But I guess I could be lynched by all the TSS crew if I dared to say I envy you.
  48. Universal communication[ Go to top ]

    A "universal communication kit" is not the same as "the ultimate solution".

    Perhaps you have heard the story about the two consultants in the African that was attacked by a lion? While they were running one of them said, "it is hopeless, we can never outrun the lion". The other answered: I don't have to. The only thing I need to do is to outrun you!

    So:
    The only thing that is needed is to have a better price/performance factor than the competition.
  49. The only thing that is needed is to have a better price/performance factor than the competition.
    Which, ironically, gets us to proven open-source products and tools.
  50. Universal communication[ Go to top ]

    A "universal communication kit" is not the same as "the ultimate solution".Perhaps you have heard the story about the two consultants in the African that was attacked by a lion? While they were running one of them said, "it is hopeless, we can never outrun the lion". The other answered: I don't have to. The only thing I need to do is to outrun you!

    There was a third one. He suddenly stopped running and relaxed. The others shouted to him 'what are you doing?'. He replied 'there is no need to worry - Microsoft has announced that their Universal Gun (TM), guaranteed to kill all animals, will be available to everyone Real Soon Now'.
  51. sorry for that I exist![ Go to top ]

    So I retract into my cave again, plaster my wounds and cuts and make my twentieth SOAP call today. Sorry I opened my month. Sorry I spoke about the future product Indigo Beta 1 Release Candidate!

    Regards
    Rolf Tollerud
    (must call the doctor..)
  52. can you finish sometime?[ Go to top ]

    why don't you propose that the J2EE world could use a "Indigo type of universal communication kit" instead of buying MQSeries, Tibco, Tuxedo, etc, etc, hire a bunch of consultants with 20+ years of experience and build custom solutions for millions of dollars.You don't need Kant or Hume or Don Box to understand that.

    Because one size does not fit all. Some communication needs to be lightweight and very high-performance (so XML-based) messaging is not appropriate), some needs to work with legacy code or non-Java applications (e.g. MQSeries).

    Choice and competition is good. You don't hire a bunch of consultants (your usual straw man), you look at competing existing products, not just the one that a vendor like Microsoft decides to provide, and decide which is best.

    You don't need St Augustine or Derrida or James Gosling to understand that.
  53. couldn't resist[ Go to top ]

    For heavens sake, I never intended to get into this discussion I only wanted to put forward the simple and practical SOAP protocol workhorse.But now that we are here anyway, if you want "java to improve and grow and to encourage the java community towards less arrogance", as Peter put it, why don't you propose that the J2EE world could use a "Indigo type of universal communication kit" instead of buying MQSeries, Tibco, Tuxedo, etc, etc, hire a bunch of consultants with 20+ years of experience and build custom solutions for millions of dollars.You don't need Kant or Hume or Don Box to understand that.

    You realize that Indigo is really just copying JMS providers out there who already provide most of the features Indigo is suppose to provide. You don't need guys with 20+ years of experience to build the system correctly. Someone with 3 solid years of large scale systems experience and lots of diligence can build it.

    Unless you really need MQSeries, Joram, ActiveMQ and several other products can do the job just fine. Is there an equivalent clone of Biztalk or MSMQ in the .NET world?

    peter
  54. "Someone with 3 solid years of large scale systems experience and lots of diligence can build it"

    ha ha. I just thought I better generously sprinkle out years because you regularly makes comments like these:

    Peter,
    "I've never claimed to be an expert in complex transactions. I'm simply citing real world use cases I know of first hand ---I wish I had 10 more years of experience in this specific domain, but that's something I'll have to acquire over time ---I know guys with 10-20 years of experience building compliance systems and I always ask them for their input.
    Peter light weight?

    "providers out there who already provide most of the features Indigo is suppose to provide"

    As usual when MS innovate the people says "something almost like this was done 10 years ago" or "company A is planning build this in the immediate future".

    It doesn't matter if it is new or not, what matters is easy of use and quality. And it is not a trifle we are talking about it is a mayor effort. What Indigo does is:

    1) Bring all together under a common umbrella. The equivalent in the Java world would be, "just change an XML descriptor to switch between CORBA and Axis".

    2) Making it so easy to use that any Tom, Dick and Harry can do it.

    3) Lower the price. Indigo will be free as part of the OS.

    Regards
    Rolf Tollerud
  55. Lower the price. Indigo will be free as part of the OS
    Buy a car and you'll get the wheels for free! :)
  56. Not necessarily true[ Go to top ]

    "Someone with 3 solid years of large scale systems experience and lots of diligence can build it"ha ha. I just thought I better generously sprinkle out years because you regularly makes comments like these:
    Peter,
    "I've never claimed to be an expert in complex transactions. I'm simply citing real world use cases I know of first hand ---I wish I had 10 more years of experience in this specific domain, but that's something I'll have to acquire over time ---I know guys with 10-20 years of experience building compliance systems and I always ask them for their input.
    Peter light weight?"providers out there who already provide most of the features Indigo is suppose to provide"

    As far as I know, I am still a light weight in the world complex distributed transactions. Most likely the statement will still be true 3 years from now, unless I branch out to other areas. Experience with one specific type of distributed transaction in no way makes me an expert in the domain of distributed transactions. That would be like saying, a 5 year old can drive a F-1 race car because he can ride a bike.
    As usual when MS innovate the people says "something almost like this was done 10 years ago" or "company A is planning build this in the immediate future". It doesn't matter if it is new or not, what matters is easy of use and quality. And it is not a trifle we are talking about it is a mayor effort.

    I absolutely agree with that statement. But when has any company produced a toolkit that was mature, complete, bug free and significantly better than existing products with 5 years head start on the first try? WS-I compliant webservices will one day be mature, but it's going to take time.
    What Indigo does is:
    1) Bring all together under a common umbrella. The equivalent in the Java world would be, "just change an XML descriptor to switch between CORBA and Axis".
    2) Making it so easy to use that any Tom, Dick and Harry can do it.
    3) Lower the price. Indigo will be free as part of the OS.

    Regards
    Rolf Tollerud

    Point #1 is debatable. Some people love xml driven config, some hate it.

    Point #2 is not possible. A good toolkit can make it "easier", but not easy. Definitely not easy enought that a total newbie can build a rock solid distributed app in days or weeks. it takes time. The reason why Don Box is respected in that field is because he has over a decade of deep experience. That didn't come through some magic tool.

    Point #3 is nice, but there's already plenty of free open source toolkits that are mature with 3-5 years of real world testing.

    I think it's great that MS is finally trying to offer these tools, but it's going to take time. Like everything, once Indigo reaches the third release, it will be mature and robust.

    peter
  57. What Indigo does is:
    1) Bring all together under a common umbrella. The equivalent in the Java world would be, "just change an XML descriptor to switch between CORBA and Axis"

    It brings things together, but using a method of communication that puts a heavy demand on processors and networks: XML messaging. Personally, I really like this use of XML, but it is not suitable for all situations.
    2) Making it so easy to use that any Tom, Dick and Harry can do it.

    I don't want 'any Tom, Dick and Harry' developing critical enterprise systems. I want skilled software engineers who understand what they are doing.
    3) Lower the price. Indigo will be free as part of the OS.

    No, that is not free. That is 'bundled'. Indigo will be part of the price of the OS.
  58. The dilemma[ Go to top ]

    You could simply pick Rolf's statements line by line and rebut them easily because if you look closely precious little of what he says actually makes any sense.

    Because I have been down that roat before. Rolf's arguments are like the mythical Hydra - you demolish one FUD statement and he replaces it with many others (often ones which have already been rebutted on previous threads), and things descend not just into noise, but noise the same noise again and again in each new thread...
  59. Good point![ Go to top ]

    'I have no real proof at the moment other than respect for Microsoft's "wealth and power and general ingenuity"'

    this is not something to be underestimated...MS is indeed capable of a certain level of focus and drive that is rarely found in other IT companies.

    food for thought anyway.

    who knows, when Indigo does get formalized, perhaps Java implementations can steal some of the insights and implement to our advantage?
  60. at last someone with humor[ Go to top ]

    Stealing from others and possibly improve is the Good Old Capitalism in action that have been the workhorse building welfare all over the world. Or is there anybody that will have a bad conscience stealing from Microsoft! Or is there anybody that thinks that Microsoft has not stolen anything in its days! ;)

    How long is the average time you are allowed to have an idea for yourself in this business? This is a cut-throat play-ground for people that are totally corrupt with absolutely no moral.
     
    That is why I feel so comfortable in it.

    If only Cameron would go away. He is the only one that thinks he is better than the rest of us!

    Regards
    Rolf Tollerud
  61. at last someone with humor[ Go to top ]

    Stealing from others and possibly improve is the Good Old Capitalism in action that have been the workhorse building welfare all over the world.

    Yes, but at some point the ideas that are copied have to be invented in the first place - that is where 'innovation' comes it. What annoys me and others is when companies copy an idea then label this 'innovation'. This is one area where Microsoft is so infuriating.
    How long is the average time you are allowed to have an idea for yourself in this business?

    That depends on the license or patenting of an idea.
    This is a cut-throat play-ground for people that are totally corrupt with absolutely no moral.
     
    Considering the success of GNU and Linux, and other open source products, I would have to say that it is possible to be non-corrupt and moral and succeed phenomenally well.
    That is why I feel so comfortable in it.

    heh
  62. at last someone with humor[ Go to top ]

    If only Cameron would go away. He is the only one that thinks he is better than the rest of us!

    Rolf, it is unfortunate that you have managed to degrade the level of public discourse once again.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  63. Cameron,

    So you of all people have the nerve to complain! Stop acting like a jerk yourself and maybe you will see some results.
  64. Stop acting like a jerk yourself and maybe you will see some results.

    Rolf, you are an obnoxious bully, and every thread that you participate is ruined. This thread itself is proof, as any reasonable person can see -- just scroll down from the top and find where it degrades. I'll give you a hint:
    This whole discussion is a very good example on the ivory tower approach of the J2EE impractical computer scientists.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  65. How is that different from the thousands of condescending Cameron posts about ridiculous and "criminal" Microsoft? Not to speak about VB programmers in general?

    Patrick Boyle:
    The Java/UNIX/Oracle camp particularly seems to enjoy casting their technical preferences in quasi-religious terms that encourage hyperbole, paranoia and hatred. The rhetoric used by Java advocates about Microsoft and Bill Gates is not subject to common standards of decency.
    In fact you have the dubious honor of being the person that was the catalyst that made me start in TSS. Thanks to posts like these:
    .Net dead in the water anyway

    Bashing Microsoft in everyway but at the same time faking an "objective" attitude by giving credit for some small and unimportant things. If you argue for something please be honest enough to admit where you stand. In fact you seem more desperate than any other person I been debating with for the dominance of Java. Therefore, in my eyes your articles are far worse then the ones that Patrick Boyle refers to.
  66. Rolf,

    for each time someone shouts "Microsoft is crap" here, you come 10 times more with your boring and repetitive abuses. You could just realize that no matter how much you abuse here or anywhere, people's opinion about Microsoft won't change at all. You're not helping anyone or making any difference besides polluting the forum, so quit it, willya?
  67. You're not helping anyone or making any difference besides polluting the forum, so quit it, willya?

    +1
  68. besides it is fun too[ Go to top ]

    "You could just realize that no matter how much you abuse here or anywhere, people's opinion about Microsoft won't change at all"

    Is that so? You just have to follow the link that I gave above ".Net dead in the water anyway", read that and other articles from that time. Then compare with current time.

    So, why should I quit when I am winning?

    Regards
    Rolf Tollerud
  69. besides it is fun too[ Go to top ]

    "You could just realize that no matter how much you abuse here or anywhere, people's opinion about Microsoft won't change at all"Is that so? You just have to follow the link that I gave above ".Net dead in the water anyway", read that and other articles from that time. Then compare with current time. So, why should I quit when I am winning?RegardsRolf Tollerud

    You aren't winning because you aren't even fighting a serious battle with anyone. You invent a series of straw men (J2EE scientists, OOP, stateful servers), and repeatedly rant on about them, ignoring what anyone else says. If you are shown to be wrong, you ignore this too and start the whole thing again on a new thread. You constantly contradict yourself (as when you said how awful ORM is then in the same thread praised the Ruby on Rails approach and Castle, which uses Hibernate).

    Whereas those you are trying to argue with post reasonable statements, such as from Cameron's post you referred to:
    MS *will* teach us a thing or two about ease of development with .NET

    You ignore such reasonableness and rant on about
    Bashing Microsoft in everyway
    .

    You live in your own small niche world where your specific Microsoft-based approaches work, no matter how crazy they are (remember when you advised someone how to run part of their companies' website on their personal workstation on Experts' Exchange?), and you assume that your limited approach must be right for everyone, and you try and defend that point of view with hilariously unrepresentative links and meaningless statistics.

    You are a tiresome waste of time. I used to find it interesting to argue with you, but it has got too boring and pointless.
  70. besides it is fun too[ Go to top ]

    So, why should I quit when I am winning?RegardsRolf Tollerud
    That's childish, don't you think? Besides, the only "thing" you'll win is some personal satisfaction for such perception of gain (a very distorted one, by most peoples account). But at what cost? Your reputation down the drain, our patience and time, forum's low quality, etc. I am sure you could find fun and wellness in much better ways other than trolling, name calling, abusing, whinning or other similar childish behaviours. You should try coding for example, I find it very rewarding.
  71. take a pill, dude[ Go to top ]

    In fact you have the dubious honor of being the person that was the catalyst that made me start in TSS. Thanks to posts like these: .Net dead in the water anyway

    Wow, did you miss the point entirely ..

    1. I was responding to a message titled ".Net dead in the water anyway"; I did not make that title up nor did I support its assertion.

    2. That post of mine is four years old, and I would guess that most reasonably intelligent technical people who would read it today would say that it was correct then and its predictions have almost all been proven correct over time.

    Your blatant negativity and total lack of objectivism is astounding.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  72. I have Carte Blanche[ Go to top ]

    Cameron,

    "take a pill, dude"

    Is it some kind of American slang?

    "most reasonably intelligent technical people who would read it today would say that it was correct then and its predictions have almost all been proven correct over time"

    hi hi (i pronounced as in insanity!)

    Objective? How can I be objective in this case?. "The hottest places in hell are reserved for those who, in a time of moral crisis, maintain their neutrality." - Dante's Inferno

    Anyway, I have an open offer that still stands: should Floyd or Dion tell me to quit, I will quit. They haven't done so, so all is clear.

    Regards
    Rolf Tollerud
  73. I have Carte Blanche[ Go to top ]

    I have an open offer that still stands: should Floyd or Dion tell me to quit, I will quit. They haven't done so, so all is clear.

    Not to nit-pick or anything, but you did promise us that you would never post on TSS again. What happened to that promise? Your word means nothing.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  74. American slang[ Go to top ]

    Cameron,"take a pill, dude"Is it some kind of American slang?

    Regards
    Rolf Tollerud

    "take a pill" or "take a chill pill" is an american slang for "take a deep breath and relax." In other words, people are just joking around.

    peter