Opinion: Will Longhorn outflank Java rivals?

Discussions

News: Opinion: Will Longhorn outflank Java rivals?

  1. Opinion: Will Longhorn outflank Java rivals? (31 messages)

    A ZDNet article discusses the web services market, and how Microsoft is "attempting to convince customers that its forthcoming operating system will go hand-in-hand with a Web services infrastructure that beats Java offerings". He talks about how Microsoft can't "win" like they did with other consumer projects (Windows, Office).

    "What's more, I don’t know anybody of sane mind who believes that Microsoft's domination in Web services is a foregone conclusion. The fact is that Microsoft's .Net strategy for Web services remains a work in progress. And unlike the market for operating systems (where Windows bested OS/2) or office business apps (when it essentially disposed Lotus, WordPerfect and Borland), the company won't be able to count on its desktop monopoly to guarantee success. Microsoft is lobbying IT managers on the need to upgrade to (the still-delayed) Longhorn operating system, but big corporations are not dumping their J2EE-based systems just because Steve Ballmer says .Net is a grand idea."

    It is nice to read something this week that isn't a love fest for Microsoft via the PDC.

    Read: Will Longhorn outflank Java rivals?

    Threaded Messages (31)

  2. Risky, Interesting Indigo[ Go to top ]

    Hi,

    The Longhorn stack appears to be Avalon for client and presentation -> Indigo services/business layer -> WinFS resource layer, with a cross-cutting tools layer. Picking out just one of those, Indigo, reveals some interesting risks. At runtime its services are (theoretically) perfectly compatible with web services deployed in J2EE and in other technologies, or with existing J2EE apps that expose facades behind new service endpoints, as once the Indigo metadata is resolved aspects such as policy assertions and reliable messaging are ultimately SOAP-based (regardless of the actual transport) managed through WS-* standards (as far as I can tell).

    The interesting and risky thing is that classic distributed RPC -- including the half-released .NET Remoting, and including DCOM, etc., like EJB and CORBA, and including even in-process invocations of local services -- appear to be implementation details to Indigo, and the top-level framework and API is now entirely message-based and service-oriented. Service Oriented Architecture and the aggregation of business processes subsumes all other distributed APIs at the highest level. Such a thing is possible in J2EE, certainly, and some truly smart folks in the TSS community have created such designs. But at its specified basics, J2EE relies on more of a singly-deployed enterprise app unit composed of collected web, business, and resource artifacts. Each single app has a web tier, has a business tier, and has a resource tier, where the tiers are very seldom shared with other apps. At its basis, Indigo appears to be a more organic means of aggregating services that may not be developed or deployed at the same time, and it assumes the asynchronous behaviors, federated trust relationships, etc. that go along with that.

    Aside from adding a super model atop classic distributed programming, and introducing new deployment and management to go along with that, it's also fairly risky in that Indigo is still apparently 2-3 years away. Even though its services may interoperate with J2EE and other platforms, Indigo itself is still based on a single platform (Longhorn) that may be released in 2006 meaning it probably won't be widely available even in the Windows world until 2008 or so -- so much time and so much risk that even though the model is interesting and even attractive, I can't possibly see how it can make an end run around J2EE unless a lot of smart folks at BEA, IBM, Apache, JBoss, Sun, Oracle, etc. fall asleep at the wheel. Of course this says nothing about the other layers -- Avalon being basically a rich DirectX web client generated through markup, and WinFS being a full-blown database as the file system -- which are interesting and risky in their own right, and warrant different sorts of J2EE discussions.

    Here's a link to Don Box's fairly strong summary of Indigo: http://msdn.microsoft.com/longhorn/default.aspx?pull=/msdnmag/issues/04/01/Indigo/default.aspx

    -psn
  3. Risky, Interesting Indigo[ Go to top ]

    My understanding is that Indigo will be available as an "add-on" to Windows XP and Windows Server 2003 in 2004.
  4. Risky, Interesting Indigo[ Go to top ]

    Indigo looks equivalent to MDB(message driven beans)
  5. Risky, Interesting Indigo[ Go to top ]

    Indigo looks equivalent to MDB(message driven beans)

    But with so much more value added. Can a client discover what message beans are online at a J2EE shop? Are message beans encouraged to form federations, establish standardized specialties within the federation, and then delegate to eachother according to specialty? Do message beans support single sign on between isolated enterprise applications?
  6. Risky, Interesting Indigo[ Go to top ]

    Sean - interesting stuff. Do you know if choosing part of the MS stack requires choosing the whole stack? For example, if an MS user wants to use Indigo, would the only sensible thing be to then use Avalon and WinFS? And if Avalon is generating DirectX code... I haven't checked on this in awhile, but I assume that's going to require IE on the desktop? I haven't looked at WinFS, but it would seem that the plethora of solutions for the resource layer in Java is pretty tough competition.

    My point is that Indigo seems like it's meant to be the most compelling part of the stack. But since its main focus is delivering web services, what it can achieve is limited to what the standards allow it to achieve, especially in terms of transactions, security, and asynch messaging. Those sorts of things are featured by many Java vendors already, though MS would never say that since Sun doesn't have an official spec for it. I just don't seem the slam dunk here for MS, other than they'll most likely have a nice tool for doing stuff.

    Rob
  7. Risky, Interesting Indigo[ Go to top ]

    Hi Rob,

    Based on limited exposure to the specifics but familiarity with the model, I do not think that you need to buy into the entire stack in order to access or even build Indigo services. I can imagine J2EE-based services rendering Avalon front ends perhaps using a thin Indigo service intermediary or Avalon proxy, and on the other hand I can also imagine Indigo services being accessed by a classic JSP-based web tier that renders HTML in a browser. I can imagine a Data Access Object that uses connectors to allow J2EE services to reach into WinFS. There are alternatives to Avalon/XAML for rendering rich clients for J2EE in an equally stunning but more cross-platform manner (it's hard to avoid going into vendor mode and talking about Macromedia Royale here, but in an effort to stay objective I could also point out XUL and SVG), but it's certainly true that .NET Windows Forms can make a decent front end to J2EE today and I don't think this is a trend that's likely to disappear when Longhorn eventually emerges.

    -psn
  8. It is nice to read something this week that isn't a love fest for Microsoft via

    > the PDC.

     Allow me to point out two XUL News Wire story about Microsoft's latest XAML "innvoation" unveiled at the PDC Dev Pow Wow love-in titled "XAML In Action: A Closer Look At Microsoft's XUL Rip-Off" and "Mozilla XUL Gurus Dissect Microsoft XUL Knock-Off".

      - Gerald
  9. Is it possible that somebody will be able to define an XSLT stylesheet that allows UIs to be written in XUL to be dynamically translated into XAML, or are there semantic differences that make this unlikely?

    JWS
  10. I may be totally wrong but it seems like XUL is pretty close to XAML in syntax but XAML elements are all also C# classes so you can work in XML or code or both roundtrip, and also does XUL render to a vector graphics layer that abstracts hardware graphics or is it confined to the components in the Mozilla DOM only, and what type of content extensibility is exposed in XUL, because from reading it looks like the XAML client is pretty extensible there? And does XUL handle Schema or just RDF for data binding? Maybe there are small differences between XAML and XUL and the real differences are between Mozilla and the Longhorn browser or client? I am probably sounding ignorant about both but these are important questions. Also, is XAML and its compiler free, baked into an IDE, or what, and are there IDE plugins or tools for XUL that can let XUL publish to something more widely used than Mozilla?
  11. does XUL render to a vector graphics layer that abstracts hardware graphics or

    > is it confined to the components in the Mozilla DOM only, and what type of
    > content extensibility is exposed in XUL, because from reading it looks like the
    > XAML client is pretty extensible there?

     For some insight about XUL check out the Luxor XUL Toolkit @ http://luxor-xul.sourceforge.net and the Luxor XUL Plugin Central site @ http://petra.sourceforge.net

      - Gerald
  12. Just how equivalent are XAML and XUL?[ Go to top ]

    ...XAML elements are all also C# classes so you can work in XML or code or both roundtrip...

    That's a classy XUL. I like that it allows mixing processing and presentation without marshalling -- much nicer than JAXB. The down side is that tight integration with procedures precludes using XSL to entirely convert a XAML application to portable MozXUL. Though XSL could still easily convert MozXUL to XAML fully.

    Dual use between procedural and declarative is a good evolutionary step toward directly executable XML, the destiny of XUL and of all computing. Longhorn is begining to seem cogent. And of course it'll be here soon. Fat clients, oh happy day!
  13. For MS's take on it:

    http://blogs.gotdotnet.com/ffortes/permalink.aspx/b7708c79-cbb9-4b2e-a22d-f8a7b1416b7b
  14. XUL[ Go to top ]

    I am surprised at the cold shoulder XUL is receiving in the Java world (please don't jump on Sun, Gerald. I mean all the biggies like IBM, BEA, Oracle). Surely it is worth spending effort on, considering that MS thinks it's important.
  15. XAMJ[ Go to top ]

    XUL has been around since, when, the late 90s?
    It's unclear how exactly it would be able to
    put up a fight against a .NET based language
    developed by Microsoft's army of programmers.

    Anyway, we've just done the first public
    announcement of the XAMJ Project, an open-source
    Java-based alternative. Please visit
    http://html.xamjwg.org. Feedback is appreciated.
  16. Risky, Interesting Indigo[ Go to top ]

    Just to clarify, Avalon does not generate ActiveX code. XAML is compiled directly down into managed code run by the CLR. Unlike similar UI markup technologies like XUL, XAML is not interpreted and provides a wider offering of services than something like XUL.

    You can leverage individual stacks of WinFX such as Indigo, without requiring other components like Avalon or WinFS. The 3 stacks are conceptually organized along the lines of:

    1. Presentation (Avalon)
    2. Communication (Indigo)
    3. Data (WinFS)

    Definitely a lot of work ahead with MS with regards to this, especially when you consider that relatively new technologies like Windows Forms are now going to be legacy in a relatively short time.

    -Kris
  17. Risky, Interesting Indigo[ Go to top ]

    At its basis, Indigo appears to be a more organic means of aggregating services that may not be developed or deployed at the same time, and it assumes the asynchronous behaviors, federated trust relationships, etc. that go along with that.

    The resemblance to WSDL-based Open Grid Service Architecture (OGSA), the leading gridware, is uncanny. And Indigo's daring embrace of asynchronous messaging is truly fascinating. Perhaps an analysis methodology dedicated to queueing, such as Shlaer-Mellor, has increased relevance. Anyway, this is Microsoft's most learned grab at the server side yet.

    Avalon being basically a rich DirectX web client generated through markup...

    Ie, XUL.
  18. Risky, Interesting Indigo[ Go to top ]

    First a bit of disclaimer, I quickly browsed through the description of Indigo so bear with me if I missed some important detail.

    Here's my first impression: "Good ideas but execution will be too late!".

    There are a lot of ideas (i.e. asychronous messaging based) that I do agree with, however many of these have already been implemented in the Java world! (For reference see http://www.manageability.org/blog/stuff/open-source-agent-java/view ).

    The great benefit on Indigo to the Java community is that it LEGITIMIZES asychronous architectures as the dominant architecture of the future. In otherwords, the Java community will focus more on this and not some backward concept such as EJB.

    The execution of Indigo is problematic since its not going to be a partial upgrade but a major overhaul where developers have to wait til 2006-2008. Meanwhile Java implementations would be making incremental progressing using emerging technologies such as AOP. The other weakness of Indigo is the use of XML Schemas, rather than the use of "partial" schemas like Schematron.

    Carlos
  19. Risky, Interesting Indigo[ Go to top ]

    <carlos>
    .. some backward concept such as EJB.
    </carlos>

    you sure how to start a controversy, don't you? ;-)

    <carlos>
    The other weakness of Indigo is the use of XML Schemas, rather than the use of "partial" schemas like Schematron.
    </carlos>

    I am really interested here. Could you please expand on this point a little bit? Why do you prefer Schematron over XML Schemas? Schematron enables validating document instances and as such don't replace XSDs that _define_ schemas, right? or am I missing something?

    --Dilip
  20. partial schema[ Go to top ]

    Well a lot has to do with trying to achieve "loose coupling", here's a table that I put together a while back:

    http://www.manageability.org/blog/archive/20030628%23principles_of_loosely_coupled_api/view

    Anyway, there's this notion that you don't have complete knowledge of what I document should look like, rather you know what you need it to look like, everything else you ignore. Grammars are the first kind which requires a complete picture, however patterns (i.e. partial grammars) are a partial (albeit relevant) view of a document.

    This is more loosely coupled because you can have numerous overlapping schemas in play at any given time. You don't need to go to a centralize schema repository to update the definitions. XML Schema is weak in this matter, more promising approaches are Schematron and of course RELAX.
  21. Risky, Interesting Indigo[ Go to top ]

    There are a lot of ideas (i.e. asychronous messaging based) that I do agree with, however many of these have already been implemented in the Java world! (For reference see ... ).

    Maybe you've confused actors and agents. Actors queue requests. Agents are mobile actors. Indigo makes no mention of agents, and industry interest in agents is low.

    The great benefit on Indigo to the Java community is that it LEGITIMIZES asychronous architectures as the dominant architecture of the future.

    Friggin' finally. The concept has beenevolving since 1975.
  22. Actors vs Agents[ Go to top ]

    Agents as in the kind described by FIPA are entities that do respond to asychronous message requests. Of course theres also that association that agents are "intelligent". Actors, a word I haven't heard in a while are less of an overloaded term and I agree is more appropriate. However, no work has been done on them for ages!
  23. Actors vs Agents[ Go to top ]

    Actors, a word I haven't heard in a while are less of an overloaded term and I agree is more appropriate. However, no work has been done on them for ages!

    The word may be almost dead, but the concept is very much alive, especially in J2EE. A message driven bean is an exemplary J2EE actor. JMS also fully supports actors. Assuming a web server queues requests to an endpoint, then servlets are also actors. As such, how many server applications don't use actors?!

    The need for mobility it's innacurate to attribute agents to Indigo. Microsoft has a compeling security concern against supporting agents. Agents aren't useful if confined to a corporate intranet. And agents only succeed in a community of trust, such as academia. They'll remain experimental for a long time.
  24. Actors vs Agents[ Go to top ]

    "Maybe you've confused actors and agents. Actors queue requests. Agents are mobile actors."

    Mobile agents are one definition, however the FIPA definition doesn't deal with mobility rather it deals with asychronous conversations.

    The use of the word actors hasn't been used for a long time now.
  25. Actors vs Agents[ Go to top ]

    Mobile agents are one definition, however the FIPA definition doesn't deal with mobility rather it deals with asychronous conversations.

    Oh.
  26. IMHO[ Go to top ]

    It is close to impossible to create single
    "user-easy-to-use" and enterprise system.
    "easytouse" is what makes MS leader in desktop.
    It cost a lot in term of stability and security.
    (Just for example, when KDE starts to be user-fiendly
    it starts crashing....). SQLServer worms success this year
    is (loosely) based on desktop security pushed into
    enterprise level.

    So, IMHO, when MS will create strong separate server,
    with client features in miriards desktops, this will
    be something to consider. Any "single" offering will
    not fly far. (IMHO ten times)

    Alex V.
  27. The deal about Longhorn[ Go to top ]

    Longhorn (will/should)

    - elevate the "service" level of an operating system a lot higher than right now. Expect the OnCoffeeDone() message handler.
    - will really try to push TCPA upon us. Security will be the killer-argument.
    - will raise the operating systems API layer a lot higher, exposing "managed code" APIs (.NET) instead of the C-Code API (Win32). It might even be coded to a huge amount in "managed code" itself. This, of course would be revolutionary, *IF* performance will be sufficient enough. Because C# Apps would make no difference to native apps.

    In the end its finally kicking the "I" out of the old LIM (Lotus,Intel,MS) Standard, which already mutated to IM. Guess win32 was too good. Now make the OS API OOriented and catch all the java folks :-)

    Funny: people really hate this bastardized way of using "hybrid" techniques (managed code or the WFC that that borland guy did to Visual J++. It just feld like an native client app). Everybody cried out at that time, remember the MS/SUN lawsuit over this.

    Now, IBM does just the same with SWT. No one cries. Why? because those who rule the desktop will rule the server eventually. Java needs better (in the sense of slicker) GUI client support. And IBM really uses Java for client stuff - every installation thing for my thinkpad (drivers etc) comes with a Swing-GUI that already looks quite native but not perfect yet.

    Totally off topic? Hmm need another coffee.
    Greets from Berlin/Germany
    agill
  28. The deal about Longhorn[ Go to top ]

    - elevate the "service" level of an operating system a lot higher than right now. Expect the OnCoffeeDone() message handler.

    This is what happens when a desktop ISV makes a server -- the server is event driven like a GUI.

    In the end its finally kicking the "I" out of the old LIM (Lotus,Intel,MS) Standard, which already mutated to IM.

    We all appreciate hardware independence.

    Now, IBM does just the same with SWT. No one cries. Why? because those who rule the desktop will rule the server eventually.

    True, unless servers switch to utility computing, the one place Microsoft can never reach.
  29. This is useful reading:
    http://msdn.microsoft.com/longhorn/understanding/pillars/indigo/default.aspx?pull=/msdnmag/issues/04/01/Indigo/default.aspx
  30. No Microsoft bashing so far ? weird.[ Go to top ]

    I'm surprised guys.
    I think it's first time here when TSS mentions MS technology and java zealots remain quiet. (well, almost) :))
  31. No Microsoft bashing so far ? weird.[ Go to top ]

    Why you wanted to see microsoft bashing
  32. No Microsoft bashing so far ? weird.[ Go to top ]

    Why you wanted to see microsoft bashing

    I don't.
    I'm just surprised and glad actualy, that it did not happen this time as it happens always.