|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 267
Messages: 267
Messages: 267
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #53942
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #53947
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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?
|
|
|
Message #53956
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
"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
|
|
|
Message #53959
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #53962
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #53964
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
<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
|
|
|
Message #53965
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #53967
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #53969
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
Reading Doug's interview, it strikes me how much he knows about J2EE and how little Microsoft opponents usually know about .NET.
--
Cedric
|
|
|
Message #53971
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #53973
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #53975
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and 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 //////// ???????
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.
|
|
|
Message #53977
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #53979
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
<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
|
|
|
Message #53982
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #53983
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #53986
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
You think Microsoft could afford to buy Doug some hair given all the money they're making.
|
|
|
Message #53987
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
"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...
|
|
|
Message #53988
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #53990
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #53992
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #53993
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #53994
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
<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
|
|
|
Message #53995
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
<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
|
|
|
Message #54000
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54002
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54007
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #54012
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54013
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
Jason,
"I'm not even sure XML is a language"
Yep.. but XSLT sure is. :)
Mike
|
|
|
Message #54014
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #54017
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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 :-)
|
|
|
Message #54018
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #54022
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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)
|
|
|
Message #54033
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54037
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54040
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
> 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...).
|
|
|
Message #54041
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #54050
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54051
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
>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.
|
|
|
Message #54052
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE vs. .NET
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
|
|
|
Message #54053
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
<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.
|
|
|
Message #54056
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54057
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54063
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #54065
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #54070
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
MS does have an O/R mapping solution that is in beta.
Stef
|
|
|
Message #54071
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
XDoclet comparison completely wrong
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.
|
|
|
Message #54072
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
"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
|
|
|
Message #54073
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54078
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54085
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54087
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE vs. .NET
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
|
|
|
Message #54113
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
.NET - Multiple langagues - Aren't we missing the point
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
|
|
|
Message #54114
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
>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
|
|
|
Message #54116
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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...
|
|
|
Message #54131
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
<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
|
|
|
Message #54132
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
XDoclet comparison completely wrong
<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
|
|
|
Message #54134
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
XDoclet comparison completely wrong
<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
|
|
|
Message #54136
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
Cedric,
Not necessarily responding to your last message ... but, please, try to make an effort to separate your lips from MS's a**.
|
|
|
Message #54138
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
"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
|
|
|
Message #54146
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
>spare info: microsoft.public.objectspaces
Thanks, but I cannot access anything at that address. Is this a news URL?
|
|
|
Message #54148
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
>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?
|
|
|
Message #54149
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
>but I cannot access anything at that address. Is this a news URL?
news://msnews.microsoft.com/microsoft.public.objectspaces
|
|
|
Message #54150
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE vs. .NET
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
|
|
|
Message #54152
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54155
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
XDoclet comparison completely wrong
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
|
|
|
Message #54160
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE vs. .NET
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
|
|
|
Message #54168
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE vs. .NET
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
|
|
|
Message #54179
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
>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
|
|
|
Message #54183
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54185
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
XDoclet comparison completely wrong
<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.
|
|
|
Message #54192
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
|
Message #54196
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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’t going to be cross platform anymore. It’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’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
|
|
|
Message #54197
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
>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!
|
|
|
Message #54199
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54200
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
You forgot to mention the six figure entry costs for Oracle
|
|
|
Message #54206
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
>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
|
|
|
Message #54207
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
>.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
|
|
|
Message #54210
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
>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
|
|
|
Message #54211
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54213
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
"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
|
|
|
Message #54222
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
<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
|
|
|
Message #54235
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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...
|
|
|
Message #54240
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
"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...."
|
|
|
Message #54242
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Stored Procs / Java over-engineering
<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.
|
|
|
Message #54243
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
J2EE vs. .NET
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
|
|
|
Message #54247
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Stored Procs / Java over-engineering
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
|
|
|
Message #54249
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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
|
|
|
Message #54252
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
"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).
|
|
|
Message #54276
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
TheServerSide Interviews Microsoft's Doug Purdy on .NET and J2EE
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.
|
|
