And I shudder at the realization that this person has students.
Anyone who takes the time to become informed and check facts can clearly tell that many improvements arose from the security initiatives. Patching is far easier and less expensive, the new architecture of IIS is very secure, the new development platform,.Net, is sand-boxed and includes declarative security, and all you need do is go to CERT to see that the number of Windows vulnerabilities is lower than that of *nix.
If I were grading this diatribe disguised as an article I'd give it an F based on the discussion of buffer overflow exploits alone.
He fails not only in his technical analysis, but in the basic tenants of journalism as well.
In short, Mr. Penenberg, what you've just said is one of the most insanely idiotic things I have ever heard. At no point in your rambling, incoherent response were you even close to anything that could be considered a rational thought. Everyone in this room is now dumber for having listened to it. I award you no points, and may God have mercy on your soul.
I have the black one. They also have some nice sound dampening options. It costs about half as much as the one shown in the article and it looks great.
http://www.coolermaster.com/index.php?LT=&Langua ge _s=&url_place=product_list&p_class=290
Whenever I'm sick I ask my electrician what I should do. My Doctor has been studying the human body for years and is just too biased for my comfort.
With regards to The Register article, the gist of what he is saying is that Winodws is more insecure than Linux because it takes a lot more effort to run a program on Linux than Windows and that social engineering is the easiest Windows hack.
The only people who think it's a great thing that Linux is hard to use are the same kind of nutjobs that toss around words like 'mono-culture' and 'pigopoly'. So he says:
Instead of just reading an email (... just reading an email?!?), a Linux user would have to read the email, save the attachment, give the attachment executable permissions, and then run the executable. Even as less sophisticated users begin to migrate to Linux, they may not understand exactly why they can't just execute attachments, but they will still have to go through the steps.
and
There is one Linux distribution that is ignoring many years of common sense, good design, and an awareness of secure operating environments in favor of a Microsoft-like deprecation of security before the nebulous term "ease of use": Lindows.
If that is the position of the Linux community in general, then here is a quote from me:
Good Luck!
His second argument about the engineering of Windows, its browser, and email are exactly what SP2 addresses as far as I know, but I'll still be using Firefox. Why? Because they understand the "nebulous term", ease of use.
You have four kids and at least 6 years of experience? If so, I must say that your's is the most shockingly stupid post I've read in many days.
Firstly, I can only conclude that you aren't studying or keeping up on current events because your second paragraph is extremely uninformed. It's the knid of statement people were making 2 1/2 years ago when 1.0 shipped.
Secondly, if you aren't going to move to.Net you should be moving to Unix/Linux. Both of these platforms have something VS6.0 on Win32 has not got: a future. If you are the primary bread-winner in your home, please do not be so foolish as to jeopardize your family's future well being.
I've been in the industry for a long time and I've seen many sea changes. The biggest difference this time is that the economy is soft and the market is hyper-competetive. Now, I'm not saying that if you get canned you'll never work again, but I am saying the pain you feel when you find yourself between gigs and you come to realize that your skills are too dated to get a new job making anywhere close to what you had before is pretty serious.
It's a mistake I've made, in my case it was not jumping on Windows and getting some good referenceable experience before Windows 95 came out and made my ass obsolete over night. It's a mistake I've seen others make. The industry is moving on (hell HAS moved on). If you don't move with it, you will pay a price.
So sure,.NET may trounce Java if you want to make a Recipe-Card manager for Grandma - but if you have any heavy lifing infolved, forget it.
Heavy lifting eh? You might want to take a quick little trip over to the Transaction Processing Performance Council. Take a look around! Windows and.Net are kicking in the other vendors' teeth in both clustered and unclustered modes in terms of performance and cost/transaction.
Now if I could just get someone to give me a Superdome to play with....
This very useful program is a code analysis tool that checks your.NET assemblies for conformance to the.NET Framework Design Guidelines . It uses reflection, MSIL parsing, and callgraph analysis to inspect your assemblies for more than 200 defects in the following areas: naming conventions, library design, localization, security, and performance (see rule descriptions). The package includes both GUI and command line versions of the tool, as well as the SDK to create your own rules.
There is not a global market for labor except for a few specific cases, like H1-B, where government action has created artificial influences that expand the reach of the natural market.
If the market were truly global, the whole concept of trade-deficits and balance of payment theory would become irrelevant. The reality of the "global market" is that it is only a collection of smaller markets with trade moving between them. Sometimes freely and sometimes not depending on where you are. Certainly a famine victim in Sub-Saharan Africa is not influenced in his decision making by the abundant supply of Wonder-Bread in Toledo Ohio!
H1-B subsidises the local employer and the foreign worker at the expense of the local worker and in interference of the micro-economic supply and demand.
"Worry about the impact of the 10:1 ratio of new engineering graduates in China and America first. Think about the impact of that on US engineering jobs in a free market for goods."
This feeds my argument. Why are there so many engineering graduates in India and China? If it were not a well known fact that these professions enabled one of the easiest ways to emmigrate to a country with more freedom and oportunity, would this ratio change?
I rather suspect that it would.
Aside from that, do you not agree that the current policy is likely accelerating the movement of certain service jobs overseas as former H1-B holders return home with a network of connections and up-to-date knowledge of particular American markets?
I am frankly amazed by the astounding ignorance of those who claim decreasing H1-B's is anti-free market, communist, or xenophobic.
According to the American Heritage Dictionary, a subsidy is "assistance granted by a government to a person or group in support of an enterprise regarded as being in the public interest." In this case supposed public interest is benefiting businesses by manipulating the supply of a scarce commodity in a given market, in this case, labor.
In a free-market scenario, scarcity has the effect of increasing price. Increasing price has the effect of attracting more supply to address demand, which lowers price, until equilibrium of some sort is reached.
The US government is interfering with the natural free-market process that, theoretically, would have the long-term effect of increasing the native supply.
In return for that, wages are artificially low for native workers. Non-native individuals and companies who are given special rights not normally available in the free-market receive training and create business networks that enable them to compete with native supply by ultimately providing competitive services in their own countries at much lower prices.
The last time I checked, successful competitors do not and are not obligated to assist the competition in any way. I have no problem with people born in other countries once they become citizens of my country, but until they do, they play for another team.
This author is dead on. The IT graveyard of invincible vendors is wide and deep, and without an exception I can think of the killing blows were always self-inflicted: Micro-Channel Architecture, Word Perfect 5.0 for Windows, Unix-Ware, and on and on and on.
I watch this board closely to try to gauge perception. (I watch lots of other things too, because everything has some inherent bias, borg toon anyone?) I want to know where the industry is headed. In the past I've felt the pain of backing the wrong technology and after many years have come to appreciate such an error's effect on my families ability to do things they enjoy, like eat and sleep inside.
For the last several years the food on my table has come from a deep knowledge of many of Microsoft's products. At the end of the day, I really don't care what tools I used to create a new system. What I care about is that I can do what I love (design and build software) for someone who appreciates the effort enough to pay me a decent sum of money.
I view many of the arguments on this site with mild amusement (open vs. closed source) as the ravings of modern-day hippies or the very young. Unfortunately, I am constrained by certain requirements in my life and I doubt very much that my wife or my children would care about free-as-in-speech vs. free-as-in-beer, and as such care much more about the bottom-line than high-minded principals, no matter how appealing.
That said, I am starting to study and use Linux and other offerings of this community. Some of it is very impressive and some of it, I must say, is promising but primitive crap. I do not believe that the movement will overthrow Microsoft on its own merit. I do believe that Microsoft is creating enough incentive for the market to make this a commercially viable alternative.
The PS2's were awesome and reliable machines. They were probably worth the additional price. But, by the time IBM really tried to strong-arm the market, the IT buying community was pissed off enough that the platform's relative merits meant nothing. I believe that OS/2 was equally affected by this, although it's terrible setup procedure hurt it as well. Microsoft is today's IBM. I hope they get their heads out of their asses soon, but they'd better do it quickly.
It looks like I'll just be one of those wierd old guys that still listens to music on vinyl. I also enjoy books.
I bet my kids will hate me for it.
On the other hand, now might be a good time to learn how to fix the current generation of 'disposable' kit and start hoarding parts. It might eventually become a nice little niche market.
I'll try to hit the high points I've found without mentioning any of the stuff you're likely to have heard of in the marketing materials.
There are two fundamental differences between.Net and COM that I think are pretty compelling.
1.) COM is interface oriented and.Net is object oriented. True, you can do COM with OO languages like C+, but at the COM layer you're still fairly restricted in terms of what you can easily pass between processes. IDL is not very friendly when it comes to complex data types and creating interfaces that require the marshalling of them has some nasty side effects in terms of dependencies between components, not to mention the need for custom marshallers.
As a result, most distributed app's based on COM usually work by passing simple data between tiers instead of passing objects. Each tier winds up implementing code that consumes that data into a redundant object model.
In contrast,.Net objects are fairly easy to manipulate between tiers. There are three basic serialization technologies in the framework, (XML, Binary, and SOAP) as well as support for a variety of protocols (remoting channels include SOAP, HTTP, and TCP) and rolling your own is not that hard to do.
Admittedly, the client and server bits still need to understand the type definitions, but passing an object around that encapsulates data and enforces business rules is very straightforward. With.Net you can be OO and avoid the expense of chatty interfaces that cross physical and process boundaries.
For example, I just did an app that sends and receives objects that are serialized and deserialized to and from XML between a Windows Service and a mainframe using MQ-Series.
2.).Net assemblies, by default, are local to the project path instead of being global to the machine and do not depend on the registry. In terms of time savers, this one is huge (no more DLL hell!) and it makes both versioning and deployment a lot easier.
Because of this, you can run two versions of the same application side-by-side, you can deploy an application with XCopy or from a web server (with the right security policy you can place a WinForm app on a web server and.Net will download it to a cache and execute it just like it was insatlled on the machine), and because.Net supports code signing, you can (if you want) ensure that referencing bits will only load specific versions (and protect yourself from Trojans).
Finally, these are complimentary technologies. If the application is truly distributed between diverse environments, there is no reason not to mix-and-match RPC models. However at the boundaries,.Net really shines. And if it is a 100%.Net implementation, you're left wondering how you ever put up with the headaches inherent in COM in the first place!
I live in Georgia so I wrote to Senators Zell Miller, Max Cleland and my local Rep. Johnny Isakson (all of you should do the same IMHO). I got replies from Cleland and Isakson. Here they are....
Dear *****:
Thank you for contacting me regarding S.2048, the Consumer Broadband and Digital Television Promotion Act, being introduced by Senators Hollings and Stevens.
I certainly understand your concerns regarding copyright issues. The U. S. has traditionally been a strong supporter of copyright holders. As you know, the development and expansion of the Internet has created questions in some people's minds as to how to deal with copyright issues of all kinds. I believe that we can find a way to balance appropriately electronic commerce with copyright protection issues. Currently, the measure has been referred to the Senate Commerce Committee, of which I am a member. Please be assured that I will keep your concerns in mind when the Senate considers this bill.
Again, I appreciate your taking the time to contact me. It was good to hear from you. Most respectfully, Max Cleland United States Senator _________________________________________ __
Dear Mr. ******:
Thank you for contacting my office regarding technology mandates. I appreciate your thoughts on this issue.
I do not support legislation of this type for the following reasons: The Digital Millennium Copyright Act of 1998 (DMCA) gave copyright owners the tools to stop purveyors of "piracy tools" that circumvent copyright protection technology, but it explicitly declined to specify which technologies should be used, clarifying instead that there can be no mandate for manufacturers to respond to particular technologies. Draft legislation supported by some companies would repudiate the DMCA's carefully struck balance by requiring the Commerce Department to "certify" specific copy protection technologies and outlawing all interactive digital devices (computers, digital TVs, cell phones, etc.) that do not include the certified technologies. The flaws in the discussion draft of the bill indicate the difficulties in government technology mandates for copyright protection: * Retards innovation by freezing today's technology in place. By picking specific technologies to mandate in every device, federal mandates virtually guarantee the inclusion of outdated technology in future digital technology products.
* Government picks winners and losers. Even if the entertainment and technology industries agreed on a common approach, the government would still be picking specific copyright protection products to be included in every computer, cell phone, personal video recorder or other electronic device.
* Multiple mandates mean extreme performance degradation. Scanning every datastream for numerous certified "digital watermarks" would significantly slow down computers, even where no protected content is involved. Audio/video capabilities would be unworkable on cell phones, PDAs and other portable devices.
* Government (and lobbyists) as gatekeeper over new technologies. New products that didn't work with the certified copyright protection technologies would be unlawful until the government approved new copy protection. Approval would have to be gained over the lobbying of companies, NGOs or any others who wanted to stall the new technology.
* Consumer backlash. Unworkable copyright mandates would cause new IT and consumer electronics products to fail in the market and cause consumers to blame technology companies and policymakers.
* Reduced global competitiveness. IT and electronics products produced for the US market with lower performance, higher prices and burdensome restrictions would be noncompetitive in international markets where such mandates did not apply.
* Unintended consequences. Mandates would potentially impact digital products whose uses are unrelated to the entertainment industry, such as measuring and testing equipment that incidentally fall under the Act, thereby needlessly increasing the cost to the consumer.
Please feel free to visit my website at www.house.gov/isakson for more information on issues that may be of importance to you, as well as to sign up for my monthly email update. Thank you again for contacting me, and I hope you will not hesitate to call on me in the future if I can be of assistance to you. Sincerely, Johnny Isakson Member of Congress
Well, I said it is more flexible, not that it is miraculous. It just provides a nice layer of abstraction in a way similar to, but different from, a data dictionary in an RDBMS. Here are a couple of practical things you can do with it...
1. Provide location transparency. A wsdl file contains an address for the endpoint. You can leave the location of the description in one spot and move the endpoint any time you want in a way that is transparent to the clients of the service.
2. A clean means of extension through ports. A wsdl file describes the methods available and their locations. Ports give you a clean way of managing name conflicts between names in different endpoints. This is nice if you want to add a new object to your service with what would otherwise be a conflicting name in a way that doesn't disturb existing clients. (and without having to create a new web-site).
3. A way to conform to a standard API that allows different levels of support. Imagine an insurance API that supports the full range of insurance-type activities. You want to implement it, but you only support 80% of it. Clients can use the service and understand that you only support 80% by reading the description instead of by trying unsuccessfully to call the other 20%.
Hardly ever post here, but I know a thing or two about SOAP and thought you nice folks might find it informative.
I've done three implementations for three different clients in the last two years. The first integrated an existing UNIX front-end with an existing NT back-end (I know... the real world sure is strange), the second enabled a COM+ app server to talk asynchronously to Apache on a Linux, and the third was a port of a windows forms app that used DCOM to SOAP for use in a VPN.
I have to say that I am mostly pleased with SOAP, but that it does have areas that need improving.
Reading this board, I've noted a couple of misconceptions that seem pretty prevalent.
1. SOAP is not Simple. Several posters noted that the spec is over 100 pages long. Most of the specification is about the correct formatting of the description language on the server side. Fortunately, both Microsoft and IBM toolkits provide tools for generating this stuff and the tools cover 99.9% of what you will ever want to do. As a developer you can use SOAP without ever authoring a wsdl file. Reading the file is not very hard, I was able to write my first working SOAP client implementation within a week of starting. All you need is a good understanding of the HTTP protocol, XML, and your client platform.
2. SOAP is bloated. Many people (including me) think this when they first see an example of a web service description language (wsdl) file. The key thing to note is that a decently designed client only needs to read it once (using http GET) to understand the service. The actual requests (using http PUT) and responses don't have too much adornment and are pretty darn simple. The server will use the wsdl to validate incoming requests and if it has a decent design, it too only read it once on the service startup.
3. XML-RPC is better because it is simpler. XML-RPC is actually very, very similar to the rpc aspect of SOAP. But going back to 1. above the spec is so short because XML-RPC lacks an equivalent to wsdl (a runtime readable description of the service). In other words, XML-RPC requires you to understand the interface at design time. Because of this an XML-RPC solution is more tightly coupled and less flexible than an equivalent SOAP implementation. (This might be acceptable depending on the requirements).
4. Running over port 80 is bad. In fact, it can be. However SOAP requests are generally speaking, HTTP POST, so this has less to do with the standard than the reliability and security of the listener. A good listener will act as an application proxy and reject any shenanigans. A good network design that includes a DMZ with another firewall between the private network and the server is also required for it to be secure. Message level security can use SSL or an alternative.
5. It isn't standard between vendors. Some validity to this, but I found the differences between M$ and IBM to be very minor and easy to accommodate.
There are some problems with running over HTTP though. 1. It is never as fast as native rpc solutions in my experience. You can cut down on the size of the response by using gzip or deflate with http 1.1, but there is no facility for compression on the inbound side. The need to minimize round trips is directly at odds with this lack of functionality because:
2. It is stateless so things like transactions are very difficult to do and cause the requests to contain enough info for the server to do something ACID... These accentuates problem number 1.
3. You can't do call backs or event from the server to the client. This is strictly a 'you request and I respond' protocol. You can't push from the server to the client with SOAP.
Slashdot Mirror
And I shudder at the realization that this person has students.
.Net, is sand-boxed and includes declarative security, and all you need do is go to CERT to see that the number of Windows vulnerabilities is lower than that of *nix.
Anyone who takes the time to become informed and check facts can clearly tell that many improvements arose from the security initiatives. Patching is far easier and less expensive, the new architecture of IIS is very secure, the new development platform,
If I were grading this diatribe disguised as an article I'd give it an F based on the discussion of buffer overflow exploits alone.
He fails not only in his technical analysis, but in the basic tenants of journalism as well.
In short, Mr. Penenberg, what you've just said is one of the most insanely idiotic things I have ever heard. At no point in your rambling, incoherent response were you even close to anything that could be considered a rational thought. Everyone in this room is now dumber for having listened to it. I award you no points, and may God have mercy on your soul.
I have the black one. They also have some nice sound dampening options. It costs about half as much as the one shown in the article and it looks great.
a ge _s=&url_place=product_list&p_class=290
http://www.coolermaster.com/index.php?LT=&Langu
With regards to The Register article, the gist of what he is saying is that Winodws is more insecure than Linux because it takes a lot more effort to run a program on Linux than Windows and that social engineering is the easiest Windows hack.
The only people who think it's a great thing that Linux is hard to use are the same kind of nutjobs that toss around words like 'mono-culture' and 'pigopoly'. So he says:
and
If that is the position of the Linux community in general, then here is a quote from me:
His second argument about the engineering of Windows, its browser, and email are exactly what SP2 addresses as far as I know, but I'll still be using Firefox. Why? Because they understand the "nebulous term", ease of use.
You have four kids and at least 6 years of experience? If so, I must say that your's is the most shockingly stupid post I've read in many days.
.Net you should be moving to Unix/Linux. Both of these platforms have something VS6.0 on Win32 has not got: a future. If you are the primary bread-winner in your home, please do not be so foolish as to jeopardize your family's future well being.
Firstly, I can only conclude that you aren't studying or keeping up on current events because your second paragraph is extremely uninformed. It's the knid of statement people were making 2 1/2 years ago when 1.0 shipped.
Secondly, if you aren't going to move to
I've been in the industry for a long time and I've seen many sea changes. The biggest difference this time is that the economy is soft and the market is hyper-competetive. Now, I'm not saying that if you get canned you'll never work again, but I am saying the pain you feel when you find yourself between gigs and you come to realize that your skills are too dated to get a new job making anywhere close to what you had before is pretty serious.
It's a mistake I've made, in my case it was not jumping on Windows and getting some good referenceable experience before Windows 95 came out and made my ass obsolete over night. It's a mistake I've seen others make. The industry is moving on (hell HAS moved on). If you don't move with it, you will pay a price.
If you want to go completely free and use a nice IDE, try #develop. It isn't as nice as VS, but it is astoundingly nice for a free (as in speech) IDE.
I live in Atlanta and I'm actively involved in the hiring process where I work. That number is utter bullshit.
Heavy lifting eh? You might want to take a quick little trip over to the Transaction Processing Performance Council. Take a look around! Windows and .Net are kicking in the other vendors' teeth in both clustered and unclustered modes in terms of performance and cost/transaction.
Now if I could just get someone to give me a Superdome to play with....
http://www.gotdotnet.com/team/libraries/
.NET assemblies for conformance to the .NET Framework Design Guidelines . It uses reflection, MSIL parsing, and callgraph analysis to inspect your assemblies for more than 200 defects in the following areas: naming conventions, library design, localization, security, and performance (see rule descriptions). The package includes both GUI and command line versions of the tool, as well as the SDK to create your own rules.
This very useful program is a code analysis tool that checks your
So, it is more resistant to minor damage. But if it's a film applied to the whole part, what happens if you do damage it?
The nice thing about paint is that you can patch a small area. This sounds like you'd have to replace the entire damaged part.
If so, it has the potential to slightly decrease the original price and really increase the maintenance and repair costs.
I'm not sure that constitutes an improvement.
They have One head,
They have Two eyes,
And Three uhmm...
I got nothin'
There is not a global market for labor except for a few specific cases, like H1-B, where government action has created artificial influences that expand the reach of the natural market.
If the market were truly global, the whole concept of trade-deficits and balance of payment theory would become irrelevant. The reality of the "global market" is that it is only a collection of smaller markets with trade moving between them. Sometimes freely and sometimes not depending on where you are. Certainly a famine victim in Sub-Saharan Africa is not influenced in his decision making by the abundant supply of Wonder-Bread in Toledo Ohio!
H1-B subsidises the local employer and the foreign worker at the expense of the local worker and in interference of the micro-economic supply and demand.
"Worry about the impact of the 10:1 ratio of new engineering graduates in China and America first. Think about the impact of that on US engineering jobs in a free market for goods."
This feeds my argument. Why are there so many engineering graduates in India and China? If it were not a well known fact that these professions enabled one of the easiest ways to emmigrate to a country with more freedom and oportunity, would this ratio change?
I rather suspect that it would.
Aside from that, do you not agree that the current policy is likely accelerating the movement of certain service jobs overseas as former H1-B holders return home with a network of connections and up-to-date knowledge of particular American markets?
I am frankly amazed by the astounding ignorance of those who claim decreasing H1-B's is anti-free market, communist, or xenophobic.
According to the American Heritage Dictionary, a subsidy is "assistance granted by a government to a person or group in support of an enterprise regarded as being in the public interest." In this case supposed public interest is benefiting businesses by manipulating the supply of a scarce commodity in a given market, in this case, labor.
In a free-market scenario, scarcity has the effect of increasing price. Increasing price has the effect of attracting more supply to address demand, which lowers price, until equilibrium of some sort is reached.
The US government is interfering with the natural free-market process that, theoretically, would have the long-term effect of increasing the native supply.
In return for that, wages are artificially low for native workers. Non-native individuals and companies who are given special rights not normally available in the free-market receive training and create business networks that enable them to compete with native supply by ultimately providing competitive services in their own countries at much lower prices.
The last time I checked, successful competitors do not and are not obligated to assist the competition in any way. I have no problem with people born in other countries once they become citizens of my country, but until they do, they play for another team.
This author is dead on. The IT graveyard of invincible vendors is wide and deep, and without an exception I can think of the killing blows were always self-inflicted: Micro-Channel Architecture, Word Perfect 5.0 for Windows, Unix-Ware, and on and on and on.
I watch this board closely to try to gauge perception. (I watch lots of other things too, because everything has some inherent bias, borg toon anyone?) I want to know where the industry is headed. In the past I've felt the pain of backing the wrong technology and after many years have come to appreciate such an error's effect on my families ability to do things they enjoy, like eat and sleep inside.
For the last several years the food on my table has come from a deep knowledge of many of Microsoft's products. At the end of the day, I really don't care what tools I used to create a new system. What I care about is that I can do what I love (design and build software) for someone who appreciates the effort enough to pay me a decent sum of money.
I view many of the arguments on this site with mild amusement (open vs. closed source) as the ravings of modern-day hippies or the very young. Unfortunately, I am constrained by certain requirements in my life and I doubt very much that my wife or my children would care about free-as-in-speech vs. free-as-in-beer, and as such care much more about the bottom-line than high-minded principals, no matter how appealing.
That said, I am starting to study and use Linux and other offerings of this community. Some of it is very impressive and some of it, I must say, is promising but primitive crap. I do not believe that the movement will overthrow Microsoft on its own merit. I do believe that Microsoft is creating enough incentive for the market to make this a commercially viable alternative.
The PS2's were awesome and reliable machines. They were probably worth the additional price. But, by the time IBM really tried to strong-arm the market, the IT buying community was pissed off enough that the platform's relative merits meant nothing. I believe that OS/2 was equally affected by this, although it's terrible setup procedure hurt it as well. Microsoft is today's IBM. I hope they get their heads out of their asses soon, but they'd better do it quickly.
It looks like I'll just be one of those wierd old guys that still listens to music on vinyl. I also enjoy books.
I bet my kids will hate me for it.
On the other hand, now might be a good time to learn how to fix the current generation of 'disposable' kit and start hoarding parts. It might eventually become a nice little niche market.
I'll try to hit the high points I've found without mentioning any of the stuff you're likely to have heard of in the marketing materials.
.Net and COM that I think are pretty compelling.
.Net is object oriented. True, you can do COM with OO languages like C+, but at the COM layer you're still fairly restricted in terms of what you can easily pass between processes. IDL is not very friendly when it comes to complex data types and creating interfaces that require the marshalling of them has some nasty side effects in terms of dependencies between components, not to mention the need for custom marshallers.
.Net objects are fairly easy to manipulate between tiers. There are three basic serialization technologies in the framework, (XML, Binary, and SOAP) as well as support for a variety of protocols (remoting channels include SOAP, HTTP, and TCP) and rolling your own is not that hard to do.
.Net you can be OO and avoid the expense of chatty interfaces that cross physical and process boundaries.
.Net assemblies, by default, are local to the project path instead of being global to the machine and do not depend on the registry. In terms of time savers, this one is huge (no more DLL hell!) and it makes both versioning and deployment a lot easier.
.Net will download it to a cache and execute it just like it was insatlled on the machine), and because .Net supports code signing, you can (if you want) ensure that referencing bits will only load specific versions (and protect yourself from Trojans).
.Net really shines. And if it is a 100% .Net implementation, you're left wondering how you ever put up with the headaches inherent in COM in the first place!
There are two fundamental differences between
1.) COM is interface oriented and
As a result, most distributed app's based on COM usually work by passing simple data between tiers instead of passing objects. Each tier winds up implementing code that consumes that data into a redundant object model.
In contrast,
Admittedly, the client and server bits still need to understand the type definitions, but passing an object around that encapsulates data and enforces business rules is very straightforward. With
For example, I just did an app that sends and receives objects that are serialized and deserialized to and from XML between a Windows Service and a mainframe using MQ-Series.
2.)
Because of this, you can run two versions of the same application side-by-side, you can deploy an application with XCopy or from a web server (with the right security policy you can place a WinForm app on a web server and
Finally, these are complimentary technologies. If the application is truly distributed between diverse environments, there is no reason not to mix-and-match RPC models. However at the boundaries,
I live in Georgia so I wrote to Senators Zell Miller, Max Cleland and my local Rep. Johnny Isakson (all of you should do the same IMHO). I got replies from Cleland and Isakson. Here they are....
_ __
Dear *****:
Thank you for contacting me regarding S.2048, the Consumer Broadband and Digital Television Promotion Act, being introduced by Senators Hollings and Stevens.
I certainly understand your concerns regarding copyright issues. The U. S.
has traditionally been a strong supporter of copyright holders. As you know, the development and expansion of the Internet has created questions in some people's minds as to how to deal with copyright issues of all kinds. I believe that we can find a way to balance appropriately electronic commerce with copyright
protection issues. Currently, the measure has been referred to the Senate Commerce Committee, of which I am a member. Please be assured that I
will keep your concerns in mind when the Senate considers this bill.
Again, I appreciate your taking the time to contact me. It was good to hear from you.
Most respectfully,
Max Cleland
United States Senator
________________________________________
Dear Mr. ******:
Thank you for contacting my office regarding technology mandates. I appreciate your thoughts on this issue.
I do not support legislation of this type for the following reasons:
The Digital Millennium Copyright Act of 1998 (DMCA) gave copyright owners the tools to stop purveyors of "piracy tools" that circumvent copyright protection technology, but it explicitly declined to specify which technologies should be used, clarifying instead that there can be no mandate for manufacturers to respond to particular technologies.
Draft legislation supported by some companies would repudiate the DMCA's carefully struck balance by requiring the Commerce Department to
"certify" specific copy protection technologies and outlawing all interactive digital devices (computers, digital TVs, cell phones, etc.) that do not include the certified technologies. The flaws in the discussion draft of the bill indicate the difficulties in government technology mandates for copyright protection:
* Retards innovation by freezing today's technology in place. By picking specific technologies to mandate in every device, federal mandates virtually guarantee the inclusion of outdated technology in future digital technology products.
* Government picks winners and losers. Even if the entertainment and technology industries agreed on a common approach, the government would
still be picking specific copyright protection products to be included in every computer, cell phone, personal video recorder or other electronic
device.
* Multiple mandates mean extreme performance degradation. Scanning every datastream for numerous certified "digital watermarks" would
significantly slow down computers, even where no protected content is involved. Audio/video capabilities would be unworkable on cell phones, PDAs and other portable devices.
* Government (and lobbyists) as gatekeeper over new technologies. New products that didn't work with the certified copyright protection technologies would be unlawful until the government approved new copy protection. Approval would have to be gained over the lobbying of
companies, NGOs or any others who wanted to stall the new technology.
* Consumer backlash. Unworkable copyright mandates would cause new IT and consumer electronics products to fail in the market and cause consumers to blame technology companies and policymakers.
* Reduced global competitiveness. IT and electronics products produced for the US market with lower performance, higher prices and burdensome restrictions would be noncompetitive in international markets where such mandates did not apply.
* Unintended consequences. Mandates would potentially impact digital products whose uses are unrelated to the entertainment industry, such
as measuring and testing equipment that incidentally fall under the Act, thereby needlessly increasing the cost to the consumer.
Please feel free to visit my website at www.house.gov/isakson for more
information on issues that may be of importance to you, as well as to sign up for my monthly email update. Thank you again for contacting me, and I hope you will not hesitate to call on me in the future if I can be of assistance to you.
Sincerely,
Johnny Isakson
Member of Congress
Well, I said it is more flexible, not that it is miraculous. It just provides a nice layer of abstraction in a way similar to, but different from, a data dictionary in an RDBMS. Here are a couple of practical things you can do with it...
1. Provide location transparency. A wsdl file contains an address for the endpoint. You can leave the location of the description in one spot and move the endpoint any time you want in a way that is transparent to the clients of the service.
2. A clean means of extension through ports. A wsdl file describes the methods available and their locations. Ports give you a clean way of managing name conflicts between names in different endpoints. This is nice if you want to add a new object to your service with what would otherwise be a conflicting name in a way that doesn't disturb existing clients. (and without having to create a new web-site).
3. A way to conform to a standard API that allows different levels of support. Imagine an insurance API that supports the full range of insurance-type activities. You want to implement it, but you only support 80% of it. Clients can use the service and understand that you only support 80% by reading the description instead of by trying unsuccessfully to call the other 20%.
Hardly ever post here, but I know a thing or two about SOAP and thought you nice folks might find it informative.
I've done three implementations for three different clients in the last two years. The first integrated an existing UNIX front-end with an existing NT back-end (I know... the real world sure is strange), the second enabled a COM+ app server to talk asynchronously to Apache on a Linux, and the third was a port of a windows forms app that used DCOM to SOAP for use in a VPN.
I have to say that I am mostly pleased with SOAP, but that it does have areas that need improving.
Reading this board, I've noted a couple of misconceptions that seem pretty prevalent.
1. SOAP is not Simple. Several posters noted that the spec is over 100 pages long. Most of the specification is about the correct formatting of the description language on the server side. Fortunately, both Microsoft and IBM toolkits provide tools for generating this stuff and the tools cover 99.9% of what you will ever want to do. As a developer you can use SOAP without ever authoring a wsdl file. Reading the file is not very hard, I was able to write my first working SOAP client implementation within a week of starting. All you need is a good understanding of the HTTP protocol, XML, and your client platform.
2. SOAP is bloated. Many people (including me) think this when they first see an example of a web service description language (wsdl) file. The key thing to note is that a decently designed client only needs to read it once (using http GET) to understand the service. The actual requests (using http PUT) and responses don't have too much adornment and are pretty darn simple. The server will use the wsdl to validate incoming requests and if it has a decent design, it too only read it once on the service startup.
3. XML-RPC is better because it is simpler. XML-RPC is actually very, very similar to the rpc aspect of SOAP. But going back to 1. above the spec is so short because XML-RPC lacks an equivalent to wsdl (a runtime readable description of the service). In other words, XML-RPC requires you to understand the interface at design time. Because of this an XML-RPC solution is more tightly coupled and less flexible than an equivalent SOAP implementation. (This might be acceptable depending on the requirements).
4. Running over port 80 is bad. In fact, it can be. However SOAP requests are generally speaking, HTTP POST, so this has less to do with the standard than the reliability and security of the listener. A good listener will act as an application proxy and reject any shenanigans. A good network design that includes a DMZ with another firewall between the private network and the server is also required for it to be secure. Message level security can use SSL or an alternative.
5. It isn't standard between vendors. Some validity to this, but I found the differences between M$ and IBM to be very minor and easy to accommodate.
There are some problems with running over HTTP though.
1. It is never as fast as native rpc solutions in my experience. You can cut down on the size of the response by using gzip or deflate with http 1.1, but there is no facility for compression on the inbound side. The need to minimize round trips is directly at odds with this lack of functionality because:
2. It is stateless so things like transactions are very difficult to do and cause the requests to contain enough info for the server to do something ACID... These accentuates problem number 1.
3. You can't do call backs or event from the server to the client. This is strictly a 'you request and I respond' protocol. You can't push from the server to the client with SOAP.
Hope you found this informative.