Discussions

News: U.S. Office of Management and Budget ranks J2EE above .NET

  1. The U.S. Office of Management and Budget (which supervises all executive branch government agencies and makes recommendations to the President of the United States) in April released a study that ranks J2EE higher than .NET as a platform an underlying technology for all e-government initiatives.

    In the study, they gave J2EE the highest overall technology ranking, saying it scored 22 out of 24 points on a scale for meeting federal government program architecture requirements. Microsoft .NET scored a 17 out of 24.

    "J2EE is an established, mature technology and by far the more open of the two (J2EE and .NET)," said Debra Stouffer, who served as a federal enterprise architecture program manager for OMB, in a recent interview with Government Computer News. "The fact that it is multi-platform is key."

    Read OMB advocates J2EE, .Net for e-gov.

    I found out about this news from a recent press release from J2EE learning management provider, Plateau Systems.

    Threaded Messages (47)

  2. Good to hear - .Net will never get the data modelling ability of Java/J2ee .Having said that getting the best of the 2 technologies is advisable.
    Faisal
  3. Looks like .Net is dead on arrival.

    Good to hear that an objective study confirms what all the proponents of J2EE knew all along.
  4. Looks like .Net is dead on arrival.


    While I too like to see objective analysis of the two sets of infrastructure confirm my own (biased) view, I don't see how this is any sor of proof that .NET is DOA.

    Chuck
  5. I will say it again -- ".Net is dead on arrival."

    According to the article:

    "J2EE is an established, mature technology and by far the more open of the two," she said. "The fact that it is multiplatform is key."

    Microsoft’s .Net, on the other hand, works only with one platform and needs to mature, Stouffer said. ...

    --------------

    These are reasons enough to choose J2EE over .Net for implementing serious enterprise solutions.

    My opinion is definitely biased, but it also happens to be true.

    ".Net needs to mature" = Inadequate and Risky
    ".Net works only with one platform" = Closed and Risky

  6. Er, yes but many ignore the big, BIG picture of the
    "multi-platform" statement you cling to.

    Microsoft has realized the benefits of an intermediate
    layer (IL or Common Language Runtime). This means
    they write the code and its gets compiled to the CLR spec...means they can then target the CLR VM to any machine...eventually.

    Yes, perhaps this is still a long time off but it'll
    happen. When it does - .NET matures - and it'll be
    multi-platform too, perhaps #;-)

    Thx,

    Gary
    _______________________________________________
  7. <quote>
    When it does - .NET matures - and it'll be multi-platform too, perhaps #;-)
    </quote>

    Perhaps, it'll be called Java then ;-)

    -- Igor
  8. And not to forget:

    - there exists a basic port to BSD from MS
    - MONO with friends is underway
  9. I won't hold my breath for this one. Even if they get it to run now, it'll always lag behind and some of the more interesting and advanced features will still be Windows-only.
    Nevertheless there are good reasons to use .net but I'm sure multi-plattform support and openess won't be one of those.
    So what should a Java developer do? Get to know the enemy, take his best ideas, prove that J2EE is superior for the task and stop whining.
  10. After looking over all the reams of info on .Net, especially the C# language, it struck me that .Net is sort of a wild shotgun blast of features--I got the sense that Marketing always had the final say over Engineering; "don't choose one over the other, keep both so we can sell more!" So Yes to Java's syntax, but Yes to pointers too, Yes to everything.

    I tend to think anything is better when design choices are made, as Java's caretakers have done. The metaphor that comes to mind is .Net is like a Winnebago camper van, while Java is like a Honda CRV. You can take a Honda/Javamobile more places and more easily. If it turns out that the .Net/Winnebago has a nice feature, like a cup holder in back/library feature, then Java will adopt it, in a clean and elegant way.
  11. Cole Thompson writes:

    "I tend to think anything is better when design choices are made, as Java's caretakers have done. <...>

    If it turns out that the .Net/Winnebago has a nice feature, <...>, then Java will adopt it, in a clean and elegant way."

    Agreed: Javabeans struck me as a ripoff of the VB components concept done more elegantly.
  12. <quote>

    And not to forget:

    - there exists a basic port to BSD from MS
    - MONO with friends is underway

    </quote>

    Essentially it's marketing stuff. MS gave to ECMA only 250 of the 7000+ classes of .Net.
    So you can successfully ("standard") build a .net clone which makes addition, subtractions and other interesting things.
    But the rest of the stuff needs reverse engineering or a direct, generous help from MS, which definitely will make Windows the only serious choice for .Net.

    uL
  13. Which of the libs? I've not looked that up yet. The ones I would hope for are:

    -io
    -globalisation
    -sockets & networking
    -system stuff
    -xml
    -serialisation
    -soap stuff
    -db connectors of some sort

    addition techs
    -assembly specs
    -reflection
    -signing

    Given this lot we can turn on the free software folks and end up with the same infrastructure that we have with java (should we want to). i.e. we don't need anything else.

    And we could then have the free software competition against core .Net that we are seeing with Jakarta v's J2SE and J2EE.

    Everything changes but stays the same.

    I wonder if microsoft HAS to comply with the standard in order to have c# in .net. Anyone know? i.e. could they decide to change the CLR to disable mono produced code.

    In my more paranoid time I have imagined the following:
     - release C# and J#.
     - hurt the java community, by getting developers to switch over.
     - ditch c# and j# leaving VB and C++ as the only CLR languages.

    It would be an aggressive approach, putting it mildly.

    If mono for server side stuff really worked (and that is a big if), then c# is actually a natural bridge for ms coders to get onto unix/linux. The ECMA spec probably holds enough to be damn useful server side - note the 'probably' because I don't know yet.

    Jonathan
  14. Jon Gibbons writes:

    "In my more paranoid time I have imagined the following:
     - release C# and J#.
     - hurt the java community, by getting developers to switch over.
     - ditch c# and j# leaving VB and C++ as the only CLR languages."

    Something like this could happen, though not (in my opinion) because of any grand plan at Microsoft. The facts at this time seem to be that VB and C++ are far more popular on the .NET platform than C# and J# (in terms of jobs listings on Monster and Jobserve that is).

    Assuming that this doesn't change over the next year, Microsoft could well decide to focus their efforts in the popular languages at the expense of the laggards. This is why I've stated that if I learned .NET I would begin with VB.NET rather than C#. J# looks to be like Java 1.1. A non-starter perhaps useful for the occasional porting or integration job.

    I hope Microsoft is smarter than to try a strategy like you thought of, because they would massively anger much of the development community by doing something like this. The loss of trust would not remotely be worth any minor gains they might get in the short term by 'undermining' Java.
  15. Sounds like the pipe dreams sold to vendors about COM on unix.

  16. I don't believe this shows that .NET is dead, though it is evidence that J2EE is not going to be killed by .NET. As if we needed it.

    I think .NET will tend to be client-side for now, though our vocabulary (client-side, server-side) fails us in an N-Tier world I think. Perhaps we should borrow terminology from the router world which has different kinds of equipment in what we call the 'server-side' space. What I'm thinking of are called 'edge' equipment. .NET has a place in server-edge components using Web Services to pass requests.
  17. Don,

    I quite like the edge idea. How would that work...hmmm...

    Core enterprise systems stay Unix and C++/corba or J2EE. The smaller systems maybe are done in ms tech. And the comms are done... how. OK, we know XML/soap fits that space, but what is the structure. Is it simply soap in the app server or is there a need for some sort of integration layer to decouple the enterprise systems from the smaller ones. i.e. so that the two systems do not need to know of each other, its the edge glue that joins the two domains. Um. Has to be a better name than edge. It's the wrong term. Adapter has been used already but fits nicely.

    I've seen enterprises tackly this through hubs which take feeds and then provide data. Very mixed results for time and political reasons. A different 'adaptor' type approach would be good. What is the pattern name for that?

    Jonathan
  18. Actually, this is a pretty nice problem. How to make use of enterprise data stores from .Net. They would use ADO.Net to simply connect to the enterprise db. But would that be best? No decoupling, so schema changes kill off all the others.

    As I said, the problem with data hubs is the time and politics (who owns the data, cleans the data and so on).

    So we have these data bridges from j2ee to .Net, which is better than adaptor and fits your n/w terminology. They could reside in either the java or .net camp because they serve up XML and soap. I remember way back reading a good paper on XML layering. One XML layer closely coupled to your DB, and then layers of XSLT on top to transform the data model as required. This is not multi-rendering, its about preserving different data model for different uses. So, for a decoupled data bridge we use xslt engines for the .Net world to j2ee? Anyone got a product to do that?

    Jonathan
  19. Well this report definitely kills .NET for government work. I'm from the D.C. area and I hear J2EE jobs in the IRS, INS, SSA, FBI, NIST etc. also in former gov't corps like Freddie Mac and Fannie Mae. I haven't heard of any .NET activity, but this report definitely kills it before it even starts.

    In short, the billions of dollars that the government is spending to upgrade it's woefully inadequate IT structure is going to the guys who know Java. For .NET guys that want to work in gov't projects, well don't expect to put food on the table!
  20. Did you even read the article? The article states quite clearly that .Net and J2EE are the preferred frameworks for government agencies to use. While the headline for this discussion doesn't clearly reflect the article's message I would think you could actually take the time to read the article before commenting. The article actually plays nicely to the .Net world... J2EE has been around for years and .Net is still in its infancy and yet we have the OMB recommending both.

    A sidenote also... I see that you had some problems on the gotdotnet site and were finally kicked off. Well just to let you know this site also failed while reading this message flow... does that mean J2EE is worthless too? Perhaps you should recommend that the site move to a different platform?
  21. Microsoft needs to resort to censorship in the newsgroups and in the gotdotnet site to hide the truth. This news item about the OMB has in fact been censored in those forums. Aside from strong arm licensing policies, they have now gone even lower by actively censoring dissenting opinion.

    I'm glad that the U.S. government is recommending an open standard over one promoted by a monopolist.
  22. Carlos Perez wrote:

    >Microsoft needs to resort to censorship in the newsgroups
    >and in the gotdotnet site to hide the truth. This news
    >item about the OMB has in fact been censored in those
    >forums. Aside from strong arm licensing policies, they
    >have now gone even lower by actively censoring dissenting
    >opinion.

    Looks like Micro$oft has something to hide, which further proves that J2EE is the superior platform and the only serious platform for enterprise initiatives.
  23. I think we're on the same page here, Jonathan. I figure that .NET uses Web Services to interact with the enterprise world. There is nothing which says that a client running any of the M$ languages cannot request a Web Service request to a .NET Web Service server which decomposes the base XML document into subservices through XSLT (either directly or by calling other Web Services to do the conversions. Then the base Web Service calls other Web Services (on the other side of the cloud) and orchestrates responses before assembling the reply to the client.

  24. 'edge' servers[ Go to top ]

    Jonathan,

    I agree that 'edge' is the wrong word but the concept I am groping fuzzily toward is similar to edge routers in the Cisco world. That is the interface where the Lan ends and the cloud begins. That whole area used to be called just plain bridge or router or switch but now a host of specialized equipment have sprung up. I think that N-Tier will in the end force us to develop syntax to describe the various roles our 'server-side' components fill in our distributed software service architectures.
  25. Comparison between J2EE and .NET is not quite correct in my mind. .NET pretends to be next OPERATION SYSTEM from MS. They did this trick before with Win atop of DOS.

    I would claim conceptual difference between .NET and J2EE.

    Because of Java&#8217;s limitations (yes, limitations) I consider J2EE to be more suitable for business development. MS attempt to address too much does not look good to me from theoretical position.
     
    JRE pretends to be OS for business applications too, so does every OS (Linux, Mac, Unixes &#8230;), as business developers we need something more specific than OS.
  26. Take a look at:

    http://www.ximian.com/products/ximian_evolution/

    Convert Microsoft business users by boatloads and they will thank you in the end.







  27. You can put a web services front end to J2EE solutions using the JAX-RPC api from Javasoft. It fits naturally with the J2EE architecture.

    There is no need to kludge in .Net, a closed protrietary solution that only runs one one platform, just to get the web services functionality.

    At JavaOne 2001, I saw a graphical tool for J2EE solutions that automatically mapped WSDL and UDDI definitions to Java classes that breaks appart the maessage and calls several web services, and assemble the results to get a response.
  28. Hi Peter,

    "There is no need to kludge in .Net, a closed protrietary solution that only runs one one platform, just to get the web services functionality."

    I don't want to argue any of that. But my question is, "If you HAVE to integrate your j2ee enterprise system with .Net then how?"

    The choices are to closely couple the integration with the enterprise system (ie in java on the same app server). Or closely couple with .Net (say ado.net direct to the enterprise db, or even a data feed in sql/DTS). Or you could do it via a 3rd way, say one of these 'edge' devices Don mentioned. This is good as it acts as the bridge between the two - and as long as it talks soap (which has problems I know) then you could do it in C, C++, VB, C# or Java. It doesn't matter.

    Maybe. I'm interested in any other approaches that you can think of.

    Jonathan
  29. i dont know about .NET in particular and Iam inclined to think j2ee is the better architecture but c# as a language definitely has better features-if u think u dont need function pointers or operator overloading or generics - well think again - c# will definitely be liked by programmers who know both c++ and java
    i think c# has gained support in opensource because it has the features that all of us have been moaning about for years now- watch mono
  30. Peter English writes:

    "There is no need to kludge in .Net, a closed protrietary solution that only runs one one platform, just to get the web services functionality."

    I think Peter has a perfectly valid point in a greenfield scenario. That is a project in which both server and client sides are being built from scratch without having to worry about existing systems. J2EE can indeed handle it all.

    Many of us work in enhancing existing systems or in integration of existing systems in organizations which have already made some choices. With Web Services it has become possible to integrate clients written in VB.NET or ASP.NET with J2EE EJB or SOAP services, and we will surely be asked to do just this in view of J2EE's superior ability to scale server-side applications.

    We are making the assumption that M$ applications will not dissolve in a puff of smoke leaving a small of brimstone behind, Peter! We're going to have to live with Mr. Gates for a while yet, and I personally would prefer to do so on my (J2EE) terms rather than his terms!.......
  31. I've looked all over and I can't find this study that
    is referenced in these articles. If anyone knows where
    it is I'd like to read it (and maybe use it if some
    potential customer thinks they'd rather do .NET :-)
  32. try{
     this Url http://www.gcn.com/21_9/top-stories/18493-1.html

    Faisal
  33. I didn't mean I couldn't find that article, I meant I
    can't find the report/study that OMB has supposedly
    announced/released. For example, in this article:
    http://industry.java.sun.com/javanews/stories/story2/0,1072,46509,00.html
    they say "The Office of Management and Budget has announced a study that ranks Java 2 Enterprise Edition (J2EE) as the preferred underlying technology for all e-government initiatives."
    I'd like to see that actual study, not a press release talking about the study!
    But it seems impossible to find something like this on the US government web sites.
  34. I agree,
    Where is the "study"?
    You all together are speaking about an opinion.
    So i ask again :
    Where could i found the "study" .



    Psit : Delagate are now avauilable on java 1.4 great !-)
  35. How is .NET "relatively proven"?
  36. My impression is that Microsoft's primary focus for developers has been good productivity at the early stages of the learning curve, and they have a demonstrated willingness to reshape technologies to achieve this aim.

    Whatever you think of the quality of the eventual solution, .NET developers can easily produce (for example) SOAP-accessible components with declarative transaction management, all with a few handy attributes. Compare with the time it takes to happen upon XDoclet and learn that properly.

    I think that the pro-EJB message has really steepened the perceived learning curve for J2EE, despite EJB being complete overkill for the vast majority of small and medium projects. With the right tools and architecture, Java can save a lot of time, but the quality of the specs in the next year will really make or break the community.

    Imagine the effect if Microsoft started pushing a standard O/R layer on top of SQL Server, and made a fairly flexible, default mapping both automatic and transparent to the developer? This would be an astounding productivity boost to entry-level Microsoft developers.
  37. Imagine Oracle buys TopLink O/R tool from WebGain and adds in as layer on top of Oracle DB Server, and made a fairly flexible, default mapping both automatic and transparent to the developer? Imagine linking it to J2EE/EJB server Oracle 9i AS. Imagine adding it to JEE/UML tool Developer...
    Imagine...

    This would be an astounding productivity boost to entry-level Java developers.

    Ups...,it looks like above laready happened, check:
    http://otn.oracle.com/products/ias/toplink/content.html

    Stop waiting for Cairo, .NET, blackboomb and other false never_intended_to_be_delivered promises which are only created so you do not see in what crappie MS world you are living today.
  38. Let's put to rest the inferrence that EJB is too difficult.

    If you do not understand how to use EJB, get the following FREE downloadable book:

    http://www.theserverside.com/books/masteringEJB/

    It provides a clear explanation and gives examples of how to do EJB.

    The book is also available in print and I reccommend getting that too so you can read it without needing a computer or to lookup something while you are working on a project on the computer.

    Once you see the quality of the PDF edition of the book, you will definetly want to invest in the print copy.

    I bought the print edition of the book and it was money well spent.
  39. Personally I can't see how .NET is dead... I quote the article:

    "The Office of Management and Budget is recommending that the architects of the 24 e-government initiatives use Java 2 Enterprise Edition or Microsoft .Net as underlying technology. "

    Basically they're saying, use one or the other. I think the obvious statement that can be made is that COM/CraptiveX is dead - which is about time. Long live J2EE/.NET.
  40. Jason Smith wrote:

    >> Personally I can't see how .NET is dead... I quote
    >> the article:

    ------------------

    The article said that J2EE has a clear decisive advantage over .net.

    In the "foundational criteria" rating, J2EE scored 22 out of 24 while .net scored 17 out of 24.

    J2EE can more easily adopt new features.

    "The preferred architecture, Stouffer said, would be to adopt J2EE using Extensible Markup Language over the Simple Object Access Protocol."

    "J2EE is an established, mature technology and by far the more open of the two," she said. "The fact that it is multiplatform is key."

    The article also infers that there are security problems with .net.


    The two are not equal -- J2EE is better by far and the clear choice for enterprise initiatives.
  41. So it has been proved that Dot NET is basically "NOT YET"
  42. There is no competition of J2EE with .NET and i think for U.S. Office J2EE will be suitable because of smaller scale work.
  43. "&#8220;They offer the capabilities that we outlined in our requirements. They are open technologies with proven industry standards.&#8221; "

    .Net is an industry standard??
  44. Carlos, I gotta agree with you. I don't work for the federal fovernment. But I have, for the last 10 months, been working on a large scale application, secure application for the government. They wouldn't even let Microsoft OS in the data center when I recommended using Seagate for a report server. They practically laughed at me when I said that. The security problems were just too pervasive.

    On top of which, one of the core requirements for the project was open source, which amazed me at the time. I didn't think the government would go for it, but they did. And it worked well for us! Tomcat, Struts, Log4J, Poolman, some others.

    -Newt
  45. I have to agree with Jason and Carlos - the security vulnerabilities are horrendous and are an embarrassment, so much so that I would not propose using Microsoft technologies to my clients.

    Nothing unusual about this you might say, except that I have specializing in Microsoft technologies for the past 13 years. For those who know me, this is a huge admission.

    As a member of the enemy camp, all I can do is hope and pray that Microsoft gets their ducks in a row.
  46. Woow , gr8 to hear that J2EE rates high then .NET,

    pls can any one provide me what are the 24 points factor which the U.S. Office of Management and Budget did.
    Thanks and Regards

    Viswa
    =====
  47. Are the government systems the best designed?
    Are the government systems the best implemented?
    Are the government systems the best secured?

    My opinion, different technologies always have their pros and cons. The final quality of the projects are all depending on how the technologies are used to solve those real problems. Technologies are always just tools.
  48. I agree that technology are just tools, however, there are good tools and there are bad tools.

    According to the study, J2EE is the better tool.

    Anyone picking a platform to build their enterprise solution wishing to avoid hardware lockin has only one real choice. That choice is J2EE.

    Other reasons also weigh heavily towards J2EE being the ideal platform.

    I reccommend that all C++ programmers learn Java if they have not already done so. The two languages are so similar that it should only take a couple of days to learn.