TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE

Discussions

News: TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE

  1. TSS presents a new Hard Core Tech Talk interview with Doug Purdy, a Program Manager with Microsoft's XML Web Services Team. The intention of the interview was to learn about .NET from the perspective of a J2EE architect;What followed was a fascinating comparison of both features and application design strategies of .NET and J2EE.

    Watch Hard Core Tech Talk with Microsoft's Doug Purdy.

    The interview is not intended to be a debate or a competition, simply a technical, fact finding discussion. Some of our members might wonder why we would do this interview and post it here. TheServerSide is a J2EE community, and as such, we feel it our duty to bring you news and content that will empower you in your work. We feel that a good technical understanding of the alternatives to J2EE is important from that perspective.

    Threaded Messages (267)

  2. Hi,

    Interesting piece of information. The only question I did not hear is the portability issue. Will .NET be portable across different OS & Hardware stacks ?

    Salim MANSOURI.
  3. Very interesting interview.

    The multi-language-feature is IMHO marketing bull-shit (it's difficult enough to maintain a system written in one language, I don't even want to think about how difficult it would be with a system written in 24 languages). But the "attributal programming" is definitely one of the more interesting features of .NET, and although XDoclet is really spectacular it is compile-time and not run-time. Isn't there an effort in the JCP to get this thing into Java?
  4. "But the "attributal programming" is definitely one of the more interesting features of .NET, and although XDoclet is really spectacular it is compile-time and not run-time. Isn't there an effort in the JCP to get this thing into Java?"

    This is probably what you're asking for
    http://www.jcp.org/jsr/detail/175.jsp
  5. <quote>
    The multi-language-feature is IMHO marketing bull-shit (it's difficult enough to maintain a system written in one language, I don't even want to think about how difficult it would be with a system written in 24 languages).
    </quote>

    If you are writing J2EE applications, you are already using at least two languages (Java and XML) and probably much more (JSP, Javascript, and maybe even Perl, Python, etc...)

    --
    Cedric

  6. Reading Doug's interview, it strikes me how much he knows about J2EE and how little Microsoft opponents usually know about .NET.

    --
    Cedric
  7. Doug strikes me as knowledgeable, but not knowledgeable enough to know that you don't want to put your business logic in stored procedures which locks you into a proprietary database like MS SQL Server.

    You want an abstraction layer so you can choose whatever database the customer may have -- like Oracle, DB2, Sybase, Interbase, MySql, PostGresql, etc. Remember, when you deploy an enterpise solutuion, there may be cases where you cannot fully dictate what database the customer has or is willing to install.

  8. <quote>
    you don't want to put your business logic in stored procedures which locks you into a proprietary database
    </quote>
    This depends on what sort of business logic you deal with and in what scenario.
    I can think of several scenarios where it is beneficial (sometimes even necessary) to put you BL into a stored proc.
    When you have search-type operation that uses non-trivial criteria (such as multiple joins, needs work tables etc.) and operates on big data sets, I think you should use stored proc. Otherwise, you might risk having a lot of network traffic to/from the db. Sometime you can afford it, sometime you can't.
    I'd tend to agree that create/update/calculation type of BL should not be in stored procs - and you should not use them if you are developing a commercial product (unless you have tie-ins as a part of your business plan).
    (*grin* although people could argue that even that has it's advantages as you just recompile one stored proc, not having to build and deploy the whole application )
    Regards,
    Vlad
  9. I can think of several scenarios where it is beneficial (sometimes even necessary) to put you BL into a stored proc.


    I agree - sort of. If you consider triggers stored procs. They essentially are. I think EJBs would solve some of it but not all. And if you don't use them then you gotta do what you gotta do. My policy is that SPs/Triggers are last ditch methods.

    >Otherwise, you might risk having a lot of network traffic to/from the db

    Not if you do your database access server-side, which one should in a distribute environment.

    >and you should not use them if you are developing a commercial product

    True. But sometimes you gotta - just minimize them.

    >(*grin* although people could argue that even that has it's advantages as you just recompile one stored proc, not having to build and deploy the whole application )

    If the db code runs server-side this is not true. And if one doesn't use jars, it could be a class or just a mapping file.


  10. I totally agree with you, IMHO his knowledge about J2EE is not that much, my impression was in fact that he has a rather theoretical knowledge about J2EE concepts, knowing the basics of CMP and other topics is not much more. But does he have really deep real-world knowledge? I doubt it.

    In the real-world stored procedures are a nightmare if you work in a changing environment or you have to deal with multiple databases, since they not only look you into a vender dependency but there are also great productivity and maintainance issues if you write low-level (and often vender-specific) SQL for one or more databases. Why doesn't he talk about this topics? They are really important.

    Stored procedures are a good solution for some specific situations, but in most cases you will prefer some Object/Relational and a good business object design to be MUCH more productive and by the way your mantaince issues will be much less.

    Talking about O/R stuff, what about comparing ADO.NET to JDBC? I still haven't read too much about ADO.NET, so I may be wrong, but for know it seems to me that ADO.NET has almost nothing to do with JDBC. ADO.NET is the first Microsoft persistence solution that models genuine business objects, not only specific record sets, it also provides a kind of XML descriptors for the relations mapping, so I would compare it rather to JDO, although it seems to be significantly more simple.

    There are many more examples that show a lack of deepness, but this should be enough...

    Regards,
    Alberto

  11. Cedric,

    Microsoft "opponents" are busy implementing systems not marketing strategies. Why in the world would an individual invest their most valuable resource (time) into system framework that is not proven? Especially, from criminals. No thanks, I’m happy with open source tools and J2EE.

    I can understand your comradery with Microsoft web services, since you are part of the Microsoft web services consortium with BEA. Hopefully you won't wake up one morning in your bed with BEA (Microsoft Web Services consortium) and discover Microsoft has packed up and left for another flavor.

    You’re a newbie to the industry and experiences will demonstrate what I am talking about. These experiences have been relived many times by many companies dealing with Microsoft.

    One more point to add: Microsoft's pseudo multiple languages support will be seen as one of Microsoft's biggest blunder 5 years from now. It’s been done before in Java and we saw the leading trend. No need to guess where Microsoft's multiple languages support is headed.


  12. You think Microsoft could afford to buy Doug some hair given all the money they're making.
  13. "Microsoft "opponents" are busy implementing systems not marketing strategies."

    LOL, .NET isn't a system?

    "Why in the world would an individual invest their most valuable resource (time) into system framework that is not proven?"

    It is proven enough to use it for non-critical apps.

    "Especially, from criminals."
    "I can understand your comradery with Microsoft web services, since you are part of the Microsoft web services consortium with BEA."
    "You’re a newbie to the industry ..."

    Jesus...


  14. <quote>
    Especially, from criminals.
    </quote>

    The tone is given.

    <quote>
    You’re a newbie to the industry
    </quote>

    Ha ha ha.

    Come out of the cowardly anonymity and maybe I'll argue with you.

    Until then, plonk.

    --
    Cedric
  15. Cedric,

    I think you're splitting hairs a bit. I'm not even sure XML is a language, I tend to think of it as a syntax. Javascript doesn't really play here since it's served to the client side. It's been my experience that languages tend to lend themselves to project. You might have a perl project, and a java project but not often on that is both. They might even be on the same web server/app server.

    I think what the poster meant was, it would be a nightmare if you had one guy writing on (for example) a persistence class in Java, and another developer writing theirs in C++. I sure wouldn't want that where I work. Both of these conceivably could handle the transactions in the same way, but maintenance, changes etc would really suck.

    -Newt
  16. I think if you have a nice architectural split, this would be ok. For example, using one language for doing UIs and another for the server isn't that bad, is it? (thin client comes to mind). OF course match and mix is bad, but you wouldn't write one persistent object to use Sybase and other Oracle either? (if you could avoid it)
    I for one wouldn't mind being able to call EJBs from a perl/python script directly.
    It could also be arguably good for interfacing/reusing your legacy applications (which is where I think the original idea came from). The arguably comes in as you would need to be able to recompile it using .NET language. I doubt that at the moment most of the legacy programs out there would and I won't hazard a guess on how hard it would be to change them.
    Regards,
    Vlad
  17. <Q> I think if you have a nice architectural split, this would be ok. For example, using one language for doing UIs and another for the server isn't that bad, is it? (thin client comes to mind)</Q>

    Thin clients - Like a DHTML UI? This an example of why it is bad. Mixing languages in this way will mean giving something up. One thing .Net has given up is throwing exceptions. You get to guess, search docs, trial/error or search code. The same is true for Web services.

    <Q>OF course match and mix is bad, but you wouldn't write one persistent object to use Sybase and other Oracle either? (if you could avoid it)</Q>

    In todays world - who knows where things are 'persisted'. That is why we should write to interface.

    I'm not saying this is bad. I am saying it is not easy and .Net doesn't solve it in a good way.
  18. <quote>
    I think you're splitting hairs a bit.
    </quote>

    Yes, maybe a little bit ;-)

    The way I see it, multi-language gives you choice. Choice in who you hire for a certain job, and choice for developers to use whatever language they see fit for specific tasks.

    Now, you do have a point: a precise separation of tasks need to be made. The .Net example of a VB class extending a C++ one is a k3wl hack, but I wouldn't want to see this in a real-world application. But I can definitely see myself assigning engineers to different tasks and leave it up to them to choose whatever language gets the job done, as long the dependencies on other teams are clearly delineated.

    Remember that language neutrality is something that "we" have been looking for for a loooong time (CORBA and IDL anyone?). Microsoft has achieved it, and I give them a lot of credit for it.

    --
    Cedric
  19. that I'll agree with. It also gives an easy tools choice for projects. You think a specific project should be done with VB, you implement it. Another project really needs something more powerful like C#, you implement that.

    The beauty is it would run in the same place. You don't need separate platform.

    Still, there are too many things keeping me away. I would like to learn it. But I like being able to choose app servers, os's, IDE's, etc etc.

    Finally I agree with other posts that it seems that MS people know J2EE but not the other way around. They are very good at a sort of "know your enemy" approach, and capitalizing on the other sides strengths. Some of us J2EE developers could make J2EE a whole lot better by doing exactly that with J2EE.

    -Newt
  20. In regards to multilanguage support, the way i see useful uses for it is in getting shops to adopt .net... not the individual people.

    i would think that a vb shop would migrate to be a vb.net shop, and a c++ shop would migrate to a c# or managed c++ shop, en bloc.

    the extra bonus being that my framework product written in c# could be incorperated as a framework in your vb.net application.

    i dont think ms has envisioned that each member of a team uses his own .net language, which indeed would be babylonian.

    in my opinion the languages is mostly a means to make .net interresting to the largest possible userbase, since ms is really betting the farm on it.

    the bashing of .net along the lines in this thread (multilanguage support a blunder etc.) is in my view to underestimate ms's plan, which is dangerous if you prefer java over .net.

    sincerely
    morten wilken
    sincerely
    morten wilken
  21. c++ shop would migrate to a c# or managed c++ shop


    I think that you meant ATL & MFC shops will migrate to C# and .NET.

    What comes to multiple-languages support. I rather call it multiple syntax support. If you look more closely .NET languages, you see only one language MSIL, that is designed C# in mind. Look for example modifications in VB.NET, Python.NET etc. (thay are basically the same). I think that more important thing is to classify languages not by syntax, but by approach (= functional, procedural, object oriented, aspect oriented...).
  22. we basically agree, my point was more that the multilanguage support's primary objective is to ease the transition to .net, in line with ms's past efforts of gaining dominance on the desktop (JoelOnSoftware has a lot of good articles and examples of this).

    the java community is, in my opinion, more highbrow and more "geeky" (ie. is it nicely architectured, does it work optimally?), and therefore debate this point from a technical point of view.

    microsoft sees that most people will prefer wichever has the smallest learning curve, and then stick with that later on. this means that they focus on making the transition to .net as easy as possible for their userbase, rather than focus on .net being the optimal solution.

    as i see it the percieved benifits of multilanguage support is mostly sugarcoating that ms wants people to adopt their technology.

    im positive that a couple of years from now, the companies working in vb today will be working in vb.net, and similarly with c++ etc.
    if they had not done this they and solely promted c#, they might have lost a lot of vb programmers.

    sincerely
    morten wilken

  23. I agree completely with Aapo. .Net does not support multiple languages more than Java does. Anyone who had a chance to read a couple of articles in C/C++ journal on the so called Managed C++ can realize this.

    Here's an example of what .NET limitations and characteristics sum up Managed C++ to (hope there's some audiance that knows c++ around here):

    Limitations:
    - No multiple inheritence
    - No managed templates (that is no templates since the unmanaged code has practically nothing to do with .NET)
    - No friend declarations
    - No operator overloading (what they suggest for operator overloading are static functions that take two arguments and must be invoked explicitelly that way - just like one would do in Java)
    - No pointer aritmethics (pointers in Managed C++ are practically the same thing as references just their written in different way i.e. using * when declaring them and -> instead of . when accessing object members)
    - No const or virtual functions
    - No more copy constructors or assignment operator overload (for that one must use Clone method on the object)
    ..

    Characteristics:
    - All classes derive implicitely from class Object
    - Interfaces (a new construct - just like one in Java) only declare methods and can be multiply inheritted
    - References point to objects on heap and objects are always created with new. Primitive types are created on stack.
    - All constructs now must have their visibility declared
    ..

    In short, it's Java. Actually there are only three differences that I noted:
    - attributes
    - explicit property declaration
    - mutliple dimension arrays are not arrays of arrays but truly mutliple dimension matrix

    But, the greatest thing of all is that the above does not only apply to C++ but to all .NET "languages". That is, Object Pascal, C#, VB, .. All having the same constructs and the same way of doing things, the only difference being the lexical part of language grammar? Is that what M$ sells for multiple language support? One language with n flavors.

    So, on one hand IT managers shouldn't be affraid of language diversity but of the fact that they will spend a lot more money teaching C++ programmers M$'s C-- (i.e. Managed C++).

    PS. If I had some spare time I would code down this "multi-language" support for Java myself. It's a two man month project - at most!

    My 2c worth,

    Damir
  24. Try http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  25. Hi Cameron,

    Hmm... that's not really a "multi-language" proof. Note that almost all languages listed in that link are toy compilers, academic projects, etc.

    Interesting quote below from http://www.objectwatch.com/issue_33.htm

    Adi

    -------------
    If the Java platform were to be language neutral, the key would have to be Java bytecode (JBC). The Java language architecture requires that Java source code be translated to JBC before being either compiled or interpreted. In theory, any language that can translate to JBC should be usable within the Java platform.

    Based on Tolksdorf's web site, the list of languages that can generate JBC is impressive. I counted 133 links. As I followed and categorized these links, I found the results much less impressive. [...]

    I found that the most popular category on Tolksdorf's site was interpreters, compilers, or scripting engines written in Java, but ones that neither produce JBC nor in any other way attempt to allow non-Java programming for the Java platform. This included 53 of the 133 entries. These entries are just software systems that happen to be written in Java. None of these should have been included on this web site.

    The second most popular category is Abandoned Projects. A full 40 of the 133 links are either links that are no longer active or links that show no sign of having been updated within the last year. As best I can tell, all of these are projects that have long since been abandoned.

    Tied for third place were the categories Freeware and School/Hobby projects at 19 entries each. Both of these categories include technologies that show the feasibility of generating JBC from sources other than Java (a capability that is not in dispute), but do not include actual supported implementations that would be used in a large commercial project.

    Out of 133 "languages that can compile into JBC", the total count in the category of Possibly Commercial Languages (non-Java) that compile into JBC is 8. The 8 products are these:

    - Convert, a product which converts from VB to Swing forms from Black Dirt Software. I sent email to Black Dirt Software requesting more information. This email was not answered. No contact information was listed on the web site.
    - Smalltalk/JVM from Mission Software. I called Mission Software and talked to Kim, who told me that this is an internal tool and that they don't actually sell this product. If Kim is correct, then this product should not be on this list.
    - PERCobol, from LegacyJ. Based on the marketing literature, this does not appear to generate Java byte code, but instead provides a bridge between COBOL compilers and some parts of the Java platform, particularly enterprise JavaBeans. If this is true, this product should not be on this list.
    - AppletMagic, a compiler of Ada 95. I was unable to get any information on this product.
    - JGNAT, another compiler of ADA 95 from Ada Core Technologies. I spoke to Nancy Cruz at Ada Core Technologies who told me this work was funded by the Defense Department. She promised me a list of customers using this product within 15 minutes, but, as of press time (five days later) has not followed through.
    - Canterbury Pascal, Oberon-2, and Modula-2, all produced by Mill Hill and Canterbury, an English company. I sent them a note asking for more information on the sales and deployment of these compilers, but, as of press time (one week later) have not received a reply.
     

    Based on this research, I draw the following conclusions.

    1. If there are any serious commercially supported compilers that generate JBC from non Java languages, there are very few, probably fewer than 5.
    2. If there is any commercial usage of non-Java JBC emitting compilers, it is very limited. It is highly unlikely that more an infinitesimal fraction of the JBC in existence today came from anything other Java.
    3. If there is any support for language neutrality in the Java runtime, it is very marginal. None of the non-Java JBC emitting languages indicate that they can support the minimum features that I previously identified as necessary for true language neutrality. None, for example, seem to support either cross-language polymorphic method resolution or cross-language exception handling, features that are absolutely critical for true language neutrality.

    At best, the Java platform supports not true language neutrality but rather language replacement. There is a big difference between language neutrality and language replacement.
  26. Hi Adi,

    Do you still work for Microsoft? I missed that in your signature. Look, if you guys had "multi language support" as anything more than an afterthought marketing campaign, you'd actually be able to support things like C++. I don't mean "Microsoft Managed C++", which is a proprietary subset of C++. Frankly, it's hard to believe that with five extra years to perfect what Java had started, you ended up with C#.

    Quoting from ObjectWatch is a nice touch too. Why not use an objective third party site, like gotdotnet.com? This (OW) is the same site that said that J2EE was based on COM. You guys have such a "head in the sand" attitude, that you actually start to believe some of your own hype. That won't work so effectively now that you've lost critical mass in the developer market.

    It's not too late for you guys to convert all that stuff to Java and ship a compliant J2EE app server. Close, but not yet.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  27. Hi Cameron,

    >>> Look, if you guys had "multi language support" as anything more than an afterthought marketing campaign, you'd actually be able to support things like C++. I don't mean "Microsoft Managed C++", which is a proprietary subset of C++.

    That's nonsense. Just pick up a C++ program, compile it with CL.EXE /CLR <My_program.c>, and it will generate an IL binary instead of normal x86 code. You can start with this:

    #include<stdio.h>

    void main()
    {
        printf("Hello world");
    }


    >>> Quoting from ObjectWatch is a nice touch too.

    Again, all I said is that the support for multiple languages is pretty limited in Java platform. There are no commercial C++, COBOL, Delphi, etc. compilers for Java simply because the runtime wasn't designed that way. But I agree that it's nice that from time to time one tries to write it's own little language interpreter/compiler in Java - that might be a interesting programming exercise.

    BTW, Borland, one of the most active players in Java IDE market didn't release (and they don't even intend to release) any commercial C++/Delphi compilers that generate Java bytecode - hard to figure out why? Instead, their near future plans include Delphi/C++ Builder support for .NET platform. Well, I guess they figured out that Java/J2EE might not the best thing after sliced bread after all...

    http://www.borland.com/news/press_releases/2002/02_12_02_borland_unveils_product_strategy.html
    http://www.borland.com/news/press_releases/2002/08_06_02_Delphi7_Launch.html


    Adi
  28. Hi Adi,

    Cameron: "Look, if you guys had "multi language support" as anything more than an afterthought marketing campaign, you'd actually be able to support things like C++. I don't mean "Microsoft Managed C++", which is a proprietary subset of C++."

    Adi: "That's nonsense. Just pick up a C++ program, compile it with CL.EXE /CLR <My_program.c>, and it will generate an IL binary instead of normal x86 code. You can start with this:"

    #include<stdio.h>

    void main()
    {
        printf("Hello world");
    }

    So you are telling me that Managed C++ supports all features of ANSI C++? Yes or no. Please, just one word for the answer. Friggin' "hello world" example. Even JavaC could compile that. ;-)

    Adi: "Again, all I said is that the support for multiple languages is pretty limited in Java platform. There are no commercial C++, COBOL, Delphi, etc. compilers for Java simply because the runtime wasn't designed that way."

    True. Same goes for .NET. It can't even support VB, so the VB stuff had to be re-written to be more C# like. Same with C++. Same with COBOL.

    Adi: "But I agree that it's nice that from time to time one tries to write it's own little language interpreter/compiler in Java - that might be a interesting programming exercise."

    Actually, we have built compilers for three different languages for the Java VM. Including one for Java itself, so two non-Java languages that compile to Java byte codes. One which wasn't even an imperative language.

    BTW - our work isn't on that list, so apparently there's much more available in the Java world than even the 140 languages that are known to exist for the Java VM.

    Adi: "BTW, Borland, one of the most active players in Java IDE market didn't release (and they don't even intend to release) any commercial C++/Delphi compilers that generate Java bytecode - hard to figure out why? Instead, their near future plans include Delphi/C++ Builder support for .NET platform. Well, I guess they figured out that Java/J2EE might not the best thing after sliced bread after all..."

    So? We support .NET too (with our clustering software) via various bridging technologies. So what? That's what software companies do -- try to make sure that they don't alienate parts of the market. Unless of course they are big monopolies with everything to lose and no particular strategic vision.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  29. Cameron,

    '.."Microsoft Managed C++", which is a proprietary subset of C++'

    The correct title is "Managed Extensions for C++", and they are exactly that - extensions - not an implementation (or even a subset) of C++ itself. They can be seen as part of the superset that is VC.Net (or version 7 if you like). The /clr flag enables the use of those extensions, in the same way as /Ze enables Microsoft's other extensions.

    As for underlying standards conformity, VC.Net is certainly better than VC6, but not perfect (the last few issues of Deep C++ on MSDN go into it in detail). That conformity has little to do with Managed Extensions though - the standard allows for extensions.

    There are some useful articles on Managed Extensions in the September edition of C/C++ Users Journal.

    By the way, I completely agree that multi-language support in .Net is a real lame duck.


    Jim
  30. Jim: "The correct title is "Managed Extensions for C++", and they are exactly that - extensions - not an implementation (or even a subset) of C++ itself."

    But you can compile C++ to MSIL, correct? I thought that was called "Microsoft Managed C++".

    What exactly is "Managed Extensions for C++"? I thought that the managed extensions were the APIs made available to stock C++, kind of like JNI (or maybe the opposite, C++ wrapped so that you can use it from C#).

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  31. If you compile standard C++ (with or without Managed Extensions) with the /clr option, a managed assembly will be created. Any calls to standard functions (like printf) will be wrapped as a managed method and P/Invoked. Any classes declared with __gc will be fully managed types, and any calls to other managed types will of course be handled by the CLR, but the built-in types usually map to CTS types (int foo becomes int8 for example). Does that make sense?

    Although Adi's example was simple, it's a perfect way to see what's going on. Compile it to an exe, then run it through ILDASM so you can see what's managed and what's invoked.

    Jim

  32. The conclusion is: Remember quality

    .NET is faster, leaner, use less memory, is more consistent, have more innovative (=practical) libraries and better tools. An ISO standard with an Open Source implementation. All in all a excellent framework for implementing "maintainable multi-user business apps with rich browser clients" as opposed to simple "one table one page" creation so loved by Java app servers. And Microsoft is a much better Steward of .NET than Sun is of Java.

    To sad that the they want to discard all this because "Microsoft is evil".


    Regards
    Rolf Tollerud
     
  33. The conclusion is: Remember Reality

    J2EE/Java offers good developers a standards based, multi-platform/OS infrastructure for building quality enterprise applications that do not limit anyone to only one particular vendor or hardware platform, along with mature open source implementations of the full platform. In addition to being able to implement "maintainable multi-user business apps with rich browser clients", the full spectrum of enterprise applications, including EAI and other non-gui specific apps that VB programmers don't typically encounter, can easily be developed.

    The J2EE specification is sponsored by Sun, but developed by industry input. A wide range of companies offer J2EE solutions. Only Microsoft for .NET.

    Cheers
    Ray
  34. Fact remains Managed C++ is slow as molasses as compared to regular C++.

    Just check all the microsoft.public.dotnet newsgroups. Here's the original thread:

    http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&frame=right&rnum=1&thl=0,1092070214,1092067641,1092061148,1091837120,1091796884,1091677519,1092053663,1092018007,1091835734,1092051417,1092033071&seekm=u36mAf4zBHA.2292%40tkmsftngp07#link1

  35. Cameron,
    I haven't read all the OW newsletters, but I'm fairly
    sure that what OW asserts is that EJB is based on MTS/COM+, and not that J2EE is based on COM.
    In the transcript of a debate between Roger Seesions of
    OW and Ed Roman of TSS/TMC, ER didn't seem to have
    refuted RS' assertion.

    http://objectwatch.com/eddebate.htm

    Regards
  36. Cris: "I haven't read all the OW newsletters, but I'm fairly sure that what OW asserts is that EJB is based on MTS/COM+, and not that J2EE is based on COM. In the transcript of a debate between Roger Seesions of OW and Ed Roman of TSS/TMC, ER didn't seem to have refuted RS' assertion."

    That is what he asserts, but I'm not sure whether it even matters. While it is unreasonable to assume that the EJB designers ignored the existence of COM and DCOM and MTS and COM+, I am certain that they (including Sun and particularly IBM) had plenty of pre-existing models to select ideas from. (To point, of the transaction managers actually used in production, MTS is one of the newest in the market.) In fact, I would hang the "fault" of some of the ugliness of EJBs squarely on IBM's shoulders. I wouldn't be trying to take credit for that ;-) and maybe they should have looked even closer at COM+.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  37. "The way I see it, multi-language gives you choice. Choice in who you hire for a certain job, and choice for developers to use whatever language they see fit for specific tasks."

    IMHO using multiple languages will save you money.

    The question that I would debate is the trade that there is between using many languages because of their different expressive power, and the complexity and flexibility of the code base, which suffer as the number of interfaces goes up.

    Perhaps a good way to think of the issue of multiple language is the XP way - pick the simplest thing that will possibly work, given the real requirements of the customer.

    Guglielmo
  38. Jason,

    "I'm not even sure XML is a language"

    Yep.. but XSLT sure is. :)

    Mike

  39. Hi Jason,

    I think that Cedric was probably refering to XSL/XSLT rather than XML itself. Never the less splitting the hairs all the way: XML = eXtensible Markup Language :o)

    Seriously speaking, large projects are multi-language. You can't build the entire project leveraging only J2EE technology (well you can but it will be time consuming and expensive), you usually end up buying some off the self product that might just offer exclusively a C/C++ or COM API.
    You might want to use or already have some content management tool such as eGrail that is written entirely in Perl ...

    I enjoyed working on a large project where some people where using an app server, others perl scripts (eGrail in this case), etc, etc ... it wasn't funny then (now it is) :o)

    Therefore I don't think it's just marketing hype ...

    a++ Cedric (another one)
  40. cedric, "If you are writing J2EE applications, you are already using at least two languages (Java and XML) and probably much more (JSP, Javascript, and maybe even Perl, Python, etc...) "

    WHAT? Get a clue. In the .net world you'll be doing javascript and perl as well. JSP is not another language either.

    .net is a joke. It's nothing more than m$ trying to overpower quality with marketing hype.
  41. MS does have an O/R mapping solution that is in beta.

    Stef
  42. Posted by Stefan Mischook 2002-07-19 08:48:21.0.

    >MS does have an O/R mapping solution that is in beta.

    >Stef

    Stef,

    very interesting. Could you provide (a link to) some more information about this?

    Stefan Tilkov
  43. "very interesting. Could you provide (a link to) some more information about this? "

    It is called ObjectSpaces and was alvailable at the last PDC as technical preview.


    spare info: microsoft.public.objectspaces

  44. spare info: microsoft.public.objectspaces


    Thanks, but I cannot access anything at that address. Is this a news URL?
  45. but I cannot access anything at that address. Is this a news URL?


    news://msnews.microsoft.com/microsoft.public.objectspaces
  46. Thank you. I browsed through the list hunting for information about "ObjectSpaces" ... sparse info indeed. None of the links seems to work any longer.

    Does anybody have a (working) link to some technical documentation about this?

    Stefan Tilkov
  47. Does anybody have a (working) link to some technical documentation about this?


    An Introduction to ObjectSpaces
    http://hosting.msugs.ch/dotnetrox/articles/Art07.html

    Working with .NET ObjectSpaces
    http://www.informit.com/isapi/product_id~%7B5327F5A0-BB97-4365-9028-FFE5248EB73D%7D/st~281272C2-25BA-4446-AEE6-B140B462D2D5/content/index.asp
  48. Does anybody have a (working) link to some technical documentation about this?


    A rathar old presentation about ObjectSpaces:
    http://www.microsoft.com/seminar/mmcfeed/mmcdisplayfeed.asp
    "Advanced ADO.NET" 2002/02/11
    At about 32:20 is the part of ObjectSpaces. At 43:00
    there is a code example.

    And something about ORM, a database modeling technology by Dr. Terry Halpin
    news://msnews.microsoft.com/microsoft.public.visio.database.modeling

    Luoh Ren-Shan
  49. <quote>
    WHAT? Get a clue.
    </quote>

    I usually don't bother responding to people who open their posts with "get a clue" or spell "MS" with a dollar sign (what is this, high school?), but I'll make an exception this time.

    <quote>
    In the .net world you'll be doing javascript and perl as well.
    </quote>

    And this contradicts my statement in what way?

    <quote>
    .net is a joke. It's nothing more than m$ trying to overpower quality with marketing hype.
    </quote>

    Oh dear.

    --
    Cedric

  50. Cedric,

    Not necessarily responding to your last message ... but, please, try to make an effort to separate your lips from MS's a**.

  51. I for one am giddy at the prospect of being able to write enterprise systems in Prolog and ML. Are these ported to .NET yet :-)

    Joking aside, Purdy you don't seem to bad (shame you work for Darth) and I'm a lot less scared of the .NET threat now than before.
  52. His analysis of the the difference between XDoclets and C# Meta Attributes is a bit off. There's nothing in XDoclets that prevents attributes from being discovered in Runtime. It's simple just write tags whose values can be looked up in Runtime.

    His claims that Webservices, XML everywhere, Meta Attributes and Superior IDE are also far from the truth.

    (1) Webservices - Java webservice support is on par or even better than .NET. There are a multitude of vendors that specialize in webservice support i.e. themindelectric, capeclear, systinet, furthermore many of the big vendors (SUN, IBM, Oracle) and Apache have their support. In fact a recent survey from http://www.webservicesarchitect.com indicate much larger interest in Java for Webservices that .NET. Even a search in amazon shows that the most popular webservice book is for Java.

    (2) XML - Java XML support is superior. Is there an equivalent to Jaxen (i.e. XPath API) for C#? Navigating XML via XPath is orders of magnitude easier, does C# have the same thing?

    (3) Meta Attributes - XDoclets is more than adequate, furthermore there is a JSR proposed by BEA that will standardize this. Furthermore, a newly release JSR based on OMG MOF (i.e. JMI) give even greater capability with for managing metadata.

    (4) Superior IDE - Developers spend most of their time manipulating code rather than using Wizards. Java's IDEs (i.e. Eclipse, JBuilder, IDEA) have refactoring support that VS.NET lacks. Furthermore, the navigation and browsing capabilites of these tools are far more superior than VS.NET.

    In summary, most every you heard was marketing fluff.
  53. <quote>
    His analysis of the the difference between XDoclets and C# Meta Attributes is a bit off. There's nothing in XDoclets that prevents attributes from being discovered in Runtime. It's simple just write tags whose values can be looked up in Runtime.
    </quote>

    You can't, unless you have the source of the file you are trying to get attributes for, since they are not part of the class file.

    JSR 175 will fix that, but until then, we are left with kludges.

    --
    Cedric
  54. <quote>
    (3) Meta Attributes - XDoclets is more than adequate,
    </quote>

    Solutions like EJBGen or XDoclet are not more than adequate. They get the job done, but they would be much more useful and less kludgy if meda-data was supported natively in Java.

    <quote>
    furthermore there is a JSR proposed by BEA that will standardize this. Furthermore, a newly release JSR based on OMG MOF (i.e. JMI) give even greater capability with for managing metadata.
    </quote>

    Not quite. There are two JSR's in progress:

    - JSR 175 is the one everybody should support and be interested in, and it was initiated by Sun. It will make meta-data part of the introspection.

    - JSR 181 is the JSR you are referring to, and it was initiated by BEA. This JSR aims at standardizing meta-attributes for Web Services.

    --
    Cedric


  55. Cedric Beust wrote:

    <quote>
    Not quite. There are two JSR's in progress:

    - JSR 175 is the one everybody should support and be interested in, and it was initiated by Sun. It will make meta-data part of the introspection.

    - JSR 181 is the JSR you are referring to, and it was initiated by BEA. This JSR aims at standardizing meta-attributes for Web Services.
    </quote>

    There is also the JSR 40, covering metadata in a more general way.

    Stefan Tilkov
  56. <Carlos Perez>
    His analysis of the the difference between XDoclets and C# Meta Attributes is a bit off. There's nothing in XDoclets that prevents attributes from being discovered in Runtime. It's simple just write tags whose values can be looked up in Runtime.
    </Carlos Perez>

    He is right. In .Net there's a neat runtime API for handling metadata. You can do something like myObject.getClass().getAttribute("ejb:bean"). It returns the Attribute-derived class (say EjbBeanAttribute) then you can use the properties defined there. So there's a very easy to use Runtime API for accessing metadata at runtime, whereas in Java there's no standard API for working with metadata defined in deployment files and those files do not map to the attributes (@tags) directly.

    But anyway with XDoclet, from a user's point of view, you can basically do the same thing as .Net. So there's an answer from the Java camp to what .Net offers *right now*. And in some aspects it's superior to .Net. For example? Well, the community formed around XDoclet for example. We already have all kinds of @tags for various things. There are @tags for common stuff such as ejb/web-wars/webservices, OR tags for ejb/castoer/etc, basic @tags for i18n/javabeans/etc, and support for various app servers.

    Ara.
  57. Greetings,

    Very interesting interview. I am also glad that Doug Purdy has deep knowledge in both technologies J2EE and .NET.

    This interview just proved one more time that MS knows how to get more clients. While Sun was spending time to write "ideal" specification, MS wrote "ideal" tool that can be used in real life by the users to develop Web Applications, Web Services, etc. It is good example for Sun about how implementations should be synchronized with specification. I will not be surprised if in nearest future number of .NET developers will be larger then number of Java developers.

    Best regards,

    Taras
  58. I really like his knowledge of the J2EE world. I dont know many J2EE developers having this knowledge in .NET
    But its not astonishing at all, there are also some bright guys on the other side.
  59. I had the pleasure of meeting Doug when we did the Tech Talk. He was a real character, and *did* know his stuff.
    I was expecting some marketing monkey who didn't know anything but buzzwords :)

    With respect to the "multilanguages" side of things. We have this too! Jython anyone? There are a lot of others out there (mostly from academia and not used much).

    Technically: We both have a virtual machine

    Marketing: .NET -> Focus: Multiple languages
                       Quiet: Multiple platforms

               Java -> Focus: Multiple platforms
                       Quiet: Multiple languages

    Sure there are subtle differences in the virtual machine opcodes and such... but they are not THAT different.

    Both are good. We can learn from eachother and compete, ending with better platforms and tools.
  60. Regarding multi-language availability, look as IBM's BSF ( Bean scripting framework ), it supports a myriad of languages that are available for the JVM in a consistant manner.

    I think the biggest advantage of .NET is it does Windows native Look and Feel so much better than Swing.

    Maybe .NET will dominate client side and j2ee will continue to dominate server side?

    If MS want to have any chance on the server side they need to move their BSD porting efforts along, or throw some money at MONO and give people a non Win2K server option. But we know they won't be doing that as they see controlling the servers as important as controlling the desktops in their plans for market domination.

    The reality is that feature sets of any note can and will be copied by the opposition pretty quickly, its all turning machines under the hood :-)



     


  61. Couple of points not mentioned yet:

    Security.
    J2EE has an excellent track record with respect to security. Sun has well-defined boundaries for both client-side and server-side in what exactly a Java program can do. In my opinion, .Net has a flaw here. It still allows native OS integration via "unmanaged" code. Therefore, .Net written software will still continue to have buffer overflow problems.

    Intermediate Language.
    Pay close attention to what each "camp" stuffs inside of their intermediate language code (byte code for Java and MSIL for .Net). Consider what is put into MSIL in order to support multiple-languages. And this will get much worse as .Net supports more languages going forward.

  62. Joe,

    ".Net has a flaw here. It still allows native OS integration via "unmanaged" code. Therefore, .Net written software will still continue to have buffer overflow problems."

    Managed code can call out to unmanaged code - there are marshalling libraries and language constructs to help with this - but is this any different to JNI or Java's "native" keyword? How else do you interop with things like database drivers and window handles? How else do you bootstrap the runtime? I think it's very misleading to suggest that .Net code is susceptible to buffer overflows because of this - the weak point will always be native code (see the recent security notice about the ASP.Net ISAPI runtime, which is a native piece). Furthermore, allowing limited pointer manipulation in a managed environment is arguably safer than calling out to (eg) unmanaged C/C++, which would be the case with Java/JNI. It's certainly proving useful to me at the moment, building wrappers around DirectX.

    Really, the less C or assembler code I have to see, the better, but until there's widespread hardware (or at least OS level) support for the things that the Java and .Net runtimes do, interop will remain a necessary evil.

    As for the multi-language issue, I think non-OO languages will always be second-class citizens in .Net. There's a lot you can emulate (I think Eiffel has managed to hack-in multiple inheritance), but I don't think MS will spend too much time supporting more esoteric stuff in the future. IMHO, the multi-language idea was mainly a way to get a lot of language academics (like from the Scheme/CAML/Mercury camps) on-board as advisors in the early days.

    Jim
  63. Taras -
    The two platforms appeal to different personality types - some folks will go with .NET, others will stay with or come to J2EE. If there are more .NET programmers than J2EE folks it isn't that important - it wouldn't be that different to what the situation is now. I suspect (but don't know) that there are more VB developers than those who work with J2EE. And by the way, the goal and content of J2EE encompasses more than web applications and services.

    And the interview is certainly interesting....

    Cheers
    Ray
  64. Since a lot of things are more or less equal,
    can somebody provide information about
    expences (per item, or per item per year).

    Windows XP (need Pro?) - ????
    IIS - ????
    Visio -- ?????
    .NET platform - ????
    .NET Studio - ???
    SQL Server -- ???
    Version Control (SafeSource - ???) - ????
    Support - ???

    For compasion (VERY aproximate values):

    Low-end J2EE //////////////////////// high-end J2EE

    Linux - free
    ArgoUML - free ///////// RR or TCC - 10K / developer
    JBoss+Tomcat - free ///// WebLogic 10K / CPU (?)
    Eclipse+XDoclet+ANT - free // JBuilder 6K / developer
    CVS - free
    mysql - free ////////// Oracle - 15K /y per CPU
    Support - no support //////// ???????

    Did I miss something ???

    Thanks for any info,

    Alex
  65. Linux - free

    > ArgoUML - free ///////// RR or TCC - 10K / developer
    > JBoss+Tomcat - free ///// WebLogic 10K / CPU (?)
    > Eclipse+XDoclet+ANT - free // JBuilder 6K / developer
    > CVS - free
    > mysql - free ////////// Oracle - 15K /y per CPU
    > Support - no support //////// ???????

    You also have plenty of choices for J2EE solutions

    OS: Linux, Solaris, HP-UX, AIX, OS-X, etc
    Hardware: Sun, IBM, HP, DEC, Apple, Intel, etc
    EJB Engine: Oracle, JRun, WebLogic, WebShere, JBoss
    IDE: JBuilder, Forte, Netbeans, Eclipse
    Database: Oracle, DB2, MySql, Interbase, etc

    In every category, the user can make choices that best meet their needs rather than being confined in a proprietary straight jacket.
  66. You forgot to mention the six figure entry costs for Oracle
  67. Greetings, Ray,

    I agree with you, J2EE is much more then just Web Applications and Web Services. But (I think) 90% demand of the market is just for Web Applications - JSP/Servlets/JDBC. I think majority of the potential customers does not need full J2EE solution or can not pay for it. By the way, you do not have to use EJB to write on-line store or some other transaction-agressive system for web - you can do it with JDBC (it will take more efforts to build scaleble system of course). Plus, MS marketing approach oriented on non-technical management will do its job. Most managers does not care how system was build they care that it will keep working 24/7/356. They dont care about propritory solutions aspecially when each Workstation or Server in office runs Windows. We can keep this conversation forever but, my point is that Sun should spend more time to build implementations that will be user friendly and affordable rather then creating new specs. J2EE vendors does not have much time to implement spec while new version is comming up. And vorse situation with tools vendors. I think, unfortunately, no one J2EE development tool can compete with Visial.NET in subjects like performances and user intreface.

    Best regards,

    Taras
  68. J2EE vs. .NET[ Go to top ]

    Right on Taras. Sun's competitive problem vs. Microsoft is twofold:

    1) Specification-implementation impedance. To be an expert in the field, a J2EE developer has to master both the specification and its implementation(s). However, since in many if not most cases the application server and other supporting technology are fixed for the duration of the project, this double learning curve adds unnecessary intellectual overhead. Moreover, JSR specifications are prone to design-by-committee compromises and delays.

    Interestingly, the split between specification and implementation -- the justification of which is encouraging competition, which in turn should lead to better implementations -- has thus far failed to produce tools equivalent to Microsoft's offerings. J2EE development is still quite cumbersome.

    2) General confusion due to complexity. The array of buzzwords tossed around in the community can be staggering to a newcomer. The right technologies and tools often don't get initially chosen or at least their application will be suboptimal. There is sometimes confusion, or at least indecision, in the more experienced community, too (cf. Entity Beans vs. JDO vs. straight JDBC vs. O/R mappers). Sun has advocated EJB as a general middle-tier solution to building web applications, with disastrous consequences: the added complexity only pays off if you really need declarative transactions, security, pooling, and so on. Further examples of the tendency to cater for very complex projects include the Petstore application and the J2EE patterns literature -- sometimes I think those may do more harm than good for the average project, as people will indiscriminately over-engineer their solutions with the incorrect assumption that more patterns equals better software.

    Regards,
    Pietari Laurila
  69. J2EE vs. .NET[ Go to top ]

    Pietari,

    "1) Specification-implementation impedance. To be an expert in the field, a J2EE developer has to master both the specification and its implementation(s). However, since in many if not most cases the application server and other supporting technology are fixed for the duration of the project, this double learning curve adds unnecessary intellectual overhead. Moreover, JSR specifications are prone to design-by-committee compromises and delays."

    I've tried to say the same thing on TSS, but not nearly as well. I am committed to the J2EE camp, and accept the learning curve burden you describe as "worth it" to avoid MSFT lock in. I accept it, but find it very tiring. :)

    I thought you expressed your points very well, but I will take exception to your point about design patterns. I view design patterns as simply the new buzzword for selecting best practices and standards for your project. In effect, they are an attempt to narrow the possible solutions for your project, and therefore reduce complexity. Even a small project should benefit. All quality software development requires this process, or you will create a maintenance nightmare. Sure, alot of it is industry hype, but pick up a practical "real help" book like Floyd's, and it will serve as an incredible aid for a developer starting out. I think your complexity issue, may be one of those "pay me now" or "pay me later" issues. Using something like STRUTS and Session EJB facades will likely cost you more up front. But what about maintaining the application? JMO.

    Agan, good post.

    Mike
  70. Folks:

    Aren't we all working in the real world here? I am not a fan or opponent of either technology....I need the right technology to solve the problem and one that I can maintain for a few years without spending a ton of money. It's like buying a car for personal use. If you need to get from point A to B and have limited resources, you buy a Huyndai or Neon. If you have a lot of money, you may buy a Mercedes. If you have a need to do some off-roading, you may buy a truck. If you have mixed needs and enough money, you may buy a truck and a car. In the final analysis, you want to make sure that you don't pay more than you can afford up-front or pay too much for maintenance during the life of your ownership. You also want to ensure that there are parts and mechanics for that car in the market for the life of your ownership. So how is IT different? The key thing here is that one has choice. A rising tide lifts all boats.

    I see multiple languages in .NET NOT as an invitation or license to program in multiple languages within the same enterprise. It merely reduces the barrier to entry for an enterprise that may have a particular skill-base in house. Some may have only C++ programmers or only PERL programmers in house and yet want the benefits of .NET. These folks don't have to hold up their adoption of .NET because they have to send developers for training in some specific language first. Of course, if I were running this enterprise, I would ensure that we don't start programming in multiple languages just for the heck of it.

    Now look at it from the standpoint of the vendor. If you were building and selling a product and wanted the widest possible market, wouldn't you want to lower the entry barrier for your customers as much as possible within the limits of time, money and other resources available to you?

    OK, so MS has many langagues and technologies under one roof for .NET. That equates to Risk. Java has many vendors committed to it, but one vendor that it may depend on for survival. That too equates to risk. In the final analysis, I as a consumer of that technology would rather see both platforms flourish and survive and see the two camps collaborate like hell on Web Services that allow them to talk to each other.

    I sleep well at night. Technology is just a tool....not a religion :-)

    -RJ
  71. J2EE vs. .NET[ Go to top ]

    Mike contended above that, in effect, design patterns should be viewed as narrowing the solution space; and that choosing and using design patterns could be viewed as a "pay me now" or "pay me later" issue. If it only were so!

    First, if design patterns merely narrow the solution space by pruning out suboptimal solutions and by promoting good ones, one can reasonably ask why this narrowing was not done at the specification level, i.e., why the specification allows us to shoot ourselves in the foot. It is a well-established tenet of class API design that whatever you do with the API, it should not break anything. At least, the methods should throw meaningful exceptions. J2EE design doesn't do this: it leaves the solution space wide open, thereby creating the need for pattern and other "best practices" books. But this should be viewed as the failure of the specifications themselves; patterns are not specification fixes. The role of a pattern, quoted from Marinescu's book, is to provide a "best practice solution to a common recurring problem". That problems should be manifest in J2EE itself would hardly qualify as acceptable to me.

    That said, pattern books clearly have value in helping people avoid the most common pitfalls.

    With the second point, that patterns might be viewed as a "pay me now" or "pay me later" issue, I have to disagree in the spirit of agile methodologies. It is best to build what the customer needs today, with only a little thought to future needs, as those needs might change, which might very well invalidate any patterns speculatively inserted into the software. I think Martin Fowler said it best in his "Refactoring" (if memory serves me correctly): when it is easy to change it in the future (i.e. most of the time), just implement it in the simplest way. That "pay me later" scenario might never materialize.

    I shall illustrate my points -- the unfortunate impression that pattern books can inflict on the mind of the unexperienced developer -- with an example from Floyd's "EJB Design Patterns". That example is the Session Facade pattern, arguably one of the most fundamental EJB patterns in existence. In the book, Floyd writes that some of the problems with a JTA transaction demarcation approach include:

    * High network overhead
    * Poor concurrency
    * High coupling
    * Poor reusability
    * Poor maintainability
    * Poor separation of development roles

    According to the book, the Session Facade has the following advantages:

    * Low network overhead
    * Clean and strict separation of business logic from presentation layer
    * Transactional integrity
    * Low coupling
    * Good reusability
    * Good maintainability
    * A clean verb-noun separation

    Now, without a doubt, in certain circumstances all of these are true, and I suspect the number of points which do hold correlates positively with the complexity of the project. But for specific projects, the Session Facade pattern may not be good at all. Why? First, these kinds of patterns enforce the mistaken notion that "every coarse-grained function should be an EJB method", a common fallacy among novice developers. High network overhead is not an issue for web sites where the tiers are co-located; this remotely resembled a problem because EJB1.x didn't have local interfaces, which are a superior design anyway. Similarly for poor concurrency. The problems brought about by high coupling can certainly be severe as the complexity of the application increases, but on the other hand, for simple applications it sometimes just doesn't matter, and besides doesn't the coupling just move from the servlet (or Swing app) to the session facade? Reusability is such a buzzword of unfulfilled promises that 90% of all projects can simply ignore it. (It's not impossible, it's just damn hard, i.e., usually uneconomic.)

    As for maintanability, this is actually the session's facade main tradeoff -- and sadly this is not properly elaborated in the book, misleading inexperienced developers into pattern euphoria where none is due. A few months ago, a study was published that compared the relative performance of pure servlet, session bean, and session facade implementations. More interesting than the performance results were the relative LOCs (Lines of Code) that the implementations had. The session facade implementation comprised about 11,000 lines of code as opposed to less than 5,000 lines for the pure servlet implementation (if I remember correctly). It is hardly new that the maintainability of a program inversely correlates with the number of lines it contains. Since the 11,000 lines moreover contained an elaborate design pattern (with regard to its justification of existence), one can venture which solution in this case was more maintainable.

    The preceding is an isolated example, but it is clear that the Session Facade pattern leads to a greater amount of code, which then has to balanced against any other benefits it offers. And the Session Facade is only one example of the pattern hype -- which, when the pattern is not properly evaluated against the case at hand, leads to blatant over-engineering. Most significantly, this over-engineering is not warned against in the patterns literature, and this leads to my conclusion that patterns may increase, rather than decrease, confusion in the J2EE community. Any misapplication could be said to be the fault of the developer, not of the pattern. But this only true to a degree; if the pattern does not explicitly mention where its boundaries of application lie, then the pattern-writer is equally at fault.

    I love patterns as much as the next guy, but they are not substitutes, or fixes, for bad design in the platform itself (cf. how to write EJBs "properly"). We should instead be asking how to redesign the platform itself so that such "narrowing" patterns wouldn't be needed in the first place. The failure of the J2EE pattern literature to explicitly delineate the boundaries and tradeoffs of its patterns can, in the wrong hands, only lead to over-engineered, expensive solutions that are difficult to understand and maintain.

    Regards,
    Pietari Laurila
  72. J2EE vs. .NET[ Go to top ]

    Pietary,

    a very interesting post. I'd argue that the difference in lines of code in the study you mention is the result of a poor development process, but that's a different issue (discussed e.g. in another thread here on TSS.) Could you provide a link to that study?

    Apart from that, applying patterns blindly is certainly as bad as not using any at all. But the prerequisite for applying the pattern - as described in Floyd's book - is that an EJB client wants to "execute a use case's business logic in one transaction and one bulk network call". If that's not the problem you want to solve, i.e. if you have (possibly wisely) decided on a different architecture, you don't apply the pattern.

    I don't think you can blame the spec for giving you more than one option.

    Stefan Tilkov

  73. J2EE vs. .NET[ Go to top ]

    Pietari,

    I love the way you write, but I think you gave a brilliant response to points I did not make. :)

    You said:

    "Mike contended above that, in effect, design patterns should be viewed as narrowing the solution space; and that choosing and using design patterns could be viewed as a "pay me now" or "pay me later" issue. If it only were so!"

    I stand by that, but let's clarify it a bit, because I think you missed my point. I'm talking from a project perspective. I have a desire to narrow my projects "Solution space". Standards always "cost you more up front" but "you pay alot less later compared to every programmer doing their own thing". I'm including design patterns as a part of the formulation of project standards. You aren't against sitting down early on in a project to choose technologies, and then apply some form of standard usuage rules for your project, are you? This isn't the same as saying "everything should be an EJB" or "you have to use the Session Facade" pattern. My point is that "bad project standards" beat the heck out of "no standards", any day, any project.

    Although I'm inflexible on the project standards issue, I'm very flexible on changing to the next "best mousetrap" when it comes along. Maybe I make a judgement call on my current project that Session and JMS facades will be a part of our project standards. By the next project, or even in some cases on the current project, if someone brings a better technique to the table, I will be the first to adopt it, and drop the old techniques.

    "But this should be viewed as the failure of the specifications themselves;"

    That makes no sense to me. No language or platform dictates how you use it. I guess one could wish for less complexity (I do), but what does that have to do with design patterns or best practices? Maybe your point is we would have to spend less energy coming up with these techniques if the platform and spec were simpler. Maybe, but no matter where that line is drawn, the developer and the industry will still need to evolve "best practices". Maybe you can clarify.

    Mike
  74. J2EE vs. .NET[ Go to top ]

    Replying to my patterns post, Stefan asked for a link to the study I was referring to. The study is here. As it turns out, the size difference between a servlets only and a session facade solution is even more striking than I remembered: 4590 vs. 13440 lines. The number of classes is 25 for the servlet solution and 109 for the facade, an increase of more than 300%.

    Stefan then pointed out the prerequisite of the Session Facade pattern: the pattern applies when an EJB client wants to execute a use case's business logic in one transaction and one bulk network call. Merely reading this precondition verbatim is not likely to keep developers out of harm's way, however. They may be lured into thinking that transactions are a universal norm, as it were, even if many applications, being read-mostly in nature, could do without them most of the time; the more so because Floyd illustrates his points with a banking example where transactions are clearly needed. The bulk network call concept can similarly be misinterpreted. If all you have is a web site, i.e., no Swing clients, you can use a plain Java class to coordinate your other classes and dispose of the pattern entirely.

    Discussing unnecessary flexibility offered by J2EE specifications, I wrote, "But this should be viewed as the failure of the specifications themselves". To take an analogy from class design again: the objective is to strive for interfaces that are complete and minimal at the same time. I originally learned this guideline from Scott Meyers' classic Effective C++: on page 78 of the book Meyers observes, "On the one hand, you'd like to build a class that is easy to understand, straightforward to use, and easy to implement. [...] On the other hand, you'd like your class to be powerful and convenient to use, which often means adding functions to provide support for commonly performed tasks." Applied to specification writing, these concepts imply culling out the less useful features, and making sure that what remains is versatile yet easy to understand and apply.

    There will doubtless always be room for patterns and best practices; my only point is that a specification in itself should sufficiently limit the solution space, which the EJB specification does not, and at the same time be reasonably complete. Perhaps some examples will help:

    1) The Business Interface pattern from Floyd's book. Understanding the justification of this pattern requires some reading and deliberation. Also, the pattern is not immediately necessary or obvious, which confuses people by giving them many options to choose from. If the EJB specification for example mandated XDoclet-style method tagging, this pattern wouldn't be necessary.

    2) Entity Beans. Pushing a semi-mature specification as an industrial strength solution to modeling entities in an object-oriented fashion has certainly increased developers' intellectual burden for little benefit and a great many outright failures. The specification tried to cover too much ground too early, expanding the standard solution space (design alternatives) unnecessarily. Note that due to the official status of the specification, this is different from 3rd party solution development, where experimental approaches are necessary for innovation.

    Related to this is the JDBC for Reading pattern from Floyd's book. The three justifications that the pattern offers for its existence seem to be specification failures, since the aim of entity beans as I understand it was to eliminate the need for straight JDBC (with CMP) and to obliterate row-level thinking. Now we have to evaluate for each entity whether it would be prudent to make it an Entity Bean or not.

    Similar arguments hold for the Dual Persistent Entity Bean pattern, again from Floyd's book. The distinction that the EJB specification offers between CMP and BMP is probably largely unnecessary, as BMP entities are unfortunately relatively useless due to design faults documented elsewhere. But regardless, some people will speculatively use this pattern "just in case". If the specification didn't contain BMP, this pattern would never have been written. (As a remedy, I believe the current BMP should be clearly deprecated.)

    3) 7.5.8 of the EJB specification (2.1 Public Draft). The freedom that container vendors have with stateful session bean concurrency (as defined in Note 7) is, in my view, unnecessary and highly detrimental. I recently wrote to the JSR 153 Expert Group about this; no reply thus far.

    In summary, the specification should be kept minimal, only relatively proven designs should be written, yet the specification should cater for 90% of the community for 90% of the time. This is what EJB, the pattern literature around it, and Sun's advocacy efforts do not do as well as they could. Going forward, right-sizing J2EE as Jonathan suggests above will indeed have to play a greater part in the community's collective knowledge-gathering efforts.

    Regards,
    Pietari Laurila
  75. J2EE vs. .NET[ Go to top ]

    <quote>
    There will doubtless always be room for patterns and best practices; my only point is that a specification in itself should sufficiently limit the solution space, which the EJB specification does not, and at the same time be reasonably complete.
    </quote>

    I don't agree that a specification should always limit the solution space - I believe the developer should do that. Developers should always be given enough rope to hang themselves, as it were.

    In the .NET/J2EE debate or even in general discussions of J2EE itself, a concern is always raised that the J2EE developer is uneccessarily burdened with complex, hard-to-learn specifications and how easily the developer might wander off and over-architect a given business solution. In my experience that was more prevalent in the earlier days of J2EE and much less so now. Now developers and architects appear knowledgable enough to know when to use a given J2EE component and when not to. Certainly if everyone used entity beans for every solution, they would be doing everyone a disservice. I don't see that in practice.

    Cheers
    Ray

  76. J2EE vs. .NET[ Go to top ]

    Pietari,

    Your argumentation is clear and only too true, I absolutely second it. And yes, I also second Jonathan's "right-sizing for various scenarios" argument: The menu of best-of-breed technologies compiled into one page is a neat idea!

    Of course, complex problems need complex solutions. But especially EJB is far too complex for the common problems that developers have to cope with. It should be some optional package that you resort to if you really need distributed components and/or declarative transactions. Just like JTA is there for you if you need distributed transactions, JMS if you need asynchronous messaging, JMX if you need manageable components, and JCA if you need transactional legacy integration. Finally, of capital importance: EJB should be promoted that way instead of celebrated as the core of J2EE!

    Instead of the current over-engineered PetShop with ridiculously little functionality implemented using an extremely proliferated application structure and a myriad of design patterns, there should be best practices for right-sizing an application to achieve an appropriate solution for the problem you are facing.

    You can implement a clean application architecture with a very clear separation between tiers and/or modules without using an EJB container at all, and IMHO you should do it that way if there is no need for EJB. Concerning the particularly popular "just in case" argument: It shouldn't be too hard to refactor wisely designed plain Java services into Session Beans or export them as Web Services. Don't introduce overhead if you don't need to, and keep your options in other directions too: You might need your business logic in containerless standalone applications, for example.

    For most web applications including Web Services, a good Servlet container is a reasonable choice. Containers like Resin give you everything you need for database-driven web apps at a great price, including a JNDI environment, pooled JDBC DataSources and JTA support. If you need JMS beyond that, for example, then integrate a JMS provider. If you should really need an EJB container at some later stage, you can migrate to it with relatively little effort: IMO such options of refining and evolving your application are the real promises of J2EE, instead of a priori consideration of every possible demand.

    In a nutshell: EJB's officially claimed "industry standard for writing reusable business logic" status should be converted to what it de facto is: the "Java standard for writing distributed transactional components". The "one size fits all"/"core of J2EE" PR does more harm than good. OK, maybe it drives more people into J2EE courses like TheServerSide's, but that may be the only upside ;-)

    Regards,
    Juergen
  77. J2EE vs. .NET[ Go to top ]

    A recent gripe about EJB:

    "3) 7.5.8 of the EJB specification (2.1 Public Draft). The freedom that container vendors have with stateful session bean concurrency (as defined in Note 7) is, in my view, unnecessary and highly detrimental. I recently wrote to the JSR 153 Expert Group about this; no reply thus far." -- Pietari

    I think the intention might be to more or less guarantee thread safe invocation of the business logic. This is a perfect example of how a little extra prerequisite has value.

    Certainly, the JSR should mention the reason for the concurrancy limitation, but the JSR doesn't. How sad.
  78. Taras - Greeting from Denver.

    I have to disagree with you: Most managers I work with DO care about proprietary solutions. Especially in this day and age. The MS marketing approach is to beginning developers, existing VB developers, and non-technical managers as well as all-MS shops. I haven't ever worked in an all MS shop, I'm not a beginning developers or exisiting VB developer and I am not a non-technical manager. Their marketing doesn't work for me. And I have found (though not always, for sure!) that most non-technical managers know enough to ask more technically oriented people about such issues.

     I have been using J2EE for over 2 years - I feel pretty comfortable with it. Maybe its just that I am used to it, but the tools I use are plenty user friendly.

    The .NET side of the .NET/J2EE debate always talks about how expensive J2EE developers are, how difficult J2EE is to learn, and how user-unfriendly the tools appear to be. As a J2EE developer, I like costing more than the average VB programmer. I also like the wide range of tools I can bring to the fore on any project, be it a web project or a full-blown enterprise app with EJB 2.0CMP/JMS/ETC, on any platform. The tools that I use are at least as effective (to me) as anything MS has to offer, though I haven't looked at VB.NET (and being easy to use is not an incentive to me to go try it).

    And also, ALL managers I work with care a great deal how the system is built - it's partially their ass on the line if it doesn't work.

    I work with an excellent technology that works on all platforms, including Microsoft. It is available at many different price levels, and has many tools to work with. Why would I want to move to something that offers (in my opinion) less? In my mind there haven't been real solid technical arguments to change platforms - just statements about how easy VB.net is and how easy it is for beginning developers.



    Cheers
    Ray
  79. Interesting that when asked to identify some benefits of .net over j2ee, we no longer hear benefits of cost, speed, scalability, robustness, etc. Now it's more along the lines of multiple languages (as long as they end in ".net") and "because we use xml everywhere". In contrast to another comment posted here, I get more of the impression that Mr. Purdy's knowledge of .net and j2ee is not deep, but rather superficial...which is pretty much what I'd expect from an evangelist/marketing type.
  80. It's funny that he described himself as an evangelist. Here's one definition: A traveling preacher whose efforts are chiefly directed to arouse to immediate repentance.

    All I know is that the first step for Microsoft is to repent. I've been averaging a new security patch download per week (for my windows 2K machine). I think that the biggest problem for .net is that it runs only on Microsoft OS (and that it is a Microsoft product).

    Sam
  81. On the same note, I will be doing a webcast comparing .NET and J2EE. Obviously I will be trying to highlight the .NET side, but on the other hand we will try to keep on plain technical facts. You are invited to join the event at: http://www.microsoft.com/usa/webcasts/upcoming/1025.asp

  82. From a technical point of view, I can accept that Microsoft are beginning to shape a platform with some technical merits - a far cry from the days of com and vb.

    I'm not really sure it's necessary, considering J2EE is already here and proven - it would have much nicer if MS had shown a little co-operation and helped to work with J2EE and the rest of the community in developing the technology forward.

    But technical issues are not enough, and everyone seems to be focussing too much on them. No matter how good, and powerful, and fast and intuitive .NET is. Even if it grows to be better and more pleasing to develop with than J2EE, several factors still remain, without a solution to which .NET will be completely ruled out as a usable solution, irrespective of it's technical merits:

    1. Cost. MS costs lots and lots of cash. If you're a big bank with money to burn, fine. If you're a small player, forget it...
    Think about those developing countries, those small startups.. there's NO WAY they can afford MS, so it's a non-starter.

    2. Tie in. To have no control over the source. To be at the mercy of technical support and have no power over bug fixes.
    For your systems existence to be at the mercy of MS changing the infrastructure and priceing policy at the next release.

    3. Moral/ethical validity. MS have consistently given the finger to the community at large, squashing competition, and using the power to quash, control and stifle innovation.
    They are only happy when they have it THEIR way.

    So, in summary, I welcome the technical development of .NET and look forward to educating myself with it's technical merits.

    But until the above points are addresses, and until MS stops acting like the Al Qaeda of the software business, terrorising and destroying all in it's way, then myself and millions like me will be steering well clear.

    I dearly long for the day when MS decides to play fair on the pitch, then their products can be considered on their technical merits alone, but I fear that dayis long off...
  83. "1. Cost. MS costs lots and lots of cash. If you're a big bank with money to burn, fine. If you're a small player, forget it...
    Think about those developing countries, those small startups.. there's NO WAY they can afford MS, so it's a non-starter."

    It's funny you mention this because Objeq, the company I work for (and where I own a small part), is a small start-up (50 people now, from 4 people four years ago) based in Ecuador, a developing country in Southamerica. So far, we have had no economic problems using .NET in our projects. Before you start thinking we have kind of sold our souls and minds to Microsoft, please take notice that roughly half our revenue comes from Java projects (and Microsoft knows it).
  84. 50 people is not small.

    So you have all the proper licenses for all your Windows machines and all the proper licenses for each copy of VS.Net (unless you are just using a text editor/other tool)? Where you always properly licensed? How much does that run? Did you buy the "software assurance"? For Office automation and email(etc) you probably will need Office and Exchange. Tack that on and what do you have?
  85. Hi Mark,

    "So you have all the proper licenses for all your Windows machines and all the proper licenses for each copy of VS.Net (unless you are just using a text editor/other tool)? Where you always properly licensed? How much does that run? Did you buy the "software assurance"? For Office automation and email(etc) you probably will need Office and Exchange. Tack that on and what do you have?"

    It would be a pitty to transform this very interesting thread on .NET vs. J2EE technical merits into a "Why not to work with M$" or a "M$ licencing stinks" discussion. I mean, these by themselves are very important matters to discuss but I think they are off-topic in this thread. Please note that I guess I am a strong defender of .NET architecture and may be even of its prices and licencing model, about other Microsoft products I haven't said a word...
  86. <It would be a pitty to transform this very interesting thread on .NET vs. J2EE technical merits into a "Why not to work with M$" or a "M$ licencing stinks" discussion.>

    True. I was just following up on your comment. You said it had no affect. I want to know if you realize how much it costs you and your customers to use MS products.

    MS can charge anything they want - they have that right.

    Okay, the part about this being an interesting thread isn't true. It just shows how gullible and shortsighted people are. "Those who don't learn from the past are doomed to repeat it." MS.Net is a neat technology. Unfortunate the issues are much greater than that.
  87. btw, is Doug Purdy related to the Cabbage Patch kids ?

    Cabbage Patch Kids:
    http://bobcat.bradley.edu/~ambiree/Jul21$26.JPG

    Doug Purdy:
    http://www.theserverside.com/events/index.jsp


    Hmmm...
  88. I like Doug. He comes across as an articulate guy who works hard to promote the architecture of the company he works for.

    I sense that there is still good in him. If we can trun him to the good side of the force, he can be a powerful ally.
  89. Folks,

    I have been saying this to a lot of my friends and foes on the other side that the biggest feature of .Net(multi-language) that MS is promoting, would end up being the biggest bomb shell for corporations if they choose to buy into what MS is selling them.

    Someone else also made this point above and i totally second that. Multi-language support doesnt buy you anything except complexity, maintenance nightmares and other management issues.

    But at the same time, I would like to give credit to .Net where it deserves. Stuff like meta-data support, built in XML support, from the point of view of Web-Services and XML data-stores, is kinda cool. Also i have been impressed by ADO.NET. Has a very strong API, to do lot of fun stuff.

    Here in defense of Java world (since thats what i do), i would like to add that these bits n pieces (meta-language, wide range XML Suppport) will be added to the language and made integral part of the langauge. So will additions continue to the .Net platform too. Thats what makes technology so dynamic. It has to evolve and will keep evolving.

    I think this discussion was very good. Its very appreciative that Doug could come on here and talk bout .Net in comparison with Java/J2EE. However i still dont buy on Doug's or MS's suggestion on a "pure" Stored Procedure based architecture. I have been through it numersous times and its not the best option.

    For now though, I am very happy with the results and the output we have got back from Java/J2EE related technologies and continue to stick with it.

    Kapil
  90. Nice interview, very enlightening. Doug Purdy knows his stuff, he's far more aware of the ins and outs of J2EE that I expected.

    He made some very good points which really struck me as astute. The first was the decision in .NET to place less emphasis on the deployment descriptor, such as removing the transactional semantics and putting them into the source code instead. i think that's a very good idea.

    Also, the stuff about "reflective emissions" (I think that's what he called that), where you can generate new code at runtime based on reflective information - that's neat.

    My opinion of MS just went up a notch.
  91. Kenny,

       These abilities already exist within Java/J2EE and has been for a while. Unfortunately, we don't have the marketing might of Microsoft.



    Kenny:
    NET to place less emphasis on the deployment descriptor, such as removing the transactional semantics and putting them into the source code instead. i think that's a very good idea.

    me:
    Take a look at doclets.

     
    Kenny:
    Also, the stuff about "reflective emissions" (I think that's what he called that), where you can generate new code at runtime based on reflective information - that's neat

    me:
    Take a look at jython.


    Kenny:
    My opinion of MS just went up a notch.

    Me:
    My opinion of Java is still up a notch.
  92. Nothing new. The message of this interview was:
    "If it is an executable, it is a web service."

    I do not know what people mean that Doug has superior knowledge of .NET and Java (or J2EE)? I don't mean that he does not, but what comes around in this interview does not require very much knowledge at all.

    A few things that I see better in .NET world are:
    - ADO.NET (vs. JDBC which remainds me a lot of the days of old ADO)
    - ASP.NET (vs. JSPs that are much like old ASP pages)
    - Easier for beginners (vs. Reading all the specs and find out how to configure (deployment descs) everything)
    - Attributes (this is the most advertised feature in .NET against Java (besides multi-language support (yes there is java bytecode compilers for at least as many languages as for .NET) and SOAP everywhere, of cource)

    I have quite a long background with Microsoft's technologies and I know how the things are done there. Currently I am mostly a Java developer and the differences are not very big. I do not use entity beans, JDOs or any other or OR-mapping tools. I do need that another layer between my data access logic and business logic. If I need some weird data access I can use dbms features for that (some of you might argue this).

    MS tries to delivery you all in one package. At least I do not think that some other 3rd party tries to implement (not with success) another distributed transaction manager, connection pool, queue engine, database abstraction layer or any of the core components that .NET Enterprise Services delivers you. Maybe you can choose a different DBMS if you like. If you compare this to SUN's strategy that is to deliver specs and let the 3rd partys compete, you'll soon find that there is many more components that you can choose from than with .NET. For example web-frameworks... in .NET you have ASP.NET + Web Controls (someone might try to develop another framework on .NET, but I think that it is going to be tough to compete with ASP.NET... maybe 3rd partys will provide Web Controls as they have provided ActiveX Controls). With Java you have WebWork (my favourite), Tapestry, Struts, Turbine, WingS, ... this list is endless. I do not know which one is better, but nowadays I feel more confortable with Java (in good and in bad).

    If you don't understand a word... all I can say that it is 2.30 AM o'clock and I'm a little bit tired and drunk, so let is be my excuse.
  93. Some observations/opinions:

    1) interview - good (actually, excellent)
    2) haircut - bad
    3) having language choice for server side programming - good
    4) using more than one language for your server side programming or your project - bad
    5) assembler.net - LOL ... I just peed on myself
    6) not having a seperate component type for async messaging - good
    7) not supporting container managed persistence - good
    8) logically partitioning server side but not physically - good (guess that one could depend on app)
    9) dividing developer and deployer (admin) semantics - good
    10) app semantics discoverable at runtime - good
    11) code attribute driven vs descriptor file - don't care as long as it works

    And the final thing that really matters

    12) married to MSFT for life - bad

    Cheers,

    Mike
  94. I think the interviewer might have gotten BEA's positioning a little bit wrong. The question to Doug was that BEA claims its Web Services are similar to .NET. Actually BEA was talking about WebLogic Workshop as being well suited for the VB crowd - those software developers tha prefer a scripting-language tool over an object oriented language.

    .NET's hidden flaw is its dependency on object oriented structures. I went to VBits last October and got a chance to talk to a bunch of Visual Basic developers who attended Microsoft's .NET day. A common issue I heard from VB developers is they got lost when the examples had a lot of object oriented techniques in use. It's not that they didn't want to learn OO but many weren't there yet.

    -Frank Cohen (http://www.pushtotest.com)
  95. I really agree with this.
    The reality of multi language support is that VB.NET is NOT VB and ASP.NET is NOT ASP.
    So for an oo developer it is like choosing between, to say, Object Pascal and C++, different syntax but almost the same thinking model.
    For another type of developer...I don't know if it is so simple
  96. Mr Purdy, If you are reading these comments, I would like to ask some questions...

    1. If I choose to write programs in .Net and all my programmers are say procedural Cobol programmers, will I have to teach all of my programmers OOP and the core libraries of the .Net framework to convert to Cobol.Net?

    2. If I then write programs in Cobol.Net, will my programmers have to adapt the syntax to match the requirements of the .Net framework after working with microfocus Cobol? if so what would you say the learning curve is?

    3. Will my programmers still be able to bypass some the .Net functionality to access a legacy of libraries written in procedural Cobol built up over the years. furthermore can I access the most powerful functionality of procedural Cobol, bypassing the .Net framework?

    4. Does .Net run on an AS/400 as used by most of my clients that run my procedural Cobol solutions? Will I be able to Scale .Net across 100+ processors on my mission-critical Sun-Box as I can with Java applications?

    5. Why should I endorse a proprietary product using proprietary technology from a monopolist when I can choose the best of Breed product capable of running on the hardware/OS platform of my client's choice EVEN if it is Windows?

    regards.

  97. Hi Anon Ra,

    "Why should I endorse a proprietary product using proprietary technology"

    Let me guess, the Sun specs aren't proprietary? <chuckle>

    You're sending the discussion askew, what's interesting here are the features. It's an interesting marketing strategy to demonize a company rather than talk shop.

    The bottom line is that things are damn easy in the MSFT world, writing a web service is fingers in the nose for any dodo ... in the j2ee world it's a nightmare although it's getting there.

    I'm not an .NET expert but from what i've understood:

    1/ No in theory but you'll have to teach them how to use Dev Studio product (slightly different from vi ;o) )
    However knowledge of the .NET Framework librairies is required if you want to leverage .NET functionnalities.

    2/ COBOL is a specification, either you stick to the spec, either you don't. Your question is biased ... replace the .Net framework with some other vendor product, say NetCOBOL for the fun of it :o)

    3/ First part is yes. Second part ... what do you call powerful functionnality of procedural COBOL?

    4/ What's the link between running .NET on an AS/400 and the scaling issue?
    You can using Integration Server access ressources running on an AS/400 but you don't have (to my knowledge) a .Net Server available on the AS/400 platform. Of course you could get the specs and implement one as an opensource project :o)

    My wood to the fire ...

    a++ Cedric
  98. <>The bottom line is that things are damn easy in the MSFT world, writing a web service is fingers in the nose for any dodo ... in the j2ee world it's a nightmare although it's getting there. <>

    No its not. Pick better tools.
  99. <quote>
    The bottom line is that things are damn easy in the MSFT world, writing a web service is fingers in the nose for any dodo ... in the j2ee world it's a nightmare although it's getting there.
    </quote>

    I'm not so sure that your statement is exactly a ringing endoresment of the MS world. By the way, Mark is correct - pick better tools. J2EE isn't rocket science nor is it a nightmare, although given the above statement, perhaps the nose-picking dodos that find MSFT so easy may have a harder time. (Just having fun here ;-)

    Cheers
    Ray
  100. Looks like we have the Microsoft .Net crowd on the run.

    They can't compete with J2EE so they have to make up bogus claims about J2EE being more difficult.

    Servlets, JNDI, JSP, JDBC are all members of the J2EE family and these are so easy that even Dumb and Dumber can develop with it.

    EJB takes a little understanding but still not too difficult. If you have a problem understanding EJB, stop whining and read the following free book.

    The IDEs like JBuilder makes creating EJB's so simple that even Forest Gump can do it.

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

    .Net can't compete with J2EE for enterprise develoment beacuse it locks you into closed Microsoft properietary technology. It locks you into Windows XP. There are doubts about its security. And the developent recommedations from Microsoft about putting the business logic in the database makes the architecture suspicious. It also highlights Micosoft's lack of experience in this fireld.

    J2EE is mature and every feature you could possibly want is available now. You can participate in a community process to direct the future path for J2EE, and the whole thing is designed from the ground up to be secure.

    Enough said. There are always people who will blindly follow Microsoft. To those people, I say, "Get a squeegee because you will need it so you can run out into the streets to wash car windows for tips when you loose your jobs because you picked an unsecure, closed, dead end technology."
  101. <quote>
     <>The bottom line is that things are damn easy in the MSFT world, writing a web service is fingers in the nose for any dodo ... in the j2ee world it's a nightmare although it's getting there. <>

    No its not. Pick better tools.
    </quote>

    My pay check every month comes from J2EE development... but when I messed around with Web Services I was very impressed with what the .NET guys had. Maybe I am being ignorant here but this http://homepages.nildram.co.uk/~newbolds/index.html
    is me writing and debuging a "hello world" web service in Visual Studio. Can anyone show me doing something as straightforward in J2EE. I found myself having to download this and that, update path statements etc. when I had to do the same in the environment my boss was paying me for.

  102. GLUE: http://www.themindelectric.com/glue/index.html

    It's easy! It's free! It's small! And it runs on any platform! What about Visual Studio?

    The cool thing about Java is that you don't hava to use the tools Sun provides you. Other people out there make very reliable, very cheap, easy-to-use tools.

    Ryan
  103. The SOAP tools from Sun, IBM, Apache suck (at least the last time I tried them they did). They don't 'get it' in terms of making things easy to use.

    GLUE on the other hand is a pure joy to use it is soo easy (create a web service in a few lines of code, assuming you have an existing class you want to expose that is). I have used it in a large commercial project and it was awesome. I'm sure there are others like it too and probably the other ones I mentioned and tried some time ago are getting better all the time as well.

    That's one of the great things about J2EE is that you have choice and there are many many vendors and tools available.

    Cheers.
  104. Future of Java[ Go to top ]

    I love Java despite the fact that EJBs (and entity beans in particular), are a little clunky.

    But there is something that worries me more than any of the technical arguments I've read in this thread (and many of them have been interesting to read).

    Sun stock has fallen from a high of about $63 a share less than two years ago to $3.95 this morning. BEA (weblogic) stock has fallen from a high of around $82 a share to $5.97 this morning.

    Compare this to Microsoft whose stock has only fallen from around $80 a share two years ago to $43.25 this morning.

    Given the devastating drops in Sun and BEA market capitalization, I am a little worried about the future of J2EE, and frankly, our beloved IT industry in general.
  105. Future of Java[ Go to top ]

    A company's stock price only represents investor sentiment (feelings, mindlessness, etc.) not actually how well the company is doing.

    Java is greater than Sun.

    Sun and Bea are not the only players in Java.


    I too am worried about our 'IT' industry.

  106. Future of Java[ Go to top ]

    Jeff -
    I don't think the stock prices of Sun or BEA indicated negative news for J2EE - while J2EE is certainly driven by Sun, it is more than the sum of the parts, if you will - it is a much larger industry initiative than, say, Microsoft .NET, which is a single company's initiative. J2EE I believe has the momentum to survive rough times by Sun or BEA or any of them. I think IT will itself turn around given time - companies will need more IT in the future, not less. Information is still King and J2EE in particular is situated such that it can help companies gather, analyze and distribute that information.

    Just my thoughts -
    Ray
  107. Future of Java[ Go to top ]

    Jeff, you're economics logic here doesn't make a whole lot of sense, kind of a non-sequiter. First off, Market capitalization is rarely a good economic indicator of a company's viability. How much of their stock price and price to book ratio is made up of real assets (return on assets) and how much is made of "concept."
    Stock prices aren't solely made up of real assets, a large portion is made up by the undefinable: Executive knowledge, public trust, intellectual property, market momentum, share, about a million other things, including advisory ratings based on publicly available information.

    Software companies especially tend to have a price to earnings that is driven largely by intangibles.


    -Newt
  108. Future of Java[ Go to top ]

    <quote>
    Software companies especially tend to have a price to earnings that is driven largely by intangibles.
    </quote>

    True. And it seems that Sun and BEA don't have many intangibles attractive to investors. ;-)
  109. Future of Java[ Go to top ]

    <quote>
    True. And it seems that Sun and BEA don't have many intangibles attractive to investors. ;-)
    </quote>

    Sun is more heavily weighted on hardware, but they and BEA have been hit by poor business spending and a fear of investing in the internet economy. I like Sun and BEA long-term as people realize that the internet economy is a good idea (just have a business plan with profit in mind, this time). Microsoft provides diversified software for the corporate client-side, along with its .NET offering for serverside stuff. Widespread adoption of .NET remains to be seen - but companies are always going to by Microsoft Office and Windows 2000\XP for their employees. Therefore I wouldn't expect Microsoft's stock to take such a large plunge as compared with BEA/Sun. That said, J2EE is very much still alive and kicking and will be for quite some time.

    Cheers
    Ray
  110. Future of Java[ Go to top ]

    This is extraordinary.
    <quote>
    Sun stock has fallen from a high of about $63 a share less than two years ago to $3.95 this morning. BEA (weblogic) stock has fallen from a high of around $82 a share to $5.97 this morning.

    Compare this to Microsoft whose stock has only fallen from around $80 a share two years ago to $43.25 this morning.
    </quote>
    Let's get serious:-
    1. Telcos have to go through further pain and possible shake out.
    2. The pick up, when it comes (first half of 03) will be in capital spending first.
    3. S/W vendors have longer to wait.
    4. Now is as good time as any to buy SUN and BEA stock, it wont go much lower.
    5. It shows greater promise for growth than MS.
    6. Investors know that MS is a monopoly and have an assured revenue stream that enables product tie ins and subsidies.
    7. In an uncertain market MS certainly is a good bet.
    8. Inter-alia this proves the damage the MS is inflicting on the market.
    9. wrt SUN and BEA the uncertainty is if they will survive.
    10. I think they survive. This makes them a good purchase now.
    11. Stock value doesn't mean a thing apart from how much a company can raise. -It doesn't- mean a company is unsound.
    12. A company is unsound if it doesn't make profit - monopoly or not.
    13. A stock is unsound if it is bought at an outrageous p/e ratio unjustified by profit.
    (14. I admit I don't know the p/e of SUN and BEA at the moment. But I have read that, in this catastrophic market, MS profits are up 10%. Every sinew in my body cries out -there is something wrong here! Cleary MS would like nothing better than for a few of their competitors to go bust.)
    15. I think it is impossible to understand MS without putting oneself in the shoes of their marketing. I do not believe that their decisions are technology driven first.
    16. I believe they have taken a -marketing- decision to bring to market .NET in its current form as least intimidating to their existing developer base.
    16. .NET, in its current form, is arguably not fully capable of competing in the Enterprise market into which they are buying market share.
    17. It remains to be seen what will happen as succeeding version of .NET appear that redress these issues, by this time they will have a beach head in the market the covet.
    18. Do I think MS are wrong, dangerous and damaging as well as costly to the developer community, to S/W houses and to the consumer? Don't answer!
  111. Straight from the horses mouth[ Go to top ]

    Bill Gates gives .NET a grade of "C" for server side development:

    http://news.com.com/2100-1001-946087.html

    avoiding the word "Server-based", he called them "building-block services".

    Face it guys, this is a dead end technology. A lot of development involves interfacing with things that already exist, after seeing microsoft's renewed attempts to work with Apache and Oracle, you begin to realize that .NET is fatally flawed. .NET doesn't talk to anything that microsoft doesn't feel to be important.

    It's not going to matter how productive you maybe using their IDE, once you realize that there's no way to talk to that CICS,Tuxedo,MQSeries,TibCo,CORBA or SAP, PeopleSoft, Lawson, based server out there, you've hit a productivity wall.
  112. Straight from the horses mouth[ Go to top ]

    <quote>
    ...no way to connect ...
    </>
    Do people agree?
    Is this correct, that BizTalk end points are SOAP services, so there is no way to get into the middle tier app without all these translations?
    The more I learn about it the more disabled the platform seems since it _really_ restricts you to a turn key solution based on all MS technology or, at least, dbs with ODBC drivers, but little scope for middle tier optimisations.
    So there is huge risk associated with the (marketing?) decisions taken by MS in developing the CLR model.
    But I guess that if the connectivity is not an issue it is possible for MS to do some re-jigging to produce a way of optimising the middle-tier?

    Cheers,
    Adam
  113. Straight from the horses mouth[ Go to top ]

    Quote:
     Bill Gates gives .NET a grade of "C" for server side development:

    http://news.com.com/2100-1001-946087.html

    avoiding the word "Server-based", he called them "building-block services".


    ---------------
     I think you try to mix the concept of server side development with web service development. Web services is part of the server side development and but is only part of it.
  114. Straight from the horses mouth[ Go to top ]

    I'm pretty sure the reason he called them "building-block services" is because he was talking about "building-block services" (like all the hailstorm stuff) versus general server side development. It seems like the context makes that pretty clear, especially when mentioned in the same sentence as "software-as-a-service". I guess you could interpret it as building-block services == server side development if you want to, but that really isn't what it says.

    As for the "there's no way to talk to" bit, I've included quite a few links below. I'm sure if I went looking, I could find Java versions of all these as well. I'm not comparing functionality -- I've used the MQ Java API, but not the COM API, so I honestly don't know if one has more features than the other.

    But to say there is no way to talk to these systems from Microsoft platforms and technologies is just to ignore the fact that people have been doing this for years. Only a very strict definition of "no way" works here -- either Microsoft doesn't personally make the integration technology, or it's available on Windows, using Microsoft-supplied language tools, but it isn't native .NET code (so you can still use it, but it isn't "managed" code).

    Enjoy the read...

    Mark
     
    CICS:
    http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/host/proddocs/appint/appinc01.asp
    http://www.microsoft.com/hiserver/default.asp
    http://www.microsoft.com/hiserver/techinfo/HISoverviewwp.pdf
    http://www.softwareag.com/investor/engl/press/coop_microsoft-QA.htm

    Tuxedo:
    http://edocs.bea.com/tuxedo/tux80/interm/jolt.htm (look for ASP access)
    http://edocs.bea.com/tuxedo/tux80/ovrview/benefits.htm#1024868

    MQSeries:
    http://publibfp.boulder.ibm.com/epubs/html/amqtan02/amqtan02tfrm.htm

    Tibco:
    http://www.tibco.com/solutions/products/active_enterprise/rv/default.jsp (check platforms, this is for Rendezvous)
    http://www.tibco.com/solutions/technology_solutions/web_services/default.jsp?m=c22 (web services based integrations)

    CORBA:
    http://info.borland.com/techpubs/books/vbcpp/vbcpp45/framesetindex.html (getting pretty old at this point)
    http://www2.iona.com/MinervaRoot/index.jsp?action=article&articleURL=/support/docs/e2a/asp/5.1/develop.xml (check out the COMet stuff)

    SAP:
    http://www.sap.com/solutions/technology/keycapabilities/ (lots of J2EE, but SOAP and BizTalk make an appearance as well)
    http://www.sap.com/solutions/technology/businessbenefits/platformsupport.asp (VB, C# support listed as well, not sure if it's there yet)
    http://www.sap.com/businessmaps/CA831F66565211D3979D0000E83B54CE.htm#C1EE32EB70B4D311BCAD0800060DFE94

    PeopleSoft:
    http://www.peoplesoft.com/corp/en/products/technology/ptools/intg_brok/comp_interfaces.asp

    Lawson:
    I gave up here. If you Google for Lawson and Microsoft, you'll find some stuff, but there's no way for me to confirm what's current, and the Lawson site looks like it was designed to make it as hard to find information as possible.
  115. Straight from the horses mouth[ Go to top ]

    I agree that MS does communicate with other systems. The hype about Web Services is so silly because it was all possible before (and probably better). It might add another dimension but we were already communicating between tools and platforms via XML before .Net came out. Another reason is that it is not yet that robust and one must leave out important things/techinques to get it all to work (i.e. exception handling and custom objects).

    It seems (C.M.A.) though that it doesn't do as well with anything other than MS products and that other vendors tools don't do as well with MS products. ADO works much better with SQL Server than DB2 or Oracle do. We have people that have problems with MQ. They use VB. We don't have problems. We use Java. Of course maybe we are just better architects :p.

    Can I use Apache as my web server instead of IIS with .Net (or previous technology)? I've never heard of it. I can use IIS as my webserver for Websphere, Tomcat, ... (NOT suggesting anyone should).
  116. Straight from the horses mouth[ Go to top ]

    It looks like they are working on getting it going with Apache, which would be nice (choice is always a good thing), but in general I'm sure .NET is still mainly a Microsoft-centric solution. I'd be interested to see if that changes over the next year -- if vendors start creating .NET-specific APIs, for instance -- but it's always hard to guess at the future. I guess the point I was responding to was that it's somehow not possible to communicate with these other systems. That's just so obviously false I felt I had to reply to the poster.

    As for which works better for each, that's really where I think a good discussion can take place, and where the solutions can show their merits. I guess I would rather see someone say "I'm using MQSeries with Java because that works better" (probably true) than "I'm using MQSeries with Java because that's the only way I can get to it" (definitely false).

    Mark

  117. Straight from the horses mouth[ Go to top ]

    <Q>As for which works better for each, that's really where I think a good discussion can take place, and where the solutions can show their merits. I guess I would rather see someone say "I'm using MQSeries with Java because that works better" (probably true) than "I'm using MQSeries with Java because that's the only way I can get to it" (definitely false).</Q>

    I think the tools will work fine in the case of VB and MQSeries. I think it has more to do with not knowing what they are doing. So the question is - Do they not know how to pick tools or do they not know how to build systems or both?

    I have found that MS tools don't work well with other tools if the vendor had to write the interface (like ADO - Not MQSeries).
  118. Straight from the horses mouth[ Go to top ]

    "Can I use Apache as my web server instead of IIS with .Net (or previous technology)? I've never heard of it."

    http://www.covalent.net/products/rotate.php?page=93

    Things change, start to listen.
  119. "Things change, start to listen."

    I do listen - alot. That is why I asked and didn't say it wasn't being or couldn't be done. And I had just seen that news article.

    If it does work (and it should - depends on MS), it would be great. I turn off IIS whenever I connect to the net - I would love to never have to turn on IIS ever again.

    How much is really changing? Will Apache work as well with [MS].Net as it does with Java, etc? If it doesn't, it won't be due to the lack of effort on the part of the Apache people.

    Somethings stay the same. Keep your eyes open and your back to the wall.
  120. Question: "Can I use Apache as my web server instead of IIS with .Net (or previous technology)? I've never heard of it."

    Edgar: "http://www.covalent.net/products/rotate.php?page=93
    Things change, start to listen."

    Actually it has been possible for quite a while to use .NET with Apache. It was through CGI and thus wasn't as efficient as Covalent's solution _should_ be, however it had the ability to work.

    Still though, when you remove any part of the Microsoft stack from .NET, it loses its primary value proposition, which is all built around the single-vendor tightly-integrated software stack, just like IBM on the mainframe was in the 70s. For Microsoft, it's a "damned if you do, damned if you don't". They've got everything to lose by allowing interoperability and portability, and everything to lose by dismissing it.

    .NET doesn't fit in the modern world. Mono might, dotgnu might, but .NET never will.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
  121. Straight from the horses mouth[ Go to top ]

    <Q>... Still though, when you remove any part of the Microsoft stack from .NET, it loses its primary value proposition ...
    </Q>

    And thus, MS CAN'T have Mono succeed (more than just sort of work). Or any thing like Apache with .Net ("IIS works so much better with .Net") or C# with MQ Series ("C# works so much better with COM+(MSMQ)") ... .
  122. Future of Java[ Go to top ]

    <quote>
    13. A stock is unsound if it is bought at an outrageous p/e ratio unjustified by profit.
    (14. I admit I don't know the p/e of SUN and BEA at the moment
    </quote>

    Unfortunately, SUN and BEA don't have P/Es, because they are operating at a loss.
  123. Future of Microsoft[ Go to top ]

    Unfortunately for Microsoft, Java is not limited to Sun and BEA. You are forgetting (not intentionally, I hope) IBM, Oracle and many others.

    .Net, regretfully, is just one OS, one vendor and not much else. With MS's license fees going up and companies announcing support for Linux almost daily, .Net is a very difficult sell, in my opinion.

    Interesting figures should come out next month showing how many current MS's customers chose not to subscribe to MS's new License 6. If the figure is more than 30%, then ... holding MS stock may not be such a good idea ;-)

    Read more
    Norway won't renew Microsoft deal

    Windows is a lot more expensive to run than Linux

    ... and take a look at Linux desktop. Arguably, it looks better than XP.

    -- Igor
  124. Future of Microsoft[ Go to top ]

    I can't find the link but I just saw that England is the latest gov saying that their orgs now can look to open source as a choice.
  125. Future of Microsoft[ Go to top ]

    That might be :

    http://news.zdnet.co.uk/story/0,,t289-s2119628,00.html

    On the other hand whilst I am posting this in Mozilla and I run linux on my laptop I do feel as though I am in some minority group.
  126. Future of Microsoft[ Go to top ]

    Thanks. That is the one.

    I am posting via Mozilla. I love the tab feature. Unfortunately I am using a Windows machine. It isn't mine though. If they would stop writing VB programs we could get rid of them. Wish they would take a trip to Damascus. Maybe they would 'see the light'. Is killing companies equal to people? I hear that is a pre-requisite to 'seeing the light'.
  127. Future of Microsoft[ Go to top ]

    This is based on a consultation document produced by QinetiQ.
    http://www.govtalk.gov.uk/interoperability/egif_document.asp?docnum=430
    Unfortunately we only get 37 pages out of a 400 page report.
    These are important steps.
    Open Source and commercial companies such as Sun and Bea have a symbiotic relationship.
    Successful commercial companies are needed for stewardship. I think Sun have been doing an excellent job so far.
    It is possible (just possible) that this is a historical moment whereby the tide will turn for Open Source due to the draw backs for the consumer of non-standards compliant and closed systems. We don’t need to rehearse the arguments here.
    I should imagine that many of those arguments concerning monopolies are in the residual 350p.p. of the aforementioned report.
    Cheers
    Adam
  128. Future of Java[ Go to top ]

    Yes they are operating at a loss, so the value of their stock (up from your figures slightly) reflects a value on those intangibles.
    Still, there is no doubt these companies are going through tough times.
    As I say, things have a way to go before they begin to improve.

    Cheers,
    Adam
  129. Future of Java[ Go to top ]

    "Can I use Apache as my web server instead of IIS with .Net (or previous technology)? I've never heard of it."

    but what kind of applications will require this? who will be the intended audience?
  130. GLUE rocks but...[ Go to top ]

    "GLUE: http://www.themindelectric.com/glue/index.html

    It's easy! It's free! It's small! And it runs on any platform! What about Visual Studio? "

    First of all, I totally agree with you: GLUE is a small wonder and a showcase of how easy and powerful things can be in Java.

    Visual Studio is not free, but you can create .NET web services using any decent editor, and you can do it as easy as with GLUE. Furthermore you can use WebMatrix (free at http://www.asp.net/webmatrix) to create dynamic web pages and web services, I'm not sure if I would use it for a sizeable project, but for starters it's just OK.

    Finally, let's discuss JWSDP (Java Web Services Developer Pack), the official API for web services from Sun and you are back to the 700 pages tutorial (no kidding). As per what I said about GLUE this is not as much a critic to Java the platform, as the way Sun (the steward of Java) considers development.
  131. And another thing...
    Having played with .Net a bit now I am growing increasingly concerned about the exposure of the creaking windows API's.

    Simple examples (the only ones I've had to use so far) are hungarian window handles for string sizing in property setters. And then the WMI Management object 'stuff' to get the disk size. In both cases you step right out of the framework and are dumped into the Msoft historic crap I loathe.

    Still climbing though.

    Jonathan



  132. And as you do .Net think about how you would be able to do those things with a text editor and the barebones 'free' .Net framework.
  133. Doing .Net with emacs is no worse than doing java with emacs.
    Very similar actually. Much like doing csh or C++ with emacs.

    You write your macros/libs first. Then write your apps to drive them. Who needs drag n drop anyway!

    Jonathan
  134. But all the cool things that VS.Net provides one will have to do themselves. Just like Java if they don't buy a tool.
  135. Jonathan Gibbons wrote: "And another thing... Having played with .Net a bit now I am growing increasingly concerned about the exposure of the creaking windows API's. Simple examples (the only ones I've had to use so far) are hungarian window handles for string sizing in property setters. And then the WMI Management object 'stuff' to get the disk size. In both cases you step right out of the framework and are dumped into the Msoft historic crap I loathe."

    Having done some major .NET research here, I can say that Jonathan is actually spot-on in this case. (Regardless of what you may think of his previous posts ;-)

    .NET make pretend to be "cross-platform-couldbeable", but it doesn't take much more than a "Hello world" program to realize that the .NET monolith is tied tighter to Windows than the pointless re-build of Internet Explorer with artifical cross-dependencies between GDI/Kernel and IE DLLs to pretend that IE was actually a necessary part of Windows.

    Mono will probably succeed on the merits, but .NET applications built in MS Visual Studio .NET will never be portable.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
  136. By 'no its not' I meant not a nightmare. But for many tools they are about just as easy too.

    http://www.capeclear.com/
    http://www.alphaworks.ibm.com/tech/webservicestoolkit/

    Directly from a tool like WSAD they are very simple to do. Just like VS.Net
  137. Interesting interview. Doug seems to know what he is talking about, at the very least a lot better than a lot of people here on TSS that talk about .NET.

    What strikes me as a *real* disadvantage of .NET - apart from the vendor dependence and the missing multi-platform support that has already been beaten to death on TSS - is the lack of an O/R mapping solution. That he didn't even think it was necessary indicates, IMHO, that he has no experience developing real-word OO enterprise systems. I can't believe that anybody would develop an OO application exceeding trivial complexity without the need for something like JDO or CMP.

    (I know I'm going to get flamed for that ;-))

    Stefan Tilkov
  138. Stefan,

    I have no idea why you would get flamed for that. I think you are exactly right about the response to O/R mapping. I thought Doug was to break out into a tap dance. :) Oviously the J2EE community can't exactly claim they are not also wrestling with the issue, but at least it is acknowledged as an issue. Others may disagree, but I think that the O/R technique selected for a new J2EE project would be the "most important" descision that would be made regarding the application architecture. I would be curious if other's agree.

    Mike
  139. Hi Stefan,

    This guy can't say all what he knows, or perhaps he doesn't know it yet (what I find hard to believe).

    MS is working on a persistence framework (on top of ADO.NET) in order to offer CMP. The rumors say it will be available with .NET 2.0

    Greetings,
  140. The O/R mapping will be available with the upcoming version of .NET Framework. You can read more about it at

    http://hosting.msugs.ch/dotnetrox/articles/Art07.html
  141. Here's another tidbit of information that I didn't realize:

    ADO.NET drivers don't seem to support non-microsoft databases too well:
    http://news.com.com/2100-1001-945763.html?tag=fd_top

    Are there ADO.NET drivers for other vendor's databases, like DB2, Sybase, MySQL, Informix (does this still exist)?

  142. Why are these discussions always centered around us vs. them rhetoric? Why not use the best of both worlds? - IMHO ASP .NET is far superior to the JSP/Servlet model and J2EE is a more proven, reliable, secure, robust middleware platform. Throw in web services as the glue, and you have a very flexible architecture.

    I for one, would like to see the IT community much more focused on solving business problems and less on technical evangalism.

    Tim...
  143. Why are these discussions always centered around us vs.

    >them rhetoric? Why not use the best of both worlds? -
    >IMHO ASP .NET is far superior to the JSP/Servlet model and
    >J2EE is a more proven, reliable, secure, robust middleware
    >platform. Throw in web services as the glue, and you have
    >a very flexible architecture.

    Because it is us vs. them. Microsoft has been proven in court testimony to use underhanded business dealings to lockout and squash the competition. I would not give Microsoft a beachhead in this area because I believe they will be up to their old tricks again. They lost my trust a long time agao. Why should I trust them again?
  144. Because it is us vs. them. Microsoft has been proven in >court testimony to use underhanded business dealings to >lockout and squash the competition. I would not give >Microsoft a beachhead in this area because I believe they >will be up to their old tricks again. They lost my trust >a long time agao. Why should I trust them again?


    As an IT professional, you are commited to providing the best technical solution to solve a business need. The next time you are in front of your business community giving a presentation on your technical solution, please think long on hard before telling them you dismissed a Microsoft solution because you do not trust them!
  145. The next time you are in front of your business

    >community giving a presentation on your technical
    >solution, please think long on hard before telling
    >them you dismissed a Microsoft solution because
    >you do not trust them!

    A company's past behavior and rhetoric is a legitimate consideration when selecting a platfrom to build you enterprise infrastructure. Microsoft's behavior is not one of coexistence, but one of dominance. I don't see how their attitude is compatible in a field where a solutions should coexists with legacy systems and with anything else that may come in the future.

    Remember how Microsoft dismissed Java as just another language and how they tried to kill the Java platform by not ugrading it to the most current version as required by the contract they signed with Sun. Imagine if you built your infrastructure on Microsoft technology and another platform emerges. I can see Microsoft using similar underhanded techniques to kill the new technology in its infancy -- Not good when you want a partner that can interroperate with new technology.

    I am quite proud of my analysis of Microsoft and my advocacy of J2EE is more comprehensive than Tim McNamara is trying to portray. If you read all of my postings in this thread as well as others, you will see that my advocacy of J2EE is also based on technical merrits.

    J2EE
    Secure
    Cheaper
    Open
    Widely embraced by the industry
    Proven technology
    Backed by companies have been in the enterprise bsusiness for over 20 years
    Community driven architecture


    .Net
    Not secure
    Expensive
    Closed
    Not widely embraced
    Not proven
    Backed by a monopolist with little experience in the enterprise business
    Closed architecture

  146. .Net

    >Not secure
    >Expensive
    >Closed
    >Not widely embraced
    >Not proven
    >Backed by a monopolist with little experience in the >enterprise business
    >Closed architecture

    Roll back to 1996, java was a new language. The first to promise a widely used cross platform technology - not the first to do it by any means, but one that might actually gain acceptance. I was an advocate, and it was a hard battle because:

    Java
    - JVM and sandbox were not secure
    - There were few staff, no tools and those that knew anything charged a bomb.
    - It promised to run anywhere but was buggy as hell on anything except solaris. Fine for simple things.
    - Not widely embraced
    - Not proven
    - backed by Sun, who had a proprietary OS and Hardware. What the heck was that about?
    - What architecture? It was a runtime interpreted language with about 6 core libs and that was all.

    My point? None of what you say will effect the massive success of .Net in every type of system. I hope java can keep up, or someone else can come up with a new technology that competes.

    Jonathan
  147. My point? None of what you say will effect the

    >massive success of .Net in every type of system.
    >I hope java can keep up, or someone else can come
    >up with a new technology that competes.

    Don't believe the FUD. I think the demise of Java is grossly overstated. Look folks, Microsoft will not be releasing the core of their .Net technology on other operating systems because it would be contrary to their Windows XP business. Yeah, yeah, yeah, people says that there is the Mono project, but you will still not have all the libraries needed to port enterprise solutions written for .Net running on Windows XP to run on other systems. Don't believe the empty promises of .Net.


    Tim McNamara, I can appreciate your taste for technical discourse. Let's take a look at the .Net Pet Shop and the Java Pet Store.

    We can see how a company with a closed mindset colors the architecture. We can see in Doug's interview that he has no problem putting the business logic into database stored procedures. .Net Pet Store has alot of business logic coded in database stored procedures. This might be OK if you live in a Microsoft only universe where all you have is MS SQL Server or if you purposely want to lock the user into your proprietary database. Also the .Net Pet Shop is written for .Net which locks you into Windows XP and Microsoft's implementation of .Net and Microsoft development tools.

    Contrast that with the Java Pet Store which has the abstraction layers that are appropriate for enterprise solutions which does not lock you into a particular database. And the application is written using J2EE technology so you can move it to other hardware and operating systems. You also have a wide variety of development tools to choose from to fit your fancy.

    Based on these two platform demonstrators, I would say that it looks like trust in J2EE is well placed and people should be sceptical about Microsoft's attemp at an enterprise arhcitecture.

    For more details on a comparison between Java Pet Store and .Net Pet Shop, refer to the following:

    http://java.sun.com/features/2002/07/rimapatel.html

  148. No FUD. Java will continue, much as C++ did. Even Corba is still used and that was always a silly idea :-)

    Its not as black and white as you want to make out.

    Jonathan
  149. <quote>
    .Net Pet Store has alot of business logic coded in database stored procedures. This might be OK if you live in a Microsoft only universe where all you have is MS SQL Server or if you purposely want to lock the user into your proprietary database.
    </quote>

    Your flawed assumption is that most applications are ported to multiple databases. Most IT development occurs in house (or by contractors) for a single client for a single database. Most companies have made a significant investment in time and money for their database of choice, and it is very unlikely they will change databases on the time scale of the lifetime of a typical application (a few years).

    For example, if company X has 19 man years of development and a dozen apps designed for its Oracle database, they aren't likely to decide on tuesday to port it all to Sybase. So it would be silly for them to base their architecture on the assumption that it needs to be portable to other databases. Company X might be better served to put business logic common to all their Oracle apps into stored procedures in the database. It would then be faster than using EJBs. Obviously, speed is paramount with many multi-user and web applications.

    There are exceptions, of course. If the business logic is very complicated, it might be tricky to implement the logic in PL/SQL or some other SQL variant. If the company has people with skills in EJBs (or some other middleware, like MIDAS), then leveraging these technologies might be preferable.

    And, if company Y is developing an application it wants to market to other companies (which might use a variety of databases), putting the business logic into session beans certainly makes sense.

    But I think there is a tendency among SOME Java evangelists to over-engineer systems so they are unnecessarily flexible at the expense of runtime speed and excessive development time. Sometimes quick and simple is the way to go.
  150. Jeff,

    I see it a little different. At the end of the day, I see only one justification for the complexity of J2EE development.... the need to develop scaleable applications. If I need to develop a scaleable application, I certainly want to scale the middle tier, and not the database. I move my business logic processing to the middle tier so the database does not become the bottleneck. I'm ok with stored procedures for retrieval and updates, but not for business logic. I'm sure on any given application I may make some exceptions, but they would be rare.

    JMO.

    Mike
  151. Stored Procs / Java over-engineering[ Go to top ]

    "Your flawed assumption is that most applications are ported to multiple databases"

    Your flawed assumption is that he meant that they were. And that a port must occur to even have applications do this.

    Most applications are written so that a 'port' would be difficult. This is usually very unecessary. If the data access occurs on the data server then there is little need for SPs. It doesn't take that much more work to do it right. In fact, it may take less. And no, I'm not even thinking about EJBs.


    "For example, if company X has 19 man years of development and a dozen apps designed for its Oracle database, they aren't likely to decide on tuesday to port it all to Sybase"

    Yep. Sounds like bad architecture/design to me. They are now at the mercy of a single vendor.


    "Sometimes quick and simple is the way to go"

    Stored Procs are quick and simple? I can do code that is not vendor specific and be quick and simple. Anyway, quick and simple usually is bad in the long run.
  152. Stored Procs / Java over-engineering[ Go to top ]

    <quote>
    Yep. Sounds like bad architecture/design to me. They are now at the mercy of a single vendor.
    </quote>

    If a company is developing an in-house application and is not going to switch databases, it is NOT a bad architecture to utilize the specific features of the database (like stored procs).

    I suppose that designing an application using EJBs makes it more difficult to later port the application to another language like C++. Does that make it a bad architecture since the developers can't easily change programming languages later on?
  153. Stored Procs / Java over-engineering[ Go to top ]

    <>If a company is developing an in-house application and is not going to switch databases, it is NOT a bad architecture to utilize the specific features of the database (like stored procs). <>

    Glad your crystal ball is working.

    There usually is very little reason to tie your app to a specific database. This is the bane of the majority of inhouse apps.

    <>If a company is developing an in-house application and is not going to switch databases, it is NOT a bad architecture to utilize the specific features of the database (like stored procs). <>

    The impact should be minimized. So I would say EJBs should be used with caution and aways via interface.
  154. Stored Procs / Java over-engineering[ Go to top ]

    "Your flawed assumption is that most applications

    > are ported to multiple databases"

    My advocacy about maintaining a cross platform capability is right on target.

    There are times when the quick and simple approach is appropriate, however if you are designing an enterprise solution, you want to do it right so you can adjust to any contigencies that may come in the future.

    For example: Suppose you developed an application using stored procedures using MS SQL Server and .Net. Let's say a directive comes from above to have an all Unix solution. MS SQL Server does not run on Unix and neither does .Net. Hmmm, looks like heads are going to roll.

    If you are going to design an enterprise solution, don't lock yourself into a proprietary database like MS SQL Server and don't lock yourself into a closed proprietary platform like .Net. And don't lock yourelf into close proprietary operating system like Windows XP.

    Based on these sort commings of .Net, the platform is inappropriate for enterprise solution.
  155. " Let's say a directive comes from above to have an all Unix solution. MS SQL Server does not run on Unix and neither does .Net. Hmmm, looks like heads are going to roll."

    Yeah heads are going to roll the someone who OKs a project to go ahead on .NET and then sends out a directive saying move to Unix!

    This is nonsense. It is not a valid point saying "SQL Server does not run on Unix" it is stating the obvious. How many native Unix apps run on Win2K? Zero.

    The point is you architect a solution that best fits your requirements, scope, budget and time and pray that a directive does not come in half way through saying "I want an all Palm OS solution?"


    - Maurice Lynch
  156. Stored Procs / Java over-engineering[ Go to top ]

    "This is nonsense. It is not a valid point saying "SQL Server does not run on Unix" it is stating the obvious. How many native Unix apps run on Win2K? Zero."

    I would say it is not nonsense. You just don't understand the issues and impact.

    This is very valid. Why? Because organizations are inspecting their finances and realizing they can save money on licenses and equipment and building space - if they don't use tools and technologies that tie them to one vendor, one platform, one machine architecture.

    "The point is you architect a solution that best fits your requirements, scope, budget and time and pray that a directive does not come in half way through saying "I want an all Palm OS solution?" "

    Why not do this and architect it to minimize the impact of change? You can have your cake and eat it too if you know what you are doing, ignore the FUD and propaganda and choose the right tools.
  157. Stored Procs / Java over-engineering[ Go to top ]

    "This is nonsense. It is not a valid point saying

    > "SQL Server does not run on Unix" it is stating
    > the obvious. How many native Unix apps run on
    > Win2K? Zero."


    MS SQL Server does not run on Unix and that is a problem if you want your solution to be cross platform so you can handle contingencies.

    Oracle run on Linux, Windows, Solaris, HP-UX, AIX, etc
    DB2 runs on Linux, Windows, Solaris, HP-UX, AIX, Palm-OS, etc
    Sybase run on Linux, Windows, Solaris, HP-UX, AIX, etc



    Companies do switch database all the time. I Saw following at the Oracle site:

    Oracle wins eWeek Labs' Database Performance Runoff - SQL Server finished last.

    Siemens replaces Microsoft NT File Servers with Oracle Internet File System and saves.

    ZDNet reports "PalmGear.com swaps SQL Server for Oracle"

    Blue Nile runs out of gas on SQL Server, switches to Oracle
  158. The original point I was making is that of course SQL Server is not cross platform so why bring it up if you plan to be cross platform?

    Surely "Oracle Internet File System" is Vendor lock in? On that point; Oracle, SQL Server et al. all provide features outside of regular RDBMS such as full text indexing, XML input and output even TCP/IP access. In these times of "Return On Investement" is in not financially prudent to leverage the out-of-the box features of database servers even if it involves dancing with the devil - vendor lock-in :)

    Is it wise to sanction the development of a vendor neutral text indexing sub system and incur the cost of design, development and test cycle just to avoid using your chosen DB's functions?

    I think a mix of solid middle tier object design with a controlled amount of vendor specific functions is no harm.

    - Maurice Lynch
  159. <quote>
    Companies do switch database all the time. I Saw following at the Oracle site:
    </quote>

    Your evidence is propaganda from the Oracle website? Have you ever done a database port?

    Businesses do not switch databases all the time, or there would be a hell of a lot more jobs on Monster.com for people to port millions of stored procs, trigger, and applications from one database platform to another.

    First off, buying a new database costs a lot of money. Second, you may need to hire a couple of new DBAs, skilled in the new database. Third, you have to transfer all the data, stored procs, triggers, views, roles, etc. from one db to the other, and make any application changes that are needed as well.

    Then you have both systems run in parallel for a while to make sure there weren't any mistakes.

    I have done several and it is not something that is done frivilously. And the larger the company, the more complicated and expensive the port, and the less likely they will want to do it.
  160. Your evidence is propaganda from the Oracle website?

    > Have you ever done a database port?

    From my work experience, database port has been an issue. I publish my own e-commerce software and I kept the whole this cross platform by eliminating store procedures. I know what I am talking about.

    >I have done several and it is not something that is
    >done frivilously. And the larger the company, the
    >more complicated and expensive the port, and the
    >less likely they will want to do it.

    Which is why you should keep the business logic out of the database. Put them into session beans if you are using EJBs. Don't lock yourself into a database when you don't have to. If you find that you have to do some stored procedures or triggers, keep it to a minimum so your port would take at most a day to switch over.
  161. My experience is even worse...
    (by people who never learn!!)

    We created an app build using Oracle stored procedures
    running on Java/Solaris,
    and a year later the management decided to integrate
    it with an app running SQL Server on VB/NT.

    How did they decided to go forward?
    Convert the PL/SQL stored procedures to SQL Server stored procedures...!! :-o

    I should think there are a lot of people out there (still)
    praying by stored procedures...
    How can you convince those type of people that there is another way...
    Maybe by leaving a patterns book on their desk... ;-)
  162. Stored Procs / Java over-engineering[ Go to top ]

    <Q>Businesses do not switch databases all the time, or there would be a hell of a lot more jobs on Monster.com for people to port millions of stored procs, trigger, and applications from one database platform to another. </Q>

    You are stuck on this port thing. We are not saying port. We are saying don't build to one database. It really isn't that difficult. It is difficult to 'port' (NOW I am talking about porting) if SPs are extensively used).

    Business don't switch because applications are build so they 'can't'.


    <Q>First off, buying a new database costs a lot of money</Q>

    Depends. There are cheap/free alternatives and will do for many tasks.

    <Q>you may need to hire a couple of new DBAs, skilled in the new database</Q>

    I am not really a DBA but I have installed, set up and created applications for Oracle, DB2 and SQL Server.

    <Q>Third, you have to transfer all the data, stored procs, triggers, views, roles, etc. from one db to the other, and make any application changes that are needed as well.</Q>
    Data - yes - simple.
    Stored procs - no.
    Triggers - yes - limited use.
    Views - no.
    Roles - no.
    Application changes - no.

    <Q>Then you have both systems run in parallel for a while to make sure there weren't any mistakes<Q>

    Hopefully one tests any change to the system.

    <Q>I have done several and it is not something that is done frivilously. And the larger the company, the more complicated and expensive the port, and the less likely they will want to do it. </Q>

    So companies do ports!

    You can thank the developers and DBAs for the problems.




  163. Stored Procs / Java over-engineering[ Go to top ]

    <quote>
    You are stuck on this port thing. We are not saying port. We are saying don't build to one database. It really isn't that difficult. It is difficult to 'port' (NOW I am talking about porting) if SPs are extensively used).
    </quote>

    I agree that if you are starting out from scratch and you possess J2EE expertise, you should minimize stored procs and triggers. And obviously if you are developing a system to sell to customers who may use a variety of databases, then you should keep stored procs/triggers to an absolute minimum.

    But many businesses have been around longer than J2EE and their databases already have lots of stored procs and triggers. Therefore, moving to a new database platform is difficult and often times, unfeasible. And if they aren't going to switch databases and they already possess considerable expertise with their database, why not utilize the special features of their database?

  164. Stored Procs / Java over-engineering[ Go to top ]

    <Q>I agree that if you are starting out from scratch and you possess J2EE expertise,</Q>

    Yes, if it was done wrong from scratch, then it will be difficult.

    It doesn't require J2EE expertise.

    <Q>obviously if you are developing a system to sell to customers who may use a variety of databases,</Q>

    Why put your 'own' company in the same position?


    <Q>And if they aren't going to switch databases and they already possess considerable expertise with their database, why not utilize the special features of their database? </Q>

    They don't know they won't. But, you are right, they won't if they do it your way.

    There are few special features that are worth it. SPs are not. Use the features if necessary but minimize and use via interface.

    <Q>But many businesses have been around longer than J2EE and their databases already have lots of stored procs and triggers. Therefore, moving to a new database platform is difficult and often times, unfeasible<Q>

    It may be to late for them. They could have done it better. This really has little to do with J2EE. We were doing the same sort of thing with COBOL, IMS and DB2 years ago.
  165. Stored Procs / Java over-engineering[ Go to top ]

    <quote>
    It doesn't require J2EE expertise.
    </quote>

    It requires J2EE expertise to implement business logic in EJBs--which was the alternative I was referring to.

    Of course, there are other middle tier solutions which don't require J2EE expertise.
  166. Stored Procs / Java over-engineering[ Go to top ]

    <Q>Of course, there are other middle tier solutions which don't require J2EE expertise.</Q>

    Which is why I said one didn't.

    There are also middle tier solutions that require J2EE experience but no EJB knowledge. 'Cause EJBs are not J2EE. They are just part of it.

    And if you can read, or do a wizard then EJBs don't require expertise either.
  167. Stored Procs / Java over-engineering[ Go to top ]

    <quote>
    And if you can read, or do a wizard then EJBs don't require expertise either.
    </quote>

    You should be an evangelist for Sun. "EJBs don't require expertise. Why they are so easy to use that Dan Quayle could create an entire enterprise system with EJBs in the morning before his noon tee time". ;-)

    You've been doing J2EE and EJBs too long if you've forgotten how steep the learning curve is for newbies.

    And I suppose by your logic one doesn't need expertise to do brain surgery either because "if you can read", all you have to do is read all the material brain surgeon is required to learn in med school.
  168. You've been doing J2EE and EJBs too long if

    > you've forgotten how steep the learning curve
    > is for newbies.

    Jeff. Learning EJB is easy and costs nothing.

    Download the excellent Free book on EJB:
    http://www.theserverside.com/resources/ejb_review.jsp


    Download JBoss:
    http://www.jboss.org


    If wou want an IDE, get the enterprise trial version of JBuilder:
    http://www.borland.com

    and the JBoss integration for JBuilder from:
    http://www.protegra.com/javagroup.html


    It took me only a day to learn the stuff.





  169. Peter I am glad that finally people are realizing that EJB is not that hard. I believe any one with a common sense and little programming background can easily write the EJB, and that was the whole purpose of the framework at very first place. I find Java/J2EE community responsible to give EJB a perception of being very hard. I don't know, was it a fad or some marketing trick for EJB programmers to make some top $$, but in reality that perception alone hurting EJB a lot when people compare it to .NET.

    Second lot of people compare .NET and J2EE at tool level (ease of use),instead of component and technology level. When it comes to middleware and enterprise applications, development tools don't help you beyond a certain point, it is then the framework that wins.

    Rashid.
  170. If EJB are really so easy[ Go to top ]

    "It took me only a day to learn the stuff."

    Then I wonder why Mastering EJBs takes 488 pages (not including appendices). Wouldn't be enough with some 20 pages? Why TheServerSide EJB *Essentials* training takes 4 days?

    Seriuosly, Peter, you don't do any favor to the technology over-simplifying it. You're harming your cause trying to win the argument at all costs. Distributed, scalable applications *are* hard to do. In that respect EJBs are not especially complicated (as compared to other technologies). The real question is: must everything be constructed as a distributed, scalable application? "Yes, why not?" or "Just in case, after all EJBs are easy" don't seem professional answers to me. You don't buy a 40 tons truck if all you want to move is a dozen chickens from farm to store every day. And don't tell me software is not like trucks, that software is soooo much elastic, I mean: it is, and to a big extent, but some people is losing the sense of proportions.
  171. If EJB are really so easy[ Go to top ]

    Hi: Edgar,

    One can read a 1000 pages book on Microsoft word and take a 8 days training class on Databases. Learning any thing new requires some time, 488 pages or 4 days class doesn't qualify EJB specifically very hard.

    Like you said, writing distributed, transactional, and multi threaded applications are hard (but not too hard after EJB), and it has nothing to do with J2EE or .NET. I never understand the claim that how writing distributed, transactional, and multi threaded applications are easier on .NET than J2EE. I would really appreciate if Doug Purdy or some one lese solves this puzzle for me.

    Rashid.
  172. If EJB are really so easy[ Go to top ]

    Rashid Jilani wrote:

    "One can read a 1000 pages book on Microsoft word and take a 8 days training class on Databases. Learning any thing new requires some time, 488 pages or 4 days class doesn't qualify EJB specifically very hard."

    What you are overlooking is the degree of mastery needed to do useful work. One doesn't have to read the 1000 page book or even a small fraction of it to use MS-Word. The 1000 pages may contain a tutorial chapter to get one started, but the bulk of the text is reference.

    Databases are not a good analogy, as 'mastery' of databases can range from an hour tutorial up to a subject many times as complex as EJB is, depending upon what you're objectives are.

    Unlike MS Word, I would estimate that one would have to read and try out at least half of the 488-pages of the Mastering EJB II book to achieve some mastery.

    If you are lucky enough to work in a shop where someone has set up an EJB container with working examples accessable to you learning EJB is relatively simple, being limited to reading the book, setting up the deployment descriptors, and running the examples, and perhaps writing a few of your own.

    If yopu don't work in such a place things get much more complicated. Most EJB books (include Mastering EJB II) don't provide detailed instructions for obtaining, installing, and configuring an EJB container, nor do they address container-specific deployment descriptors and configuration or setting up databases to work with the EJB container.

    This is not intended as a criticism of the books, but the fact is that you need all of the above to even begin to run the examples, and you must run the examples to learn EJB properly. So you end up reading and doing far more than 244 (or 488) pages worth of reading (including substantial troubleshooting) in order to learn EJB.

    IDE's can and do take some of the burden off of the leaner here, but there is still considerable need for improvement.
  173. If EJB are really so easy[ Go to top ]

    Edgar Sanched wrote:

    >On the same note, I will be doing a webcast
    >comparing .NET and J2EE. Obviously I will be
    >trying to highlight the .NET side, but on
    >the other hand we will try to keep on
    >plain technical facts. You are invited
    >to join the event at:
    >http://www.microsoft.com/usa/webcasts/upcoming/1025.asp

    >Then I wonder why Mastering EJBs takes 488
    >pages (not including appendices). Wouldn't
    >be enough with some 20 pages? Why TheServerSide
    >EJB *Essentials* training takes 4 days?

    >"Yes, why not?" or "Just in case, after all
    >EJBs are easy" don't seem professional answers
    >to me.

    From the above, We know where your loyalty stands.

    Mastering EJBs II happens to be a very good book that explains the reasons why things are the way they are in EJBs. I even bought the book in paper form because it is that good. The explanations are also crystal clear and the tools I reccommended will get you up to speed quickly. It is that easy when you have the right information and the right tools.

    Similarly if you are going to do enterprise development, you need the right platform and the right tools. The best and only viable platform is J2EE and there are numerous tools to choose from. JBuilder happens to be the best, but others are adequate.

  174. If EJB are really so easy[ Go to top ]

    The real question is: must everything be constructed

    >as a distributed, scalable application? "Yes, why
    >not?" or "Just in case, after all EJBs are easy"
    >don't seem professional answers to me. You don't
    >buy a 40 tons truck if all you want to move is
    >a dozen chickens from farm to store every day.

    Sorry about that dig earlier about your loyalty. I appologize for that.

    I agree with you here that not everything has to be in EJB. For solutions that don't have to scale and handles low traffic, then you don't need the EJB container, however you should still be careful to keep the business logic separate from the presentation layer. Building the application using JSP, servlets, and business logic in plain JavaBeans will go a long way in upgrading to EJBs should the application later need to be modified so it scales.
  175. Yeah heads are going to roll the someone who OKs a

    > project to go ahead on .NET and then sends out a
    > directive saying move to Unix!

    > This is nonsense...

    Maurice, Maurice, it happens all the time. Directives to move to Unix get issued quite frequnently. Unfortunately, most of the time, it is the head of the manger closest to the project that is on the chopping block.

    Now, if the manger built the solution using J2EE technology and kept the busiless logic in session beans and used an abstraction for the data like entity beans or JDO the he would be sleeping pretty cozy at night and might even get a promotion out of it.
  176. "Now, if the manger built the solution using J2EE technology and kept the busiless logic in session beans and used an abstraction for the data like entity beans or JDO the he would be sleeping pretty cozy at night and might even get a promotion out of it. "

    This is really about methodology, not technology. Go read up on some agile processes. Spend all your time planning for the future and you won't have time to do anything for the present. Most XP projects would have half the system up and running before you'd finished wiring up your Windows-->Linux Instant Switch-Over Hot Button.

    You Ain't Gonna Need It!

    Jim
  177. Stored Procs / Java over-engineering[ Go to top ]

    <>Spend all your time planning for the future and you won't have time to do anything for the present<>

    It really doesn't take that much time. If any.


    <>You Ain't Gonna Need It!<>
    You ain't gonna be able to do it. That really is the problem. People buy into the FUD and thus make it so they can't.
  178. Stored Procs / Java over-engineering[ Go to top ]

    It really doesn't take that much time. If any.


    I'm talking about feature-creep in general. There's creep from the customer ("hey, since you're building us this great new system, let's make it do xyz as well"), and creep from developers ("I'll just cook up a little O/R persistence layer - it won't take long").

    I could quote XP mantras all day (but it probably won't get me anywhere, so I won't), but I believe (and have seen real evidence) that focusing on the simplest solution that fits the requirements produces better software faster. If a database/app server/OS move is on the cards within the lifetime of the app, build it into the scope. If not, forget about it. You can't predict it and You Ain't Gonna Need the capability.

    >You ain't gonna be able to do it. That really is the problem.

    Having had some experience building/maintaining/porting/upgrading applications for various companies, on various platforms, the problem is almost never the technology, and almost always the humans who use it.

    Jim
  179. Stored Procs / Java over-engineering[ Go to top ]

    <Q>and creep from developers ("I'll just cook up a little O/R persistence layer - it won't take long"). </Q>

    Who is cooking anything up? I'm just using something that exists and not wasting my time writing a bunch of SQL/SPs to do mostly crude work. Do you write your own ODBC drivers? Doubt it.

    <Q>I could quote XP mantras all day (but it probably won't get me anywhere, so I won't), but I believe (and have seen real evidence) that focusing on the simplest solution that fits the requirements produces better software faster. If a database/app server/OS move is on the cards within the lifetime of the app, build it into the scope. If not, forget about it. You can't predict it and You Ain't Gonna Need the capability.</Q>

    From my experience and searching, building it with tools like OR mapping is faster and simpler.

    <Q> almost always the humans who use it.</Q>

    Yep. Because they don't use it wisely.
  180. Stored Procs / Java over-engineering[ Go to top ]

    "Anyway, quick and simple usually is bad in the long run."

    On the other hand, long and complex kills the project on the short run. I think the point was that *over*-engineering is a bad thing, that doesn't mean *no*-engineering, it means *right*-engineering. It is not unusual that I find a project stalled because they are fighting with an EJB container and it's arcane configuration options when all they needed is a nice servlet engine (I love Resin) and a light persistence framework (Artyom is my current favorite). This especially sad when the project was planned to handle a dozen users with a few hundred transactions a day...
  181. Stored Procs / Java over-engineering[ Go to top ]

    <On the other hand, long and complex kills the project on the short run ...>

    I'm with you. I was thinking more of wizards the hide what was done a create code that can only be maintained via the vendors tool.

    I like light peristance tools for most things. I think EJBs are over sold and over done. If EJBs are needed at a later date and if the system is architected properly - it doesn't take that much - then EJBs can be incorporated later.
  182. <quote>
    On the other hand, long and complex kills the project on the short run. I think the point was that *over*-engineering is a bad thing, that doesn't mean *no*-engineering, it means *right*-engineering. It is not unusual that I find a project stalled because they are fighting with an EJB container and it's arcane configuration options when all they needed is a nice servlet engine (I love Resin) and a light persistence framework (Artyom is my current favorite). This especially sad when the project was planned to handle a dozen users with a few hundred transactions a day...
    </quote>

    Sure - but using J2EE doesn't mean long and complex. Using J2EE isn't over-engineering. And again, I don't find that most people throw things into EJB containers willy-nilly using so-called arcane configuration options (personally, they seem pretty straight forward) of j2ee app servers. They use what they need - personally I like to use Orion - it has a great EJB container AND a great servlet container. I can use the appropriate technology whenever, wherever and however I want.
  183. "Company X might be better served to put business logic common to all their Oracle apps into stored procedures in the database. It would then be faster than using EJBs. Obviously, speed is paramount with many multi-user and web applications."

    From http://otn.oracle.com/tech/java/oc4j/pdf/9ias_net_bench.pdf:

    "To develop a version of Java Pet Store that was suitable for comparison with the .NET Pet Shop application, Oracle made modifications to the SQL and some of the Java to make it more efficient, but did not change the structure of the application.
    Oracle9iAS was able to achieve superior performance to .NET without compromising the J2EE blueprint design principles demonstrated in Java Pet Store or using database stored procedures.
    In summary, Microsoft published benchmark results based on an unfair comparison between different applications.
    In reproducing that benchmark, with only minor modifications to the Java Pet Store, Oracle9iAS proved to be over 22 times faster than .NET in some cases, while using far fewer resources."

    You don't have to go for a monolithic approach to produce fast results...
  184. <quote>
    My point? None of what you say will effect the massive success of .Net in every type of system. I hope java can keep up, or someone else can come up with a new technology that competes.
    </quote>

    Jonathon,

    Your previous paper and your current arguments about how .NET is the next big thing have been less than convincing in my mind as to the state of Java and J2EE. The Java community is large and clever enough that it will continue to evolve, providing ever better solutions to those companies where solid enterprise applications matter to their bottom line.

    Microsoft will probably do well in all MS shops - I think J2EE has the edge in other scenarios though, not to mention that it works well in all MS shops too. It is .NET that will have to do the catching up and it has quite a ways to go - as someone mentioned it remains to be seen if it is secure, it is certainly expensive, it is closed (and despite what you may think - many companies and vendors are moving from closed, proprietary solutions to open ones - which leaves Microsoft sucking hind tit) and there is absolutely no choice of vendor ( I know this has been said many times) - which I have heard claims that companies don't care about - believe me - they care about it!

    I find J2EE to be less chaotic in nature than you have made it out to be, and while J2EE has a learning curve, it also isn't rocket science either. It has great tools - and no, maybe they aren't the drag-n-drool tools of Microsoft, but one can be quite productive using them. At least as productive in my experience.

    Neither Java nor J2EE are finished - far from it. .NET will take its share of the market and I may work with it some day as situations warrant, but the doom and gloom scenario of the Java side sliding off into the sunset and everybody running to Microsoft is not an accurate representation of the situation.

    Cheers
    Ray
  185. Oh no, Not this clown again !

    Jonny boy, are'nt you done with AMENDING that brain dead article of yours ?. Thought you'll be too busy with that to bother about posting another pile of poo.
  186. A java evangelist:

    http://java.sun.com/features/2002/07/rimapatel.html

  187. <quote>
    A java evangelist:

    http://java.sun.com/features/2002/07/rimapatel.html
    </quote>

    Which has to do with....?


  188. I must have missed something fundamental about the current .net iteration.

    Where is the equivilent of the J2EE AppServer?

    Where can I host a component in a managed environment - where threading, object lifecycle management, monitoring and administration etc are all managed/provided transparently - where it can be accessed by a variety of clients - not just SOAP/asp.net clients...?

    Its my understanding that you have to write your own server - or take a step back in time to MTS. (Also the understanding of my .net colleagues). Neither of which compare favourably at all with an EJB container.

    Its my opinion that (asp.net aside) .net is a closer match for J2SE than J2EE. Does anyone disagree violently with this assertion? Care to discuss?

    -Nick

  189. Coming from the Java world (back) into Microsoft I started to search for the equivalent Java-like bits. The first thing I sought was an EJB Container equivalent (AppServer) and found MTS with the "ah" factor that's where I shove all my COM objects, sit back and let the nanny take care of everything. Only to discover that MTS is no more - try COM+ (formerly known as DCOM or OLE2 or both or was ActiveX?). No COM Container, ok it must be the operating system - just run regsvr32 (why was it never spelt regsrv32)? on your DLL. Hmmm.

    The assertion in a previous thread that .NET is more akin to J2SE is nearer the mark. COM objects feel like JavaBeans - ASP+COM+ADO <=> JSP+Beans+Servlets+JDBC but where's the EJB?

    In the Web Application arena ASP.NET is brilliant and Java heads should feel comfortable with the slew of technologies, which Microsoft have improved and added. Microsoft excels at keeping simple things simple. The ASP custom tags were sorely missed before. And no more stopping servers when you update your DLL (sorry COM object), just pop it into the bin directory in the web app and keep cycling. There's a web.config XML file which I immediately felt at home with coming from servlets. To output debugging info merely add "debug=true" to the language tag at the top of the ASPage.

    Another point about the cost of MS v OpenSource Java is that the .NET SDK Framework is free. Start there, don't fork out for Visual Studio (yet). The free framework even ships with a GUI debugger. What did amaze me though was the 131Mb download! Good ol' MS bloat and the samples are very limited. Some dedicated MS bod would do well to write the equivalent examples that ship with the Java SDK especially the JFC 2D sample.

    As for C# - stop complaining and drawing comparisons it's exactly what you want if stepping in from Java. Forget about J#; do you thing Microsoft are ever going to nurture anything starting with a "J"? However, this multi-language business is going to cause headaches for IT managers with training budgets - which language to choose? At least with Java it's just Java Java Java. Already I find there are strong opposing camps with VBScript versus JavaScript. Wait until the COBOL.NET brigade start!


    At the end of the day I feel that if you are going to get stuck with implementing a pure Microsoft solution then just go for it and soak up every little detail about .NET. Bend it to your likening and stop saying "why didn't we do it in Java, I miss Java, I want my nanny"



    Take care
    - Maurice Lynch

    P.S. Container Container where forth arth thou? Someone enlightenment me.

     

  190. Nice feature. Keep them coming. I especially like the way that he could relate to things in terms of the java viewpoint. Even within our own world we argue to death about architecture and implementation - so for him to have a different perspective is pretty good, one of us and not one of them. He saw both sides, but argued his - I get the impression he believed it and was not simply doing it because of the pay.

    Java cross platformedness? When .Net framework is installed on all corp. PC's (admin right needed, 20M install), I wonder if the question will become: how will your java app run on my .Net framework. Is .Net the platform rather than wintel, and if it is then java isn&#8217;t going to be cross platform anymore. It&#8217;s a view at least, and given msoft's aggression could be true. What we need is a java VM that runs on top of .Net - is anyone working on this? It then becomes another supported java platform.

    Not being too silly here. msoft are pushing the common intermediate language(CIL) - your high level lingo simply 'compiles' down to that. They make it run on the hardware then.

    And the SDK is as cool as the original java one - except for the bloat, but we all have higher bandwidth now :). So you can do your apps right off.

    Keep these articles coming, and I am still waiting for some J2RS stuff - i.e. Java 2 right size. This should be a simple menu of technologies, all best of breed, all compared independently in ONE page. And maintained quarterly to reflect JDK and Jakarta recent updates.

    eg:
    Right Size 1: 100 concurrent users, young dev team training up.
       Tomcat, JSP, JDBC, Oracle/SQLServer/MySQL
    Right Size 2: 100 concurrent users, java trained already.
       Tomcat, Struts, DAO, Oracle/blah blah
    RS3: 100 concurrent with transactional features
       JBoss, MDB, Struts, DAO, blah
    RS4: 1000 concurrent transaction, fully owned DB, budget
       Weblogic, EJB, MDB, ...
    RS5: Software shop selling into client&#8217;s infrastructure
       JBoss/WebL/Orion (as is)/WebSphere/etc,
       CMP, MDB, Deployment Descriptors, JAAS

    and so on. Maybe have about 10 of them. Some with Velocity/Coccoon/Struts/whatever.

    This Right Sizing of java would be very useful to so many folks, and would provide a training list as well.

    Jonathan

  191. Hi Jonathan,
    <quote>
     eg:
    Right Size 1: 100 concurrent users, young dev team training up.
       Tomcat, JSP, JDBC, Oracle/SQLServer/MySQL
    Right Size 2: 100 concurrent users, java trained already.
       Tomcat, Struts, DAO, Oracle/blah blah
    RS3: 100 concurrent with transactional features
       JBoss, MDB, Struts, DAO, blah
    RS4: 1000 concurrent transaction, fully owned DB, budget
       Weblogic, EJB, MDB, ...
    RS5: Software shop selling into client&#8217;s infrastructure
       JBoss/WebL/Orion (as is)/WebSphere/etc,
       CMP, MDB, Deployment Descriptors, JAAS

    </quote>

    yes this is what i am yearning for..thank God there is atleast some one on earth who feels the same :-)

    wish some day some company works on this & help customers in J2EE arena to choose the right stack they want..

    Good luck
    ~murali
  192. Nick,

    In .NET land, I was just viewing their OS (Windows) as the application server. OS and the application server become one.

    Isn't that correct?

    Mike



  193. "In .NET land, I was just viewing their OS (Windows) as the application server. OS and the application server become one.

    Isn't that correct? "

    Not completely so.

    Some of the services are there (JTA/JDBC/J2EE Security equivilents).

    However, for a free-standing Business Logic tier, the only thing going is MTS - and that means DCOM junk rather than .Net remoting.

    I really struggle to understand how .NET and J2EE can even be compared without a CLR-based AppServer...


    -Nick


  194. "However, for a free-standing Business Logic tier, the only thing going is MTS - and that means DCOM junk rather than .Net remoting."

    Not exactly true, you hace (D)COM and COM+. .Net applications will use (existing) COM+ runtime services for e.g. transaction management, role based security etc. .Net (the CLR) will bring another (a far better) component/object model to Windows development, a model which has IMHO features already found in the Java model (some remarks on this new programming model see: Don Box column House of COM on http://msdn.microsoft.com/msdnmag/issues/1200/com/com1200.asp) A quote from Tim Ewald's book Transactional COM+ , appendix A: "The CLR is a replacement for COM, but not for COM+. CLR classes can be configured to use COM+ runtime services the same way COM classes do. In fact you can mix both classes using both component technologies in the same COM+ based system. This works because the CLR is backwards compatible with COM. The .Net Framework SDK simplifies COM+ programming...."



  195. >>Net applications will use (existing) COM+ runtime services

    Does this mean they can use .Net remoting?
    Does it mean they have to be wrapped as COM objects?

    -Nick
  196. Does this mean they can use .Net remoting?

    >>Does it mean they have to be wrapped as COM objects?

    No remoting, No Wrapping !!
    it is this simple ...
    Example:

    using System.EnterpriseServices;
    public class Account : ServicedComponent
    {
    ....
    };





  197. I think one major issue was overlooked in the interview. What about security? How can you possibly get a quality and consistent security model coming from a company known for it's security holes. I would be very afraid to store private customer information on the new .net platform especially if it is build with a variety of languages with who know's what kind of security model build in. Please, somebody throw them a life jacket. Although I doubt the life jacket will hold up the anchor.

    ds
  198. Does this mean they can use .Net remoting?

    Why not? (altough this is not advocated by MS judging from what Doug Purdy says on this in the interview: "The best practices architecture you described of basically making sure your Enterprise Services are local to your ASP.NET layer sounds very similar to, in our world, having your servlet and EJB app. co-located on the same VM, and using local interface calls directly to the EJB layer? Is that how it is? Yeah absolutely. We really believe that the cost of marshalling is enormous, it's very expensive. If you can eliminate the marshalling layer, then you certainly should try to do that. Now obviously, the .NET framework will support having the middle tier on a separate physical machine and there's a lot of secure scenarious where indeed you want to be able to support that. So we do support models but the best practice is very similar to what it may be with EJBs running in the same VM utilizing local interfaces. Put them on the same box and eliminate marshalling"
     

    > Does it mean they have to be wrapped as COM objects?
    No!


  199. .Net Appserver[ Go to top ]

    Frank, Soundra,

    Ok, firstly:
    Have you actually written a 3 tier app using .net - where the three tiers are physically seperate - AND used .net remoting? I just need to know if what you have posted (.net remoting and COM+) is educated opinion or proven experience?

    If it was just me who held this opinion (re lack of appserver) I would be inclined to back down. However, we have a couple of people who have been working with .net for a little while (Long-time Microsoft developers, before you ask) - and the lack of an MTS equiv is one of the first things they discovered when they actually tried to do something meaningful. I would be very interested to know if you have an angle they have missed. (No offence, but suspect our guys know what we need to build and therefore know what is missing)

    Regardless of debates/opinions on process affinity and usage of local interfaces, avoiding marshalling etc, etc, it is largely irrelevant to us. Almost all of the apps we do are NOT web based (the browser just doesnt provide the functionality we need). And anyway, if they are internet facing web apps, the tiers need to be physically seperated for security reasons (there is a firewall between each tier)

    So, getting back to .net:

    My question is: If your .net component is making use of the COM+ services AND using .Net remoting, then:

    a) How is the object activation done? Do I have to write something that implements an NT service, listens on a port and dispatches the calls? (This is the sort of stuff that we dont want to write because its what an appserver does).

    b) What port do I contact the component on? Do I just contact a server, or do I have to contact each "service" independantly?

    I fully realise that if you use IIS to front the components (as an ASP.net web app or as a SOAP service) then this is done for you (much the same as using Apache Axis and a servlet engine).
    However, I asked my question in a very specific way - viz a "free-standing" business logic tier. Something that would serve a WinForms Client (or Java/C++ for that matter).

    Again, my understanding is that you need to use DCOM protocol if you want to take full advantage of COM+/MTS.

    Interested to see what I am missing...

    -Nick

  200. .Net Appserver[ Go to top ]

    Hi Nick, allow me to step in:

    "Have you actually written a 3 tier app using .net - where the three tiers are physically seperate - AND used .net remoting? I just need to know if what you have posted (.net remoting and COM+) is educated opinion or proven experience? "

    Yes, first we saw it running in three physical layers of which the GUI and business layers were by themselves clusters. Then we wrote it and put it to run for one of our customers (a small local bank).

    "My question is: If your .net component is making use of the COM+ services AND using .Net remoting, then:

    a) How is the object activation done?"

    Let me see what you want to do is to remotely invoke a method which is part of a COM+ component, right? A skeletal and simplistic example (but it will give you the idea):

    1. Create the component as in:

    // COM+ registration details
    [assembly: ApplicationName("Northwind Traders")]
    [assembly: ApplicationActivation(ActivationOption.Server)]
    [assembly: AssemblyKeyFile("..\\..
    NorthwindOrders.snk")]

    namespace NorthwindOrders
    {
      [Transaction(TransactionOption.Required)]
      [ClassInterface(ClassInterfaceType.AutoDispatch)]
      public class OrderComponent : ServicedComponent
      {
        public int PlaceOrder(string orderCode)
        {
          try
          {
    // whatever operations you need to do
            ContextUtil.SetComplete();
            return theResult;
          }
          catch (Exception e)
          {
            ContextUtil.SetAbort();
            throw new Exception("Error ... " + e.Message);
          }
        }

        // in this case SetComplete() and SetAbort() are
        // called automatically as needed
        [AutoComplete]
        public int CancelOrder(string orderCode)
        {
          // whatever operations you need to do
          return theResult;
        }
      }
    }

    2. Create a .Net remoting facade for this component

    namespace OrderServerFactory
    {
      public class OrderFactory : MarshalByRefObject
      {
        public int Place(string orderCode)
        {
          OrderComponent oc = new OrderComponent();
          oc.PlaceOrder(orderCode);
        }
      }
    }

    The MarshalByRefObject inheritance does the trick of marshaling by reference the OrderFactory object, if you don't use the inheritance the object is marshaled by value, i.e. it is copied to the client process (which may or may not be what you want to do).

    3. Create a runnable class that expose the factory to the net:

    namespace OrderServer
    {
      class Server
      {
        public static void Main()
        {
          TcpChannel chan = new TcpChannel(2001);
          ChannelServices.RegisterChannel(chan);

          RemotingConfiguration.RegisterWellKnownServiceType
              ( typeof(OrderFactory), "OrderServer",
                WellKnownObjectMode.Singleton );
          Console.WriteLine("Server running.\nPress <Enter> to terminate the server");
          Console.ReadLine();
        }
      }
    }

    Here the server is exposing the facade using TCP port 2001, binary enconding, and using a single OrderFactory object to attend all the calls.

    And voilà, you have exposed a COM+ component using .NET remoting. Of course, production code would have to fill a number of gaps, but you get the idea...
  201. .Net Appserver[ Go to top ]


    >> 3. Create a runnable class that expose the
    >> factory to the net:

    Aha! Exactly.

    Thats what I said - you have to write your own server. (write code that registers each component, write management code, write etc etc).

    Thats not the sort of stuff I feel we should be writing. Thats what an appserver is meant to do...

    Its just like RMI - but obviously a whole lot better (it has declarative transaction/security and the like). Its still not an appserver though - you still have to write infrastructure code that you shouldnt have to write. It is also missing some functionality too (like hot deployment of new components etc).

    -Nick
  202. .Net Appserver[ Go to top ]

    "Thats what I said - you have to write your own server. (write code that registers each component, write management code, write etc etc). "

    Oh, excuse me, I thought that, being among fellow programmers, you would've found cool that we can create a "server" in three lines of code. Yes, controlling threading issues and exceptions would take it to a few dozen lines, including an XML file listing the classes to be exposed. But if even this is unsatisfactory to you, you can always use IIS as your appserver, all it takes is a few configuration lines, like these:

    <configuration>
       <system.runtime.remoting>
          <application>
             <service>
                <wellknown
                   mode="Singleton"
                   type="ServiceClass, ServiceClassAssemblyName"
                    objectUri="ServiceClass.rem"
                />
             </service>
             <channels>
                <channel
                   name="MyChannel"
                   priority="100"
                   ref="http"
                />
             </channels>
          </application>
       </system.runtime.remoting>
    </configuration>

    So now you have a zero-lines server, but have to deal with a XML configuration file.
  203. .Net Appserver[ Go to top ]



    >>Oh, excuse me, I thought that, being among fellow
    >>programmers, you would've found cool that we can create
    >>a "server" in three lines of code.

    Cool it may be. But I am sure you are aware it is many more than 3 lines of code for a non-toy, production application.

    That is exactly the code we shouldnt be writing. In addition to the server code, you have to write administration tools, configuration management, write documentation so production people can support it, etc etc etc. Writing servers is exactly what we shouldnt be doing as IT developers. If we want to write servers, we work for an appserver company.

    Not only that, what will be developed by a project team is likely to be pants. (Its bound to be. Its their first attempt).

    And, not only that, you still dont have functionality that appservers have (ie, every time you need to add a new component you have to write more infrastructure code)

    -Nick
  204. .Net Appserver[ Go to top ]

    Edgar,
    I think this discussion is wrong footed. All these .NET technologies are cool, and it seems that a lot of what can be done with Java can be done within the .NET framework.
    In that regard what is left unanswered is how performant a .NET based system would be in a very high volume middle tier app using straight through API calls to the back end. What is there in the architecture that allows you to tune it for performance and make known calculable trade offs?
    So Edgar, it may be cool, but cool isn’t a technical reason to adopt a technology. What were the technical reasons you had for adopting .NET, on which points did it compare more favourably than competing solutions including Open Source? And now throw cost into the equation, including cost of purchase, development and maintenance, how was the decision made?
    .NET is damn cool, but what are its overall, quantifiable advantages?
    Cheers,
    Adam
  205. .Net Appserver[ Go to top ]

    You're right when you say that coolness is not a good reason for using a technology in any given project. On the other hand coolness is a very strong adoption factor in the developer community. Don't get me wrong: I believe that it is in the best interest of the developer community at large (not only Java, .NET or whatever) to have strong and evolutioning options to choose from. In this sense, having a strong and always enhancing Java offering is not only good but necessary. The thing is that, after having fought bravely and with good reasong against the status quo during 1996-1999 (when Java was so cool, mostly a toy, but so cool), I see that Java is now becoming the status quo, and as such is starting to loose interest in learning and enhancing, switching instead to a policy of FUD about what .NET is (beware of big bad MS, .NET can't connect with everything, MS will chase you back with patents, etc.). Furthermore, there is this *immense* ignorance about .NET, this ignorance added with a false idea of intrinsic superiority (MS will never create something as good as Java) is a very dangerous strategy for the future of Java. That's why every time I see a blatantly false statement about what .NET can't do, I feel the obligation of setting the record straight.

    You asked if I had quantifiable reasons for choosing .NET over Java in some projects, I only have one so far: Programmer productivity, say what you like, you *are* more productive in .NET (a fact not only due to VS .NET). This is a repeatable experience from programmers that have previously worked with Java (and no, they are not morons, and even if they were, how come they are morons in Java and perfectly good in .NET?)

    Whether .NET will scale in very demanding environments is something which remains to be seen. But this does not equals to ".NET doesn't scale" let alone ".NET will never scale", I say you better keep J2EE enhancing because .NET will scale.
  206. .Net Appserver[ Go to top ]

    <Q>You asked if I had quantifiable reasons for choosing .NET over Java in some projects, I only have one so far: Programmer productivity, say what you like, you *are* more productive in .NET (a fact not only due to VS .NET). This is a repeatable experience from programmers that have previously worked with Java (and no, they are not morons, and even if they were, how come they are morons in Java and perfectly good in .NET?) </Q>

    If by productive, you mean whipping out exe's then I would tend to agree. If you mean reusable code, unit test, refactoring, incorporating different aspects, incorporating different ui's, maintaining, etc. then I would say you are wrong. I've used MS products for years and a good Java IDE for a few years. I'm a pretty quick learner and learn most things on my own (not classroom). I've whipped out something in VS.Net but to do something robust and well thoughtout will take just as much time[at least]. And VS.Net is not a quick learn. I don't think VS.Net has been out long enough to determine if it really is more productive.
  207. Myth of superiority of VS.NET[ Go to top ]

    The claim that VS.NET is a more productive environment is a complete MYTH. It may get a developer up and running faster using wizards, however, that's a small percentage of the development process.

    I agree with Mark, once your in a real environment and do multiple things and integrating multiple systems, then the something like Eclipse is the way to go. Requirements and design do change in development, that's why refactoring tools are important. That's also why JUnit tests are extremely important. Integrating with different kinds of systems, using code generation tools, using interpreters all this is important and you need some like ANT to pull it all together.

    Maybe you might be more productive in VS.NET creating nice form based GUI applications, however serious heavy lifting software needs serious having lifting tools, VS.NET is a toy, and is definitely something inadequate for serious development.
  208. Myth of superiority of VS.NET[ Go to top ]

    <quote>
    VS.NET is a toy
    </quote>

    Carlos,

    Perhaps you can share with us all a screencam or whatever of you switching from editing to server side debugging in your non-toy environment?

    I haven't seen loads of wizards in Visual Studio... I see a snappy environment written by people who understand the needs of developers.... All this sort of stuff is really so personal its not surprising that people dont agree. Developers never have. However I would love someone to step up to the plate and share with us a screencam of their productive J2EE environment. Slagging off MS is easy to do, demonstrating something better is a little harder I think. I'd be happy to be proved wrong though!

    Regards

    Quentin

    Quentin
  209. Myth of superiority of VS.NET[ Go to top ]

    Okay Quentin,

    Let's go on a bake-off. We'll use viewlets from www.qarbon.com to show off the features of VS.NET vs Eclipse. You'll do VS.NET and I'll do Eclipse. You think you're up to it?

    Anyone recommend a place where we can host this?

    Carlos
  210. Myth of superiority of VS.NET[ Go to top ]

    Carlos

    Well I already posted

    http://homepages.nildram.co.uk/~newbolds/index.html

    showing server side debugging. I am genuinely interested in seeing what you've got to show. For my paid work I used UltraEdit / vi, Ant and to debug I'd use either console / telnet and println or perhaps log4j....

    Quentin
  211. Myth of superiority of VS.NET[ Go to top ]

    Quentin
      Now that Carlos has shown you this, show us how you can do something like JUnit, refactoring and AspectJ in VS.Net (right now - not when someone writes it and then we have to buy it).

    Then show us how you find a class in the IDE, that you know is in a loaded namespace, but you only know the classname or only the first few letters.

    Then show us how you can change values in debug mode.
      
    Then show us how to create more than one class in one namespace that can be run with its own main without changing any setting in the IDE.

    Then explain how having to deal with Assemblies and namespaces is better than just packages.

    Then switch persistance frameworks without writing a line of SQL or modifying your business objects (With currently available ones).

    Then change your database vendor (no recoding exception handling).

    Then change an API that is used many places and add a few exceptions but don't tell anyone or add the exceptions to help or let anyone see the source. Just tell them they should recompile or pull the new version into their IDE.

    Then take your project and run it on Windows, Linux, Unix, Mac, AS400 and z/OS and an IPaq. And then divide it up and run it on a couple of these platforms.

    Then yank all your code from your IDE and send it to a buddy who has volunteered to help but hates your IDE and has all these cool macros he/she wrote for some thing he/she uses. You don't know what tool or platform he/she is using.

    Then implement your UI in three - no four different solutions not including HTML that provide different solutions to the same problem browers 'solve'.
  212. Myth of superiority of VS.NET - more[ Go to top ]

    then try - http://sangam.sourceforge.net/
  213. Myth of superiority of VS.NET[ Go to top ]

    Mark

    Who has demonstrated what so far?

    Quentin
  214. Myth of superiority of VS.NET[ Go to top ]

    Oops. Got my names crossed. This thread is too big. Anyway, since you are awake - by serverside do you mean debugging on another machine or serverside code? Anyway go ahead and answer the questions because it can be done either way in Eclipse/WSAD. I develop on one machine and usually have the application server (full fledge) on the same so there is no need to have it running on another machine. It is the same thing.
  215. Myth of superiority of VS.NET[ Go to top ]

    Mark

    Either of your scenario's may be considered server side. In answer to all your other requests... well you and I know the answer to many of these and they are all good reasons why one might choose J2EE. Great for you and me.

    However my point is simply that Visual Studio and .NET is no toy. Sure there are things that aren't cool but you specifically asked for debugging and changing values. Coinicidently that's exactly what I showed you... No stopping the app server and restarting it with some weird set of parameters and although you can't tell in a viewlet, no waiting around thinking that something had crashed whilst you hard drive struggles to page in out shed loads of memory. It all just works out of the box.

    By the way I'd love to see a viewlet of you doing all that stuff you asked me to do. I might learn something useful ;-)

    Quentin
  216. Myth of superiority of VS.NET[ Go to top ]

    Mark, Quentin,

    So we can compare apples-with-apples lets just make a short list of features let's just start with yours. What Quentin showed (i.e. Creating a Webservice and debugging) is completely trivial and does not show off the features of the IDE (it shows of the features of the webservice implementation). In Axis you just copy your java file in the webapp directory and you're done! It's just as simple in GLUE. Debugging a server is a no brainer.

    Anyway, let's narrow your list to what we can show in viewlets:

    (1) Create a new class given an interface.

    (2) Extract a snippet of code, and make a method out of it.

    (3) Find the definition of a class.

    (4) Write a snippet of code and test it.

    Now in all cases, feel free to include any nice features that help you show off some nice features of the IDE. That fair enough for you Quentin?

     I was working early this morning on a viewlet, unfortunately it was too big. Looks like I need to split it up into simple steps. Can we agree on these (4) scenarios?

    Carlos


  217. Myth of superiority of VS.NET[ Go to top ]

    Carlos

    I'm not much interested in your agenda. However I am interested in seeing the "no brainer" debugging a server. I genuienly have never seen this work well in J2EE. I am sure this is my ignorance. Since I've shown you mine I think it would be nice to see a bit of yours ;-).

    Quentin

  218. Myth of superiority of VS.NET[ Go to top ]

    Quentin,

    Okay, so how about this we do the 4 scearios I mentioned, plus will add the debugging a webservice scenario.

    So the scenarios are:

    (1) Create a new class given 2 interfaces.

    (2) Extract a snippet of code, and make a method out of it.

    (3) Find the definition of a class.

    (4) Write a snippet of code and test it.

    (5) Create and debug a webservice.

    Agree?

    Carlos
  219. Myth of superiority of VS.NET[ Go to top ]

    "In Axis you just copy your java file in the webapp directory and you're done! It's just as simple in GLUE. Debugging a server is a no brainer."

    I also use GLUE, and I agree it's very nice, but, how do you debug a web service from Eclipse? I would love to see how you do it...
  220. Myth of superiority of VS.NET[ Go to top ]

    If I get a chance I will try. Should be easy.
  221. Myth of superiority of VS.NET[ Go to top ]

    Edgar,

    Quentin doesn't seem to be up to the challenge. If you could build some viewlets of VS.NET for the 5 scenarios I propose. I promise that I'll give you the equivalent for Eclipse. I assure you the debugging of a webservice using GLUE and Eclipse is a no-brainer, in fact, I've got something to show that will make your jaw drop.

    Carlos
  222. Myth of superiority of VS.NET[ Go to top ]

    Carlos

    I'd be up for most things but so far I've done the work and everyone else has just talked a good talk. Bottom line is Carlos that if you'd read what I have written you'd realise that I am a J2EE guy who's idea of an IDE is vi and telnet. I am probably not the world's greatest Visual Studio expert and I am certainly not going to waste my time learning .NET to jump through hoops for your satisfaction. If your are so keen to see it then do it yourself.

    Still I am waiting to see a J2EE debug session that doesn't involve stopping and starting the server with some weird combination of parameters and hours of setup. To be clear in the toy environment its write your code in the editor, F9 to set your breakpoint and F5 to start your server side debug session... If you can make it this smart and simple in a J2EE environment then I'll ditch UltraEdit and vi!

    Regards

    Quentin
  223. Myth of superiority of VS.NET[ Go to top ]

    Okay Folks!

    Here's it is, debugging webservices using Eclipse and Glue.

    http://www.geocities.com/ceperez/eclipsedebugginwebservice_viewlet_swf.html

    Enjoy!

    Carlos
  224. Nice work Carlos!

    (that was actually a really impressive demostration of eclipse and java!)
  225. Myth of superiority of VS.NET[ Go to top ]

    Carlos

    Very nice. I like the look of that. I’ll check it out when I am back in the office. My customer is currently using SilverStream 3.7X app servers. I seem to recall reading something from their CTO or someone, being less than positive about eclipse. I’ll try and see what can and can’t be done with eclipse and SilverStream...

    Quentin
  226. Myth of superiority of VS.NET[ Go to top ]

    So, any .NET promoters ready to take on this viewlet challenge? (For reference, Scenarios listed above)

    Quentin, did a good job showing off VS.NET's webservice debugging. I did the same for Eclipse. If you look at it, VS.NET doesn't show any clear advantages over Eclipse when it comes to WebServices or Server Debgugging. This comparison is in an area where Microsoft's solution is claimed to be superior. However, it clearly is not!

    How about showing off Microsoft's "Intelisense"?
  227. Myth of superiority of VS.NET[ Go to top ]

    Does not have anything to do with dotnet per se

    anyone seriously considering dotnet - i am sure u have at present windows boxes or lots of clients on windows - i assume your server side is not as important as the client side - u need rich client side functionality

    well lindows is coming www.lindows.com

    mebbe your clients will pay you more for less windows license liability

    dont say nobody warned u

    anyone for mono on linux :)
  228. I know one global co that is preparing for global upgrade to XP, with .Net framework as part of that.

    They are also evaluating the role of Open Source for the enterprise, in servers not clients.

    They also develop nearly all enterprise systems with heaps of stored procedures.

    They even use shell scripts and perl for data feeds.

    Sometimes they install weblogic as the server, and sometimes apache or tomcat. But they are transitioning from Netscape to IE. Except when they use Notes. They have loads of VB, and IIS systems.

    So there is a clear winner here then.... :)

    In fact, they only thing that they are pretty certain of is the drive towards soap as a cross technology infrastructure. XML will save the world after all. Except in their core transaction systems, written in C++ which are fundamental to the business. Some of these will use message queues, and some corba. Except those using vanilla sockets, or database triggers.

    And all users are building access and excel 'databases' and demand heaps of VBA. CSV's rule in this space.

    Ho Hum.

    Jonathan

    ps Loved the viewlets. Very nice.
  229. Jon Gibbons writes:

    "know one global co that is preparing for global upgrade to XP"

    and

    "They are also evaluating the role of Open Source for the enterprise, in servers not clients."

    <Plus tons of descriptions on how this corp also uses Weblogic, Apache, Tomcat, scripts, and perl, & uses SP's and VB.>

    What are you getting at here, Jon? That this corp is going to upgrade the desktop to XP and .NET, or that it's going to bin everything else? Unlikely I would think. I could see them trying to hook up a bunch of systems using Web Services though.
  230. Myth of superiority of VS.NET[ Go to top ]

    Impressive demo, I certainly learnt a couple of things, congratulations and thank you.
  231. Myth of superiority of VS.NET[ Go to top ]

    Here's it is, debugging webservices using Eclipse

    > and Glue.
    >
    > http://www.geocities.com/ceperez/eclipsedebugginwebservice_viewlet_swf.html
    >
    > Enjoy!

    Great job, Carlos, with the demo!!!
  232. .Net Appserver[ Go to top ]

    You're telling us that this has been proven with smaller apps only so far.
    Listening to Doug Purdy he too offers few compelling reasons to go to .NET.
    Of course there is suspicion and FUD. But I don’t think that MS .NET is the great white horse of technology. It’s a comparable technology that has difficulties to iron out while it seeks its market. Gradually it will migrate up. No more, no less. Meanwhile J2EE technologies will evolve including tool support etc. In the end there is no silver bullet. And that is where it depends on developer skills. Note Doug Purdy. He says the developing should be simple!
    But we know that is not possible. We are creating complex solutions to complex problems. If any tool can help, great. If we are not hindered by the framework, so much the better. But, in the end, the team of developers have to know what they are doing and how to make the trade offs they make. Doug, for instance, didn’t offer a good reason for the design decision to use declarative programming :-
    <q>
    … but what's interesting about .NET is we support a thing called declarative programming or attributal programming …</>
    The administrator should alter the deployment descriptors in the EAR or WAR jar files. It would be strange if they did. The deployer should be looking at those files though. But that is a side where the J2EE paradigm scores, as this allows for separation of roles and parallel development activities.
    Lacking this would translate into slower development.
    From the discussion so far it is unclear what those trade offs are in .NET.
    w.r.t. <q>MS will chase you back with patents, etc.</>
    They will if they so choose.
    w.r.t <q> Programmer productivity </>
    I believe you. Everyone agrees that J2EE is complex, and that, quite possibly, it could be compartmentalized (indeed componantized) into well sized solutions for types of project, as discussed elsewhere on tss.
    I take it that productivity led to a lower price as against zero cost Open Source and some of the saving was passed on to the customer?

    Cheers,
    Adam
  233. .Net Appserver[ Go to top ]

    <q>
    administrator should alter the deployment
    </>
    I mean administrator should - not- alter the deployment
  234. .Net Appserver[ Go to top ]

    "w.r.t <q> Programmer productivity </>
    I believe you. Everyone agrees that J2EE is complex, and that, quite possibly, it could be compartmentalized (indeed componantized) into well sized solutions for types of project, as discussed elsewhere on tss."

    I wouldn't say that writing a quick jsp with dbtags or jstl in tomcat + mySQL is complex? Just as easy, or even easier, as php + mySQL.

    You, and many others, seem to confuse j2ee with ejb's which does the java community a big disservice by making j2ee look "complex"...

    EJB's aren't complex either (IMHO)- making scalable, robust and easily maintained server components is...
  235. .Net Appserver[ Go to top ]

    Check out this recent article on JavaWorld by Humphrey Sheil and Michael Monteiro which gives a concise side-by-side comparison of a Web Application designed for J2EE and the equivalent on .NET.

    - Maurice

    "Rumble in the jungle: J2EE versus .Net"
    http://www.javaworld.com/javaworld/jw-07-2002/jw-0726-j2eevsnet2_p.html





  236. .Net Appserver[ Go to top ]

    Here is another good article that explains some of the technical issues and differences between .NET and J2EE.

    http://java.sun.com/features/2002/07/rimapatel.html

    This article is well worth reading.
  237. .Net Appserver[ Go to top ]

    IMHO they was a little wrong on the caching bit as the different j2ee webpage caching technologies available are very mature and can indeed cache both dynamic (whole pages or parts of pages) and static content. Thus j2ee was first and is better even in this area.

    I for myself have used OSCache very successfully (increasing response times *a lot* - http://www.opensymphony.com/oscache/)
  238. .Net Appserver[ Go to top ]

    lol, that should of course read "decreasing ..."

  239. Re: .Net Appserver[ Go to top ]

    For .NET and COM+ interoperability (or so called Enterprise Services):

    1) If your COM+ should be invoked out of process .Net uses DCOM
    2) The way around proposed by MS is to use .NET remoting to the managed, that then calls COM+ componet in process.

    For more detail about this stuff see
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/entserv.asp

    Enterprise Services are basically same as in the COM+, they are just somehow "wired" to .NET using attributes (which are then used register them in COM+ Catalog) and ServicedComponent class, that enables methods of object context.
  240. Re: .Net Appserver[ Go to top ]

    Ivan

    >> 1) If your COM+ should be invoked out of process .Net uses DCOM

    now, are you saying that .Net 'inherits' all the DCOM problems?

  241. Regarding the lack of an EJB equivalent in .Net:

    There are, I think, several responses to this issue. Firstly, it is arguable that the promise of component technologies like Corba, COM+ and EJB have failed to eventuate. Anecdotally, there seems to be a great number of projects that can safely ignore distributed component technologies and provide more-or-less direct access to the RDBMS from the business tier, using the underlying database to ensure transactional integrity. Microsoft has always pushed this model as their preference, which is why the PetStore uses stored procedures. For one thing, it sells more SQL server licenses. (As an aside, Visual Studio will generate the neccessary stored procedures for SQL Server when a datasource is configured, so arguments about productivity and maintenance are relatively moot).

    Remember that Microsoft was first with COM and MTS in 1996. COM+ moved the capabilities of MTS into the OS itself and the declarative transactions, security and pooling are all still present in .Net, albeit hosted on a much lower level of integration than the traditional app server model.

    From the .Net SDK:

    In .Net, developers can write Serviced Components. A serviced component is a class that derives directly or indirectly from the System.EnterpriseServices.ServicedComponent class. Classes configured in this way can be hosted by a COM+ application and can use COM+ services.

    COM+ services, such as automatic transactions or Queued Components (QC), are configured declaratively. You apply service-related attributes at design time and create instances of classes that use those services. You configure some services by calling methods on service-related classes or interfaces.

    So this is how a JIT component is created in .Net, simply by applying the relevant attribute to the class declaration:

    <JustInTimeActivation()> Public Class Account
    Inherits ServicedComponent



  242. Just a comment to this already long thread (doesn't this happen everytime, just mention .Net to spawn a long thread ;-)

    I happen to be in a position of having to recommend one or the other to a client right now. It seems that .NET and J2EE are both good technical solutions. I think you can easily build a web site with either with similar level of effort, robustness, etc (as long as you are happy with sticking to Window's servers, which this client is).

    However I have decided to recomment J2EE to them based for 2 major reasons, only one of which I have really seen mentioned here as a major point:
    1.) The wide spectrum of solutions. There are so many solutions to almost every problem in Java. The number of app servers alone is very large (not to mention all of the support tools, IDEs, etc), from free and full featured to expensive and tool focused, you have your choice. If one were to 'plot' the solutions out, Java would be a mass of points covering the spectrum, while .NET would be a single point While .NET is a high-value product (lots of features at reasonable price) I don't feel it is a "one-tool fits all" solution and there will be comprimises for many that use it.

    2.) Open source software. The support for Java by open source projects is amazing (the entire Jakarta group of projects for example). I wrote a search engine for my companies file system using Jakarta's wonderful Lucene tool that took less than a day to complete. The Java libraries and tools that have been created by the open source world are amazing. Every Java project our company does uses at least 3-4 open source pieces in it everytime. All of our Java development is done with open source tools. Microsoft, on the other hand, has compared open source to communism and cancer (they appear to have softened on this somewhat recently, saying they specifically dislike the GPL and not all open source in general). With this kind of stance and the general dislike of Microsoft by the open source community, it is unlikely that .NET open source projects will be significant (certainly not on a relative scale). If the functionality you need is not built directly into the Microsoft framework you will have to build it or buy it. In the search engine example above, if I had to rely on .NET, it simply would not have been done.

    Cheers.
  243. Good comments Anick. I think most would agree that as a tool and plaform VS.Net and .Net are pretty good. It is these other factors that most miss. They are blinded by the glitter of this new MS has provided.

    I've been looking for tools to solve the same problems in both the MS world and the Java world. The MS world ones [almost] always cost me. I can usually find Java ones of equal or better quality for 'free'.
  244. <Reply to Anick Thistle>
    My sentiments exactly Anick. I am in a similar situation here. We do use Windows Servers as well as various flavours of UNIX. IIS is not used. They use Stronghold(Commercial version of Apache) instead.
    J2EE offers you a wide range of options to implement your solutions. Unfortunately till recently, EJB was promoted as the only solution to all problems.

    .Net sure does have a great development environment and I am sure that it is reasonably robust and technically sound. But I think we can make a sound case for J2EE as well, just as long as you present your case clearly and not make statements like "Microsoft is evil" or ".Net Sucks" or ".Net is .NOT" or something like "Real developers code in Java".
    Regards
    Ravi.
  245. Anick,

    I agree that open source is the strength within the java world. And I can see why msoft hates them - any corp loses control very rapidly when open source gets involved. And a loss of control is nasty.

    I note the POIS (not looked it up, spelling might be off) is tackling the Office suite file formats. So people understand the worth of some microsoft platforms - ie users user them.

    What would be your argument if Lucene was ported? Even IntelliJ and such IDE's(Eclipse) could be ported. The libs are pretty similar and the open source community might do it just for the hell of it. If open source decided to do java and also C# - maybe using an open source porting tool what then?

    This is not a spoiler, I really wonder if open source is java focused, or solution/interest focused. I believe loads of the open source guys use these projects as a form of training in the hope they get consultancy at the back end (but maybe thats my world view). I would think some of the projects would port well to .Net. We could use Java type tools in an MS world. Which would be nice.

    Another factor is that open source is not profit driven. So while corps don't tackle MS strengths because they will lose, open source should have a real chance.

    Anyone working on an open source porting tool? Byte code to CIL, Java to C#. Or maybe the java API's on top of the .Net ones?

    Jonathan
  246. Jonathon,

    "What would be your argument if Lucene was ported?"

    By "what if Lucene was ported" I assume you mean what if Lucene and a large section of open source programs were ported (not just Lucene, which is only one of many important open source compontent relevent to this client).

    Well then I would probably recommend .NET, since this particular client is not concerned about portability and is slightly more comfortable with Visual Basic approach than Java and the .NET tools are probably simpler to use for their needs. But, this is not the case, thus my current recommendation.

    It is possible this stuff could be ported (C# is pretty similar to Java, so the port would probably not be too hard), but I don't know who would do it? Open source people like their stuff to be portable (witness BSD and GNU projects - the original open source) They tend to come from a Unix background, because they value power, configurability and simplicity of the architecture over usability (i.e. config files, small programs combined together through pipes, etc). I find that the people that support .NET the most seem to come from large corporations with a fairly low-skilled IT force (hopefully that didn't come across as derogatory, probably I will get flamed, but it is just my perception from anecdotal evidence). Anyway, these are not the type of people to participate in open source. They are focused solely on solving the problems of their corporation. They have bought into the idea that Microsoft will solve their problems for them and if not then they just have to make due.

    Also, I think it is no secret that the open source community despises Microsoft. It is basically an us versus them mentality. Microsoft - "closed prietary systems are the American way damn it" versus open source - "information should be free" don't exactly have compatible philosophies. Microsoft telling open source folks they are like "communists and cancer" is not a great way to win them over either ;-)

    Could this change? Sure, maybe, eventually, but open source projects take a while to get rolling. They take a while to build up momentum and interest. .NET so far seems to be starting very close to zero (in terms of Open Source support). Even if open source people immediately jumped on the .NET, it would be quite a while before projects were at a useful state.

    Cheers.
  247. Open source projects in C#[ Go to top ]

    "It is possible this stuff could be ported (C# is pretty similar to Java, so the port would probably not be too hard), but I don't know who would do it?"

    A few pointers:

    Ant: http://nant.sourceforge.net
    log4j: http://sourceforge.net/projects/log4net/
    Programmer's editor: http://www.icsharpcode.net/OpenSource/SD/default.asp
    CVS: http://www.icsharpcode.net/OpenSource/NetCvsLib/default.asp

    And of course:

    CLR: www.go-mono.com

    Yes, the sample pales compared with the Java burgeoning open source community, but .NET open source is already alive and kicking.
  248. Open source projects in C#[ Go to top ]

    Only time can tell, but right at the moment Java has a huge advantage, to be sure.

    SourceForge.net projects by language (there are a lot of amateur projects here that never take, probably 80%)
    C# / .NET - 290
    Java - 5855

    Apache
    C# / .NET - 0
    Java - 25 or so, every one of them a seriously powerful and useful tool.

    GNU
    C# - 0
    Java - 2189 hits in the search engine, don't know how many projects this translates into.

    Google directory Computers > Programming > Languages > Open Source
    Java - 2398
    C# / .NET - 0


    Google search

    +open +source +C# 86,500 hits, probably most of these are news articles talking about Mono ;-)

    +open +source +Java 1,730,000 hits


    You get the idea. I searched for C# projects some time ago. Specifically I was looking for portal projects (the existing commercial portal tools are just way too expensive to even consider). I found 2 solid Java open source projects (one of them from Jakarta of course, who else), but none for .NET. In fact I found very few portal solutions for .NET at all (even commercial ones). This is not that surpirsing given the .NET is new, but it means I have to rule .NET out. It just doesn't have what I need at the moment unless I am willing to pay through the nose for everything or develop it myself.

    Cheers.
  249. Here's another interesting statistic that is very interesting.

    Search in sourceforge.net for VS.NET projects:

    One entry, a CVS plugin with no activity.

    Try Visual Studio:

    try searching now for "eclipse":

    You get 65 projects, more that 30 of them having released files and are active.

    The cornerstone of microsoft's language strategy is the IDE, it's not the language, or the CLR, or support for webservices. It is VS.NET, if VS.NET cannot gain grass roots support comparable to eclipse, then the strategy is doomed to fail.

    Historically Microsoft had an edge in terms of providing a sophisticated IDE, however today, the tables have completely been turned. VS.NET is fighting an uphill battle, it has yet to provide sophisticated navigation and browsing capabilities, refactoring support or change management support.
  250. Open source projects in C#[ Go to top ]

    How about a Windows open source Version of .Net? Even if Mono (Linux) works it would be good to an OS version on Windows. If not we really are in the same boat.
  251. Open source projects in C#[ Go to top ]

    "How about a Windows open source Version of .Net?"

    Actually Mono does run in Windows.
  252. Open source projects in C#[ Go to top ]

    So, to do C# on Windows, one needs nothing from MS?
  253. Open source projects in C#[ Go to top ]

    "So, to do C# on Windows, one needs nothing from MS?"

    Right now the answer is no. To quote the Mono site:

    "MCS is written in C# and uses heavily the .NET APIs. MCS runs on Linux (with the Mono runtime) and Windows (with the .NET framework runtime)"

    MCS is off course the Mono C# compiler. Eventually though, as the Mono runtime will be the same on Linux and Windows, this limitation should disappear... (but now I am speculating)

  254. I'm not sure I'll touch it[ Go to top ]

    It's difficult to see Mono as a viable platform due to many unresolved legal and technical issues.

    Here's what Bruce Perens, HP's Linux strategist said regarding Mono and Samba (keep in mind that HP appeared to support Mono early on):

    "If we don't get that agreement [with MS], I'll be happy to see Ximian implement this stuff, but I'm not sure I'll touch it. I'm also not sure I want to let it touch the rest of GNOME very much because if GNOME becomes dependent on it, it would have a potential weakness there."

    "This means you cannot make a compatible implementation without potentially infringing on a Microsoft patent. We went ahead and did it anyway, and Microsoft hasn't enforced that patent, but it doesn't mean they never will. This is a telling case as they've taken what was an open protocol and deliberately put in a patent to close it and then introduced the patented feature in all new systems."

    -- Igor
  255. This is really very interesting and usefull interview to have benchmark between J2EE and .NET,

    Thanks for TheServerside.com

    But I have one concern about the security of Enterprise Services component in .NET where we can write a component and able to access from out side as a webservices up to method level, How this is secured?

    Viswa
    SLK Software
    Bangalore-INDIA
  256. Yes, it was an ok interview ... I guess. My thoughts:

    1 - "Technology Evangelist": What's with this job title anyway? I guess if they pay you enough, the label is mute.

    2 - "program in assembler": No Doug, aka super-tech, you "program in assembly". How many of you "program in compiler"?

    3 - An "F" in Originality: Watching and studying J2EE for a few years and porting it as .NET with a few more bells and whistles is hardly an accomplishment for a $XXX Billion dollar company. A recipe repeated over and over again. Oh well, if nothing else it should be a snap for J2EE folks to learn .NET when the customer will settle for nothing else.

    4 - "24 languages": What a nightmare! Name me a shop that doesn't favor use of the fewest technologies possible to get the job done! 'Choice' equals 'out-of-control' engineering standards, practises, etc for most any shop.

    5 - "No CMP": I like EJB 2.x CMP! Surely its coming ... just taking them a bit longer to "really" understand it. You know ... its really complex!!

    6 - "Stored Procedures": I try to minimize use of them because of portibility issues but I pay the price in performance. No elegant design would ever rely on heavy use of them!

    7 - Maturity: Obviously a missing ingredient. But, just like NT it will and eventually get its slice of the market. I don't see how the NT market didn't backlash on MS because of all the SECURITY HOLES!! How big is the UNIX Anti-Virus market anyway?

    8 - .NET CLR: Wasn't the JVM declared by MS a major disadvantage (slow, etc) a few years back prior to .NET?

    9 - Marketing vs Technology: Yep, we like competition ... only while the deserving technology innovators are at the TOP.

    Let's hope .NET proves to be a viable technology rather than a marketing feat. And that Sun and the Java community don't "drop the ball".

    JamesHr
  257. Hmm.. interesting. can the site admin please move this thread to the hottest threads corner?
  258. ASP.NET's 'System.Web.UI' classes of the .NET framework enables server side generation of HTML form elements(cross browser compatible). I wonder when JSP/Java tools will have such a feature and a RAD tool to take advantage of the same?

    Surely, this would be a great addition to developer productivity.

    Is anybody aware of any JSR's along these lines, or any tools along these lines.

    I wish not to comment on the Java Platform and it's maturity but I surely feel this would open up a new possibility.
  259. Apache Struts project[ Go to top ]


    Take a look at Struts and Strut's extensions for UltraDev.

  260. My Comments[ Go to top ]

    I am currently a .NET developer, but had some exposures on Java and J2EE (also a big fan of the TheServerSide.com).
    I want give my experience on .NET to this community and pro/cons on .NET compare to J2EE.

    We used VB/COM+ to build our software solutions before, moved to .NET recently. At the mean time, some big clients want us to build WebSphere solution for them. As the architect of the company, my instance reaction is: That is perfect, we can convert to java and J2EE for ever. But the question is: how about other smaller clients. They could not afford this (Will be $1-2 millon dollars more). I know JBoss can do the jobs, but can clients agree on that. I do not know or have no control on that. So our decision is: We will build J2EE verion of our solution if needed, but still main VB/COM+ (.NET in future) as main stream.

    Following are chief reasons we moved to .NET
     1. ASP.NET page is a class. That means you can define your page base which other pages can inherit from. From java side view, ASP.NET page is a combination of servlet and JSP page. By using this, you can implement MVC more easily than using servlet and jsp pages (like what shows in Java PetStore demo).

     2. Web Server Form and Web Server Controls. JSP tag lib is simliar to this. But server form and server controls are just more eaiser and more object oriented and event driven.

     
    --- Better Design in .NET --------------
     Enterprise serviced componet can be public or private. That means I can define some components to be private components. So they are not accessible from out-process.

     All serviced component is derived from System.Enterprise.ServicedComponent. So I can define my serviced component base from this class, and all other class inherited from my base. What the benefit: I can easily scale down my components to regular .NET classes by just altering my base class in case I do not need enterperise services for some reasons (better performance and etc.)

    ---------- Things need to improve for .NET--------
    Entity bean: Even though personally I do not like the entity bean concept, but still it is an important functionality .NET should have.

    Application Server: I think it will be there. But for now, I have to create my own windows service use .NET remoting to register port and things like that.
  261. .Net is very immature it has lots of issue to go to producion buffer overflow, memory leak and security leaks haunts .Net. Java does more than .Net promises Java works now and is stable & scalable. .Net is dead.
  262. Sarwar: "Java does more than .Net promises Java works now and is stable & scalable. .Net is dead."

    Does that mean that this whole thread was a eulogy?

    BTW - be nice to Doug, he might be a long-lost relative.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
  263. I find it fascenating how many grasshoppers there are i nthecomputing industry. Always hopping from one technology to another. Leave it alone.

    .NET doesnt need inteviews or documentation or anythign else to explian it. You take Java and EJB, make it proprietary, non-portable, throw in a couple things not yet available in java but comming and viola!

    THe fact is that this is just yet anothe attempt by microsoft to try to sieze you and your knowledge. Even if we ignore the license agreement to .NET, which is a laugh in and of itself. The fact that it is microsoft is enough to get my suspcions up.

    My opinion is that they will loose this one. EJB has a whole lot of momentum. DIslodging it and java and pushing people back into single platform solutions is a pipe dream. You'd think they'd have learned from msn.net. A network marketed as something with potential to take over the internet.

    Microsoft has bit off more than they can chew yet again.
  264. One world, one leader[ Go to top ]

    Microsoft is famous for its "one world, one leader" policy, such as windows/IIS/ASP/SQL server. IF .NET claims to support multiple languages, why not support multiple OSs and DBs, such ad UNIX/LINUX/Oracle/DB2/Sybase?
  265. One world, one leader[ Go to top ]

    I imagine the reason they don't support multiple OSs is because they really want you to buy theirs. As for the multiple DBs thing, you can use all those databases with .NET, so I'm not sure what the issue is there.
  266. One world, one leader[ Go to top ]

    Mark: "I imagine the reason they don't support multiple OSs is because they really want you to buy theirs."

    That's a good point. On the other hand, they haven't released the licensing details on how .NET could be implemented on other platforms, so they are reserving the right to prevent such a thing from occuring. In other words, if allowing other implementations to move forward helps their PR battle and maybe even helps Microsoft to attract developers, they allow it, but if that damages core revenues, they can excercise various legal levers (including patents) to prevent companies from using those implementations. In other words, Microsoft may not be able to stop Mono (obviously they can't seem to do anything to GPL), but companies that use Mono could easily be liable.

    I don't want to get into a discussion of whether it's wrong or right. Really, it doesn't matter, since doing business under such a shadow as that is simply repugnant to the rational mind. It would be like having a Java license from Sun that gives them the right to change their mind and make you pay if you deploy on something besides Solaris on Sparc!

    Eric G @ Microsoft (under repeated public questioning) has yet to even provide a date as to when Microsoft will disclose the licensing, which I believe they were required to do over six months ago as part of the ECMA process.

    Mark: "As for the multiple DBs thing, you can use all those databases with .NET, so I'm not sure what the issue is there."

    Yes, you can use ADO or even ODBC via managed C++. However, those are arguably second class citizens in .NET, especially compared to the built-in support for SQL Server. Again, right or wrong makes no difference, since the .NET platform is simply not a rational option for most projects and companies, except for those porting Windows-only applications from VB6 or those having to build new GUI applications for Windows-only clients.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Easily share live data across a cluster!
  267. One world, one leader[ Go to top ]

    You could easily say that everything other than SQL Server is a second class citizen, including Access, simply because the main out of the box database support listed is 1) SQL Server and 2) everything else. However, a couple of points on this are:

    1) You can get access using OLEDB to pretty much everything, including lots of other vendor databases (part of the "everything else"). You don't need to use ODBC or Managed C++ to do it. You don't get a couple of extras that MS has for SQL Server, but you get all the core database functionality. The clearest comparison is probably using the JDBC interfaces versus specific vendor classes. You can use the OLEDB provider to get at SQL Server, for instance, or you can use the SQL Server classes, like you can use a JDBC PreparedStatement or the Oracle implementation, which gives you a couple of extra features.

    2) Sun doesn't make database drivers for Java either. That's the database vendor's job.

    I'm not really sure what the big deal is on this point. Oracle makes a database server, and Oracle makes database drivers. Obviously, they are really good at it. I honestly would rather have them making JDBC/OLE-DB/etc drivers for Oracle than Microsoft, simply because they know the database better. Even with that said, Microsoft did release a .NET Data Provider for Oracle.

    Mark
  268. Could I get a transcript of the interview somewhere?

    Regards,
    Manoj