Loading ...
Sorry, an error occurred while loading the content.

Re: [service-orientated-architecture] Platforms for SOA

Expand Messages
  • Anne Thomas Manes
    Please note that the report cited in this article is talking about Java EE, not about Java in general. Burton Group predicts that Java will remain strong and
    Message 1 of 36 , Aug 1, 2006
      Please note that the report cited in this article is talking about Java EE, not about Java in general. Burton Group predicts that Java will remain strong and healthy for a long time.

      Our view is that the Java EE specification has become excessively bloated with a ton of stuff that the average enterprise application just doesn't need. Rather than adopting an 80/20 approach -- in which the standard platform provides everything you need to support 80% of all enterprise applications, with a reasonable set of extensions that supports the high-end 20%, the minimal Java EE platform is designed to support the high-end 20%. As a result, the platform is simply too complex. Even if you just want to build a simple app, you have to be aware of all this high-end stuff. That's the reason that the open source communty has developed so many "rebel" frameworks -- systems that run on J2SE, or perhaps in a servlet engine --typically much easier to work with than the full Java EE environment.

      One of the primary goals of the JEE5 release was to reduce the complexity of the platform, but in our perspective, the JCP/Sun failed to deliver on this goal. The use of metadata reduces the amount of boiler-plate code that a developer needs to include in a class, but it really doesn't reduce complexity. The metadata has just as many possible settings as the configuration files of old. JEE5 has simply shifted the complexity from config files to metadata. And, of course, the configuration files haven't gone away. The responsibility of managing both metadata and config files has actually increased complexity.


      We were really hoping that JEE5 would improve the situation. We're very disappointed.


      On 7/31/06, Gervas Douglas < gervas.douglas@...> wrote:

      <<In the late 1990s, Microsoft executives bashed the Java platform at
      every opportunity, but now SOA and Web services has changed that
      hostility to benign neglect, said Greg DeMichellie, an analyst with
      Directions on Microsoft.

      "Their 'war with Java' is over," he said.

      So it was perhaps not surprising that in the midst of the controversy
      over the viability of the Java EE platform, Prashant Sridharan, group
      product manger of Visual Studio at Microsoft, said, "I don't like to
      comment on competitors directly. I like to take the high road."

      DeMichellie said this is a good public relations strategy, following
      the old political advice to stay out of the way when your opponent
      appears to be on a self-destructive path.

      Sridharan said he has read articles about the Burton Group report that
      argues that the Java EE platform is dying of its own complexity, but
      has not yet gotten his hands on the actual document titled "JEE5: The
      Beginning of the End of Java EE."

      But the Visual Studio product manager was enthusiastic when told the
      author, Richard Monson-Haefel, senior analyst at Burton, wrote some
      nice things about Microsoft .NET as an alternative to the Java platform.

      The Burton analyst said: "Microsoft's .NET offers a solution that is
      as comprehensive as Java EE, but much easier to develop. The threat of
      .NET is largely enabled by JEE5's failure to address the complexity of
      its common programming model. In contrast, .NET is generally regarded
      as an easier environment to develop applications in, but it is not
      narrowly scoped, as is the case with the rebel frameworks, LAMP and
      [Ruby on Rails]. Instead, the .NET platform can be thought of as a
      direct competitor to Java EE that offers the same level of functionality."

      This is music to Sridharan's ears and validates what he said was the
      investment and work Microsoft have put into building .NET as a
      framework for Web services and SOA.

      "From its inception in 2000," the Microsoft product manager said,
      ".NET was always built on a substrate of Web services and industry
      standard technologies such as SOAP and XML. From the onset, I think we
      understood the importance of service-oriented architecture and the
      importance of Web services, and building out a better communications
      framework than typically existed for Windows applications in the past
      with COM and things of that nature."

      DeMichellie, said it may be a bit of an exaggeration to say the
      Microsoft was focused on SOA with .NET from the beginning, but he said
      the company's ability to start work on .NET from scratch just as Web
      services technology was emerging gives it a leg up of the Java
      platform, which dates back to initial work at Sun Microsystems Inc. in
      the client/server era of the mid-1990s.

      "Microsoft got to erase the board and start over in 2000," he said,
      "and that's a little more recent than Java."

      The failure of Sun and the other vendors who contribute to the Java
      platform through the Java Community Process to "erase the board" as
      SOA replaced older models is what allowed Microsoft to gain an edge on
      its old rival, DeMichelle argues. He also credits IBM, even though its
      WebSphere is based on J2EE, with having the foresight to start from
      scratch with a focus on Web services and SOA.

      "IBM and Microsoft designed whole new systems around Web services, and
      Sun took the same Java that they've been using for other technologies
      and tried to extend it to Web services."

      Analysts may debate who SOA architects and developers will turn to if
      Java EE goes away, but considering that IBM is the founder and major
      sponsor of the Eclipse Foundation, which is now touting itself as a
      platform, DeMichelle's conclusion is not that far from Monson-Haefel,
      who said, "It's going to come down to Microsoft Visual Studio and
      Eclipse, as the two dominant players."

      IBM and other major vendors such as Oracle Corp., which is still in
      the Java EE camp, argue that the Microsoft platform is not ready for
      the high volume transaction applications of large enterprise
      customers, such as investment firms and banks.

      That is the one argument that brings Sridhara at Microsoft back into
      the competitive fray.

      "In the history of Microsoft, our competitors have always tried to
      position us as only good for departmental or small applications," he
      argued. "I don't think that is a case that exists any more. If you do
      an analysis of any application on .NET Framework 2.0 running on
      Windows Server 2003 in a comparable environment versus any J2EE,
      you'll see that our Web services platform is faster than any other Web
      services vendor. It's also capable of handling more transactions and
      larger scale applications than pretty much any other Web services
      platform vendor."

      DeMichelle agreed that this anti-Microsoft argument is not valid. He
      said whatever advantage IBM and Oracle might have in the large
      enterprise application market has nothing to do with their use of the
      Java EE platform. Oracle's advantage, he said, is the power of its
      database technology and IBM has the tradition of serving large
      enterprises that dates back to mainframes running COBOL applications.

      Yet one potential obstacle for Microsoft emerging as the SOA platform
      of choice is whether the Redmond team's products will play well with

      Microsoft's Sridhana said his company has invested time and money to
      ensure that the .NET platform can interact with other technologies.
      "We've developed patterns and practices as well as process guidance
      and methodologies to help people learn best practices in a variety of
      environments whether they are operating in a legacy environment with
      mainframes or with other platforms such as J2EE," he said.

      Dana Gardner, principal analyst at Interarbor Solutions, is right
      there with Burton's Monson-Haefel, in crediting Microsoft with
      creating tools that make Web services development easy, but in a
      recent blog on the Java EE viability controversy, Gardner labeled
      Microsoft's version "pseudo SOA."
      More on .NET, Java and SOA

      Asked to explain what he means, he said, "Increasingly, the best hedge
      that Microsoft has to keeping more developers within its stack is
      simplicity, but simplicity in the Microsoft methodology does not mean
      simplicity for general heterogeneity. That's why I call it pseudo SOA.
      It's SOA within Microsoft, with Web services and enterprise
      integration off-ramps. SOA's great promise is to be both relatively
      simple and generally heterogeneous, neither entirely grounded in .NET
      or JEE."

      DeMichellie didn't accept the pseudo SOA designation, but does agree
      that Microsoft's ubiquitous Windows operating system is somewhat

      "The biggest argument against the Microsoft approach is that it only
      runs on the Microsoft operating system," he said. "If you are an
      organization and you don't want to rely on the Microsoft Windows
      operating system for your key infrastructure, say you really want to
      be on Linux, obviously you're not going to use the .NET Framework.">>

      You can find this at:

      < http://searchvb.techtarget.com/infoCenter/originalContent/0,294292,sid8_gci1204290_iid2657,00.html?track=NL-462&ad=560290&Offer=VBret801simp&asrc=EM_NNL_406562&uid=1082648>


    • Gregg Wonderly
      ... What is interesting is to look at the methods that have been kept and the variation of implementations. In automobiles, its been metal vs plastic for
      Message 36 of 36 , Aug 9, 2006
        Ashley at Metamaxim wrote:
        >>How have cars evolved over time? How much of that original model T is
        >>in todays cars? Do car engineers spend all their time re-using what
        >>they had before or do they sometimes throw out and re-build from scratch?
        > In a recent conversation with Michael Jackson (the software methodologist, not
        > the bizarre guy with the plastic face) he recommended the following book as a
        > good insight into the way engineering evolves:
        > "What Engineers Know and How They Know It" by Walter G. Vincenti.

        What is interesting is to look at the methods that have been kept and the
        variation of implementations.

        In automobiles, its been metal vs plastic for components in the cockpit. Brakes
        have always been about friction, it just the effeciency of that friction thats
        been varied to manage heating. Engines have been about two chief technologies
        with the wankel rotary close behind. There have been countless other
        investigations, but the "it works, let's use it" attitude has prevailed from my

        In airplanes, it's been fiberglass vs wood vs metal for structural makeup. But,
        the same functionality and same basic attributes have been around since the
        early days. Only more recently, has the view of the atmosphere as a fluid
        rather than as "air" shaped the view of how to shape airfoils, wing loadings,
        power ratios etc.

        In software, we've always had ways to distribute work amongst machines. The
        granularity of that work separation has always been slanted toward work that is
        easily separated from a larger task. Only in graphics cards has miniscule
        optimization been used to squeeze out the last bit of performance.

        As SOA becomes the phrase to associate with distributed computing, my interest
        is the focus of MS who had/has no real experience with large scale distributed
        computing. They seem most interested in making it possible to exchange
        information in simple forms, because the task of interworking their environment
        with the flexibility available in all the others (mobile code, corba, simple
        text exchange when there isn't <CR><LF> issues, support for multiple filesystem
        structures and a FileSystem API, etc) was so dramatically different.

        But, in the end, if everyone gets in line with money, that's where the vendors
        will create products. If you vote with your feet and your money for the
        technologies that really work and really scale, you'll of course be in the
        minority, because the majority is not educated or otherwise prepared to make an
        intelligent decision. The majority will make a compromise decision that allows
        them to feel like they've solved the immediate problem. Then, they'll just
        continue on, solving the new set of problems they've bought into.

        Gregg Wonderly
      Your message has been successfully submitted and would be delivered to recipients shortly.