Slashdot Mirror
Programming .NET Components
One day, I stumbled upon the mono and Portable.NET projects, which are trying to bring all the .NET stuff to the penguin platform. This was the main reason that convinced me to learn more on .NET: open specs, a component-enabling technology, the cross-platform mirage, a completely new (well, sort of) set of concepts to be grasped, and something which I could use both on Linux and on Windows.
Armed with these expectations, I decided to look for a good introductory text on the .NET framework focused on components development. Among the plethora of publications on the subject, I decided to stick with a publisher having a long and respectable tradition in Open Source related books. Among the herd of funny beasts that populate O'Reilly's catalog, I picked out a "land hermit crab," aka Programming .NET Components, by Juval Loewy.
Overview The book begins with a chapter giving a rationale behind component-oriented programming versus object-oriented programming, that is, interfaces versus inheritance. The second chapter shows how those concepts are reflected in the .NET Framework, briefly introducing the Common Language Runtime (CLR), the Intermediate Language (IL) and .NET Assemblies. The following three chapters deal with interface-based programming, objects lifecycle management and versioning, gradually introducing the underlying concepts and showing how they become concrete in the .NET framework (more specifically, by using the C# language). No formal introduction to C# language constructs is given, but if you are familiar with C++ or Java you will be able to follow the code snippets fairly easily.Events and asynchronous code execution are the subjects of Chapters 6 and 7, respectively. While the former is just a quick introduction to the C# approach to delegates and events (yet useful if you are new to the matter), the chapter on asynchronous calls is much more substantial. The mechanics behind async calls are explained, together with pros and cons of using callbacks, BeginInvoke() and EndInvoke() calls, one-way methods, and so on.
Chapter 8 is devoted to Multithreading and Concurrency. Commonplace concepts like threads application and usage are explained, as always dressed with a bit of C# syntax. While such concepts are easily found in any multithreaded programming tutorial on the Internet, explaining them from the basics never hurts -- and prepares the reader to the most insidious traps of multithreaded programming. Synchronization appropriately takes a fair part of Chapter 8: automatic and manual synchronization provided by the .NET runtime environment are explained, together with the concepts of contexts and synchronization domains. This part is quite interesting, since it delves into .NET specific concepts which are quite new to programmers who had a happy Microsoft-less childhood (though they might not be so new to people who speak COM fluently). Other .NET threading related services (such as timers) are presented at the end of the chapter.
Chapter 9, devoted to object serialization and persistence, describes how live objects can be transformed (formatted) into a stream of bytes to be sent over a network channel, or stored on a persistent storage medium. This chapter lays the grounds for the exacting chapter on remoting, which follows immediately. Chapter 10 is the longest and most content-rich chapter of the book: first, the entire story of native processes, .NET app domains and assemblies is told. After reading it here, it won't look so confusing as before. Then, objects marshaling, remote callbacks, synchronization and activation modes are described, including client and server activated, single-call and singleton modes. Afterwards, the author gets to a global overview of the .NET remoting architecture, its basic building blocks (like proxies, transport channels and call dispatchers) and working mechanisms (like type registration and environment configuration). A reprise on objects sponsorship and leasing closes the chapter and completes the discussion on objects' lifecycle left pending in Chapter 4. Chapter 10 offers a lot of interesting cues, but unfortunately cannot dig deeply enough in the subject (after all, this is not a book on remoting). Many people (including Juval himself) recommend Ingo Rammer's Advanced .NET Remoting (APress) to learn more on the topic, but I have yet to get my hands on it.
Chapter 11 reprises the description of contexts in .NET, this time focusing on calls interception. The whole interception architecture is described with a fair level of detail and, as always, in a clear and understandable way. Context-agile and context-bound objects are described, as well as .NET and custom component services. While reading this chapter, you start understanding that contexts, app domains, call interception and remoting are tightly interwoven and that their full understanding is the real key to the exploitation of the .NET platform potential. Unfortunately, this is where the book leaves you alone -- but I strongly suspect that a full coverage of these topics would have required an entire book on its own.
The last chapter of the book deals with the .NET Security architecture, introducing the concepts of permissions, code groups and policies. Security administration is explained, both from a system configuration and a programmatic point of view.
What's to like What I liked most is the straightforward approach of the author in introducing the rationale behind components, components-based programming and their support in the .NET Framework: each concept is walked through step-by-step, instead of being presented in a complete working example with little or no explanation. Hence, you won't get working code on page 3 of the book -- instead, you will gradually learn how to write some.
Indeed, I found the description of awkward concepts like asynchronous calls, multithreading and remoting very clear, even for someone with no previous experience with .NET and C#.
I also consider a plus the broad experience the author has in the field, which shines through the many programming hints given, and in lots of references to concepts in COM which have an homologous in .NET.
I finally found the book to have the right balance between printed code and text (that is: do not fill hundreds of pages with code, I'll look at it online).
What's to consider Programming .NET Components is just an introductory book: it points you in the right direction toward components programming with .NET, but does not bring you very far. If you are really serious about learning .NET advanced topics, you will need a more specific tome to complement (or substitute for) this one.More specifically, the 70 pages which cover remoting are just an introduction to the matter. The same applies to some of the most important concepts revolving around .NET (app domains, contexts, and the like).
Finally, despite the subtitle ("Design and Build Maintainable Systems using Components-Oriented Programming"), be warned that this is not at all a book on software design (components oriented programming is covered in just 15 pages).
The summary Reading the book goes without a glitch, thanks to a smooth writing style and a very structured approach to explaining concepts. Still, when I turned the last page of the book I felt that my understanding of components within the .NET platform was far from complete..NET Components Programming is quite fair to its title: it will teach you how to program components by using .NET constructs, but (apart from some quick notes here and there) it will not provide extensive coverage of components oriented design and development. If you are already familiar with .NET concepts and are looking for something shedding light on components programming, this book will not help you significantly. On the contrary, if you know something about components and want to start developing them into the .NET Framework, this will surely be an interesting read.
Table of Contents
Preface
Chapter 1. Introducing Component-oriented programming
Chapter 2. .NET Component-oriented Programming Essentials
Chapter 3. Interface-based Programming
Chapter 4. Lifecycle Management
Chapter 5. Version Control
Chapter 6. Events
Chapter 7. Asynchronous Calls
Chapter 8. Multithreading and Concurrency Management
Chapter 9. Serialization and Persistence
Chapter 10. Remoting
Chapter 11. Context and Interception
Chapter 12. Security
Appendix A. Interface-based Web-services
Appendix B. Custom Security Principal
Appendix C. Reflection and Attributes
You can purchase Programming .NET Components from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I plead guilty: I have always admired Microsoft's COM architecture and the relative simplicity that allows you to reuse already installed components to create even complex programs.
For your crimes, Slashdot hereby sentences you to a living death. You are ordered to use Windows 95 until the end of your days! May Gates have mercy on your soul.
Dare I say this is the longest /. news item EVER?
This article from earlier today explained it all
The lack of starndardized libraries. KParts, Bonbobo, XParts, DCOP, XUL, OpenOffice are all competing technologies. No one component model for linux. Wan't the KHTML part to display a webpage in your gnumeric spreadshit? No, you can't do it yet.
I just hope the proposed Xembed standard gets implemented soon, or Linux will be screwed on the desktop for a while
Why anyone would say DCOM is more graspable than J2EE is IUnknown
So you admire DCOM and that's why you recomment a book about .NET which brings a new way of doing things to get away from the mess that is DCOM? now it looks a lot more like J2EE...
Go hug some trees.
Thanks to the Binary Decoder:
.NET!
I've been waiting for a good review on
It could have been a *lot* worse. Never click on anything that references 01100111 01101111 01100001 01110100 01110011 01100101 00101110 01100011 01111000 !
Stressed? Me? Of course not. Stress is what a rubber band feels before it breaks, silly.
Finally, someone that at least indirectly acknowledges that Microsoft oriented programming is at least worth reading about. I am like many people who read slashdot in that I think Microsoft doesn't play nice in the industry, but they are, like it or not, the de facto standard out there.
Nuttles
Christian and proud of it
I have always admired Microsoft's COM architecture and the relative simplicity that allows you to reuse already installed components
"Simplicity" is probably the one word you can't use to describe that nightmare called COM. COM makes programmers jump through hoops to achieve what plain vanilla C++ (mostly) already provides. Anyone who has ever tried to do a large project using COM (no, that little DirectX Tetris game doesn't count) can attest to the pain and suffering the architecture inflicts on those unlucky enough to have to use it.
No technology is trying to become Cold Fusion. .Net is trying to become Java, and so is Java, but no one in their right mind wants to aspire to be an evolutionary dead end like CF. Macromedia (who now one CF) are slowly migrating all CF to J2EE and will kill of CF.
this is getting old and so are you
blog
Win ME and 95 are nothing compared to the pile of crap know as Windows 3.1, have you alll forgotten? I therefore Sentence him to life imprisonment in Space Jail with a 20Mhx 386 SX (remember?) running Windows 3.1. How that!?
Heheheh As a computer programmer myself, I tend to like to see everything that exist in the world. I don't care if it's made by the evil monopolistic giant or not.
.NET goes (while we're on the subject), I think it's ... mmm ... nice ... Too big, too bulky, I prefer J2EE to .NET 10 folds. I choke and puke every time I see some small nibblets of C#, that aberration of a language. But it's intersting to know how it works and how to code anyways.
Like the reviews author says, I find COM concepts very easy to grasp and quite interesting. Compared to CORBA, it is indeed very easy to use.
As a hacker (someone who likes to know how it works), I find that very interesting. As someone who code for Mac and Palm, I find I can apply many concepts of COM to my code and make it object-portable.
As far as
By the way, LMAO yes hell is all frozen I think. What the heck, M$ coding book ? EEEK!
Mike
If you plan on buying this book, more reviews of the book can be found here and here and you can buy it new for $24.50 here
bulky? how?
meh.
".Net is trying to become Java, and so is Java.."
Yep, I hear that the next version of Java will be 98% Java. Then they just have to focus on removing that last 2% of Fortran... =)
Java is a language. .NET is not. .NET is a set of technologies.
I know, at first I thought Slashdot had been hacked or defaced!
I have seen this book in the stores and it serves to fill in the little left-over space left behind by all the thicker, more-complete texts.
DO NOT MOD BELOW HERE:
I try and submit articles every now and usually to no avail. How clever to submit a Microsoft article under the guise of "research". Very clever. Like going against the grain coolness. Yes, very clever indeed.
Peace out.
"This isn't a study in computer science, its a study in human behavior"
And I have always been fascinated by the distributed nature of DCOM, which seemed to me much more graspable than complex monsters like CORBA and J2EE.
First of all, J2EE is not the relevant technology. Java RMI is. RMI is massively simpler than DCOM, which, contrary to this author's take, is a nasty mess of C-inspired foolishness. ;-)
In fact, .Net is largely the latest kludge slapped on top of COM/DCOM to try and hide it's hideous complexity. The programming community should wake up and see the obvious fact that Java provides everything that .Net provides, but in a platform neutral and sane manner. It even works great on Windows. (And for those of you that would bring up Mono - we'll discuss that again the day that Microsoft sues for patent infringement under the DMCA.)
Microsoft - Just Say No.
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
where to start? ^_^
I have always admired Microsoft's COM architecture and the relative simplicity...
Are you high? Did you actually use COM or DCOM, or just admire it from afar? I have used COM and barely survived. I have not coded to DCOM, but I had to to install someone else's DCOM programs. That was torture enough.
"No matter where you go, there you are." -- Buckaroo Banzai
Before making any knee-jerk comments regarding the post, take a moment to ponder over these pearls of wisdom from none other than the great Morpheus, which are very relevant in this context. Take heed and realize that the poster is but part of the system. Forgive him.
"Microsoft Windows is a system, Neo. That system is our enemy. But when you're inside, you look around and what do you see? Businessmen, Teachers, Lawyers, Carpenters...the very minds of the people we're trying to save. But until we do, these people are still a part of that system, and that makes them our enemy. You have to understand, most of these people are not ready to be unplugged from Windows. And many of them are so innerred, so hopelessly dependent on the system that they will that they will fight to protect it. Are you listening to me, Neo? Or were you laughing at the stupid MSN fairy again?"
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
> I haven't see a single computer that runs Linux or any other alternative
> at any of my friends house.
I havent seen a single black man at any of my friends house. So they simply do not
exist.
DO NOT PANIC
Microsoft doesn't play nice in the industry, but they are, like it or not, the de facto standard out there.
Microsoft may be the defacto standard for client side apps. But on the server side it holds no such title, and enterprise development is supposed to be what DCOM is all about. Things like J2EE and CORBA have way more of a hold on enterprise development than anything that Microsoft has ever put out. There's a big difference between a single-user desktop operating system and a multi-user scalable enterprise platform. From what I've seen, Microsoft has only been sucessful with the former.
I've read a couple .NET books on threading. How is this book on threading? Does it go into detail about how .NET threading differs from POSIX threading? Techniques for getting around the differences and the performance/scalability implications. .NET is definitely an improvement over the older VB/IIS model, but it still has a long way to go to reach high level scalability.
it was more than 5 years ago, microsoft mentioned that they will port DCOM to unix. This killed of many CORBA projects on windows at many organizations. COM specs are binary specs. I am not sure about DCOM and ActiveX. But microsoft hasn't been able to port to unix even after 5 years. Either they lied or it is extremely difficult. CORBA is the only architecture which is alternative to DCOM. Not sure, how much of its complexity is due to portability.
Obviously you don't use them both.
Macromedia is not going to kill off Coldfusion and replace it with j2EE. CF is built on top of Java and co-exists very well with Java and can even be extended with Java. Other than that they are two completely different types of technology and have two different uses.
Java is for those who still think that Java is the only serious development tool for the net regardless of the long dev cycle and CF is for those who understand that rapid development and ease of maintenance is often key in sucessfull projects.
We were a huge JSP/J2EE/EJB shop and now rarely use it. It's just not necessary... CF is more than capable and just as fast for anything that is not massivly back end heavy.
Karma means nothing to me, so suck it...
Ok lets see we can choose something which works, is industry proven, IS a real standard set forth by a commitee (OMG) or we can have .NET a fake standard certified by ECMA (who got lots of $$$ for calling .NET a standard). .NET lacks a lot of cross platform availablity that CORBA has. Just about anything can use CORBA: C, PHP, PERL, C++, OBJC, JAVA, SMALLTALK, PASCAL, DELPHI, the list goes on. .NET has yet to prove itself, as well most java/.net interaction is done through CORBA.
huh?
have always admired Microsoft's COM architecture and the relative simplicity that allows you to reuse already installed components to create even complex programs. And I have always been fascinated by the distributed nature of DCOM, which seemed to me much more graspable than complex monsters like CORBA and J2EE.
Ha! Be prepared to be modded down like the astroturfing troll you are! Ooops.. too late for that I guess.
Mmmm.. Donuts
Who the fuck mods these things?
Troll me but give a 2 informative to a post that is factually incorrect...
Karma means nothing to me, so suck it...
If you were to program in C using COM and CORBA based purely on their specification, which one would be easy to program? COM spec is from MS and using their tools in C# and C++, you can simplify things, but that doesn't make COM or DCOM simpler.
Understanding the ins and outs of J2EE is not the hard part of enterprise development. Understanding things like async messaging, transactions, and multithreaded logic are what makes enterprise development difficult. Switching to .NET because you don't 'get' J2EE will not magically make you understand these complex ideas.
.NET examples, then fine. But it's not learning the particular technology that's the hard part...it's learning the theory that drives it.
If this book does a better job of explaining those concepts using
Don't trust a book review written by someone who thinks DCOM is more understandable that J2EE. Without MS's wizards that completely hide the complexity, DCOM and COM would be completely unusable. Distributed J2EE objects on the other hand can be written using nothing more than a text editor.
dude- want people to listen? Present an argument rather than an opinion.
> I have always admired Microsoft's COM architecture
> and the relative simplicity that allows you to
> reuse already installed components to create even
> complex programs.
One of the reasons COM is nice is the fact that there are so many components out there. There are frameworks (CORBA), that were much nicer (OpenDoc) but whatever the future brings (.NET) the reality is the platform with the biggest market share (Windows) and the most components will win.
No one in their right mind thinks Java is a language, Java is a computing platform. (a language howevere is a set of technologies typically. Actually almost everything is :)
I appreciate that the metadata is the managed code and the Language neutrality of the project, but I still think questions need to answered about if this is really just a new way to try to kill Java, and how nice it'll play with projects like Mono after it takes off.
CB
free ipod and free gmail!
This is one of the best books I read in a while about .Net To give you some insight download and read
C# Coding Standard by Juval Lowy
Karma stuck at 50? Add 2-5 inches.. err.. 2-5x Karmas Count to your pen1es.. err.. Karma all naturally and private
Could somebody point me out to what's the Jakarta-struts equivalent in the .Net fmwk ---if there is such. Regards.
An irrelevant review about an irrelevant book about an irrelevant technology.
Just how is this long informercial supposed to interest us? Go ahead, mod me down, flame me for my lack of understanding, but I have worked extensively with COM+ over the last years and I regret ever starting with the stuff.
Am I the only one detecting a current of counter-revolution in Slashdot? Negative moderations of eminently reasonable comments by pro-MS and pro-RIAA voices we can't identify?
A small voice says: stick to the point, people, or the point will stick it to you.
Ceci n'est pas une signature
Embedding Amazon affiliate ID's into URL's, and not disclosing their presence, is really sleazy. Any bozo knows you can go to Amazon.com to read reviews of books, so this parent post shouldn't be modded "informative." It's just a scummy way to make a buck from unwitting Slashdot readers.
Maybe thats why corporate application I've worked on the last 4 years has deployed on Solaris or Linux using Java or C++ and Corba....
It maybe the defacto standard for mail servers (exchange) but thats all I've seen it used for.
It's defacto if you want to write video games.
So Long and Thanks for all the Fish.
I have always admired Microsoft's COM architecture
untill you spend a day rebuilding DLLs because one class ID at the bottom of your architechure got f??ked up.......without a makefile!
!(^((ri)|(mp))aa$)
perhaps you are beset buy a sense of permanence, that you need especially good food/clothing etc..
out of desire for the 'wonderous' effects of the present, even though they are of little meaning in the long run (planet/population rescue), you are ready to employ all sorts of shameless exaggerations & devices to get what you think you want. making loans at high interest, looking DOWn on others, starting court proceedings, etc.. all in order to maintain your need for excess/frivolity.
once you give your life over to such trivial pursuit(tm), acquisition/more excess becomes more important than life itself. such superficiality is a fool's errand, & drives you away from things that would really help you/US.
the lives of those so afflicted, remains empty, as the needs of the spirit cannot be acheived buy external means/methods.
as always, lookout bullow.
COM/DCOM are a messy hack on top of C++ virtual tables. They are not a good thing, nor is there anything new in COM/DCOM relative to earlier OO component architectures. They are, in fact, so much not a good thing that Microsoft cloned Java in order to replace COM/DCOM with the C# object model.
J2EE is a mess, but you can't fault the underlying object and component model for that.
You only need to look at the way assemblies (packages) are organized and imported to see this.
I didn't mod you but it probably has something to do with saying that Cold Fusion is as good as a Java- JSP/Servlet for most things
CF is not as robust, not as scalable, you are tied to one vendor for the life of the project. So even when dealing with lightweight projects you're still saddled with CF crap...
(-1, Incorrect)
nuff said.
Bury your head a little deeper why don't you.
This is the reason Linux trails Windows in so many areas. YOU personally are part of the reason.
Look forward, adapt, learn every day... or die a deserved death.
"The lack of starndardized libraries. KParts, Bonbobo, XParts, DCOP, XUL, OpenOffice are all competing technologies. "(1)
I'm happy to report that with Microsoft's domination of the marketplace. There is no other competing technologies available. Next up on the agenda, Apple space.
**Insert obligatory "I welcome our 'old' overlord masters."
(1) Some, but not all. You need a new list.
shouldn't this entire story have been considered flamebait? if you don't agree, read *any* post.
!(^((ri)|(mp))aa$)
I don't really understand your comment.
Look: my company designs transactional web processing applications.
In 1996 we built a portable transaction monitor that is used today in several very large web applications that run on Linux. The entire TP monitor is only several thousand lines of C, the applications are extremely simple, and it all works beautifully.
In 1998 we were asked to make something very similar, but using MTS and COM+. The animal works, but it is incredibly complex, slow, unstable, and frankly impossible to control totally. When we approach the limits of the system in any sense, it collapses, and we cannot do anything to discover why.
It's not about Windows vs. Linux, this is a stupid misdirection on your part. COM is not simple, it is a mass of layers which can be simplified with the appropriate packaging (as can any technology), but which remains complex, slow, and unreliable at the core.
Now explain once again why I personally am part of the reason for what exactly? Or HIBT?
Ceci n'est pas une signature
Woah, you're working for some bass-ackwards companies and we're all supposed to give a shit? Good one, Troll.
Somewhere.
meh.
first there's an article touting the benefits of COM+--i disagree, but it's your opinion--then, when i go to read it, there's a windows server 2003 ad at the top of the screen
!(^((ri)|(mp))aa$)
Cannot self-invoke Godwin's Law. RTFL.
"Understanding the ins and outs of J2EE is not the hard part of enterprise development. Understanding things like async messaging, transactions, and multithreaded logic are what makes enterprise development difficult. Switching to .NET because you don't 'get' J2EE will not magically make you understand these complex ideas."
So a couple questions then:
1-In this day and age of mobility, is it wise for a programmer to get into "enterprise programming"?
2-Is it as complicated as it appears to get into "enterprise programming"?
3-What is the recommended path for getting into "enterprise programming"?
4-What tools are needed (hardware and software) to get into "enterprise programming"? Or is the barriers anything like getting into Mainframes? e.g. Availability, economic.
5-What good references are there?
6-How much of a role does OSS play?
7-How much wood could a woodchuck, chuck, if a woodchuck could chuck wood?
Troll.
Everyone loves Microsoft products? I've heard a lot of people swearing at their (often blue) Microsoft screens. I know a lot of office workers who have never used a non- microsoft OS who find Windows frustrating and mysterious to work with.
I don't think most of these people would do any better with a unix system, but to say 'everyone loves Microsoft products' is definitely bull.
Years of experience? Do you know how long Unix has been around in its various forms? This is the real experience Linux draws upon.
I think most people doubt that Linux would be 'brought down' by the SCO case. Even if they by some feat of bribery (or stupidity on the part of the US legal system) won their case, I don't think the rest of the world would go along. And there is a rest of the world.
I know, I know, don't feed the trolls, but sometimes ya just gotta.
No these were all Fortune 500 companies actually making money AND profits.....
The smallest had a gross revenue of 3 Billion ( thats of course gross, not profit).
So Long and Thanks for all the Fish.
If you program for a Mac, how can you "miss" dynamic typing, events, serialization, RPC and more built in directly into C or C++ rather than a separate hack that requires bulky, unreadable code?
Think of it, you can also build GNU ObjC for Linux, Cygwin/MinGW or (with some heroic efforts, no doubt) prc-tools for Palm. Why borrow the concepts if you can have a better-designed real thing across the board?
Books like the one described in this posting are just another attempt to let people think that networking is not an application. The whole problem with stuff like, J2EE, Corba and .NET is the fact that frameworks/platforms/or-whatever-you-call-it try to masquerade existing functionality and bring it to a higher level; in this case an Object Oriented approach. Object Orientation is invented to support more 'real-life' thinking, while designing and writing software. One can say that an Object Oriented program is more like reality.
Al the frameworks mentioned above try to encapsulate the 'distributedness' of software and offer an Object Oriented shell around the real communication (which is still TCP ;)). This means that the fact that software has something to do with networking is irrelevant while designing software with this stuff. On the other hand: the fact that software is distributed has large impact on the design. There is no single point of communication (a socket?) anymore, but the communication is done by the framework.
In my opinion datacommunication needs to be implemented as part of an application instead of an aspect.
:wq!
.NET roxers. I'm using it right now. It's elite, trust me. And I'm a GNU hippie who hates Microsoft. So it must be *THAT* good.
I don't completely hate microsoft.
I'm really really sory! I am ashamed to admit this even to myself! Please don't hate me!
Here is an article about one of their products. I think this product has merit, and would like to discuss my thoughts on the matter.
Please forgive me! I'm a bad person! I don't deserve nice things! I am filled with shame! Of course there are many superior open source alternatives!
In all matters of opinion, our adversaries are insane. -Oscar Wilde
I didn't mod you but it probably has something to do with saying that Cold Fusion is as good as a Java- JSP/Servlet for most things
CF is not as robust, not as scalable, you are tied to one vendor for the life of the project. So even when dealing with lightweight projects you're still saddled with CF crap...
The latest versions of ColdFusion are Java. ColdFusion is compiled into Java Servlets before it is run, so it should be just as fast and scalable as anything else written in Java.
You are right. I've seen the same at companies I worked for. New 'technology' is injected into an organization by the speed of light and more and more projects are failing. I've seen over 10 projects where things were just broken because of bloated 'technology'....I think you recognize this sentence: 'We have some performance problems...can you fix them?'. In my case it was EJB....over 2 years or so, it will be .NET triggering need for help like this ;)
:wq!
> so it should be just as fast and scalable as
> anything else written in Java.
Yikes!
but the book review is about .NET which you claimed is "An irrelevant review about an irrelevant book about an irrelevant technology."
.NET is not COM
What are you blathering on about COM for? Yeah COM sucks.. Get over it.
Ah, of course .NET is internally _totally_ different from COM, has no similarities at all, and my comments about the headaches of COM simply don't apply to .NET.
.NET was simply one more layer around the old COM code, thus actually adding more to the problem than it took away. Silly, silly me!
Thank you for that clarification. I stupidly assumed that
Ceci n'est pas une signature
I do. Java is simply a language - nothing else. JVM is a virtual machine. JINI is a technology that uses Java as its base language and runs on a JVM. .NET is an umbrella term that covers many different tech from M$. .NET can be utilized from many different languages (C#, C++, C, VB, whatever)
In the beginning, UNIX was ahead. It had multiple processes, pipes, and signals. This looked like reasonable interprogram communication back in the late 1970s, but it's too low-level; trying to do anything that way is painful.
The problem is that what you want is a subroutine call, but what the OS usually gives you is an I/O operation. Some OSs do have good interprocess message passing as standard - QNX, Mach, L4/Hurd, and AmigaOS have it. The others need some kind of middleware to build message passing on top of I/O operations.
In the Microsoft world, that middleware is always there, and you can assume its presence. In the Unix/Linux world, you can't. That's why few open source programs are built that way.
Worse, the message-passing middleware for Unix and Linux carries excess baggage. CORBA for Linux is big, heavy, and available from at least five different sources in incompatible forms. The GNOME people finally had to implement their own CORBA, but it's still at the beta level. GNOME wants it mostly as an internal interface for GNOME components, so they're not too concerned with external compatibility.
OpenOffice uses an incompatible system called UNO. There's an effort to build a CORBA-UNO translating gateway, but the systems have conceptual differences and don't play well together. And, of course, all this translation drives overhead up.
Related to this problem is inadequate language support for inter-object communication. Newer languages like Java and C# have some built-in support for serialization, marshalling, and introspection, but C and C++ do not. So the operation that really has to be efficient - turning a local object into a string of bytes - tends to be slow.
Because this is more of a standards problem than a technology problem, it's tough to fix in the open source environment.
Sound like you need to expand your circle of friends!
Where's your proof?
Right here.
Yup. In the newest version cf is compiled directly into servlets.
The JSP/Java crowd thinks the only way to go is Java. Nothing is faster! Nothing is more scalable. Buzzword bingo.. I used to be part of that JSP crowd..
The right tool for the job. That's the key. I wish I had discovered CF earlier than I did.
Since most sites are dynamic and database driven, here's an example.
JSP
-------
<%@ page import="java.sql.*, javax.sql.DataSource, javax.naming.InitialContext" %>
<h1>DATABASE ENTRIES</h1>
<%
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource) ctx.lookup("jdbc/TestDS");
Connection conn = ds.getConnection();
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT name FROM staff");
while ( rs.next() ) {
out.println( rs.getString("name") + "<br>");
}
conn.close();
%>
COLDFUSION
-- --------
<html>
<h1>DATABASE ENTRIES</h1>
<cfquery name="getstaff" datasource="staff">
SELECT name FROM staff
</cfquery>
<cfoutput query="getstaff">
#name#<br>
</cfoutput>
</html>
Clearl y you can see how EASY to debug and understand the JSP code is... This is just one example. I can remember while discovering CF saying over and over. "This CAN'T be right. This would take me 10 times more code in JSP to accomplish the same thing!"
If you have access to both environments running on the same box, do the tests... For many things JSP/Java is no faster than the latest CF and just as portable as JSP.<br><bR>
Karma means nothing to me, so suck it...
If everybody in my city were friends with a black guy that would mean that the average black guy had about 7,000 friends.
Conserve Oil, Recycle, Boycott Walmart
How's that Python.NET working out?
You are the one making the assertion that they are the defacto standard, the burden of proof is on you. Douche-bag.
I'm going to guess you were being sarcastic. For your information, .NET is not "simply one more layer" around the old COM code. It is internally, completely and totally different and unrelated to COM. It is a complete departure from it. Period. If you don't understand that, you don't know enough about COM or .NET to be speaking on the subject.
Forget the whales - save the babies.
I hate to bite, but here goes....
Lets have a little look at the latest monthly web server survey from netcraft. Now, I will quote:
[...]Microsoft's share is 23.75% according to the survey. Face it, the majority of sites out there use Apache, almost certainly running on some form of UNIX. Even if some of the sites are of the odd variety that use it on Windows, you must realize they aren't using an MS standard.
Further, you can probably extrapolate the type of software running on companies' internal networks from their external networks. Quite frankly, the enterprise world is not Microsoft, and it never has been.
I am glad this was clarified for you. It is a common misconception by the clueless that .NET is simply a COM wrapper, which it is not.
if so then please include one
Then you don't understand JAVA.
.NET, JAVA is a language and a framework ... which is why people comment so often about .NET's similarity to it. .NET has a couple of advantages over JAVA - precompilers and JIT via the CLR, and it's essentially a lot cleaner code/class wise than J2EE for example ... but it's not cross platform, at this stage it's not as scalable, and it misses out on some critical classes that are useful in an enterprise context.
Like
While at times Slashdot can be rather hostile towards
No, no, no!
Slashdot is Fair And Balanced.
"Provided by the management for your protection."
Oops... I hate to make this a double-reply but I just had to :)
Hmmm.... they seem to be included in the netcraft.com survey, and yet Apache still handily beats MS. Oh, I see, right... quantitative information is much more useful than qualitative information.
The largest consumer-oriented supplier. Do you think a company is going to buy big iron from Dell? Does Dell even sell it? No. The world is not Dell and Microsoft, they are barely even in the markets we are talking about.
when it's not crashing
Eeek! Maybe actually trying to understand Wines implementation of DCOM has fried my mind, but COM/DCOM cannot possibly ever be called conceptually easy. Oh sure, the IUnknown/ClassFactory stuff, while a pain in the ass, is easy enough to understand.
Now start trying to implement late binding on your object so it's usable from JavaScript. You do that by implementing IDispatch right? Wrong. IDispatch is such a horribly complex interface that MSDN recommends you don't try and implement it, because you'll get it wrong - and they're right, you will. Instead, you should use the provided typelib invokers. Now you have to describe your object using a typelib. There are two different typelib file formats, and they can be standalone or embedded in DLLs.
Of course, IDispatch binds on an interface, but you have to be careful - due to obscure implementation details, you can't have more than one of them. Therefore, you have to choose a primary interface to be your dispinterface.
Careful! You initialized OLE Automation (a part of DCOM) but forgot to process the message loop, didn't you? Now everything is locking up, right? You just have to know that inter-thread RPC in DCOM takes place via window messages, so bash that loop boy. Just be aware that the DCOM runtime runs its own message loop for re-entrancy reasons, so you could find your WndProc running while another part of the code is supposedly blocking on a remote interface call.
Confused yet?
it's called "FUD"
This is the worst jsp code you could possibly write. Why not use one of the free taglibs.
If you're an Open Source developer who's the least bit suspicious that Microsoft has anything to do with the latest IP attacks against Linux, I can't imagine why you would touch .NET with a ten foot pole. You're just begging to have all your hard work stolen in court.
Attack my grammer, what a tool....
....) BUT the point is STILL, that Windows IS NOT a defacto standard, especally when you are talking Industrial Strength Infrastructure. In fact in that environment variants of Unix are just as prevelant as variants windows (2000, XP, NT ......). Probably more so.
For the mentally challanged I'll Restate:
Yes my experince has been *nix (solaris, Linux, HP UX
Also Given the size of these corporate networks, they dwarf smaller networks. Granted smaller networks tend to be MS. Also the size of the machines as well, Yes a Sun box with 150 CPUs is one server, but how many dual xeons would need to replace it? (75???)
Thats all I was saying.
So Long and Thanks for all the Fish.
Why is that insightful? Is it because of the naive, misinformed and derogitoRy description of dotnet? or because he picks nits over the various java technologies? Maybe its because he disagree's with someone else's opinion? I don't know!
Well.. maybe. Or Maybe not. But Definitely not sort of.
I came to computers as a physicist. They filled rooms and were tended to by swarms of real scientists and engineers, not "technicians".
They were built by scientists and engineers for scientists and engineers.
The languages developed to program them, and the logical grammer developed within these languages, were those in common use by scientists and engineers, which is to say mathmatical syntax, grammer and logic. That's why they're called computers and not emailers or blogers.
This lead to the rise of "functional" programing through the natural course of things as computers became advanced enough to ignore the physical architecture when programing them. The Function is the natural "object" of the mathmatical language. You can do anything on a computer with the purely functional approach and, what may be hard for the modern trained mind to grasp, the mathmatically trained mind can often do so faster and easier this way than with any of the more recent "developments" in programing.
This is not to say that other ways of looking at things doesn't have its, ummm, functionality. The Object Oriented approach was developed by engineers ( who didn't have very mathmatical minds and didn't particularly understand computers or programing) to conceptualize and solve certain engineering problems dealing with real objects. Beams, pistons and the like. It made a lot of sense to model these objects as objects. What may not be obvious the Object Oriented programer is that these objects are still mathmatical models, in fact just a class (sorry) of function whose variables are handled in a predefined sort of way making the function into a kind of virtual Mechano set.
The way these varibles are handled from and programer point of view ( once the object itself is written) constitutes a user interface to the object.
What Microsoft is doing at the logical and matmatical scale isn't really any different, they're just using a slightly different terminolgy and logic to accomplish largely the same end, but one they are able to "brand" and control, not to mention leverage for their own dominence.
The main difference is that their interface is more ridigly controled by them, being sold by an "ease of use" argument of many small componants which are really just objects with a restricted interface, replacing understanding of what you are doing mathmatically and logically with a kind of tinkertoy set of objects. Just plug 'em together and watch 'em work.
I don't wish to ruffle any feathers, but I'm not particularly afraid of doing so.
This is an approach that may be valid for the modern crop of "programer", but if you wish to honestly be considered a computer engineer, let alone a computer "scientist", it is a largely unworkable solution, just as a person adept at using tinkertoys and mechano sets isn't qualfied to be called an engineer.
This isn't to belittle tinkertoys and mechano sets either. They have their valid place and uses.
Personally I've been "Object Oriented" programing since before there was any such thing. It's an obvious format for modeling real objects in a compact, understandable, easily modified and reusable way, although I didn't call my "beam object" a beam object. I called it my beam function, because that's what it is, even though it may well contain subfuntions while at the same time being a subfunction of the "building function."
I've always tended to think of my programing models in terms of ICs. Note that there are two basic kinds of ICs. Those that are hard wired to perform a single task, such as the venerable 555 chip, and those that are designed with a changable internal logic (you're using at least one of these right now to read this post) such as the Z80.
Both of these kinds of ICs have their valid uses. The programable chip hasn't replaced the hard wired chip, it has augmented the toolset available. Both kinds of mathmatical logic these chips represent are valuable to the programer in t
Thats the first time I saw those two words connected together, com is a lousy hack on the C++ VTABLEs for plugging an interface mechanism into C++ to the worse they than did the hard work to bend this full thing over into C and you have a real mess on your hands.
Com is by far the worst component model out there, compared to the simplicity of java beans (which avoids interfaces for reflection) the usage of interfaces in the language level and the simplicity of pure OO component models like KParts (you mentioned you haven't found anything on KDE)
you basically can say Com is the worst of it all.
DCom basically was a technology to take over Corba after Microsoft was sitting for years in the Corba consortium to get a grasp on the technology, it failed because as usual Microsoft tied DCOM to windows and therefore was no real competition to a cross platform solution.
Very funny. And how hard is it to change the X-Powered-By HTTP Header so you don't get attacked by the script kiddies?
I got in a hurry, my orginal post should have stated that the applications (multiple) ver the last 4 years, not just one.
So Long and Thanks for all the Fish.
I typically don't bother posting... but I hope you feel like an idiot, and rethink your attitude.
Ok... in taglib form. For the db connection I actually like the first one better for simple query.
r l>
n ection conn="conn"/>
<%@ taglib uri="http://jakarta.apache.org/taglibs/dbtags" prefix="sql" %>
<sql:connection id="conn">
<sql:url>jdbc:mysql://127.0.0.1/stafffolks</sql:u
<sql:driver>org.gjt.mm.mysql.Driver</sql:driver>
</sql:connection>
<sql:statement id="stmt1" conn="conn">
<sql:query>
select name from staff
</sql:query>
<%-- loop through the rows of your query --%>
<sql:resultSet id="rset2">
<sql:getColumn position="1"/><br>
</sql:resultSet>
</sql:statement>
<sql:closeCon
Actually results in more code. I prefer less code for very simple things and sometimes more readable.
Karma means nothing to me, so suck it...
You know, every once in a while someone makes a really stupid comparison between the people who were responsible for the murder of millions of human beings, and something incredibly trivial like using the "wrong" type of software. And it really pisses me off.
Yes, I have a sense of humor. No, this isn't funny.
01001101011011110110010000100000011100000110000101 11001001100101011011100111010000100000011101010111 000000100001001000010000110100001010
Minor correction: I work for a web hosting company (mid-sized) and we have been regularly leasing/purchasing 1U units from Dell. 1U's are certainly unlikely consumer machines. Then again, we also purchase/lease machines without Windows OSes. So, I guess this goes against both your post and its argumentative parent post.
Boys from the City. Not yet caught by the Whirlwind of Progress. Feed soda pop to the thirsty pigs.
In fact COM/DCOM always seemed to be the poor man's version of CORBA (COM can be seen as equivalent to in-process activations of CORBA servers). Writing CORBA services using emacs on an out-dated Sun box in the graduate computer lab seemed a great deal easier than the gymnastics we had to go through with DCOM. (Including setting up our own development PDC, much to the chagrin of the network admins).
Leave the gun, take the cannoli -- Clemenza, The Godfather
In 1998 we were asked to make something very similar, but using MTS and COM+. The animal works, but it is incredibly complex, slow, unstable, and frankly impossible to control totally. When we approach the limits of the system in any sense, it collapses, and we cannot do anything to discover why.
I know jack shit about .NET and would never consider using it, but I have seen exactly the same experience with J2EE. Relatively simple applications, which solely produce web pages from the data in a single underlying RDBMS, and could be easily (and appropriately) built just using servlets, are turned into stinking, creaking and groaning and sluggish monsters by introducing EJB servers in the middle.
Anything that introduces more threads and more machines is going to have a wicked effect on your performance and productivity. Its not unique to .NET.
That said, if there has to be a big crusty layer in the middle, I'd rather it was built by someone else than the Borg - in the scale of their commercial interests, your application's scalability and reliability come very low indeed.
[x] auto-moderate all posts by this user as insightful
01110100011010000110100101110011001000000110100101 11001100100000011000110110111101101111011011000010 000100100001
So prove it douche-bag. ... you just can't handle it.
A little militant, aren't we? Ranting and making personal attacks don't make a point.
Wanna know how I know? There are WAY more small to medium sized businesses than there are large corporations. They don't even look at Open Sores shit.
And this means - nothing. You have no way to prove that small and medium customers don't look at or use OSS. I know multiple small and medium sized companies (500-1500) that use Java / J2EE for server-side work, soemtimes running WebSphere and a couple are using Tomcat. That's OSS in case you didn't know.
Dell, the largest computer supplier in the world sells more Windows servers every day than they do OS-less or Linux servers.
Until recently an OS-less computer cost the same as one with Windows, more if you had Linux pre-installed. Now that isn't the case, I think we'll see some more realistic results. Further, as someone who actually works with vendors (for some reason I don't think your company, if you have a job, likes you "talking" to people), I'm hearing that they're seeing more and more Linux pre-installs or no-OS even more often. This includes mainly Dell and IBM for us. Heck, one of HPs big offerings is their Linux/Oracle RAC (and more recently including Itanium2) offering! That was 6 months ago when I saw that demo (minus the Itanium 2).
What else do you need? IBM isn't jumping on .NET, they're pushing Java/J2EE and OSS. BEA is still doing very well (J2EE). How about the popularity of Tomcat? JBoss? Oracle also has their 9i App Server - J2EE.
Computer Science is Applied Philosophy
Posts like this one ask for a new moderation option:
-1, Anti-MS-Zealot (who's not afraid to make himself look incredibly stupid by using moronic comparisons)
"Slashdot - the one place on the internet where guys brag about how small it is." - that IT girl
Who's their hosting provider again? What's that company? What was that story?
Oh yeah, I remember now
Computer Science is Applied Philosophy
Please explain the progress made in .NET, and how it is a step up from VB. Thanks.
Uh, Dell is #1 in servers, includng #1 in 2-way and 4-way boxes. Hardly desktop stuff.
Troll article maybe?
No, you've got it all wrong. You're clearly a complete newbie to
In Soviet Russia, you don't stick to the point, the point sticks to you!
This is supposed to be funny for some reason.
Problem is that there is no distinction between Java the language and what would be called the Java standards libraries (if it weren't mixed up in the language). The spec also defines things like object formats and linking systems and so on and so forth. Thanks to the well specified system the Java runtime and platform can be used from a quite huge number of languages of course (I agree that it isnt as well tuned for this as the .NET runtime, but it is mostly a design question rather than an overall design issue).
They could be the de-facto standard for server-side programming, web servers, and application servers, but they're not. The only reason they're not is because they're not giving away those products. A Personal Web Server is fine and dandy, but it does you no good if you can't serve pages to other people. That's why, when I started server-side programming, I immediately installed Apache and I used an Access data source with it. Apache works flawlessly, it's easy to use, and it's free. What more can you really ask for?
.Net the evil hands of M$ is buggy like VB. .Net code and M$ will blame you for it just like they did with VB
You will try to fix it forever but the day will never come to an end. Bugs will come like worms from your
Lets assume for a second that you are correct, MS has a majority and thousands (millions?) of servers are using forged HTTP headers. Since the current difference in market percent is 40%, approximately 20% of the servers on the internet would have to be using forged headers. Indeed, for every non-forged MS server there would basically be another forged MS server.
How about instead, let's apply Occam's razor, shall we?
Please check out this white paper, DCOM and CORBA Side by Side, Step by Step, and Layer by Layer and see if you can pick out which is the simpler, faster, and more reliable technology. Thanks.
Errmmm.... ya. My bad :).
In any case, the main point is Microsoft isn't the server marketplace powerhouse some people would like to have you believe :).
Gee lets all badmouth .net again. slashdor is starting to look like a very predictable bunch to me.
If we had that, some Slashbots would be joining the trolls and crapflooders posting at -1 in no time at all. It'd greatly improve the S/N around here...too bad it doesn't have a snowball's chance in hell of getting implemented.
20 January 2017: the End of an Error.
Reasons why using the netcraft survey to determine "server marketshare" doesn't work: ... there are BILLIONS of servers out there)
* there are more than just webservers out there
* it doesn't count any servers sitting behind the "site"
* unknown if they filter by domain or ip (if by domain, a single "server" may be counted multiple times)
* not all servers are available via the web
* it makes no distinction between a "real" server and the P90 sitting next to my desk in my apartment
* you can NOT extrapolate what is running in a companies internal network based on what they run their webserver off of
* survey only counts sites netcraft surveys (they surveyed 42m websites
Nobody can make any assumptions about what kind of marketshare MS does or does not have, especially from a netcraft survey. I don't think anybody can say they're hurting in the enterprise area though (points finger at billion dollar wads of cash).
I have this book, and have been using C# professionally for about a year. "Programming .Net Components" really made a difference to how I understand .Net, and allowed me to see beyond the familiar curly brackets to why and how components can best be developed and run together.
.Net project should have this book (or at least its level of understanding) in order to get more of those key design decisions right first time.
In my opinion at least one developer on any enterprise-level
I don't like Microsoft, neither the company nor their technology, but i think Microsoft is the only company that got UI components working.
.NET world?
I think COM/DCOM is crap, but what's about OLE, the "visual" side of embedding applications and documents?
Is there an equivalent for OLE in the
By the way who care of dotNet.
I mean, if i need some speedy portable stuff i got Perl and PHP !
If i need some scaleable and portable stuff (any enterprise business behind) i got Java. Already running on most platform, supported, opensourced solutions (yes !).
About the dotNet since years i heard "yeah we gonna build a tux port of it !" this is bullsh*t ! Of course building a labs kidding that is able to run the core spec is not realy a problem but be able to bring a true real cross-platform compatibility without any support from MS is stupid. MS has 100% of control of all the dotNet spec, do you think they will push any non MS OS as a viable alternative ?
Are you kidding ?
IMHO those people are loosing times. Better advocate to FSF so that RMS and others C guru puts time and FSF bucks to the Classpath project so that they briought us a real up to date GPLed version of Java ! Since two years there are no more legal reason why not having this. cf. Apache that is already running lots of Java related opensourced projects and has just launched a full J2EE server new project.
Anyway... vive Tux !
Seriously big up to this guy endorsing microsoft on /. that takes balls.
'And it burned burned burned, the ring of fire, the ring of fire' - Johnny Cash
-- Karma Karma Karma Karma, Karma Chameleon - Boy George
The link given has a hidden iframe at the bottom that links to an ASP that links to a perl file and uses an IE security hole to execute a HTA that writes an UPX-packed executable (called malwareHHMM.exe, where HHMM is the current time of day) to the hard disk and runs it. My analysis capabilities end there.
(the iframe at the bottom is indented using 32 tabs, so either turn on word-wrap or scroll right on the last line, if you want to see it.)
01010100011010000110010101110010011001010010000001 10000101110010011001010010000000110001001100000010 00000111000001100101011011110111000001101100011001 01001000000111011101101000011011110010000001110101 01101110011001000110010101110010011100110111010001 10000101101110011001000010000001100010011010010110 11100110000101110010011110010010111000100000001000 00010101000110100001101111011100110110010100100000 01110100011010000110000101110100001000000110010001 10111100101100001000000110000101101110011001000010 00000111010001101000011011110111001101100101001000 00011101110110100001101111001000000110010001101111 011011100111010000101110
"Common sense is nothing more than a deposit of prejudices laid down in the mind before you reach 18" Einstein
Primitives: Java is a language. Java is a framework. Compare the following compound statements. Java is a language or Java is a framework. Java is a language or Java is not a framework. Java is not a language or Java is a framework. Java is not a language or Java is a framework. Java is not a language or Java is not a framework. I was going somewhere with this, but now I've lost it. It appears very cut and dried to me, though. The only one that is not logically true is the last one. Something to think about while you uselessly debate such an issue. Whatever works is fine. Use the tools that your Master provides you to get the job done. If you like using Open Source tools to do what you do, then seek work which uses that. If you want to learn .NET, then learn it. If you want to learn Java, learn it.
-->--
"But do not program in COBOL if it can be avoided."
"That man lives best who's fain to live half mad, half sane." -Flemish Poet Jan Van Stijevoort, 1524.
Well, to take my comment literaly, everyone in your town would only need to have a friend who has a friend that is black. That would mean the average black guy would only have to have around 500 friends. So there :P