However, the manufacturers have been shipping multiple processors for a long time now, and they can work quite nicely -- suprisingly enough even together with older languages.
absolutely true! but trying to port an application from VMS to AIX isn't quite that easy right:) There's always room for improvement and standardization of how certain classes of common problems are handled in software and hardware.
Both platforms are owned by their creators (Java/Sun,.NET/MS)
You're absolutely right. Both platforms are owned by its creator. neither is perfect or horribly broken. On the other hand, there are major differences in each companies approach. Sun has been accused of moving too slow and MS has been accused of moving too fast. both keep repeating the same mistakes, not because of the programmers. It's because of the business guys, who can't make up their minds.
.NET definitely has an edge in client apps for windows, but not in the server world. People should just open their eyes and see the answer to all this is to have real public standards and encourage all companies to use public standards. this way, you can write a client in C# for windows and your server app in C++/Java/C. This way the chances of things integrating nicely is higher than if either company makes all the decisions. When ever one company makes all the decisions, they tend to do what they want and not what users want. the wisdom that having one company control everything insures everything works correctly isn't true in practice.
take AWT for example. when it first came out, it was slow, but now it's much faster and works well. Not blazing or faster than C++. on the.NET side, take IIS for example. IIS is a nice webserver that allows you to build dynamic pages easily, but it scales very poorly for heavy weight web apps. If you need to do anything complex or make sync database calls, it becomes a huge pain to scale. In the past, I was given the task of building a real-time monitoring tool for IIS and it was a total pain. building the equivalent real-time monitor tool in a java container like JBoss is several orders of magnitude easier. I know, the comparison is unfair (apples to oranges), but that's the thing. Stupid CTO's and execs say "IIS only" without understanding the full depth of the problem. Or an exec will say "all EJB" for a simple dynamic website.
the true evil is business people not listening and despising the IT department. Rather than see the IT staff as equals and a vital part of the company, many execs think of it as "IT is something I have to put up with." Programmers typically aren't great at soft skills, so guys in marketing are seen as more important because they can smooze. In reality, they are all equal parts and have to cooperate with each other.
<rant/>
I don't doubt the reasons for the switch back were for good, but since when has high performance multi-processor applications been easy to build? Performing sync across processors isn't something to do lightly and really should be written to meet the specific needs of the project. In this regard, I would doubt that C# can do any better, since it is built on COM+ components. If anything, MS has considerably less experience building high performance applications for multi-processor systems. Most of the Unix vendors have 5-20 years more experience with multi-processor hardware that is specifically designed for enterprise apps.
Researchers argue over the best way to tackle these problems and there doesn't seem to be a clear set of rules about how these kinds of systems should be built and maintained. It's going to take another 20-30 years before the industry as a whole (programmers, manufacturers, software companies) gets a solid grasp of building high performance parallel and distributed applications. that's not to say we don't know how, but that it is still very complicated and requires a ton of expertise. I'm no expert on multi-processor applications and hardware, but performing a sync on symmetric multi-processor hardware vs AIX is totally different. High end unix boxes use switch fabric architecture to share physical memory, where as the typical multi-cpu PC uses shared bus and must take turns accessing the memory.
Let's face the facts, C++ is more mature and has had the benefit of years of hardcore development. Java is still a young language and C# is still an infant. Each language has it's strengths and weaknesses. More things change, more they stay the same. Programmers should just realize the constant cycle of new languages is all a marketing ploy and isn't really about making software development easier or more stable. If anything, it makes it less stable because it forces people to learn whole new sets of problems and repeat the same mistakes in a different language. Using the right tool to solve the right problem should be the goal of projects, but trying to convince execs is nearly impossible
I think that Web Services are a great way to do transaction-oriented tasks. I think that it just needs a little bit more maturity before we can actually use this before its full potential. You know what it needs? It needs one person to step up and be loud and say, "We are doing it this way. This is how we are serializing all of our data types." I think it's just going to take someone to be loud.
I've been doing some hardcore webservices work lately and here's my.5 cents on this. There are some good things about web services in theory, but in practice the current implementations for WSDL, Schema and O/R mapping in.NET is majorly crippled. Before people start saying "what a load of crap" consider this. SOAP is a simple transport that doesn't understand the concept of transaction, which is fine, since it that wasn't the original goal. But that means deserializing and serializing complex objects has to be done with some other tools. The recommended method from Microsoft is to use Schema.
Schema has several major weaknesses, the primary one is it lacks the ability to inherit external types. Schema does support includes, but when the XML is converted/compiled to an object it essentially becomes flat. I'll clarify this a bit for those who haven't used schema. When schema is loaded to generate classes, the validation checks to make sure references to simple and complex types are valid. But to do so, it loads all the includes and builds one complete file. For applications that require modularity and custom extensions, schema simply doesn't work unless you build your own schema driver. What does this mean for an application?
Say you are using SOAP + Schema to build a messaging system and you want to dynamically update the messages incrementally because the messaging platform has to support tens of thousands of messages per hour. If you don't implement some kind of event mechanism within the generated objects, it would require you to transfer the entrie message, which consumes I/O and cpu time when it parses the XML. Take this use case. Say you have multiple messaging servers that can communicate on a peer-to-peer or master-slave basis. Now add several thousand clients that must recieve those messages and decide intelligently how to handle the message updates. An easy approach would be to have each of the objects register for a particular topic in the messaging server (assuming it's pub/sub). If you use the default schema driver, the classes do not extend any class or inherit any predefine logic. If you want all messaging objects to extend a base class which provides messaging subscription and intelligent updates, you have to write your own schema driver. Take another example. The default mode of building schema descriptions from a database is to open a connection to SQL Server, select the tables and VS.NET generates flattened schema models. On the surface that seems fine, if the data you want is flat. If the data you want is relational and has to preserve the structure or map to an object structure, you have to provide your own mapping implementation.
Do these kinds of problems exist in the java world? The answer is mostly no. For O/R mapping there's castor, jdo and numerous other mature drivers. Compiling schema to extend base classes, Castor provides the ability. Not only that, the Java solutions provide a more mature and flexible method of doing these types of operations. If you don't believe, try it yourself.
After reading the article, I would agree. But at the same time, I wish the article had more details, like what does it take to get time in their lab? How much time can a big customer get in the lab. It would be more honest if Microsoft posted positive and negative testimonials from customers who used the lab.
I also don't buy people's excuse about "testing 50million lines of code is nearly impossible." Obviously it's not impossible. Otherwise IBM, HP, SAP, Oracle and Sun would have the same scalability issues that Windows 2K and 2K3 have with high availability. I'm not trolling, just go read the MSDN site for windows 2K and 2K3 and it states clearly it is more scalable than previous windows servers, but it is not "High availability".
All this tells me is corporate america loves disposable society where everything moves towards use once and throw away. There is no way in hell I'm going to fork out 2 or 5 dollars for once of these lame DVD's. Hell, i will gladly pay 25 to order DVD's from Canada, UK or any other country that treats consumers like human beings. Disney can take their straight to video crap and blow it out their rear. Disney hasn't made anything good in the last 8 years and never will until the idiot CEO is kicked out of office. Eisner has done everything in his power to ruin the company walt built. for those who don't remember, disney was created so that both parents and kids could find entertainment. He made the point of making his movies intelligent and thoughtful. Not moron, thoughtless pieces of snot.
Talk about FUD and PR juggling. SCO needs to go bankrupt now, or prove beyond a doubt in their court filing with exact details, so everyone can see. Enough of this smoke and mirrors.
What a bunch of BS. the fact is, the current conditions are the result of both democratic and republican politicians. It's neither one or the other, but both. There are just as many left/dem pork barrel handouts as right/repub. Go look at the library of congress and get real. The only way this is going to change isn't through one party. It will require everyone in every party to tell politicians no more of their special interest BS.
this would be more funny if I never have to read another class that has everything in one method. it's still funny, except when I remember the times I've had to fix other people's code.
was decent, but I would hardley call it mind blowing. It definitely did a better of using philosophy than other films, but it doesn't come close to reading the I-ching or the birth of trajedy.
There's nothing wrong with Pop philosophy, but people need read the original works. Hopefully, the movie inspired some people to go read the original text and really get a mind altering experience.
How about Oracle they too were going to do the same thing. Still waiting
I believe this statement is mis-informed. In fact most of the response is mis-informed from an enterprise application perspective. I'm not talking about office productivity here. Back end enterprise applications that run 24/hrs a day with less than 2-4 hours down time a year. When java first came out, Oracle promised tight integration. They never said they would write Oracle with java. The first release of oracle 8i did have java tightly integrated. In fact, java runs at the same level as sql. Not only that, Oracle provided java triggers, so that triggers could be written in sql or java. The benefit of that is you can then hook traditional triggers to Java, which can then send messages to a messaging system like IBM messaging server.
Does MS SQL server have that kind of integration with.NET and C#? Right now, the only thing SQL Server 2K has is SQL SERVER notification, which uses COM+. I don't know if SQL SERVER 64bit is any different, but I doubt it. I could be wrong.
Actually since dot net supports 26 languages and counting it would be only proper to included them all in the tally. You see if you do Java that's all you do.
The whole argument about multi-language support doesn't hold water. There are certain classes of applications which are not well suited AIDA, COBAL or Foxpro. Not because the language is bad, but because it would require too much effort to hack a system to use 8 different languages. If you've ever tried to do cross language development, you'll know that having a way to use a library written in another language is just the tip of the ice berg. I'm not suggesting a person should avoid C# or.NET. On the contrary, if you can use an existing library written with foxpro, go ahead. But if the application has out grown foxpro, then you're better off using stock ADO.net with SQL Server. Or better yet, use something that meets the same functional requirements. Again, when you're talking about enterprise applications, most of the heavy stuff comes with mature Java support natively. The same isn't true of.NET right now. It will mature obviously over the next 10 yrs. Using libraries written in other languages isn't as simple as "recompile with.NET". Say for example you're using an existing C module that forks a new process, instead of threads. How much work is required to rework that piece? Again, not a simple task.
From what I've seen first hand. Being able to hook into a component written in another language is just the beginning. In many cases, you're better off wrapping those pieces, or rewriting it. Nothing is ever as simple as marketing slogans. There are entire class of applications that really should sit on the mainframe using the original COBOL code base. The argument of multi-language support is a moot point and doesn't accurately describe the complexity of integrating legacy code written in other languages. No one in their right mind would recompile a COBOL application for.NET. Writing a webservice for it and then hooking it to other.NET webservices makes sense. I don't know if a COBOL.NET compiler really exists or not, but recompiling a COBOL backend app to.NET is a dangerous and stupid idea.
I say it's time the people put forth a bill for all elections state and national to require full disclosure of all contributions. The current system allows for too much sneaky back room deals. This way everyone can see exactly which politicians are being bought out by which companies. That's the only real way people can make well informed decisions. Not, vote for the person with the best ad campaigns on TV.
Re:JDO vs EJB Entity Beans?
on
Java Data Objects
·
· Score: 2, Interesting
I'm no expert on JDO, but I feel EJB's have gotten a really bad PR from mis-use. I've slammed EJB's myself when lead architects think using EJB's is a good idea when the app doesn't require transactional support. The thing is, JDO and EJB can work together, though not necessarily. If you have a multi-query/transaction process, JDO will provide some level of benefit, but it won't allow you to handle the transactional aspects. Again, most people don't have these kinds of requirements, but say you have to access 4 different databases. Each database has a slightly different data model. For a transaction to be valid, all the databases must be updated.
Now with EJB's you can manage this using a standard framework and container. If you had to do this with JDO, you would need to either use it with EJB or write your own. The thing is, many architects don't understand when to use EJB's. Lead architects with the skills and technical chops know when to use EJB's. I've seen EJB's used well and use poorly. Those who use it well are programmers who understand EJB's at all levels, not just a high level over-view of what EJB's could do. One of the most common mis-uses of EJB is for simple non-transactional cache. Data that is updated weekly or monthly doesn't need EJB's and often is better off using a custom cache with specialized search/index algorithm to improve performance. This probably accounts for 50% of the apps. Without EJB's, doing transactions that require choreography would be a major pain and extremely difficult.
Most developers have only had to deal with one database and one connection. In those cases, if the connection is interrupted, the transaction isn't commited. What happens when you have to connect to several databases? and the commit threshold varies between transactions? Those situation require something like EJB's where state is maintained in memory, so that selective or full rollbacks is possible. Don't believe what MS or other marketing driods preach. Serious software development is hard and takes dedication. It's not something that can be thrown together.
Bussiness customers notice this. Especially if project deadlines are always a problem. The quicker something is done the better.
I'll bite. Although this statement may seem accurate it is not. Let's take for example companies that provide application services, be it insurance, financial or enterprise resource management. There's nothing wrong with hardcoding everything and removing abstraction layers all together, if the application will stay that way for 1-2 yrs. Having said that, none of the projects I've worked on had static requirements. If anything, the requirements change rapidly. Hardwiring everything in the petshop demo mean you'll have to change 50-80% of the code to support a new feature.
putting in abstraction layers increase code size right. adding comments to your code so that it is self-documenting and easy to maintain adds to the code size also. It's great model of development if your goal is to charge as much as possible and spend 80% of your time maintaining and fixing the system. It only works if you don't have competitors. If some one else take 15% more time to build the same system, but their maintenance cost is only 25%, you'll loose the battle in the long run. So the quicker something is done isn't necessarily better.
If sun was smart they would release newer libraries to compete with C#.net as well.
This statement is mis-informed. there are plenty of libraries that provide better standard compliance to XML, SCHEMA, and SOAP in Java than Microsoft. Try to do Object-relational mapping that follows standard OR techniques. What I mean by this is, take relational data and map it to an object hierarchy which reduces repetition/duplication of values. Guess what, if you use the stock VS.NET tool it only generate flat tables. This means rowsets that have similar/same columns will be duplicated. this is because ADO flattens everything and doesn't maintain OR mapping, therefore the Schema tool in VS.NET generates flat tables.
I could be wrong, but every time I've tried using VS.NET schema tool with database tables that is what it does. The only way to get around that is to build your own OR mapping and write the schema by hand using complexTypes instead of elements the way VS.NET does it.
All I can say is. I'm not going to buy any music from any of the big labels. Only small indepedent labels. RIAA can take all the junk they're spewing out and shove it.
Ronald is the author of one of the most useful java libs HTTPClient. I've used it and the quality of the code is good. I can see situations where a person doesn't want to d/l the entire jdk because they're on dial-up. JDK1.4.1 is 36megs. On a dial-up that is really painfully slow.
the older jdk's are smaller, but it's still 8-10 megs for jdk1.1.8. Plus it's hard to find the link on Sun's jdk archive site. the page is useful, but you'd be better of d/l the jdk or buying a java book that comes with the jdk.
Saying biztalk uses MSMQ doesn't seem to clarify the differences and how biztalk will provide better scalability. If I'm not mistaken, MSMQ is a system level messaging service that is used by windows apps right. So obviously it should use MSMQ, but lets not confuse system level messaging system with network messaging systems which have to provide a different level of service, which includes multiple transport protocols and huge latencies. A common technique is to use MSMQ in a multi-threaded apartment fashion right. Transaction comes in, a thread is created to generate a message ID. A response is immediately sent back to the requesting app for retrieval later on. The query is then sent to ADO.NET. Once the query/transaction is complete, the result is published to the queue. The requesting application then has to go and get the result from the queue.
You probably have more experience with MSMQ, since I consider myself a newbie with it. But MSMQ is a messaging system and not a transaction client, which is why the NEC TCPC setup had a COM+ transaction scheduler. Past projects that I've worked on used clients to schedule the transaction on windows, because doing it on the server rapidly reaches performance limit. By distributing it on the clients, the server hosting SQL Server only does transactions. That's all fine right. But the point I was trying to make in previous posts is not all situations lend themselves to that work flow. Say for example a process has several transactions and all of them have to go through for the transaction to be valid. If the transaction are scheduled on the client and the COM+ component is not stateful, which application is responsible for rolling back all the transactions and all their dependencies?
EJB is often mis-used, but that is one area where an application server provides a standard mechanism for handling complex processes. The applications I've worked on required connecting to multiple databases with mixed data models. Therefore each insert/update is slightly different and the data has to be massaged for each query. Is the NEC TCP setup valid? Sure it is, but for a specific set of processes. It's not well suited to complex transactions where one application has to maintain transaction integrity across multiple databases and updates. Scheduling transactions with a client is well suited for atomic processes that do not have complex dependencies. I've never tried to do that with COM+, but from my limited knowledge, it would much harder with.NET COM+ than with Tuxedo, Weblogic or Websphere.
Sounds to me like you don't understand how to do asynchronous processing under the Microsoft architecture.
AC did say "temporary" right. Obviously using a messaging system is better approach, but what if you don't have a couple months to re-write the transaction processing? How are you going to temporarily fix that problem while a redesign and rewrite is happening. How do you deal with problems when they arise, or are you one of those programmers who never make a mistake and design a system perfect the first time:) I don't remember Microsoft recommending MSMQ with IIS in 97-99 for IIS. If memory serves me correctly, their recommendation was to use MTS. I have no idea why AC didn't use MTS. I've never used it myself, but I did do some research to figure out if MTS provides state management, which it doesn't or didn't back in 98. I believe MSMQ is going to be replaced by BizTalk, which is supposed to be a more robust and implements pub/sub architecture fully with better extensibility.
In the java world you can use a variety of techniques, but the most common is to use a transaction server like BEA Tuxedo or IBM transaction server. Other possible approaches is to use an EJB container like Websphere or weblogic. Both can be used with Java triggers, which can utilize a messaging server that implements JMS. By the way, if MSMQ is the solution to event driven transaction processing, then why is there SQL Server notification Service?
MS DTC (Microsoft Distributed Transaction Coordinator) manages the transactions which span more processes, across machines.
I'm no expert in Microsoft technologies, but the page on MDTC says this:
MS DTC is not recommended for replicating a database for decision support or high availability. Microsoft recommends that you use the data replication services provided with your relational database application. For more information, see Data Replication for Decision Support.
I agree the result is what counts, and each technology has it's strengths and weaknesses, but as the quote from MSDN states, replication of state across n clients should use DRDS. My point is people should know the technology before they report on it. Claiming one solution is cheaper is the least of my worries if lost transaction means the sytem just lost 20 million. Ultimately it's up to the developer to choose the right solution, but reality is CTO tend to make that decision. Very few CTO's understand technology at a low level and have the ability to see exactly what the trade offs are.
Both posts don't seem to be too accurate. Here is the definition from the full disclosure.
The performance metric reported by TPC-C is a "business throughput" measuring the number of orders processed per minute. Multiple transactions are used to simulate the business activity of processing an order, and each transaction is subject to a response time constraint. The performance metric for this benchmark is expressed in transactions-per-minute-C (tpmC). To be compliant with the TPC-C standard, all references to tpmC results must include the tpmC rate, the associated price-per-tpmC, and the availability date of the priced configuration.
I could be wrong, but I believe the durability refers to the database, not transactions in the queue. A transaction that is queued but is never sent doesn't count. Again I could be wrong, I don't claim to be an expert.
Whereas the Fujitsu solution cost $10.8 million, twice as much
That price is from 2001. I don't know what the current price is, but it should be cheaper right. Both posts fail to mention the network for the NEC test was 2gigabit ethernet, whereas the fujitsu and IBM used 100mbit ethernet. You think that makes a difference? Again, here is the excerpt from the disclosure for NEC.
Queuing Mechanism The queuing mechanism used to defer the execution of the Delivery transaction must be disclosed.
The client application processes submitted delivery transactions to named pipe delivery server software running on the client machines. There was a single delivery server with multiple execution threads running on each client machine. These delivery servers were responsible for processing deliveries queued to the named pipe and submitting them to the database server. The source code is listed in Appendix A.
I could be reading this wrong, but it seems to imply SQL Server only ran the transaction. It doesn't manage the Queue. COM+ manages the queues on each client. Here is the disclosure from #3 IBM for how scheduling was done. I can't find the section for fujitsu.
The Delivery transaction was submitted using an RPC call to an IBM Websphere Application Server Enterpri se EditionVersion 3.0, Encina interface transaction manager (TM) . Websphere returns an immediate response to the calling program and schedules the work to be performed.
Unless I'm reading this wrong. In IBM's setup, the management of the scheduling is performed by the server with Websphere. Both posts seem to have missed some important details. Is there a difference? Read the disclosure and decide for yourself. They are definitely not equal architecturally.
Actually for once Bush might have got the budget numbers right.
And this is based on what facts and years of experience in economics? How about all the republicans who have voiced opposition to the tax cuts or allen greenspan's recommendation the tax cut is foolish and inappropriate given the current economic conditions. Does the president really think he knows better than 100's of experts who collectively have several hundreds years of experience with economics. For god sake, read both sides of the story and think for yourself. How about article by business week, usa today, capitalist mag, abc news, or washington times. there are articles for and against the tax cuts. Tax cuts are only good when spending is kept in check as others have stated. Trickle down economics doesn't work as the 80's proved. Finding a good balance is tough, and luckily the president has to convince the senate and congress.
go outside and play ball. Here's a couple more. Get some crayons, markers, pencils, pens, charcoal, pastels, water color, or oil paints and draw. Get a bowl of fruit, place it on a table, put a spot light on it and try to draw it. when you're done with that, take out some pipe cleaners and try to make stick figures playing sports or doing some activity. This one isn't as much fun, but it's rewarding. Clean up your room and help your parents around the house. It's pretty rewarding when you see them smile.
Re:Re:stupid managers and stupid HR
on
The Post-OOP Paradigm
·
· Score: 2, Insightful
exactly, the problem isn't unique. Just people with Phd's think some stupid concept will solve a human problem.
That is the biggest cause of spaghetti code. how many good teams have been ruined because the management thinks "We need 30 bodies!". Or HR's "that person doesn't exist, so just hire this guy. He only wants half the salary of the other guy."
Until management and HR get it through their head that programming is about hiring the "right people", building software will still be spaghetti. Crappy programmers who can't think beyond the line they are currently typing is the main cause of a lot of problems. In the worse cases, it's programmers who refuse to listen and understand the functional requirements before they code. Not enough programmers take a humble approach and take time to listen closely and think ahead.
Not everyone can and even the best programmers can't think of everything. It's all about finding the right balance to build a team that compliments each other.
Slashdot Mirror
absolutely true! but trying to port an application from VMS to AIX isn't quite that easy right :) There's always room for improvement and standardization of how certain classes of common problems are handled in software and hardware.
You're absolutely right. Both platforms are owned by its creator. neither is perfect or horribly broken. On the other hand, there are major differences in each companies approach. Sun has been accused of moving too slow and MS has been accused of moving too fast. both keep repeating the same mistakes, not because of the programmers. It's because of the business guys, who can't make up their minds.
take AWT for example. when it first came out, it was slow, but now it's much faster and works well. Not blazing or faster than C++. on the .NET side, take IIS for example. IIS is a nice webserver that allows you to build dynamic pages easily, but it scales very poorly for heavy weight web apps. If you need to do anything complex or make sync database calls, it becomes a huge pain to scale. In the past, I was given the task of building a real-time monitoring tool for IIS and it was a total pain. building the equivalent real-time monitor tool in a java container like JBoss is several orders of magnitude easier. I know, the comparison is unfair (apples to oranges), but that's the thing. Stupid CTO's and execs say "IIS only" without understanding the full depth of the problem. Or an exec will say "all EJB" for a simple dynamic website.
the true evil is business people not listening and despising the IT department. Rather than see the IT staff as equals and a vital part of the company, many execs think of it as "IT is something I have to put up with." Programmers typically aren't great at soft skills, so guys in marketing are seen as more important because they can smooze. In reality, they are all equal parts and have to cooperate with each other. <rant/>
Researchers argue over the best way to tackle these problems and there doesn't seem to be a clear set of rules about how these kinds of systems should be built and maintained. It's going to take another 20-30 years before the industry as a whole (programmers, manufacturers, software companies) gets a solid grasp of building high performance parallel and distributed applications. that's not to say we don't know how, but that it is still very complicated and requires a ton of expertise. I'm no expert on multi-processor applications and hardware, but performing a sync on symmetric multi-processor hardware vs AIX is totally different. High end unix boxes use switch fabric architecture to share physical memory, where as the typical multi-cpu PC uses shared bus and must take turns accessing the memory.
Let's face the facts, C++ is more mature and has had the benefit of years of hardcore development. Java is still a young language and C# is still an infant. Each language has it's strengths and weaknesses. More things change, more they stay the same. Programmers should just realize the constant cycle of new languages is all a marketing ploy and isn't really about making software development easier or more stable. If anything, it makes it less stable because it forces people to learn whole new sets of problems and repeat the same mistakes in a different language. Using the right tool to solve the right problem should be the goal of projects, but trying to convince execs is nearly impossible
I've been doing some hardcore webservices work lately and here's my .5 cents on this. There are some good things about web services in theory, but in practice the current implementations for WSDL, Schema and O/R mapping in .NET is majorly crippled. Before people start saying "what a load of crap" consider this. SOAP is a simple transport that doesn't understand the concept of transaction, which is fine, since it that wasn't the original goal. But that means deserializing and serializing complex objects has to be done with some other tools. The recommended method from Microsoft is to use Schema.
Schema has several major weaknesses, the primary one is it lacks the ability to inherit external types. Schema does support includes, but when the XML is converted/compiled to an object it essentially becomes flat. I'll clarify this a bit for those who haven't used schema. When schema is loaded to generate classes, the validation checks to make sure references to simple and complex types are valid. But to do so, it loads all the includes and builds one complete file. For applications that require modularity and custom extensions, schema simply doesn't work unless you build your own schema driver. What does this mean for an application?
Say you are using SOAP + Schema to build a messaging system and you want to dynamically update the messages incrementally because the messaging platform has to support tens of thousands of messages per hour. If you don't implement some kind of event mechanism within the generated objects, it would require you to transfer the entrie message, which consumes I/O and cpu time when it parses the XML. Take this use case. Say you have multiple messaging servers that can communicate on a peer-to-peer or master-slave basis. Now add several thousand clients that must recieve those messages and decide intelligently how to handle the message updates. An easy approach would be to have each of the objects register for a particular topic in the messaging server (assuming it's pub/sub). If you use the default schema driver, the classes do not extend any class or inherit any predefine logic. If you want all messaging objects to extend a base class which provides messaging subscription and intelligent updates, you have to write your own schema driver. Take another example. The default mode of building schema descriptions from a database is to open a connection to SQL Server, select the tables and VS.NET generates flattened schema models. On the surface that seems fine, if the data you want is flat. If the data you want is relational and has to preserve the structure or map to an object structure, you have to provide your own mapping implementation.
Do these kinds of problems exist in the java world? The answer is mostly no. For O/R mapping there's castor, jdo and numerous other mature drivers. Compiling schema to extend base classes, Castor provides the ability. Not only that, the Java solutions provide a more mature and flexible method of doing these types of operations. If you don't believe, try it yourself.
I also don't buy people's excuse about "testing 50million lines of code is nearly impossible." Obviously it's not impossible. Otherwise IBM, HP, SAP, Oracle and Sun would have the same scalability issues that Windows 2K and 2K3 have with high availability. I'm not trolling, just go read the MSDN site for windows 2K and 2K3 and it states clearly it is more scalable than previous windows servers, but it is not "High availability".
All this tells me is corporate america loves disposable society where everything moves towards use once and throw away. There is no way in hell I'm going to fork out 2 or 5 dollars for once of these lame DVD's. Hell, i will gladly pay 25 to order DVD's from Canada, UK or any other country that treats consumers like human beings. Disney can take their straight to video crap and blow it out their rear. Disney hasn't made anything good in the last 8 years and never will until the idiot CEO is kicked out of office. Eisner has done everything in his power to ruin the company walt built. for those who don't remember, disney was created so that both parents and kids could find entertainment. He made the point of making his movies intelligent and thoughtful. Not moron, thoughtless pieces of snot.
Talk about FUD and PR juggling. SCO needs to go bankrupt now, or prove beyond a doubt in their court filing with exact details, so everyone can see. Enough of this smoke and mirrors.
What a bunch of BS. the fact is, the current conditions are the result of both democratic and republican politicians. It's neither one or the other, but both. There are just as many left/dem pork barrel handouts as right/repub. Go look at the library of congress and get real. The only way this is going to change isn't through one party. It will require everyone in every party to tell politicians no more of their special interest BS.
this would be more funny if I never have to read another class that has everything in one method. it's still funny, except when I remember the times I've had to fix other people's code.
There's nothing wrong with Pop philosophy, but people need read the original works. Hopefully, the movie inspired some people to go read the original text and really get a mind altering experience.
I believe this statement is mis-informed. In fact most of the response is mis-informed from an enterprise application perspective. I'm not talking about office productivity here. Back end enterprise applications that run 24/hrs a day with less than 2-4 hours down time a year. When java first came out, Oracle promised tight integration. They never said they would write Oracle with java. The first release of oracle 8i did have java tightly integrated. In fact, java runs at the same level as sql. Not only that, Oracle provided java triggers, so that triggers could be written in sql or java. The benefit of that is you can then hook traditional triggers to Java, which can then send messages to a messaging system like IBM messaging server.
Does MS SQL server have that kind of integration with .NET and C#? Right now, the only thing SQL Server 2K has is SQL SERVER notification, which uses COM+. I don't know if SQL SERVER 64bit is any different, but I doubt it. I could be wrong.
Actually since dot net supports 26 languages and counting it would be only proper to included them all in the tally. You see if you do Java that's all you do.
The whole argument about multi-language support doesn't hold water. There are certain classes of applications which are not well suited AIDA, COBAL or Foxpro. Not because the language is bad, but because it would require too much effort to hack a system to use 8 different languages. If you've ever tried to do cross language development, you'll know that having a way to use a library written in another language is just the tip of the ice berg. I'm not suggesting a person should avoid C# or .NET. On the contrary, if you can use an existing library written with foxpro, go ahead. But if the application has out grown foxpro, then you're better off using stock ADO.net with SQL Server. Or better yet, use something that meets the same functional requirements. Again, when you're talking about enterprise applications, most of the heavy stuff comes with mature Java support natively. The same isn't true of .NET right now. It will mature obviously over the next 10 yrs. Using libraries written in other languages isn't as simple as "recompile with .NET". Say for example you're using an existing C module that forks a new process, instead of threads. How much work is required to rework that piece? Again, not a simple task.
From what I've seen first hand. Being able to hook into a component written in another language is just the beginning. In many cases, you're better off wrapping those pieces, or rewriting it. Nothing is ever as simple as marketing slogans. There are entire class of applications that really should sit on the mainframe using the original COBOL code base. The argument of multi-language support is a moot point and doesn't accurately describe the complexity of integrating legacy code written in other languages. No one in their right mind would recompile a COBOL application for .NET. Writing a webservice for it and then hooking it to other .NET webservices makes sense. I don't know if a COBOL .NET compiler really exists or not, but recompiling a COBOL backend app to .NET is a dangerous and stupid idea.
I say it's time the people put forth a bill for all elections state and national to require full disclosure of all contributions. The current system allows for too much sneaky back room deals. This way everyone can see exactly which politicians are being bought out by which companies. That's the only real way people can make well informed decisions. Not, vote for the person with the best ad campaigns on TV.
Now with EJB's you can manage this using a standard framework and container. If you had to do this with JDO, you would need to either use it with EJB or write your own. The thing is, many architects don't understand when to use EJB's. Lead architects with the skills and technical chops know when to use EJB's. I've seen EJB's used well and use poorly. Those who use it well are programmers who understand EJB's at all levels, not just a high level over-view of what EJB's could do. One of the most common mis-uses of EJB is for simple non-transactional cache. Data that is updated weekly or monthly doesn't need EJB's and often is better off using a custom cache with specialized search/index algorithm to improve performance. This probably accounts for 50% of the apps. Without EJB's, doing transactions that require choreography would be a major pain and extremely difficult.
Most developers have only had to deal with one database and one connection. In those cases, if the connection is interrupted, the transaction isn't commited. What happens when you have to connect to several databases? and the commit threshold varies between transactions? Those situation require something like EJB's where state is maintained in memory, so that selective or full rollbacks is possible. Don't believe what MS or other marketing driods preach. Serious software development is hard and takes dedication. It's not something that can be thrown together.
I'll bite. Although this statement may seem accurate it is not. Let's take for example companies that provide application services, be it insurance, financial or enterprise resource management. There's nothing wrong with hardcoding everything and removing abstraction layers all together, if the application will stay that way for 1-2 yrs. Having said that, none of the projects I've worked on had static requirements. If anything, the requirements change rapidly. Hardwiring everything in the petshop demo mean you'll have to change 50-80% of the code to support a new feature.
putting in abstraction layers increase code size right. adding comments to your code so that it is self-documenting and easy to maintain adds to the code size also. It's great model of development if your goal is to charge as much as possible and spend 80% of your time maintaining and fixing the system. It only works if you don't have competitors. If some one else take 15% more time to build the same system, but their maintenance cost is only 25%, you'll loose the battle in the long run. So the quicker something is done isn't necessarily better.
If sun was smart they would release newer libraries to compete with C#.net as well.
This statement is mis-informed. there are plenty of libraries that provide better standard compliance to XML, SCHEMA, and SOAP in Java than Microsoft. Try to do Object-relational mapping that follows standard OR techniques. What I mean by this is, take relational data and map it to an object hierarchy which reduces repetition/duplication of values. Guess what, if you use the stock VS.NET tool it only generate flat tables. This means rowsets that have similar/same columns will be duplicated. this is because ADO flattens everything and doesn't maintain OR mapping, therefore the Schema tool in VS.NET generates flat tables.
I could be wrong, but every time I've tried using VS.NET schema tool with database tables that is what it does. The only way to get around that is to build your own OR mapping and write the schema by hand using complexTypes instead of elements the way VS.NET does it.
All I can say is. I'm not going to buy any music from any of the big labels. Only small indepedent labels. RIAA can take all the junk they're spewing out and shove it.
the older jdk's are smaller, but it's still 8-10 megs for jdk1.1.8. Plus it's hard to find the link on Sun's jdk archive site. the page is useful, but you'd be better of d/l the jdk or buying a java book that comes with the jdk.
Saying biztalk uses MSMQ doesn't seem to clarify the differences and how biztalk will provide better scalability. If I'm not mistaken, MSMQ is a system level messaging service that is used by windows apps right. So obviously it should use MSMQ, but lets not confuse system level messaging system with network messaging systems which have to provide a different level of service, which includes multiple transport protocols and huge latencies. A common technique is to use MSMQ in a multi-threaded apartment fashion right. Transaction comes in, a thread is created to generate a message ID. A response is immediately sent back to the requesting app for retrieval later on. The query is then sent to ADO.NET. Once the query/transaction is complete, the result is published to the queue. The requesting application then has to go and get the result from the queue.
You probably have more experience with MSMQ, since I consider myself a newbie with it. But MSMQ is a messaging system and not a transaction client, which is why the NEC TCPC setup had a COM+ transaction scheduler. Past projects that I've worked on used clients to schedule the transaction on windows, because doing it on the server rapidly reaches performance limit. By distributing it on the clients, the server hosting SQL Server only does transactions. That's all fine right. But the point I was trying to make in previous posts is not all situations lend themselves to that work flow. Say for example a process has several transactions and all of them have to go through for the transaction to be valid. If the transaction are scheduled on the client and the COM+ component is not stateful, which application is responsible for rolling back all the transactions and all their dependencies?
EJB is often mis-used, but that is one area where an application server provides a standard mechanism for handling complex processes. The applications I've worked on required connecting to multiple databases with mixed data models. Therefore each insert/update is slightly different and the data has to be massaged for each query. Is the NEC TCP setup valid? Sure it is, but for a specific set of processes. It's not well suited to complex transactions where one application has to maintain transaction integrity across multiple databases and updates. Scheduling transactions with a client is well suited for atomic processes that do not have complex dependencies. I've never tried to do that with COM+, but from my limited knowledge, it would much harder with .NET COM+ than with Tuxedo, Weblogic or Websphere.
AC did say "temporary" right. Obviously using a messaging system is better approach, but what if you don't have a couple months to re-write the transaction processing? How are you going to temporarily fix that problem while a redesign and rewrite is happening. How do you deal with problems when they arise, or are you one of those programmers who never make a mistake and design a system perfect the first time :) I don't remember Microsoft recommending MSMQ with IIS in 97-99 for IIS. If memory serves me correctly, their recommendation was to use MTS. I have no idea why AC didn't use MTS. I've never used it myself, but I did do some research to figure out if MTS provides state management, which it doesn't or didn't back in 98. I believe MSMQ is going to be replaced by BizTalk, which is supposed to be a more robust and implements pub/sub architecture fully with better extensibility.
In the java world you can use a variety of techniques, but the most common is to use a transaction server like BEA Tuxedo or IBM transaction server. Other possible approaches is to use an EJB container like Websphere or weblogic. Both can be used with Java triggers, which can utilize a messaging server that implements JMS. By the way, if MSMQ is the solution to event driven transaction processing, then why is there SQL Server notification Service?
You seem to have a chip on your shoulder there.
I'm no expert in Microsoft technologies, but the page on MDTC says this:
MS DTC is not recommended for replicating a database for decision support or high availability. Microsoft recommends that you use the data replication services provided with your relational database application. For more information, see Data Replication for Decision Support.
I agree the result is what counts, and each technology has it's strengths and weaknesses, but as the quote from MSDN states, replication of state across n clients should use DRDS. My point is people should know the technology before they report on it. Claiming one solution is cheaper is the least of my worries if lost transaction means the sytem just lost 20 million. Ultimately it's up to the developer to choose the right solution, but reality is CTO tend to make that decision. Very few CTO's understand technology at a low level and have the ability to see exactly what the trade offs are.
The performance metric reported by TPC-C is a "business throughput" measuring the number of orders processed per minute. Multiple transactions are used to simulate the business activity of processing an order, and each transaction is subject to a response time constraint. The performance metric for this benchmark is expressed in transactions-per-minute-C (tpmC). To be compliant with the TPC-C standard, all references to tpmC results must include the tpmC rate, the associated price-per-tpmC, and the availability date of the priced configuration.
I could be wrong, but I believe the durability refers to the database, not transactions in the queue. A transaction that is queued but is never sent doesn't count. Again I could be wrong, I don't claim to be an expert.
Whereas the Fujitsu solution cost $10.8 million, twice as much
That price is from 2001. I don't know what the current price is, but it should be cheaper right. Both posts fail to mention the network for the NEC test was 2gigabit ethernet, whereas the fujitsu and IBM used 100mbit ethernet. You think that makes a difference? Again, here is the excerpt from the disclosure for NEC.
Queuing Mechanism The queuing mechanism used to defer the execution of the Delivery transaction must be disclosed.
The client application processes submitted delivery transactions to named pipe delivery server software running on the client machines. There was a single delivery server with multiple execution threads running on each client machine. These delivery servers were responsible for processing deliveries queued to the named pipe and submitting them to the database server. The source code is listed in Appendix A.
I could be reading this wrong, but it seems to imply SQL Server only ran the transaction. It doesn't manage the Queue. COM+ manages the queues on each client. Here is the disclosure from #3 IBM for how scheduling was done. I can't find the section for fujitsu.
The Delivery transaction was submitted using an RPC call to an IBM Websphere Application Server Enterpri se EditionVersion 3.0, Encina interface transaction manager (TM) . Websphere returns an immediate response to the calling program and schedules the work to be performed.
Unless I'm reading this wrong. In IBM's setup, the management of the scheduling is performed by the server with Websphere. Both posts seem to have missed some important details. Is there a difference? Read the disclosure and decide for yourself. They are definitely not equal architecturally.
You're wrong. the most accurate calendar is the 13 Moon Calendar created by the Mayan.
And this is based on what facts and years of experience in economics? How about all the republicans who have voiced opposition to the tax cuts or allen greenspan's recommendation the tax cut is foolish and inappropriate given the current economic conditions. Does the president really think he knows better than 100's of experts who collectively have several hundreds years of experience with economics. For god sake, read both sides of the story and think for yourself. How about article by business week, usa today, capitalist mag, abc news, or washington times. there are articles for and against the tax cuts. Tax cuts are only good when spending is kept in check as others have stated. Trickle down economics doesn't work as the 80's proved. Finding a good balance is tough, and luckily the president has to convince the senate and congress.
go outside and play ball. Here's a couple more. Get some crayons, markers, pencils, pens, charcoal, pastels, water color, or oil paints and draw. Get a bowl of fruit, place it on a table, put a spot light on it and try to draw it. when you're done with that, take out some pipe cleaners and try to make stick figures playing sports or doing some activity. This one isn't as much fun, but it's rewarding. Clean up your room and help your parents around the house. It's pretty rewarding when you see them smile.
exactly, the problem isn't unique. Just people with Phd's think some stupid concept will solve a human problem.
Until management and HR get it through their head that programming is about hiring the "right people", building software will still be spaghetti. Crappy programmers who can't think beyond the line they are currently typing is the main cause of a lot of problems. In the worse cases, it's programmers who refuse to listen and understand the functional requirements before they code. Not enough programmers take a humble approach and take time to listen closely and think ahead.
Not everyone can and even the best programmers can't think of everything. It's all about finding the right balance to build a team that compliments each other.