Web Services 2005 -- Five Keys Unlock the Gate

Home

News: Web Services 2005 -- Five Keys Unlock the Gate

  1. Web Services 2005 -- Five Keys Unlock the Gate (35 messages)

    Sun's VP of Java's web services & tools says open web services are at a crossroads in 2005, and posits that there are five (5) keys that would fully unlock the power of these new, open technologies.

    Notably, Keller says, XML has the power to create a vast array of portable data options. He also says multi-vendor co-operation on a number of fronts, spurred by end user pressures, may unlock web services full power.

    Read the full article: Web Services 2005 -- Five Keys Unlock the Gate

    Threaded Messages (35)

  2. Wow, sounds like one of the OASIS or Microsoft sales guys did a great job on Sun. They note that "XML is portable data" and "Java is portable business logic", what they seem to have forgotten is that Java is also portable data too so why bother with the XML? Too quiet on your network? CPU not hot enough? Programmers got too much time on their hands? Or perhaps simply because some idiot chose to use a non-Java, non-JMS, non-CORBA product that needs integrating with the real world.

    Good to see Sun keeping up with the WS race at least.

    -John-
  3. Wow, sounds like one of the OASIS or Microsoft sales guys did a great job on Sun. They note that "XML is portable data" and "Java is portable business logic", what they seem to have forgotten is that Java is also portable data too so why bother with the XML? Too quiet on your network? CPU not hot enough? Programmers got too much time on their hands? Or perhaps simply because some idiot chose to use a non-Java, non-JMS, non-CORBA product that needs integrating with the real world.Good to see Sun keeping up with the WS race at least.-John-

    Unfortunately, you can't always dictate the terms of what you integrate with. As an example, I am working on a project which requires passing data from an in-house system (java server application) to an existing third party applications (written in .NET). I wish that I could "play god" and make everything represent my image of the world, but that's often not reality.
  4. Joe Keller's opinion piece in OpenEnterpriseTrends.com is worthy of praise. He begins with the problem of "complexity" and commits Sun to a course of action to solve the problem. That's commendable.

    I wish Keller included the following in his list of 5 Keys:

    Key #6 Scalability and Performance

    Very little has been done to deliver solutions to Web Service scalability and performance problems. In 2003 I reported that SOAP RPC-encoded messaging does not scale (http://www-106.ibm.com/developerworks/webservices/library/ws-soapenc/). Since then Sun continues to push RPC-encoded messaging. In 2004 I reported on the problems of using DOM and SAX approaches to processing large SOAP requests. While the SOAP stacks will all change in the next 6 months (Axis, WebLogic, WebSphere, etc.) I have yet to see a scalability and performance focused release discussed.

    The work I did writing General Motors Web Service Performance Benchmark and best practices guide to SOA uncovered a problem most industries are encountering now. For instance, in 2003 several automotive manufacturers banded together to form the Standards for Technology in Automotive Retailing (STAR) at http://www.starstandard.org. STAR defined the Business Object Document (BOD) XML schema to describe typical messages exchanged between automotive retailers and the manufacturing plant. IBM developerWorks offers a good introductory article on STAR BODs

    The problem with BODs is the size of the message body can grow tremendously. Parsing all of the elements in a large XML document eats away at CPU bandwidth. For instance, a partially populated ProcessPurchaseOrder BOD when instantiated as an object and then printed to a String measures 166,374 bytes. A software architect and developer's choice of XML handling library greatly impacts the scalability and performance of a service that uses BODs and other large-payload size XML messages.

    The Key to Web Services is solving the existing scalability and performance problems. I blog about our work with enterprises that are using Web Services today at http://www.pushtotest.com/thecohenblog

    Key #7 Avoiding Fragmentation

    The problem at this point is that XML is a wordy and bulky way to represent objects and their related data. There is no upper limit to an XML document - at least nothing you can define in a WSDL definition. At the "Keys To SOA Scalability" (http://www.pushtotest.com/Support/events/scalablesoa.html) seminar I taught last week I fielded many questions from software architects and developers looking for XML compression, fast XML parsing, and binary XML solutions to move XML messages quickly from service to service. If architects and developers come to a conclusion that SOAP brings along too much overhead then you will see a fragmentation of the WS space into people using SOAP tools and those opening a socket and transporting XML in compressed binary form for themselves. XML would live on but Web Services will die.

    -Frank Cohen
    Author of Java Testing and Design
    www.pushtotest.com
  5. The Key to Web Services is solving the existing scalability and performance problems.

    "Web services have just become faster and more usable," according to W3C last month. W3C's SOAP optimization press release had encouraging points:

    "XML-binary Optimized Packaging (XOP) provides a standard method for applications to include binary data, as is, along with an XML document in a package. As a result, applications need less space to store the data and less bandwidth to transmit it. XOP works at the XML Information Set (Infoset) level, allowing the same abstract representation of a XML document to be serialized in different ways."

    "...the Resource Representation SOAP Header Block (RRSHB) functionality allows SOAP message recipients to access cached representations of external resources."
  6. Performance enhancements in the works[ Go to top ]

    Thanks, Brian, for pointing me to the W3C recommendations. I'm glad to see that the standards bodies are concerned about scalability and performance.

    I'm working with enterprises that are trying to use today's tools to implement service architecture. There is a lot of movement in the Web Service tools space - all of the tools are releasing new revisions over the next 6 months. I would love to learn about the tools vendors issuing upgrades that focus on scalability and performance for dealing with large XML payload sizes.

    It seems to me that it will likely be a year or more before the W3C recommendations make it into a tool release. That's not good for the enterprises trying today to build services.

    -Frank
  7. On top of these, if you give a closer look at what the W3C is issuing, it is merely to transform the base 64 encoding of binary payload embedded in XML to an external SOAP attachment format.

    See : http://jroller.com/page/design4speed/20050207#w3c_aims_at_reducing_bandwidth

    It will at most reduce by 33% the size of a very specific kind of payload. I am unsure if it can help Franck's customers.
  8. Base 64 binary[ Go to top ]

    Thanks for the pointer to the attachments encoding being proposed. I'll take a look. -Frank
  9. On top of these, if you give a closer look at what the W3C is issuing, it is merely to transform the base 64 encoding of binary payload embedded in XML to an external SOAP attachment format. ... It will at most reduce by 33% the size of a very specific kind of payload. I am unsure if it can help Franck's customers.

    Either text or binary documents can be zip compressed, if bandwidth were a problem. I suspect in many cases zipping would shrink better than the W3C's base64 hack. But the two tricks likely work well together.

    But I don't think the base64 was the only proposed optimization. The press release said that XML InfoSet will have binary serialization. That could be very significant. It could give XML an information density on the wire that's greater than IIOP's density. It could finally kill CORBA. Imagine a binary InfoSet that's memory mapped to a C struct. How's CORBA gonna compete with that for performance and convenience?
  10. Either text or binary documents can be zip compressed, if bandwidth were a problem. I suspect in many cases zipping would shrink better than the W3C's base64 hack. But the two tricks likely work well together.But I don't think the base64 was the only proposed optimization. The press release said that XML InfoSet will have binary serialization. That could be very significant. It could give XML an information density on the wire that's greater than IIOP's density. It could finally kill CORBA. Imagine a binary InfoSet that's memory mapped to a C struct. How's CORBA gonna compete with that for performance and convenience?

    Er, can you tell me how the problem of binary number representation is to be solved? AFAIK, the only REAL solution is RPC/XDR or IIOP/XDR, and they are FAST.

    Binary serialization works well only if both endpoints use the same processor, or both endpoints are Java Virtual Machines. Of course Sun or Intel would be very happy if this solution was chosen as standard. Too bad it is not an OPEN solution, since it implies vendor lock-in or technology lock-in, which is the exact opposite of what the W3C promised to end users.
  11. Correction[ Go to top ]

    Hmm, I found a link elsewhere in the topic. It appears Sun is sponsoring introduction of ASN.1 in the protocol stack, again. Knowing Sun engineers' ideas, that means XDR will play a role somewhat. So it could work, after all. Tough that would NOT perform better than CORBA, only be more human-readable.

    However, I am still VERY unconvinced that W3C will come out with a usable specification before customers become tired and throw the entire WS stuff out of the window. If you read between the lines, Joe Keller started the article stating that "web services standards have arrived at a crossroads between success and failure". Looks like he has some doubts left, too ;)
  12. You XML guys don't know what you want...

    You say everybody since a few years now that the strenght of XML is its "readability", that's why CORBA sucks, etc.
    What's the point now in XML if it's binary and one can't debug it easily (lol) ?

    Describing things in WSDL, compiling stubs and implementing servers, using binary marshalling, developping standardized Common Services... This *is* CORBA mates, why don't you try to join a real common effort instead of giving your time and money to big software vendors ?
    Or work in firewall companies to let CORBA pass through and stop this endless discussions :-)

    Cheers

    Remi
  13. This *is* CORBA mates, why don't you try to join a real common effort instead of giving your time and money to big software vendors ?Or work in firewall companies to let CORBA pass through and stop this endless discussions :-)CheersRemi
    PSYHOLOGY: desire to differentiate from the crowd, ignorance, son-father conflict – childish rebellion, etc.
  14. I dunno if it is really related to the subject, but there it goes anyway:

    http://java.sun.com/developer/technicalArticles/xml/fastinfoset/

    Regards,
    Henrique Steckelberg
  15. It is good to see somebody focused on the performance side.
    I run a blog focused on the general theme of performance in software design :
    http://jroller.com/page/design4speed

    These two new rules are very important, because performance should always be an important part of software design. But may be on top of all these, there should be a last an more general - eighth - rule :
    "Key #8 Use technology for what they are best at"

    May be web service is not the solution to every data transfer problems in Informations Systems.

    If you think about what XML - and therefore web service as transportation layer - is good at you will probably agree it is to:
    > model data that can be layed out differently through XSL transformation. So online presentation and reporting
    > loosely integrate heterogeneous systems, for instance when two companies or two completely different system has to cooperate. This is never a desirable situation from a system integrator perspective, but usually something that is required by legacy. I mean nobody should seek this situation because it is intrinsically problematic for performance reason.
    > ease complex structured data manipulation

    According to my experience, XML is poor at is :
    > transport large quantity of data, because of its intrinsic verbosity. Compression is a bypass that cost CPU both side : why not use a better, simpler and more suited format for large quantity of data ? (simple flat files, database replication systems, etc.)
    > allow tight integration of systems for the amount of semantic required always has side effect in the effectiveness of integration.

    It is true XML is a highly addictive way of designing. XML architecture can be very pleasant for programmers. They are also more and more appealing to managers. But they can't solve all the issue.

    Technologies should be used wisely and in regard of their efficiency . They should be solution to problems, not the cause of new problems. Everybody should be cautious when one solution seems to solve too many problems. This is not restricted to software ...
  16. IMHO the larget part of the problem is the dominance of SOAP as the WS transport. SOAP is highly RPC oriented and (even when you try to resist) tends to undermine good WS design & utilisation of the strengths of XML (unfortunately I can't switch the the plain HTTP binding for WSDL because nobody else uses it). But I'm looking foward to JAX-RPC 2 anyway ;-)

    One of the posters made the point about using a technology for it's strong points. I'd add another point to the list.
    I feel there is a architectural paradigm associated with 'good' web services that is quite beneficial to system architecture and web service design - a web service should be as far as possible stateless - ie operations should either query a consistent state or transition from one state to another. This implies that such an operation will correspond to a whole use case, and that the message will fully describe the operation (context complete).
    Even for a simple client app, where the same team is developing both sides this structuring provides a number of benefits:
    Client code is concerned only with constructing actions
    Server code has complete control of implementing actions
    Transactional awareness is restricted to the server
    Security enforced on these operations has complete information to work with.
    While these benefits are related to the design, not to the use of WS, their use has few problems (for this pattern), and reenforces the pattern.
  17. ... cause I'm scared of what is behind !
    :-)

    Hi folks,

    Let me add my 0.02$ please ! Chill moments like this are rare these days, I have to jump on it :-)

    I quote : "Openly debated and scrutinized by truly transparent, inclusive and democratic institutions dedicated to developing "open" standards"

    This must be a joke. Openness is something far away from M$'s and Sun's tactics IMHO. M$ has proven it many times, and Sun does too (they do not seem to be ready to open Java itself) ! This makes an evident clue that these organisations are not aimed at enhancing mankind...

    I'd rather turn to ISO or OMG when it comes to *standards*... W3C has put so much silly things on the table last times (XML everywhere, layers on top of other layers for doing things that the web was not created for... just like using a car to reach the moon) !!!
    Isn't ISO STEP technically better than XML when it comes to modelling data ?
    Isn't CORBA technically better when it comes to distributing programs ?
    It's not really hard to find technical arguments there, but nobody talks about what's actually working. Looks like there is nothing interesting there, they prefer reinventing it... Everybody talked about EJBs and the transactions there... Remember OTS ? Well, there's no EJBs without OTS... and there's many other examples like this !

    So, finally, what's that "standard" they talk about ? Why don't they join OMG or other consortiums and try to leverage existing, proven and useful technos instead of reinventing that thing ? Must be a question of "fashion"... Or economics... It can't be reasonable :-)
     
    I was in this discussion "OMG vs W3C-and-other-big-players-of-WebServices" yesterday (this must be why I'm reacting now !)... and we came to the conclusion that a standard *needs* time to mature. And I don't think Sun, IBM or M$ has time to spend there. I think they want to put drive the standardization process so that they make direct profit from it... but we already know that does not work (that's why Research is usually more in the public sector than in private companies for example). You can't make a real, efficient standard, if your only expectation is a direct ROI in terms of $.
    For example, CORBA has proven its power only after lots of people has spent time , it's been criticised for so long because it was complex (hey, have you ever seen a "simple" distributed system ??? I don't !), and now a few buzzwords are supposed to solve all our problems ? Well, sounds... faaake !

    "Royalty free -- Companies should be able to charge for their implementations or other value around test kits to cover their costs. "

    When will M$ or Sun provide real open source ? This is one of the biggest bullshit I've ever heard from such a company... Right at the opposite of their decisions actually !
    Give WebSphere for free ! No worries, we'll ask for configuration, you'll still make money, that's Open Source, dudes :-P


    "Interoperability tests are helpful, but they leave aside the issue of whether an application will work on multiple implementations of a given API."

    Ahem, next step is to re-invent CORBA's POA for Web Services !!!
    :-P


    "Free-Standing -- Standards should be free-standing in that they don’t reference other specs that are proprietary or outside of the same standards effort. "

    Wasn't that... obvious ?

    Last but not least, it misses one or two things that are important (at least for me) : "Object Orientation" and real "Interoperable Services".
    Until it goes to a CORBA clone with XML/HTTP instead of IIOP and WSDL as IDL (that's precisely what's happening yet. What for ? I don't know !), Web Services will still be more or less deguised plain procedural stuff to me... And that's a quite a step backwards in distributed computing !

    Cheers

    Remi
  18. I'd rather turn to ISO or OMG when it comes to *standards* ... Isn't CORBA technically better when it comes to distributing programs?

    Regardin' tunellin', CORBA's XIOP can reach anywhere SOAP can. But of course with CORBA you're sadly stuck with IDL, which is less expressive than WSDL+XSD. With CORBA the data validation is mostly done by hand-coded procedures, a time consuming and error prone way.

    To me it makes CORBA seem an economic waste since I can't say directly in the interface definition that phone numbers can have 10 or 7 digits, but not 8 or 9 digits. It's also harder for a CORBA user to know why his requests fail. With XML Schema validation, a developer can diagnose an invalid document in a quick and standard way.

    A web service author can validate client requests when the server isn't running. He can validate his client before the server is developed. And his team might first agree on a set of example XML document instances that could then be used for Test Driven Design. Web service is simply more scientific than CORBA.
  19. Back to stone age...[ Go to top ]

    Regardin' tunellin', CORBA's XIOP can reach anywhere SOAP can.

    True... But isn't this hectic ??? Having to write tunnelling software instead of... opening a port on a firewall !!
    Must be another way to sell software I guess :-)
    But of course with CORBA you're sadly stuck with IDL, which is less expressive than WSDL+XSD.
    Ahem. I don't think you can actually compare both. You talk me about representing data... and I'm into objects !
    Your digits example is, to an OO folk like me, kindda ugly : this is behavior, please keep it away from the state...
    With CORBA the data validation is mostly done by hand-coded procedures, a time consuming and error prone
    way.

    Well, develop a validator, once for all, and use it. That's what XSD-and-the-tools does for you actually...
    To me it makes CORBA seem an economic waste since I can't say directly in the interface definition that phone numbers can have 10 or 7 digits, but not 8 or 9 digits.

    Once again, you forget a lot about objects... In a CORBA object, the *accessors* (get/set) may do the validation you talk about in a transparent way. The formatting of the object's properties in part of the object's contract.
    Of course it's hard to figure this out when you think in XML, but this may be why you don't seem to appreciate the CORBA approach : this is OO mate :-)

    Actually your vision of web services is limited to the exchange of data. Well, compare it with ISO STEP then... and forget all the damn XML : we have better things to model data and exchange it !
    Models of airplanes, satellites, boats, cars, etc. are *not* exchanged using XML...
    It's also harder for a CORBA user to know why his requests fail. With XML Schema validation, a developer can diagnose an invalid document in a quick and standard way.

    Ever heard about compilers and static type checking (which is inexistant in SOAP - implemented by WSDL) ?
    IDL is *compiled* ! Validation is an implicit concept there... Either it compiles, either you have a typing error... You know, just like when you compile Java code...
    A web service author can validate client requests when the server isn't running.

    This may be the only benefit of XML, but please re-read the pointed article : they plan to use binary transmissions... for perf. reasons !!! This breaks down the 'S' for Simple in SOAP (another fake argument that SOAP defenders put on the table since the beginning).
    He can validate his client before the server is developed.

    Well, I usually think more about the *model*. And anyway writing hard-coded CORBA objects for testing is, to me, much better than trying to design in XML !
    And his team might first agree on a set of example XML document instances that could then be used for Test Driven Design.

    I'd rather call it "XML Driven Design" ! I'm more into UML, sorry... I won't start an explanation now, would be too long, but the "M" in UML is for "Modelling".
    XML is cool for deployment descriptors, OK, but IMHO it shouldn't be the foundation for your model.

    Anyway, the situation is :

    Embedded software in the planes you fly with is *not*
    WS-based...
    Your bank has *not* relied on SOAP for its middleware...
    Financial places neither...

    Well, can you tell me why all these industrials who run mission-critical applications have not chosen XML, WebServices and such things ?
    My opinion is that they don't care about the "mood".
    They don't want to be "trendy" and have nice articles in magazines targeted at IT managers... They want the software to *work* and to be *cost-effective*. They choose appropriate technologies.
    Web service is simply more scientific than CORBA.

    Economics and marketing *are* science. You even seem to be a living proof of concept : it actually works :-)

    Cheers

    Remi

    PS :
    I'm not an OMG member, I don't have participations in CORBA... I only try to be objective.
    If you want to know more abouit the CORBA/SOAP war, please have a look at this :
    http://www.xs4all.nl/~irmen/comp/CORBA_vs_SOAP.html
    It's old... but it's damn true :-)
  20. IMHO there is only one factor: data and class interoperability. If nobody standardizes how data and classes are represented, web services are just another transport protocol.... it's not a great result, isn't it? And definitely nothing I was miss...

    Stefano
  21. IMHO there is only one factor: data and class interoperability. If nobody standardizes how data and classes are represented, web services are just another transport protocol.... it's not a great result, isn't it? And definitely nothing I was miss...Stefano

    Well... If "Data and Class Interoperability" is your definition of "Heterogeneous Distributed Objects", then CORBA is the answer.

    It clearly has no opponent in the distributed objects battle.

    Cheers

    Remi
  22. IMHO there is only one factor: data and class interoperability. If nobody standardizes how data and classes are represented, web services are just another transport protocol...

    Web services can exchange scripts (JavaScript, bash, Python, interpreted C++, Groovy, Ant, etc). ECMAScript is an ISO standard for class interoperability. ECMAScript is Turing complete, which means that any Java class can be encoded as ECMAScript. ECMAScript can be run in a JRE, CLR, IE, and Mozilla -- practically universal. Many W3C standards mention JavaScript, and most of them also declare JavaScript bindings. I think I read that there's now a reusable SOAP stub for JavaScript.
  23. Poor CORBA guys...[ Go to top ]

    You didn't get one of the beauties of web services : you don't deal with objects. You deal with
  24. Poor CORBA guys...[ Go to top ]

    You didn't get one of the beauties of web services : you don't deal with objects. You deal with a service. You don't have to know if this service is delivered to you by a specific object instance on a server or by thousands of computers working in a server farm. It looks the same to you client.

    CORBA guys say that data validation is possible, understandable error checking is possible, everything is possible with CORBA. But there is no standard and easy way to do it, so most people don't do it ; web services toolkits provide you with all these functionalities out of the box, which makes you that much more productive. Maybe you should go back to programming in assembly, you'd be able to better optimize your code.

    About financial companies and all, of course they don't use web services for their back ends. They usually spend several years of development on these kinfs od projects, web services specifications change every six months ! I've seen myself many big J2EE project failing to replace legacy banking systems based on mainframes, because the this technology too changes too much. You try to solve problems at the beginning of the project, and you realize that the solution you spent one year developping is standard in the new version... These kind of project need stable technologies, and web services are not yet stable. But that's not to say it's not a good technology. CORBA was not stable back in the time, but it got there.

    Like it or not, web services are here to stay. They are not a "one size fits all" solution, since no such solution exist, but they are very good for many things. They're precisely very good in several places where CORBA was the only choice. Too bad for guys who have spent ten years learning and mastering CORBA, the biggest software companies in the world (IBM, Sun, Microsoft) are pushing web services forward, and they'll get unemployed.

    But don't worry, when we will all have mastered a stable version of web services, these fine companies will come up with something new :)
  25. Poor CORBA guys...[ Go to top ]

    Well, yet another strange reply...

    First of all, I'd like to know, please tell me what "beauty" you can find in going back from OOP to plain procedural stuff (looks like there's a wind of anti-OOP rebellion in the area ! :-) )
    Do you realize that without OOP you don't have COP (or very limited, ADA folks please quiet lol) ?
    Do you realize COP is the basis of (more or less) 99% of the libraries and frameworks you're using everyday ?
    Have you thought about building really reusable, extensible code, at a high abstraction level, with a procedural approach ?

    Also, I don't understand your point : you seem to be in contradiction with yourself ! You say (I quote) "They are not a "one size fits all" solution", and on the ohter hand you think that CORBA skills don't have their place in the market and CORBA people will "get unemployed" (lol, btw) !!! Don't you think there's something like a paradox there ?

    Last but not least : you're getting out of scope. I don't want to get into yet another CORBA/SOAP war, both don't play in the same category anyway, and explaining takes much more time than I actually have...
    My point was about the "5 keys", and I just wanted to stressed the fact that one should trust real standards instead of trusting M$ and IBM. You seem to confirm my feeling (I quote) : "web services specifications change every six months". Do you really want to *bind* yourself to an unstable *spec* and moreover with *code* (web services are not portable server code, as you may know) ?
    Also, what you don't seem to realize is that they are coming closer and closer to the CORBA spec... You know, transactions, security... Well, things that makes software actually work and need even more time to mature :-P
    So IMHO there's a high probability that, at the end of the Web Services "mood", the bubble will simply explode, just like .dom did a few years ago ! The conclusion then should be like "well, finally it's bullshit" :-)
    Once again, you seem to confirm (I quote) : "don't worry, when we will all have mastered a stable version of web services, these fine companies will come up with something new".
    So you're about to admit you have time to loose in trying silly technologies, knowing that they have no future and you can't rely on it for more than 6 months...

    That's quite far away of my views about software engineering actually (lol), but I guess you gave me another clue : this must be how they make money :-D

    One good thing though : maybe, when you'll really need your software to work, you'll call a "CORBA (or yet-another-thing -that-works-but-nobody-talks-about-'cause-it's-no-fashion) guy" to solve your problem... could be me ! Cool, we may have interesting chills at coffee break :-)

    Thanks a lot for this relaxing moment,

    Cheers

    Remi
  26. Poor CORBA guys...[ Go to top ]

    You didn't get one of the beauties of web services : you don't deal with objects.

    Well, the comments recently posted in reply to Richard Mansfield's article "OOP is much better in theory than in practice" constitute an easy example of the general consensus theories like "objectless is better than object-oriented" can find on this forum. Though anyone is still free to keep his opinion, I consider your statement incorrect: objectless is not beautiful, it is just another way of doing things.
    You try to solve problems at the beginning of the project, and you realize that the solution you spent one year developping is standard in the new version... These kind of project need stable technologies, and web services are not yet stable. But that's not to say it's not a good technology. CORBA was not stable back in the time, but it got there.

    Well, I agree 100% with you, this time. I experienced exactly this with CORBA security standards back in 1999: we had to handcraft a solution that was similar, but not equal, to a standard that OMG was still to consolidate (CSIv2).
    Like it or not, web services are here to stay.

    Hmmm......

    Have been listening to analysts that state "they could be not so successful as initially thought" for the last two years. Whose crystal ball is more correct? Time has the answer.
    They're precisely very good in several places where CORBA was the only choice.

    Hard to believe. First of all, DCOM was another (MS-sponsored) solution that could handle the same situations.

    Second, as you pointed out, where you have to deal with objects and statet, web services are useless, or at least clumsy. And please avoid the usual "we don't need no state" reply. As widely discussed in other threads, there are situations where you need a stateful, distributed solution. Telco is one of the case, and CORBA still rules there (unlike Entity EJBs...)
    Too bad for guys who have spent ten years learning and mastering CORBA, the biggest software companies in the world (IBM, Sun, Microsoft) are pushing web services forward, and they'll get unemployed.

    Really? I have some 300 days' worth of work scheduled for 2005 (including some to be spent on reviving the old 1999 CORBA project after no one had come out with a convincing WS alternative since 2001). Is that what you call unemployment? Unemployed I would be had I bet my career on XML, instead.

    Lets's just say that guys who mastered CORBA tended to look a bit too downwards to other developers who did not. This was a mistake I myself have made, but this does not mean that we deserve the same treatment now that CORBA is no longer a buzzword. Good developers like technology improvements, not buzzwords.
    But don't worry, when we will all have mastered a stable version of web services, these fine companies will come up with something new :)

    I fear THIS is the year this will happen....
  27. Poor CORBA guys...[ Go to top ]

    Well, I agree 100% with you, this time. I experienced exactly this with CORBA security standards back in 1999: we had to handcraft a solution that was similar, but not equal, to a standard that OMG was still to consolidate (CSIv2).

    Well then you may have participated in OMG's joint effort for liberation of distributed objects :-)
    You know how it is : working things take time to mature, and the OMG is not very fast.
    But, finally, is this really a problem ? I mean, if your "stuff" (and what a stuff is CSi !) was very close to the OMG standard itself, that's a guarantee that :
    1/ you did a good job (several brains came to the same conclusions)
    2/ you'll be able to better re-use everything (e.g. plug another sec service under your layer with less impact)

    So it may have been hard at first sight ("gee we worked for nothing"), but on the other hand isn't that better than a radical change like M$'s uses to do ?
    Hmmm......Have been listening to analysts that state "they could be not so successful as initially thought" for the last two years.

    Well, this is obvious. And I'm not that "super CORBA guru" believe me I don't feel like a design god. But honestly, this is too big, I can't understand why they all spend all this time and money there...
    First of all, DCOM was another (MS-sponsored) solution that could handle the same situations.

    Yep. And it was already far better than SOAP ! Wasn't as powerful as CORBA, but the idea wasn't so bad. At least it fulfilled the its requirements. But once again, M$ changed everything and now it's .NET time so send you DCOM code to trash and start again. CORBA guys have compat (almost) from 1.0, which is around 95 if I remember. Isn't that beautiful ? :-P
    Second, as you pointed out, where you have to deal with objects and state, web services are useless, or at least clumsy.

    Well, EJB and Web Services people don't seem to be particularly attached to state (except under the format of an XML document lol).
    And finally, why using CORBA for what they call "stateless services" ? Who can do more can do less, and passing structs to a simple CORBA object is never more complicated than using SOAP.
    Really? I have some 300 days' worth of work scheduled for 2005 (including some to be spent on reviving the old 1999 CORBA project after no one had come out with a convincing WS alternative since 2001).

    Well, don't hesistate to contact me if you've got overwork... I dreamt that Web Services were about to get my job :-P
    Is that what you call unemployment? Unemployed I would be had I bet my career on XML, instead.

    No, you could still write books and articles in magazines. This makes money apparently !
    Lets's just say that guys who mastered CORBA tended to look a bit too downwards to other developers who did not. This was a mistake I myself have made, but this does not mean that we deserve the same treatment now that CORBA is no longer a buzzword. Good developers like technology improvements, not buzzwords.

    Fully agreed. But you know, CORBA is addictive, and it's so nice you'd like it to be everywhere... You just can't understand this Web Services wind if you experienced CORBA ! All this just because of that damn port 80 ! I can't believe it...
    I fear THIS is the year this will happen....

    Hmmmm, there must be a few dollars left to pick up for IBM and M$. I'd personnally bet on next year. A beer on the table ?
    :-)

    Cheers

    Remi
  28. Poor CORBA guys...[ Go to top ]

    Remi

    This thread is supposed to be about web services ;)

    Bet of a beer agreed (so far as we live in the same continent). I hope all posters who are pro-WS and anti-CORBA will not show up to claim their beer if the WS bubble do not actually explode, though. I suppose there are too many of them for my finances to handle.

    Cheers,
  29. Poor CORBA guys...[ Go to top ]

    This thread is supposed to be about web services ;)

    CORBA is web/net/whatever SERVICE and much more. Much better than anything else out there.

    There are just way too many people want to eat and do invent ways to inhibit productivity and real progress(port 80 stupidity is one example)
  30. Poor CORBA guys...[ Go to top ]

    RemiThis thread is supposed to be about web services ;)

    You are right. Just could not resist to the temptation.
    Bet of a beer agreed (so far as we live in the same continent).

    OK, I'll try to remember !
    For the beer itself, here's an info : I'm on the good continent. My ancestors even had the best beer of the world (and *this* can't be discussed :-))) ), ya know, the old monks in a flat rainy little country...
    I hope all posters who are pro-WS and anti-CORBA will not show up to claim their beer if the WS bubble do not actually explode, though. I suppose there are too many of them for my finances to handle.

    LOL !! On the other hand, we may get severely drunk if it explodes... Either bankrupted, either overdosed...
    This bet was rather silly, sorry mate, I should have shut my big mouth once again :-)

    Have fun

    Remi
  31. Poor CORBA guys...[ Go to top ]

    I can't understand why they all spend all this time and money there...

    Very simply: we increase productivity and unemployment goes up. Those money are end up as someone’s salary…
  32. Poor CORBA guys...[ Go to top ]

    I didn't mean that objects are bad. I use OOP myself in each and every project I make, and I like it. But I don't think binding your distributed service to an object is always the best way to go. If you link the service with your executable, it sure is the best way ; if you call the service from near (same network), it's probably the best way (though it's not always the case) ; if you call it from far away (through the internet for example), it's probably not the best way (though it's not always the case). Once again, if I want to propose a service to unknown customers from eveywhere, I want the least coupling I can get, and that's the concept of web services.

    Moreover, I don't see why web services can't support stateful operations. A SOAP header and message signing (if needed) will do the trick, if you need state. Hey, you even can call the same object if you like :-p

    There's no contradiction when I say there's no "one size fits all" solution and that many CORBA guys will get unemployed. Can't you imagine that some of the CORBA projects will switch to provide web services frontends, and some will not, because web services is not the good choice for them ? That will get CORBA guys unemployed, but not all of them. But maybe your world is white and black, or binary, (0 or 1), like CORBA...

    Maybe you're a lone genius, and you will be right against all the industry. But I still haven't seen Microsoft betting the farm on the wrong technology (though sometimes they have been slow to go all out attack, as with IE), so when they spend that much money in something, I have the tendancy to think it's not a completely stupid choice.
  33. Poor CORBA guys...[ Go to top ]

    Maybe you're a lone genius, and you will be right against all the industry.
    Well geniuses are always alone...it is something to meditate upon.
    But I still haven't seen Microsoft betting the farm on the wrong technology (though sometimes they have been slow to go all out attack, as with IE), so when they spend that much money in something, I have the tendancy to think it's not a completely stupid choice.
    Check out Joel’s “Fire and Motion”
    http://www.joelonsoftware.com/articles/fog0000000339.html and you may rethink what MS strategy means…
  34. Poor CORBA guys...[ Go to top ]

    Moreover, I don't see why web services can't support stateful operations. A SOAP header and message signing (if needed) will do the trick, if you need state. Hey, you even can call the same object if you like :-p

    Sure, I can. By using a technique that I use to call "having the application do what the middleware should be doing". Which is considered a very bad practice by most architects / developers.

    As for the rest, I did not want to propose a black&white vision of the IT world more than you wanted. I am currently doing much more WS-oriented work than CORBA, of course, and there are areas where XML is much more useful than IDL. But please look at your original posting, and acknowledge that it looked "a bit biased" towards the current "Web services rule" overemphasis.
  35. Poor CORBA guys...[ Go to top ]

    I didn't mean that objects are bad.

    True. You only said more or less that they were useless...
    I use OOP myself in each and every project I make, and I like it.

    Then, my only advice is "try CORBA" :-)
    Honestly, I've had this talk with several persons, and they first had the same "views" than you. Too heavy, too complex, too much !!! They changed their mind once they tried it.
    Actually you should simply take a few days to investigate IMHO, and you may come back then with another vision.
    Can't you imagine that some of the CORBA projects will switch to provide web services frontends, and some will not, because web services is not the good choice for them ?

    That's exactly what's happening in most of the cases. This can be a good choice if, as you say, you simply have to "wrap an exe" into some remotely available service. But actually distributed systems require a bit more sometimes :-)
    But maybe your world is white and black,

    I wouldn't even spend time talking then mate...
    Moreover I told you that XML was cool for DDs, so, you should be happy with that ! I'm not an integrist LOL :-)
    or binary, (0 or 1), like CORBA...

    Well, you miss it once again. CORBA's all about interfaces, objects, polymorphism, meta-description... It's not a story about <tag>s or dummy hacks...
    Try it...
    You won't get back...
    :-)
    Maybe you're a lone genius,

    I wish I was, but when I wake up in the morning I sadly remember : I'm a human. And not the best model in the catalog apparently. Feck. :-)
    No, I've only been designing and coding for a while now. And been disappointed several times with changes in the technology. Enough to learn that standards matter !
    and you will be right against all the industry.

    Well your vision of the industry is once again very restrictive. CORBA's been accepted for a while in the "industry", and it's there to stay believe it or not. The future of Web Services (if you consider it's been really working as a stable, open, "democratic" standard some day) is not so clear...
    Also, there are lots of areas where you actually can choose. My point is just about avoiding a bad choice that you'd regret later on. And this kind of mistakes has a (big) price.
    But I still haven't seen Microsoft betting the farm on the wrong technology

    Huuu... really ?
    I personnally know a few disappointed users.
    :-)
    so when they spend that much money in something, I have the tendancy to think it's not a completely stupid choice.

    Never said they were stupid. Just said I would not personnally trust or recommend them ! And certainly not in propotion to the money they spend in something !!!
    Mostly because of omnipresent vendor lock-in (we *know* that now !), because of the cost (hey, we have so much for free now why would I give them money, even more to develop server-side applications ???) and the politics. I don't like too much the idea of giving $ to people who destroy great ideas and projects like they did in the past, and so giving them the keys to standardization processes is somewhat dangerous IMHO.

    Have fun

    Cheers

    Remi
  36. Web Services In Data Synchronization[ Go to top ]

    I was looking at http://www.webservicespipeline.com online magazine and came up with a product called NineSYNC by Jence Incorporated. This is an interesting product. This software company (NineSTEP) is using web services to synchronize and map databases and files of two machines. You can download a demo of this product from the company's site http://www.ninestep.com.

    What I really find interesting about NineSYNC that it you may not have to worry about using your PC for synchronization any more. NineSYNC runs in a server and all you need to do is tell NineSYNC where on the internet your database or files are and where on the Internet you would like to put them. Then NineSYNC will do it for you periodically.

    I think many similar applications will come out like this, where the dependency on PC will gradually go down.

    Wien.