Elliotte Harold (elharo@metalab.unc.edu), Adjunct Professor, Polytechnic University

26 Sep 2006

Fuzz testing is a simple technique that can have a profound effect on your code quality. In this article, Elliotte Rusty Harold shows what happens when he deliberately injects random bad data into an application to see what breaks. He also explains how to use defensive coding techniques such as checksums, XML data storage, and code verification to harden your programs against random data. He concludes with an exercise in thinking like a code cracker -- a crucial technique for defending your code.

For years, I've been astounded by the number of corrupt files that can crash Microsoft Word. A few bytes out of place and the whole application goes down in flames. On older, non-memory-protected operating systems, the whole computer usually went down with it. Why can't Word recognize when it's received bad data and simply put up an error message? Why does it corrupt its own stack and heap just because a few bits got twiddled? Of course, Word is hardly the only program that behaves atrociously in the face of malformed files.

This article introduces you to a technique that attempts to avert just this sort of disaster. In fuzz testing, you attack a program with random bad data (aka fuzz), then wait to see what breaks. The trick of fuzz testing is that it isn't logical: Rather than attempting to guess what data is likely to provoke a crash (as a human tester might do), an automated fuzz test simply throws as much random gibberish at a program as possible. The failure modes identified by such testing usually come as a complete shock to programmers because no logical person would ever conceive of them.

Fuzz testing is a simple technique, but it can nonetheless reveal important bugs in your programs. It can identify real-world failure modes and signal potential avenues of attack that should be plugged before your software ships.

How fuzz testing works

Fuzz testing is a very simple procedure to implement:

1. Prepare a correct file to input to your program.
2. Replace some part of the file with random data.
3. Open the file with the program.
4. See what breaks.

You can vary the random data in any number of ways. For example, you might randomize the entire file rather than replacing just a part of it. You could limit the file to ASCII text or non-zero bytes. Any way you slice it, the key is to throw a lot of random data at an application and see what fails.

Testing C-based applications Many programs written in C have trouble when strings contain extra zeroes -- so much so that extra zeroes can completely hide other problems in the code. Once you've identified a program's problems with zero-bytes, you might wish to remove them to allow other problems to surface.

While you can do initial tests manually, you should really automate fuzzing for maximum effect. In this case, you first need to define the proper error behavior for the application when faced with corrupt input. (If you discover the program hasn't bothered to define what happens when the input data is corrupt, well, there's your first bug.) Then you simply pass random data into the program until you find a file that doesn't trigger the proper error dialog, message, exception, etc. Store and log that file so you can reproduce the problem later. Repeat.

Although fuzz testing usually requires some manual coding, there are tools that can help. For example, Listing 1 shows a simple Java? class that randomly modifies a certain length of a file. I usually like to start fuzzing somewhere after the first few bytes because programs seem more likely to notice an early mistake than a later one. (You want to find the errors the program doesn't check, not the ones it does.)

Listing 1. A class that replaces part of a file with random data

import java.io.*;
import java.security.SecureRandom;
import java.util.Random;

public class Fuzzer {

     private Random random = new SecureRandom();
     private int count = 1;

     public File fuzz(File in, int start, int length) throws IOException  
{

         byte[] data = new byte[(int) in.length()];
         DataInputStream din = new DataInputStream(new FileInputStream(in));
         din.readFully(data);
         fuzz(data, start, length);
         String name = "fuzz_" + count + "_" + in.getName();
         File fout = new File(name);
         FileOutputStream  out = new FileOutputStream(fout);
         out.write(data);
         out.close();
         din.close();
         count++;
         return fout;
     }


     // Modifies byte array in place
     public void fuzz(byte[] in, int start, int length) {

         byte[] fuzz = new byte[length];
         random.nextBytes(fuzz);
         System.arraycopy(fuzz, 0, in, start, fuzz.length);

     }

}

About the code There are many ways I could optimize the code in Listing 1. For instance, it's a really good candidate for a memory mapped file with java.nio. I could also improve its error handling and configurability. Because I don't want to let those details get in the way of the ideas I'm presenting here, I've left it as is.

Fuzzing the file is easy. Passing it to the application is normally not much harder. Scripting languages like AppleScript or Perl are often the best choice for writing this part of the fuzz test. For GUI programs, the hardest part can be recognizing whether the application indicated the right failure mode. Sometimes it's simplest to have a human sit in front of the program and mark each test as pass or fail. Be sure to individually name and save all the random test cases generated so you can reproduce any failures you detect with this procedure.

Defensive coding

Solid code follows this fundamental principle: Never accept external data into your program without verifying it for consistency and sanity.

If you read a number from a file and expect it to be positive, check that it is before further processing with that number. If you expect a string to contain only ASCII letters, be sure that it does. If you think a file contains an integral multiple of four bytes, then check that. Never assume that any characteristic of externally-supplied data is as you expect.

The most common mistake is to assume that because an instance of your program wrote the data out, it can read that data back in again without verifying it. This is dangerous! The data could have been overwritten on disk by another program. It could have been corrupted by a failing disk or a bad network transfer. It could have been modified by another program that had a bug. It could even have been deliberately modified in an effort to subvert your program's security. Assume nothing. Verify everything.

Of course, error handling and verification is ugly, annoying, inconvenient, and thoroughly despised by programmers the world over. Sixty years into the computer age, we still aren't checking basic things like the success of opening a file or whether memory allocation succeeds. Asking programmers to test each byte and every invariant when reading a file seems hopeless -- but failing to do so leaves your programs vulnerable to fuzz. Fortunately, help is available. Properly used, modern tools and technologies can significantly alleviate the pain of hardening your applications. In particular, three techniques stand out:

• Checksums
• Grammar based formats such as XML
• Verified code such as Java

Fuzz proofing with checksums

The simplest thing you can do to protect against fuzzing is add a checksum to your data. For example, you can sum up all the bytes in the file and then take the remainder when dividing by 256. Store the resulting value in one extra byte at the end of the file. Then, before trusting the input data, verify that the checksum matches. This very simple scheme reduces the risk of undetected accidental failure to about 1 in 256.

Robust checksum algorithms like MD5 and SHA do much more than simply take the remainder when dividing by 256. In the Java language, the java.security.DigestInputStream and java.security.DigestOutputStream classes provide convenient means for attaching a checksum to your data. Using one of these checksum algorithms reduces the chance of accidental corruption to less than one in a billion (though deliberate attacks are still a possibility, as you'll see).

XML storage and validation

Storing your data in XML is an excellent way to avoid problems with data corruption. While XML was originally intended for Web pages, books, poems, articles, and similar documents, it has found broad success in almost every field ranging from financial data to vector graphics to serialized objects.

Impractical boundaries If you really wanted to break an XML parser, there are a few ways you could try to do it. For instance, most XML parsers are subject to certain maximum sizes. SAX parsers will fail if an element name is more than 2.2 billion characters long (the maximum size of a Java String). In practice, however, these limits are so high that you'll run out of memory long before reaching them.

The key characteristic that makes XML formats resistant to fuzz is that an XML parser assumes nothing about the input. This is precisely what you want in a robust file format. XML parsers are designed so that any input (well-formed or not, valid or not) is handled in a defined way. An XML parser can process any byte stream. If your data first passes through an XML parser, all you need to be ready for is whatever the parser can give you. For instance, you don't need to check whether the data contains null characters because an XML parser will never pass you a null. If the XML parser sees a null character in its input, it throws an exception and stops processing. You still need to handle this exception of course, but writing a catch block to handle a detected error is much simpler than writing code to detect all possible errors.

For further security you can validate your document with a DTD and/or a schema. This checks not only that the XML is well-formed, but that it's at least close to what you expect. Validation will rarely tell you everything you need to know about a document, but it makes it easy to write a lot of simple checks. With XML, it is very straightforward to strictly limit the documents you accept to the formats you know how to handle.

Still, there will be pieces of the code you can't validate with a DTD or schema. For example, you can't test whether the price of an item in an invoice is the same as the price for that item in your inventory database. When receiving an order document from a customer that contains the price, whether in XML or any other format, you should always check to make sure the customer hasn't modified the price before submitting it. However, you can implement these last checks with custom code.

Grammar-based formats

One characteristic that makes XML so fuzz-resistant is that the format is carefully and formally defined using a Backus-Naur Form (BNF) grammar. Many parsers are built directly from this grammar using parser-generator tools such as JavaCC or Bison. The nature of such a tool is to read an arbitrary input stream and determine whether or not it satisfies the grammar.

If XML is not appropriate for your file format, you can still get the robustness of a parser-based solution. You'll have to write your own grammar for the file format, however, and then develop your own parser to read it. Rolling your own is a lot more work than just using an off-the-shelf XML parser. Nonetheless, it is a far more robust solution than simply loading the data into memory without formally verifying it against a grammar.

Java code verification

Many of the crashes resulting from fuzz testing are direct results of memory allocation mistakes and buffer overflows. Writing your application in a safe, garbage-collected language that executes in a virtual machine such as Java or managed C# eliminates many potential problems. Even if you're writing your code in C or C++, you should use a reliable garbage-collection library. In 2006, no desktop or server programmers should be managing their own memory.

The Java runtime features an additional layer of protection for its own code. Before a .class file is loaded into the virtual machine, it is verified by a bytecode verifier and optionally a SecurityManager. Java does not assume that the compiler that created the .class file was non-buggy or behaving correctly. The Java language was designed from day one to allow the execution of untrusted, potentially malicious code in a secure sandbox. It doesn't even trust the code it, itself, has compiled. After all, someone could have changed the bytecode manually with a hex editor to attempt to trigger a buffer overflow. We should all have this level of paranoia about input to our programs.

Back to top

Think like the enemy

Each of the previous techniques goes a long way toward preventing accidental damage. Taken together and implemented properly, they reduce the chance of undetected, unintentional damage to essentially zero. (Well, not quite zero, but of the same order of magnitude as the chance of a stray cosmic ray causing your CPU to add 1+1 and come up with 3.) But not all data corruption is unintentional. What if someone is deliberately introducing bad data in the hopes of breaching your program's security? Thinking like a cracker is the next step in defending your code.

Switching back to an attacker's mode of thinking, let's suppose the application you're attacking is written in the Java programming language, uses non-native code, and stores all external data in XML, which is thoroughly validated before acceptance. Can you still attack it successfully? Yes, you can. A naive approach that randomly changes bytes in the file is unlikely to succeed, however. You need a more sophisticated approach that accounts for the program's built-in error-detection mechanisms and routes around them.

When you're testing a fuzz-resistant application, you can't do pure blackbox testing, but with some obvious modifications, the basic ideas still apply. For example, consider checksums. If a file format contains a checksum, then you simply modify the checksum so it matches your random data before passing the file to the application.

For XML, try fuzzing individual element content and attribute values rather than selecting a random section of the bytes in the document to replace. Be careful to replace data with legal XML characters rather than random bytes, because even a hundred bytes of random data is almost certain to be malformed. You can change element and attribute names too, as long as you're careful to make sure the resulting document is still well formed. If the XML document is checked against a very restrictive schema, you'll need to figure out what the schema isn't checking to determine where you can productively fuzz.

A really restrictive schema combined with code-level verification of the remaining data may leave you with no room to maneuver. As a developer, this is what you should strive for. The application should be able to process meaningfully any stream of bytes you send it that it does not reject as de jure invalid.

Back to top

In conclusion

Fuzz testing can demonstrate the presence of bugs in a program. It doesn't prove that no such bugs exist. Nonetheless, passing a fuzz test greatly improves your confidence that an application is robust and secure against unexpected input. If you've fuzzed your program for 24 hours and it's still standing, then it's unlikely that further attacks of the same sort will compromise it. (Not impossible, mind you, just less likely.) If fuzz testing does reveal bugs in your programs, you should fix them. Rather than plugging random bugs as they appear, it may be more productive to fundamentally harden the file format through the judicious use of checksums, XML, garbage collection, and/or grammar-based file formats.

Fuzz testing is a crucial tool for identifying real errors in programs, and one that all security-aware and robustness-oriented programmers should have in their toolboxes.

Resources

Learn

• In pursuit of code quality : Want more? There's an entire developerWorks series devoted to today's code testing techniques.
  
  
• "The Java XML validation API" (Elliotte Rusty Harold, developerWorks, August 2006): Find out what the Java 5 XML validation API can do for you.
  
  
• "Test before you code" (Gary Pollice, developerWorks, June 2004): A useful overview of test-first programming concepts and methods.
  
  
• "Macintosh stories: Monkey Lives" (Andy Hertzfeld, Folklore): Describes fuzz testing the first Macintosh (though the term had yet to be invented back then).
  
  
• "An Empirical Study of the Reliability of UNIX Utilities" (B.P. Miller, L. Fredriksen, B. So; Communications of the ACM 33, December 1990): First used the word fuzz to describe random data-based testing.
  
  
• "Fuzz Testing of Application Reliability": The original fuzz testing Web site.
  
  
• "Obscuring XML" (Elliotte Rusty Harold, Extreme Markup Languages 2005): This paper introduced a tool for randomizing XML data while maintaining well-formedness. The goal then was to aid in bug reporting, but the same techniques could be used to fuzz test XML.
  
  
• Java I/O, Chapter 12 (Elliotte Rusty Harold, O'Reilly, 2006): Discusses the calculation of checksum in Java using the DigestInputStream and DigestOutputStream classes.
  
  
• Wikipedia: Fuzz testing : A customarily excellent entry.
  
  
• The Java technology zone : Hundreds of articles about every aspect of Java programming.
  
  
• developerWorks technical events and webcasts : Keeping you current.
  
  

Get products and technologies

• Fuzzers: The ultimate list : Various open source fuzz testing tools collected by Jack Koziol.
  
  

Discuss

• Improve Your Code Quality : Andrew Glover brings his considerable expertise as a consultant focused on improving code quality to this moderated discussion forum.

About the author

		Elliotte Rusty Harold is originally from New Orleans, to which he returns periodically in search of a decent bowl of gumbo. However, he resides in the Prospect Heights neighborhood of Brooklyn with his wife Beth and cats Charm (named after the quark) and Marjorie (named after his mother-in-law). He's an adjunct professor of computer science at Polytechnic University, where he teaches Java and object-oriented programming. His Cafe au Lait Web site has become one of the most popular independent Java sites on the Internet, and his spin-off site, Cafe con Leche, has become one of the most popular XML sites. His most recent book is Java I/O, 2nd edition. He's currently working on the XOM API for processing XML, the Jaxen XPath engine, and the Jester test coverage tool.

　　SCA規(guī)范和SDO規(guī)范將成為專門提供編程模型的標準，開發(fā)人員可以在創(chuàng)建Web服務時使用SCA和SDO規(guī)范，盡管此時SCA規(guī)范和SDO規(guī)范還沒有完全成熟，達到標準水平，但是2007年他們一定能夠成為SOA標準。

　　2006年7月，希望曾到來過，有消息表明SCA規(guī)范和SDO規(guī)范有望在去年圣誕節(jié)時正式成為SOA標準。開放SOA(OSOA)組織，一個由多家提供商包括IBM、 BEA Systems Inc、和Oracle Corp等公司自發(fā)成立的組織，目前正在致力于SCA和SDO規(guī)范晉升成為SOA標準的工作。去年夏天OSOA組織預測SCA和SDO規(guī)范將于2006年底正式成為SOA標準。現(xiàn)在看來，這似乎會是2007年的某一天。

　　在回復詢問關(guān)于SCA和SDO規(guī)范更新情況的電子郵件中，IBM 的SOA合作伙伴、項目經(jīng)理、規(guī)范編寫人之一Graham J Barber這樣答到：“我們希望在2007年第一季度將SCA規(guī)范的主要部分作為第一版推出。之后，我們希望將兩個規(guī)范與已發(fā)布的V2.1 SDO規(guī)范放到一起，申請成為SOA標準。”

　　不論SCA規(guī)范是否已經(jīng)完善或是否能成為SOA標準，SCA都是已被廣大提供商應用于產(chǎn)品的SOA技術(shù)。甲骨文工具與中間件副總裁兼首席架構(gòu)師Ted Farrell說，SCA規(guī)范是一種實用的技術(shù)。目前甲骨文的WebCenter Suite 就使用了SCA規(guī)范，使開發(fā)人員方便開發(fā)SOA和Web 2.0項目，他說。

　　Rogue Wave Software，Quovadx, Inc.的一家分公司，本月初宣布開始使用SDO規(guī)范，并將SDO加入產(chǎn)品名稱，公司的SOA工具套裝將被稱為HydraSDO。

　　甲骨文的Farrell說，正式發(fā)布SOA標準是一件好事，他希望正式標準盡早出臺，不過他真正關(guān)心的是在工具和應用程序開發(fā)中如何有效地使用SCA/SDO技術(shù)。

　　“我們對SCA何時成為標準十分感興趣，現(xiàn)在我們叫它SCA偽標準，”他說。“我們不希望有所有權(quán)問題，因為采用開放結(jié)構(gòu)會有許多好處。”

　　但是Farrell說，最重要的是，一個標準需要適用于應用程序，并有廣泛的行業(yè)支持。

　　“SCA規(guī)范更趨于點對點模式，”他說。“IBM和BEA在推廣一些標準的時候受到一些挫折，所以他們開始成立開放SOA組織。甲骨文以及其他一些提供商加入了該組織。盡管它不是以前的標準組織，但是它在不斷發(fā)展，不斷進步，其實我們最為企業(yè)軟件提供商真的希望把這些規(guī)范變?yōu)橐环N軟件標準，希望能夠為SOA的發(fā)展獻出一份力量。”

　　Farrell說SCA/SDO規(guī)范似乎在走業(yè)務處理執(zhí)行語言(BPEL)的發(fā)展道路。業(yè)務處理執(zhí)行語言(BPEL)最初由IBM和微軟共同努力開發(fā)出第一個版本，之后BEA、 SAP AG和 Siebel Systems先后使用BPEL，現(xiàn)在甲骨文也開始使用BPEL。2003年，這些提供商正式將BPEL提交給開放標準組織OASIS標準化，2003年4月6日，OASIS組織用WS-BPEL的名字吸納了BPEL標準。2003年5月3日，SAP/SIEBEL加入并共同推出WS-BPEL1.1版。2003年5月16日， WS-BPEL2.0的草案也在當時被納入議事日程。

　　SOA項目的開發(fā)人員和架構(gòu)師應該從現(xiàn)在開始就接觸這些規(guī)范，不應該等著它們成熟成為正式標準，Harte-Hanks (HHS) 公司Aberdeen Group 企業(yè)集成副總裁Peter S. Kastner說。他認為SOA的工作人員都應該熟悉這些規(guī)范，并促進它們的發(fā)展。

　　“在未來幾年，將迅速推出一批與SOA相關(guān)的標準，所以對用戶來說，最好簡要地使用這些標準，從某種意義上說，這是可能的，”他說。“基本上，變化是不可避免的，所以勇于面對變化，適應變化。如果要等到所有標準都完善，之后出臺，我像那你會瘋掉，這大概需要十年的時間。”

　　UML在版本升級到2.0以后，原來的UML工具的大哥大Rational從風行到被收購，現(xiàn)在幾乎沒有了聲音。

　　建模工具沒有太顯著的變化，倒是開發(fā)工具出現(xiàn)了從原來的百花齊放到現(xiàn)在只有少數(shù)巨頭競爭的局面。其中最耀眼的當屬誕生于IBM，后在開源社區(qū)得到快速發(fā)展的Eclipse,目前它已進入嵌入式開發(fā)領域。另一個就是微軟攜其強大財力與人力打造的VSTS開發(fā)工具平臺，它將成為可以貫穿整個軟件開發(fā)生命周期和扮演不同的角色的平臺，在最近也有不俗表現(xiàn)。此外還有Sun的NetBean IDE開發(fā)工具和BEA的WorkShop開發(fā)工具等。

　　這些開發(fā)工具平臺都可以進入整個軟件開發(fā)生命周期，并且可以在其上進行各種不同應用的開發(fā)，說白了就是兼容性足夠強。

　　開發(fā)與應用

　　不論使用何種工具，真正最活躍的仍然是應用與開發(fā)。JavaEE5的發(fā)布，EJB3.0標準的落地，標注取代部署描述符，實體即是POJO等，也許這些改變對Java進行輕量級應用開發(fā)的復雜性會有所改變。在軟件開發(fā)界最流行的框架，包括Struts、Spring、Hibernate等，這些分布在Web容器和EJB容器中的各種應用框架變得讓人眼花繚亂，要選擇最適合自己的看來越來越困難了。由于JavaEE5的發(fā)布，著名的JBoss應用服務器的結(jié)構(gòu)也發(fā)生了較大的變化。微軟.NET的2.0平臺和下一代操作系統(tǒng)Window Vista桌面版發(fā)布，同時提供給廣大用戶的WinFX平臺，不僅給開發(fā)者而且給用戶帶來了挑戰(zhàn)。

　　由Ruby和Retail的聯(lián)姻，AJAX的新瓶裝舊灑，再加上Web2.0應用概念上的炒作，腳本語言、Web開發(fā)與應用在今年著時火了一把，因此今年搭上順風車的PHP也要求能夠同Java應用交互，克服語言與平臺的障礙。

　　桌面與企業(yè)服務器的開發(fā)應用也有相當發(fā)展，中間件市場、數(shù)據(jù)庫、ERP等各種應用隨著SOA得到市場的認可，各種技術(shù)與應用以及SOA的產(chǎn)品也逐漸多了起來。隨著3G時代的到來，智能手機占有率的提升，手機平臺的開發(fā)市場正進一步;不僅是手機，數(shù)字電視、各種電器和消費類電子產(chǎn)品的智能化發(fā)展也促使嵌入式領域的開發(fā)發(fā)生了很大變化，如：IP機頂盒、基于GPS全球定位系統(tǒng)的設備、工業(yè)自動化和醫(yī)療設備等，商業(yè)平臺與開源Liunx平臺共存。

　　開源、互聯(lián)網(wǎng)及其他

　　開源軟件逐漸挺進企業(yè)主流應用，不僅是Linux，還有Boss中間件、Mysql數(shù)據(jù)庫、EnterpriseDB數(shù)據(jù)庫等，而且還有各種應用軟件，包括：Open office辦公套件、Firefox瀏覽器、ERP、CRM等等。開源力量的加入也使得非常多的應用進入到微軟平臺上，在微軟的.Net平臺上也出現(xiàn)了大量的開源應用軟件。

　　互聯(lián)網(wǎng)最大的應用與技術(shù)就是搜索、軟件服務化(Software as a Service)。不管是通用搜索還是行業(yè)垂直搜索，不管是互聯(lián)網(wǎng)搜索還是企業(yè)搜索，都已經(jīng)不僅針對文本而且開始向音視頻搜索發(fā)展了。

　　最后不要忘了，由于人們對應用要求的提高，測試在這幾年顯得越來越重要了，測試工具與測試理論都有很大發(fā)展，這一點也值得關(guān)注。

手機軟件開發(fā)將與PC趨同

　　王權(quán)平

　　資深程序員，供職于威盛電子(中國)有限公司，從事GSM/GPRS芯片組的開發(fā)，主要工作包括協(xié)議軟件設計、開發(fā)與測試，以及智能手機平臺通信中間件的設計與開發(fā)。

　　2006年出現(xiàn)了很多叫好也叫座的手機產(chǎn)品，這些成功手機的背后，都明顯地揭示出了手機軟件開發(fā)技術(shù)的若干發(fā)展趨勢。2007年手機軟件技術(shù)將繼續(xù)迅速發(fā)展，無論單處理器平臺或是雙處理器平臺，網(wǎng)絡應用和多媒體應用都將是主要的開發(fā)方向，而C++和Java將是首選的開發(fā)語言。

　　未來，傳統(tǒng)的單處理器手機平臺仍將在低價手機和特色手機市場上保持不可替代的優(yōu)勢。其軟件通常都由芯片廠商和手機設計公司來提供，除了J2ME平臺外，缺乏開放和標準的API是其固有的缺陷。因此幾乎沒有來自第三方的原生的面向其處理器和編譯平臺優(yōu)化的軟件，用戶自行擴展的能力較差。展望未來，除了集成更多的應用軟件(如電子郵件、電子書和多媒體播放程序等)外，單處理器平臺上的軟件開發(fā)工作主要集中在新硬件模塊的驅(qū)動程序以及圖形用戶界面的創(chuàng)新和提高上。就開發(fā)語言而言，C和C++仍然是首選;在底層通信軟件尤其是協(xié)議棧的實現(xiàn)上，C語言仍將繼續(xù)居統(tǒng)治地位;當然在驅(qū)動程序中，匯編語言也是不可或缺的。單處理器平臺上第三方開發(fā)人員的開發(fā)空間在于J2ME平臺，但是各個解決方案對Java語言支撐能力的差異，使得Java程序很難達到真正的與平臺無關(guān)。不過，隨著硬件能力的與提高和Java虛擬機的改善，特別是硬件級Java加速和ARM平臺Java優(yōu)化指令等特性的引入，可以預料J2ME將會成為單處理解決方案的基礎軟件平臺。

　　雙處理器平臺由運行通信協(xié)議的基帶處理器和運行用戶界面程序的應用處理器組成，是智能手機的基礎平臺。未來智能手機平臺的軟件開發(fā)中，中間件和應用程序都有很大的發(fā)展空間和需求。中間件主要包括圖形庫和通信庫兩部分。圖形庫重點在于提供更加華麗和友善的用戶界面，增強用戶的操作體驗，據(jù)稱WinCE6.0即將提供Vista風格的界面;3D加速將是繼2D加速后的第二個亮點;另外，圖形庫也將重點支持硬件級的多媒體加速技術(shù)，從而支持包括移動音頻和視頻，特別是手機電視的應用。通信庫部分將重點在統(tǒng)一的框架內(nèi)整合各種廣域、局域乃至個域通信技術(shù)。應用程序部分，網(wǎng)絡應用將會是2007年的發(fā)展重點。就開發(fā)技術(shù)而言，J2ME在智能手機上的性能優(yōu)于單處理平臺，因此筆者看好基于J2ME平臺的手機游戲和網(wǎng)絡應用;而基于C++的網(wǎng)絡編程和多媒體編程仍將繼續(xù)是Symbian平臺、WinCE平臺，以及Linux上Qt平臺的的主要開發(fā)領域;另外PC平臺上的基礎軟件組件，如數(shù)據(jù)庫技術(shù)等，將逐漸移植到手機平臺上，提供其嵌入式的版本，以適應手機平臺的硬件和軟件限制。但是由于三大平臺存在的巨大差異，軟件的可移植性將成為一個重要的問題。

　　核心觀點

　　隨著中間件的加強，手機應用軟件開發(fā)將逐漸與PC趨同，將出現(xiàn)大量的個人軟件開發(fā)者和第三方軟件開發(fā)商，手機軟件產(chǎn)業(yè)勢必會有很大的發(fā)展。
注重測試需求 做好流程建設

　　戴金龍

　　注冊PMP,GB/GJB/ISO/CMMI內(nèi)審員。原嫦娥工程地面應用系統(tǒng)質(zhì)量組專家。歷任某外企測試技術(shù)經(jīng)理、項目經(jīng)理及運營經(jīng)理。對當代軟件測試理論及工程實踐有較好的領悟。

　　當前，測試作為一項職業(yè)吸引了越來越多的優(yōu)秀人才;測試作為控制軟件質(zhì)量的有效手段，融入到了越來越多企業(yè)高層的管理理念中;測試作為一門學科，獲得了前所未有的壯大。但在測試技術(shù)蓬勃發(fā)展的另一方面，測試行業(yè)也在迅速地積累著各種問題，在接下來的一年里某些隱藏的問題可能會表現(xiàn)得很顯著。

　　第一個問題是如何讓測試更有效地鍥入到不規(guī)范的軟件開發(fā)過程中。提出這個問題恐怕會有不少人大吃一驚：這類企業(yè)為什么不先規(guī)范軟件的開發(fā)過程呢?這是不是一個偽問題?其實，目前有不少軟件企業(yè)都處在這種狀態(tài)。但這些企業(yè)的管理層并不承認自己的開發(fā)過程不規(guī)范，反而認為這是一種靈活的、有個人特色的高效管理。這樣的氛圍造成軟件質(zhì)量低下自是意料中的事情。

　　即使企業(yè)管理層了解到測試是解決質(zhì)量問題的有效途徑，實施軟件測試也是需要代價的。目前的測試學科所提供的技術(shù)、流程、管理及方法論都是假設是在良好的(至少規(guī)范的)開發(fā)過程、管理氛圍及測試環(huán)境中實施的，并沒有提供在不規(guī)范軟件開發(fā)過程中做測試的解決方案，這樣就出現(xiàn)了所謂“理論”與“實踐”的偏差。解決的辦法有兩個:一種是變革企業(yè)文化，規(guī)范開發(fā)過程，建立測試所需的相關(guān)環(huán)境，從而實施規(guī)范、嚴格、有序的軟件測試;另一種就是拓展測試理論，針對不規(guī)范開發(fā)過程的特點，找到彌補、折衷的解決辦法。根據(jù)筆者對國內(nèi)軟件企業(yè)的了解，后者將是今后一段時間國內(nèi)軟件企業(yè)關(guān)注的熱點話題。

　　第二個問題是如何清晰地定義軟件測試需求，使測試工作目標明確、有的放矢。這個問題是以前的測試學科沒有回答清楚的，非常需要深入研究，它將會是今后若干年的研究熱點。可能有讀者會感到費解：測試需求不就是軟件需求嗎?其實不然。軟件需求用于指導后續(xù)設計的展開。而測試需求則是直接源自于客戶的質(zhì)量要求。測試需求的源頭非常繁雜，如何刪繁就簡，拿捏得當，目前沒有現(xiàn)成的方法，仍需要做大量理論研究和實踐探索。

　　第三個問題是如何規(guī)范軟件測試流程以持續(xù)提高測試團隊的績效。這個問題目前已有一些答案。如“制定測試計劃-設計測試-執(zhí)行測試-測試分析與總結(jié)”等等。從執(zhí)行的角度而言，這類粗略的階段劃分或許已經(jīng)夠用，沒有進一步研究的必要。但對于控制測試過程而言，對于測試服務型企業(yè)通過CMMI認證而言，尤其是對于改進軟件測試過程而言，幾乎是沒有幫助的。

　　核心觀點

　　在測試技術(shù)蓬勃發(fā)展的另一方面，測試行業(yè)也在迅速地積累著各種問題。
網(wǎng)絡安全軟件開發(fā)趨勢

　　李洋

　　中國科學院計算技術(shù)研究所博士，資深程序員。從事計算機網(wǎng)絡信息安全領域的研發(fā)工作，曾參與“國家自然科學基金”、“國家863重大專項”、“國家242信息安全計劃”、“國家973計劃”等多項國家重點項目、信息安全系統(tǒng)和企業(yè)信息系統(tǒng)的研發(fā)工作。

　　從當前國際上安全產(chǎn)品的研發(fā)情況來看，以防火墻和IDS為主導，以密碼技術(shù)為基礎的產(chǎn)品已經(jīng)取得了飛速的發(fā)展，并在實際應用中發(fā)揮了很大的效應，使得網(wǎng)絡安全產(chǎn)品的研究及應用工作不斷向前推進。2007年，對于網(wǎng)絡安全軟件開發(fā)人員來說，如下幾項新的技術(shù)值得大家期待：

　　1.基于開源軟件的開發(fā)技術(shù)

　　以Linux為代表的開源軟件及其開發(fā)模式已經(jīng)深入人心。網(wǎng)絡安全軟件中最為著名的就是輕量級的入侵檢測系統(tǒng)Snort，它已成為眾多安全廠商和科研院校研發(fā)的重要參照物。縱觀網(wǎng)絡安全軟件的發(fā)展趨勢，以優(yōu)秀的開源軟件為基礎進行研發(fā)已成為網(wǎng)絡安全界的首選技術(shù)途徑。

　　2.嵌入式安全開發(fā)技術(shù)

　　隨著移動計算和無線網(wǎng)絡的普及，以及普適計算概念的提出和應用，移動、無線和無處不在的計算已成為新世紀IT的絕對熱點。這些需求都要求在上述條件下進行信息處理和計算，因而以J2ME為代表的嵌入式開發(fā)技術(shù)也成為很大看點。

　　尤為值得關(guān)注的是，人們在獲得上述便利的同時，也在經(jīng)受著自己的隱密數(shù)據(jù)隨時有可能被竊取和破壞的威脅。那么，如何在當前的嵌入式技術(shù)當中綜合采用密碼理論、PKI基礎架構(gòu)以及其他信息安全技術(shù)來提高嵌入式系統(tǒng)的安全性，為未來輕量級的嵌入式計算保駕護航，也必將成為網(wǎng)絡安全工作者和軟件開發(fā)人員關(guān)注的一個熱點問題。

　　3.高性能計算服務開發(fā)技術(shù)

　　網(wǎng)絡帶寬的日益增長和單機處理能力已經(jīng)極不對稱。諸如早期的防火墻、IDS等都已經(jīng)不能滿足現(xiàn)實的需求。

　　因此，采用并行處理技術(shù)以及研究和開發(fā)高性能網(wǎng)絡協(xié)議處理技術(shù)來緩解上述問題帶來的壓力是不錯的選擇。并且，隨著64位計算的到來，如何在該硬件平臺上進行并行開發(fā)、編譯等，都是網(wǎng)絡安全軟件研發(fā)人員期待和需要解決的問題。值得期待的是，當今的UTM(統(tǒng)一威脅管理)技術(shù)試圖在上述各方面取得突破，建立一套高性能、高可靠、完善的網(wǎng)絡威脅防范機制，我們拭目以待。

　　4.可信編程技術(shù)

　　對于安全要求較高的場合，可信計算平臺能夠為用戶提供更加有效的安全防護。而據(jù)統(tǒng)計，在網(wǎng)絡安全領域，80%以上的網(wǎng)絡威脅和漏洞來源于系統(tǒng)自身的Bug，而這些Bug則來源于設計思路以及程序?qū)崿F(xiàn)。那么，在積極防御外來攻擊的同時，提高網(wǎng)絡安全軟件研發(fā)人員自身編程的可靠性，軟件開發(fā)平臺在軟件編程中可能出現(xiàn)漏洞(比如最常見的緩沖區(qū)溢出等)的地方進行提醒和標注，就可以極大地減少程序?qū)崿F(xiàn)的硬傷。我們不妨借用可信計算的名號稱其為可信編程技術(shù)，相信也將是軟件研發(fā)人員關(guān)心的技術(shù)，不但可以提高軟件可靠性，更能避免用于查找大量重復出現(xiàn)的系統(tǒng)Bug所需的人力和物力。

　　核心觀點

　　基于開源軟件的開發(fā)技術(shù)、嵌入式安全開發(fā)技術(shù)、高性能計算服務開發(fā)技術(shù)、可信編程技術(shù)將是未來網(wǎng)絡安全軟件開發(fā)的四大趨勢。
降低開發(fā)復雜性

　　程勇

　　Java開放源碼軟件咨詢顧問，Huihoo.org開源軟件社區(qū)共同創(chuàng)始人，北京中流科技有限公司CTO。

　　Java技術(shù)的發(fā)展已經(jīng)走過11個年頭，在企業(yè)級應用開發(fā)領域占領主導地位的JavaEE技術(shù)也伴隨著Java自身的演變，在2006年發(fā)生了許多新的變遷。 隨著系統(tǒng)開發(fā)復雜度的上升，需要一種更好的解決方案來分解系統(tǒng)的復雜，并簡化應用開發(fā)的過程。基于眾多的因素，選擇企業(yè)應用開發(fā)的架構(gòu)平臺時都需要考慮很多約束，它必須最小化對應用開發(fā)本身的影響。因此，一個好的技術(shù)平臺和應用框架應該具備如下特性：提供應用開發(fā)的一致性;提供高端和低端特性;提供管理逐步增長的應用系統(tǒng)的具體方法;為高級開發(fā)人員提供指導;能夠使不同框架的特性和優(yōu)點集成到一起進行工作;能夠快速進行應用開發(fā)，保證產(chǎn)品按市場的需求發(fā)布;能夠降低項目開發(fā)的風險，提升企業(yè)的投資回報。

　　由此，我們不難發(fā)現(xiàn)，現(xiàn)在大量涌現(xiàn)的新技術(shù)體系和框架，都是在朝著簡化應用開發(fā)的方向而努力，這些技術(shù)包括：

　　● AJAX AJAX并非一種編程語言，它是使用XHTML或HTML，JavaScript以及XML來建立互動網(wǎng)絡應用程序的一種模式。

　　● 腳本語言 Ruby的發(fā)展，使得在Java 語言中使用動態(tài)機制成為可能，使用Ruby的動態(tài)機制，用戶能夠改變腳本類的定義。這些Ruby對象允許直接使用方法管理它的狀態(tài)和行為。

　　● 應用框架 以Spring為代表JavaEE應用框架是在JavaEE技術(shù)體系之上快速構(gòu)建應用的支撐平臺，應用框架通過整合的技術(shù)架構(gòu)，將眾多的優(yōu)秀開源框架融合在一起，為應用開發(fā)提供了一個完整的技術(shù)解決方案。

　　● JavaEE 5.0 JavaEE 5.0 是新一代的Java EE技術(shù)規(guī)范，其中包括JSF、EJB 3.0等十多項全新的技術(shù)體系。它的多項新特性為JavaEE應用開發(fā)帶來了更多的便利。

　　核心觀點

　　選擇企業(yè)應用開發(fā)的架構(gòu)平臺時都需要考慮很多約束，它必須最小化對應用開發(fā)本身的影響。
工作流: 國內(nèi)國際兩極分化

　　胡長城

　　網(wǎng)名“銀狐999”，就職于TIBCO。國內(nèi)J2EE開源應用的支持者，有過6年的J2EE應用和產(chǎn)品開發(fā)及架構(gòu)經(jīng)驗，是huihoo開源組織的成員。

　　與眾多新技術(shù)相比，工作流的知名度也許會小一些，但工作流也一直處于不斷創(chuàng)新之中。所不同的是，在這個領域新技術(shù)的應用是被隱藏在應用理念和架構(gòu)體系之下的。對于工作流的發(fā)展趨勢，這里分開兩條線來闡述。

　　第一條線就是單純從工作流技術(shù)應用的發(fā)展趨勢來探索。在這方面國際上應用水平已經(jīng)遠超越國內(nèi)，這就是這兩年的龍卷風—— BPM(Business Process Management)。很多國際化的大企業(yè)已經(jīng)把BPM定位于一種解決方案。在這一整套解決方案中，工作流技術(shù)已經(jīng)成為流程的服務，圍繞這個服務，有各種模塊和應用相輔助。BPM解決方案儼然成為一種參考架構(gòu): 一方面是以SOA為主導的技術(shù)架構(gòu)，另一方面則包含了一整套的服務。

　　實際上，BPM的發(fā)展是很多年的流程和工作流發(fā)展的必然結(jié)果。在這個領域的供應商有的由早期的工作流廠商發(fā)展而來，如Staffware公司(現(xiàn)已經(jīng)被Tibco收購); 有的由早期的EAI提供商發(fā)展而來，如Tibco; 有的由應用服務器提供商發(fā)展而來，如BEA等。在它們的BPM藍圖中有很多相似之處，比如以BPEL規(guī)范闡述Business Process。

　　第二條線從國內(nèi)工作流應用和技術(shù)趨勢來分析。這兩年已經(jīng)有部分國內(nèi)企業(yè)采用EAI或BPM技術(shù)進行系統(tǒng)整合方面的應用，但大規(guī)模地采用BPM解決方案還是很少，不過這是一個趨勢。國內(nèi)目前工作流技術(shù)的應用還主要以“辦公或業(yè)務流程的人工信息化處理”為主，畢竟國內(nèi)企業(yè)和政府的一個很大特征是“以人為主”，而不是“以制度化為主”。在一些集團性的企業(yè)和跨省市集中管理性的系統(tǒng)中，分布式流程應用逐漸顯現(xiàn)出來。而伴隨著國內(nèi)幾年來工作流市場的積淀，早期的一些工作流廠商在尋求“流程分析和監(jiān)控”方面的突破，而這方面的客戶需求也日漸多起來。但短時間內(nèi)，很難由國內(nèi)工作流廠商自己取得一些突破，發(fā)展起B(yǎng)PM產(chǎn)品。

　　上述這兩條發(fā)展線也代表了兩極分化。但第一條戰(zhàn)線的BPM 解決方案肯定是未來大規(guī)模應用的趨勢，雖然短時間內(nèi)對國內(nèi)工作流應用市場沖擊很小，但是政府和國內(nèi)軟件廠商卻不應該小覷這個發(fā)展趨勢。

　　核心觀點

　　國際大廠商對工作流的研究重點是把它作為BPM的一部分，為流程服務，而國內(nèi)還主要以“辦公或業(yè)務流程的人工信息化處理”為主，短時間內(nèi)，國內(nèi)還很難有所突破，推出自己的BPM產(chǎn)品。
Java走上開源之路

　　孟冬冬

　　中科軟科技股份有限公司金融保險部系統(tǒng)分析師、軟件架構(gòu)師。9年軟件設計開發(fā)和6年項目管理經(jīng)驗,精通基于J2EE架構(gòu)的企業(yè)應用系統(tǒng)開發(fā)技術(shù)。先后在普天、中軟等多家軟件公司任系統(tǒng)分析員、軟件架構(gòu)師及項目經(jīng)理。

　　2006年11月13日，Sun公司宣布將Java轉(zhuǎn)為開源。預計到2007年3月份，除了一部分所有權(quán)不屬于Sun的源代碼之外，幾乎全部Java技術(shù)的源代碼都將按照GNU GPL自由軟件許可授權(quán)協(xié)議公開。Java在和.net經(jīng)歷了兩年的競爭后已顯疲態(tài)，相比5歲的.net以及新生的動態(tài)語言Ruby，11歲的Java已略顯復雜臃腫，甚至在網(wǎng)上還有“Java將死”的論調(diào)。Sun選擇在此時將Java開源，不管是否是Sun迫不得已、在日薄西山前的最后博弈，但影響之深遠卻絕對不可小視。它引發(fā)的“蝴蝶效應”無疑會使Java技術(shù)的生命力更強，走得更遠，更可贏得在開發(fā)語言競爭中起決定作用的更多程序員的芳心，相信未來Java領域?qū)⒊霈F(xiàn)更多令人驚奇的開源產(chǎn)品。

　　另外Sun還趕在圣誕節(jié)前發(fā)布了JDK的6.0 Release版本。對JDK而言，“成敗皆在應用服務器廠商”。市場占用率最大的應用服務器Weblogic8、WebSphere5成就了1.4，但也限制了JDK5的普及。在JDK5還沒有用熱時，JDK6就來了。不過，這倒也是好事，可以直接跳過JDK 5去研究JDK6的應用了。

　　JDK6對筆者的最大吸引力是它在JVM性能上的提升和對XML和Web服務的支持。性能方面，無論是運行時分析功能還是用戶對性能情況的反饋，尤其是在Swing方面，JDK6對JIT都有了卓有成效的提升。

　　一直以來，相對于微軟的.net，Java對Web Services的支持復雜得難以接受，也因此產(chǎn)生了優(yōu)秀的Axis和XFire框架。而在JDK6下，Java程序員也能享受到這種待遇了，不用針對Web服務另外加入額外的工具，不使用任何框架也能寫出Web Services程序了。JDK6中固化了XML、Web Services的標準，如StAX、JAXB2、JSR181等。JDK 6在語法方面沒有太大改變，最明顯的就是添加了對腳本語言的支持，如JavaScript、Ruby、PHP。JDK6 中實現(xiàn)了JSR 223，提供了讓腳本語言來訪問Java 內(nèi)部的方法。它可以在運行的時候找到腳本引擎，然后調(diào)用這個引擎去執(zhí)行腳本，這個腳本API 允許程序員為腳本語言提供Java 支持。

　　另外在JDK6中內(nèi)置實現(xiàn)了JDBC4支持的Derby數(shù)據(jù)庫，為測試和小型系統(tǒng)的發(fā)布提供了便利條件。最后，JDK 6 中對內(nèi)存泄漏增強了分析以及診斷能力，當遇到Java.lang.OutOfMemory 異常的時候，可以得到一個完整的堆棧信息，并且當堆已滿時，會產(chǎn)生一個日志文件來記錄這個致命錯誤。

　　如果說談到JDK 6更多的是對未來的一種希望的話，Java full-stack(Java full-stack，意指集成了全部所需功能的Java快速開發(fā)框架)則是一種已經(jīng)可以見到的東西。

　　很長時間以來，作為一個Java程序員，幸福的是從表現(xiàn)層到持久層都有眾多的框架可供選擇，痛苦的是在這些框架中挑選出適合自己的框架，而且還要付出將不同層次的框架粘合在一起的設計成本和時間，而架構(gòu)的穩(wěn)定性和實用性則往往取決于架構(gòu)師的設計理念和經(jīng)驗。Ruby on Rails的流行再一次證明了在軟件開發(fā)領域“簡約至上”的真理，它使得諸多Java開發(fā)人員把目光放到了“提供最方便好用的Java full-stack框架”上面，因此Java開源社區(qū)如雨后春筍般地出現(xiàn)了一批又一批的full-stack框架，如Appfuse、SpringSide、JBoss　Seam、RIFE、Grails、Trails、Rife等。Java領域也從此開始走向full-stack的快速開發(fā)道路。筆者就非常喜歡國外的JBoss Seam和國內(nèi)的SpringSide。

　　核心觀點

　　Sun選擇在2006年歲末將Java開源，不管是不是Sun的最后博弈，其影響絕對不可估量。從此以后，全世界所有的開發(fā)人員都可以對Java源代碼進行修改、優(yōu)化、除錯，同時Java也將變?yōu)橐环N真正免費的技術(shù)。
網(wǎng)絡技術(shù)融入軟件平臺

　　智雨青

　　北京理工大學計算機碩士，8年的電信行業(yè)軟件開發(fā)經(jīng)歷，曾在億陽信通、北京朗新科技公司供職，中國聯(lián)通第一版CRM的主要設計與開發(fā)者，參與聯(lián)通多個省級OSS/BSS系統(tǒng)的研發(fā)與實施。

　　2006年年初有專家曾經(jīng)說過，今年軟件發(fā)展技術(shù)很有可能進入到一個無熱點時代。的確，我們非常熟悉的網(wǎng)絡應用技術(shù)、搜索技術(shù)、應用行業(yè)軟件技術(shù)等等，已經(jīng)發(fā)展到一個非常成熟的階段，每一次升級能帶給我們的驚喜越來越少。不過，2006年雖沒大的“翻天覆地”，卻仍涌現(xiàn)出了不少亮點，而這些亮點極有可能會決定今后兩三年的應用潮流。

　　1. Web2.0

　　Web2.0是2003年之后互聯(lián)網(wǎng)的熱門概念之一。Web2.0技術(shù)主要包括: 博客、RSS、百科全書(Wiki)、網(wǎng)摘 、社會網(wǎng)絡(SNS)、P2P、即時信息(IM)等。由于這些技術(shù)有不同程度的網(wǎng)絡營銷價值，因此Web2.0在網(wǎng)絡營銷中的應用已經(jīng)成為熱門領域。盡管對于究竟什么是Web 2.0還有很多的討論，但有一點可以肯定，Web2.0是以人為核心線索的網(wǎng)。提供更方便用戶“織網(wǎng)”的工具，鼓勵提供內(nèi)容;根據(jù)用戶在互聯(lián)網(wǎng)上留下的痕跡，組織瀏覽的線索，提供相關(guān)的服務，給用戶創(chuàng)造新的價值，給整個互聯(lián)網(wǎng)帶來新的價值，才是Web2.0商業(yè)之道。

　　2. 嵌入式移動開發(fā)技術(shù)

　　嵌入式開發(fā)技術(shù)的發(fā)展推動了嵌入式操作系統(tǒng)跨越式發(fā)展，也成為現(xiàn)代及未來移動技術(shù)發(fā)展的重要保障，以微軟Windows CE系列、PalmSource公司PalmOS、Nokia公司Symbian等為代表的嵌入式操作系統(tǒng)已在各種移動設備上大量應用。尤為值得一提的是作為行業(yè)領先者的微軟2006年5月發(fā)布了Windows CE 6，憑借重新設計的操作系統(tǒng)(OS)內(nèi)核架構(gòu)以及增強的并發(fā)處理能力和新集成的工具集，提供了一個更加集成化的嵌入式開發(fā)環(huán)境，允許開發(fā)者將大量更為復雜的應用集成到比以往更加智能的設備中，從而提供高性能的多媒體、Web服務和無線網(wǎng)絡連接應用。

　　3. 中間件技術(shù)

　　隨著Internet的快速發(fā)展，中間件的定義正在走出其狹義空間，逐步形成更為廣義的內(nèi)涵。其發(fā)展主要呈現(xiàn)出兩方面的技術(shù)趨勢: 一方面，支撐軟件越來越多地向運行層滲透，提供更強的對系統(tǒng)實現(xiàn)的支持;另一方面，中間件也開始考慮對高層設計和運行部署等開發(fā)工作的支持。而這兩個技術(shù)趨勢從本質(zhì)上說正是源于軟件體系結(jié)構(gòu)和軟件構(gòu)件等技術(shù)的發(fā)展和應用。從廣義的角度看，中間件代表了處于系統(tǒng)軟件和應用軟件之間的中間層次的軟件，其主要目的是對應用軟件的開發(fā)和運行提供更為直接和高效的支撐。中間件技術(shù)已成為軟件技術(shù)的研究熱點。

　　4. 即時通信技術(shù)

　　現(xiàn)在即時通信市場不再只有一種聲音，騰訊、微軟、IBM、Avaya、Skype、中國移動紛紛將觸角伸向了這塊市場，誘惑這些大佬們的是即時通信市場的爆發(fā)式增長和隨之而來的豐厚利潤。而移動即時通信作為一項數(shù)據(jù)業(yè)務更是被視為未來3G時代的一大“金礦”。待3G牌照發(fā)放，捆綁于移動即時通信之上的包括彩信、彩鈴、圖片、博客、手機電視等應用都會得到充分發(fā)掘。

　　5. 下一代搜索技術(shù)

　　搜索引擎發(fā)展到今天已經(jīng)增添了很多新的特征，其特色主要體現(xiàn)在“概念集群”和“動態(tài)分類”，它通過分析網(wǎng)頁之間的關(guān)聯(lián)，建立一種類似人的思維的更智能化的概念分類方式，通過模仿人的思維模式，對要查找的概念進行關(guān)鍵字聯(lián)想和分類。除了概念集群和動態(tài)分類，新一代搜索引擎還更多地體現(xiàn)在個性化方面，這在以前的搜索里是很難做到的。概念集群又分為大眾化概念集群和個性化概念集群，通過搜索記錄，下一代搜索技術(shù)能夠幫助每個人建立自己個性化的搜索功能，而且信息是可以分享的。

　　核心觀點

　　基于新一代網(wǎng)絡技術(shù)的各種應用的融合是大勢所趨，網(wǎng)絡新技術(shù)與軟件新技術(shù)的相互促進將為人類創(chuàng)造一個更為燦爛的IT世界。
互聯(lián)網(wǎng)將更社區(qū)化

　　康威

　　新華社高級工程師，Lotus技術(shù)專家。曾任后勤指揮學院教員，獲全軍科技進步二等獎一次、三等獎四次，2002年7月轉(zhuǎn)業(yè)到新華社技術(shù)局，是新華社多媒體數(shù)據(jù)庫系統(tǒng)核心成員。

　　互聯(lián)網(wǎng)的飛速發(fā)展成就了搜索引擎今天的地位，同時也推動了網(wǎng)絡視頻的發(fā)展，而Web 2.0又推動了全民的參與性、主動性和互動性，密切了人與人之間的聯(lián)系，由此形成了線上與線下互動的各種模式，反過來又推動了互聯(lián)網(wǎng)的壯大。

　　1. 互聯(lián)網(wǎng)搜索

　　2006年的中國互聯(lián)網(wǎng)搜索依然是百度、Google雙頭壟斷，百度的勢頭略有提升，垂直搜索成為耀眼的明星，移動搜索也有了一定的發(fā)展。未來搜索引擎將會更精準化、智能化、人性化、垂直化和社區(qū)化，會以更快的速度為計算機和其他智能終端用戶服務。

　　筆者認為，2007年的中國搜索市場將是一個分水嶺，其競爭將達到前所從未有的規(guī)模，雅虎、搜狐磨刀霍霍，微軟臥薪嘗膽，不過雙頭壟斷局面不會改變，走向國際化的百度依然會是龍頭老大，而能滿足大家特定需求、具有差異化特征的垂直搜索和生活搜索是未來的市場增長點，其搜索商業(yè)模式也會更加豐富。2007年，搜索行業(yè)的發(fā)展必將進一步促進互聯(lián)網(wǎng)商業(yè)模式的創(chuàng)新以及相關(guān)技術(shù)的提高，成為互聯(lián)網(wǎng)發(fā)展的重要支柱。

　　2. P2P流媒體

　　P2P流媒體行業(yè)一直都被認為是下一個可能產(chǎn)生井噴效應的互聯(lián)網(wǎng)領域。P2P體現(xiàn)了真正的“互聯(lián)網(wǎng)精神”——我為人人，人人為我，但市場是理智而殘酷的，在短暫的狂歡過后，P2P流媒體行業(yè)所面臨的問題與挑戰(zhàn)也逐步顯露，商業(yè)模式不清晰、盜版泛濫、國家政策不明朗等問題不得不令人深思。

　　網(wǎng)絡視頻是中國未來幾年的熱點，目前只有兩個方向可以賺大錢: 流媒體巨頭與內(nèi)容大鱷的聯(lián)姻和微視頻，依靠盜版的視頻直播與共享只可能是小富即安。只有少數(shù)幾家有資金、有技術(shù)、有影響的流媒體廠商(包括門戶網(wǎng)站)才能獲得內(nèi)容大鱷的青睞，留給眾多中小型流媒體廠商的只能是微視頻。

　　微視頻是指短則30秒，長則不超過20分鐘，內(nèi)容廣泛，視頻形態(tài)多樣，涵蓋小電影、紀錄短片、DV短片、視頻剪輯、廣告片段等，可通過PC、手機、DV、DC、MP4等多種視頻終端攝錄或播放的視頻短片的統(tǒng)稱。短、快、精、大眾參與性、隨時隨地是微視頻的最大特點。微視頻規(guī)避了版權(quán)的威脅，降低了帶寬的成本，易形成社區(qū)，具有一定的贏利模式，隨著網(wǎng)絡融合的加快，3G和寬帶的發(fā)展，只要走專業(yè)化、特色化、差異化道路，一定大有“錢”途。

　　3. 互聯(lián)網(wǎng)社區(qū)化

　　互聯(lián)網(wǎng)社區(qū)化有三種形式: 情感的歸屬與宣泄，人們可以不受空間限制地自由溝通、發(fā)表見解、結(jié)交朋友、宣泄情感; 線上與線下的互動，互聯(lián)網(wǎng)使得人們能夠以最快捷的方式廣結(jié)交天下朋友，很多社區(qū)型網(wǎng)站都定期舉行各種線下活動; 智慧和經(jīng)驗的共享，充分體現(xiàn)了P2P精神，人們信息需求的滿足，需要越來越多地依靠其他用戶的力量來滿足，社區(qū)化的搜索是最好的例子。

　　社區(qū)化的搜索能更好地滿足用戶的需求，也可以更好地發(fā)揮用戶的價值。首先他們會享受其他用戶貢獻的智慧，同時他們在自己使用的過程中幾乎不會察覺到在給整個互聯(lián)網(wǎng)做出貢獻。2006年7月13日正式推出以“搜索+博客”為理念的產(chǎn)品——百度空間，這是百度繼貼吧、知道、百科后推出的第四個社區(qū)類產(chǎn)品，具備個人空間、個人門戶等基本特征。這一產(chǎn)品的推出，不僅進一步深化了百度的社區(qū)化搜索服務，并憑借其在中國互聯(lián)網(wǎng)的巨大影響力，進一步推動了中國互聯(lián)網(wǎng)社區(qū)化發(fā)展的進程。

　　核心觀點

　　未來的互聯(lián)網(wǎng)將更能體現(xiàn)P2P精神，將更視頻化和社區(qū)化(當然文字仍會像傳統(tǒng)報紙一樣不可替代)，同時，在互聯(lián)網(wǎng)的進化過程中，搜索技術(shù)將會改變?nèi)藗兊纳盍晳T。
應用推動軟件技術(shù)創(chuàng)新

　　張濤

　　鄭州航空工業(yè)管理學院畢業(yè)，一直從事計算機應用軟件的分析、設計、開發(fā)以及項目的實施，主持開發(fā)的軟件包括河南省縣級供電企業(yè)營銷MIS、河南省在建水利工程移民資金輔助管理系統(tǒng)。

　　今天的企業(yè)信息化面臨著更加具體的問題，比如終端數(shù)據(jù)如何快速采集傳輸; 缺乏軟件應用標準，行業(yè)應用深度不夠; 系統(tǒng)間交互性差、各自為戰(zhàn)，資源共享程度不高; 系統(tǒng)具有一定規(guī)模后，維護、升級困難。由于企業(yè)在這些方面的需求非常迫切，未來各個軟硬件廠商必定在這方面有所作為，基于此，筆者以為2007年以下這些技術(shù)將會有比較大的突破。

　　1. 數(shù)據(jù)采集自動化、便捷化

　　隨著MCU(多點控制單元)應用范圍的不斷擴大，以往的各類硬件終端，比如電力、燃氣、水等終端數(shù)據(jù)采集或檢測設備，已經(jīng)逐步從簡單的計數(shù)、指示功能，向智能數(shù)據(jù)采集終端轉(zhuǎn)變，而且傳統(tǒng)裝置經(jīng)過簡單的改造，也可實現(xiàn)終端數(shù)據(jù)的采集和存儲，這不僅讓人從數(shù)據(jù)采集的工作中解放出來，更可以通過相對廉價的手段解決采用人工采集數(shù)據(jù)所帶來的一些問題。

　　正是基于這種前提，微軟Office辦公套件的新成員InfoPath讓我們眼前一亮，借助它可以快速、方便地設計出具有超強表現(xiàn)力的電子憑單，以滿足信息采集、企業(yè)內(nèi)部和企業(yè)之間的信息傳遞。更令人稱道的是，它不僅可以使用傳統(tǒng)的數(shù)據(jù)庫作為數(shù)據(jù)源，更可以使用XML作為數(shù)據(jù)的存儲格式，讓不同系統(tǒng)之間的數(shù)據(jù)交互更加暢通有效。

　　2. 軟件插件化、框架化

　　大凡用過Eclipse的程序員都會被它的靈活和開放性所打動，而目前部分行業(yè)欠缺軟件應用標準就是擺在開發(fā)商面前的諸多問題之一。類似權(quán)限管理、自定義查詢、自定義報表、組織業(yè)務功能等應用系統(tǒng)必備的功能，完全可以通過抽象形成框架，提高代碼重用度和穩(wěn)定性。同時，采用軟件框架進行系統(tǒng)的開發(fā)，不僅可以讓系統(tǒng)分析和設計人員把主要精力放到業(yè)務模型的建立上，縮短項目周期，更可以讓系統(tǒng)用戶和開發(fā)商體會到系統(tǒng)穩(wěn)定、維護方便、升級簡單的方便。

　　在此必須要提的是Java，如果說Java的誕生是為了網(wǎng)絡，那么可以說它已經(jīng)不辱使命，而且在推動著網(wǎng)絡技術(shù)的發(fā)展，開源性使得它的追隨者們努力工作，Struts、Spring等優(yōu)秀的、基于框架的作品紛至沓來，逐步讓我們脫離繁雜的技術(shù)旋渦，把時間和精力投入到業(yè)務分析領域，使軟件的插件化、框架化不再是海市蜃樓。

　　3. SOA

　　近幾年SOA(Service-Oriented Architecture，面向服務架構(gòu))概念的提出，使得用戶和軟件開發(fā)商對系統(tǒng)建設有了新的認識。筆者認為SOA不僅是架構(gòu)模型，更是一種應用思想的體現(xiàn)。對于軟件功能粒度的劃分、軟件功能的部署、系統(tǒng)驅(qū)動模式等都會由于SOA而產(chǎn)生較大的影響。

　　企業(yè)通過應用SOA，不僅可以在成本沒有太大增幅的條件下，讓用戶使用已經(jīng)成熟的組件增強B2B的有效性，還可以讓開發(fā)商最大限度地復用代碼，把軟件產(chǎn)品變成真正的服務。此外，SOA的實施更可以加速行業(yè)標準的制訂和執(zhí)行，因為只有大家遵循同樣的標準和接口，才可能營造出業(yè)務共享和跨系統(tǒng)業(yè)務交互的良好氛圍。

　　4. 虛擬軟件

　　有時一些系統(tǒng)尤其是比較老的，對OS或DBMS有特定要求的系統(tǒng)，或系統(tǒng)在兼容性方面與新版本有差距，這時虛擬機就是最好的選擇，不僅可以節(jié)省用戶的硬件資源減少維護和管理成本，更可以讓原有應用正常運行，為應用系統(tǒng)的升級換代贏得時間。與VMWore相比，微軟的Virtual PC也在緊追不舍，筆者認為盡管較VMWare還有一定距離，但是無論產(chǎn)品孰優(yōu)孰劣，最終受益的還是用戶。

　　核心觀點

　　行業(yè)特點決定行業(yè)應用，行業(yè)應用需要軟件相關(guān)技術(shù)手段提供支持，而行業(yè)應用又會引發(fā)技術(shù)的創(chuàng)新。

其實，Struts 1.x在此部分已經(jīng)做得相當不錯了。它極大地簡化了我們程序員在做國際化時所需的工作，例如，如果您要輸出一條國際化的信息，只需在代碼包中加入FILE-NAME_xx_XX.properties（其中FILE-NAME為默認資源文件的文件名），然后在struts-config.xml中指明其路徑，再在頁面用<bean:message>標志輸出即可。

不過，所謂“沒有最好，只有更好”。Struts 2.0并沒有在這部分止步，而是在原有的簡單易用的基礎上，將其做得更靈活、更強大。

國際化Hello World

下面讓我們看一個例子——HelloWorld。這個例子演示如何根據(jù)用戶瀏覽器的設置輸出相應的HelloWorld。

1. 在Eclipse創(chuàng)建工程配置開發(fā)和運行環(huán)境（如果對這個步驟有問題，可以參考我早前的文章《為Struts 2.0做好準備》）。
   
2. 在src文件夾中加入struts.properties文件，內(nèi)容如下：
   
   struts.custom.i18n.resources=globalMessages

   Struts 2.0有兩個配置文件，struts.xml和struts.properties都是放在WEB-INF/classes/下。 struts.xml用于應用程序相關(guān)的配置 struts.properties用于Struts 2.0的運行時（Runtime）的配置

3. 在src文件夾中加入globalMessages_en_US.properties文件，內(nèi)容如下：
   
   HelloWorld=Hello World!
4. 在src文件夾中加入globalMessages_zh_CN.properties文件，內(nèi)容如下：
   
   HelloWorld=你好，世界！

   在此想和大家分享一個不錯的編寫properties文件的Eclipse插件（plugin），有了它我們在編輯一些簡體中文、繁體中文等Unicode文本時，就不必再使用native2ascii編碼了。您可以通過Eclipse中的軟件升級（Software Update）安裝此插件，步驟如下： 1、展開Eclipse的Help菜單，將鼠標移到Software Update子項，在出現(xiàn)的子菜單中點擊Find and Install； 2、在Install/Update對話框中選擇Search for new features to install，點擊Next； 3、在Install對話框中點擊New Remote Site； 4、在New Update Site對話框的Name填入“PropEdit”或其它任意非空字符串，在URL中填入http://propedit.sourceforge.jp/eclipse/updates/； 5、在Site to include to search列表中，除上一步加入的site外的其它選項去掉，點擊Finsih； 6、在彈出的Updates對話框中的Select the features to install列表中將所有結(jié)尾為“3.1.x”的選項去掉（適用于Eclipse 3.2版本的朋友）； 7、點擊Finish關(guān)閉對話框； 8、在下載后，同意安裝，再按提示重啟Eclipse，在工具條看到形似vi的按鈕表示安裝成功，插件可用。此時，Eclpise中所有properties文件的文件名前有綠色的P的圖標作為標識。

5. 在WebContent文件夾下加入HelloWorl.jsp文件，內(nèi)容如下：
   
   <%@ page ?contentType="text/html; charset=UTF-8"%>
   <%@taglib prefix="s" uri="/struts-tags"%>
   <html>
   <head>
   ? ? <title>Hello World</title>
   </head>
   <body>
   ? ? <h2><s:text name="HelloWorld"/></h2>
   ? ? <h2><s:property value="%{getText('HelloWorld')}"/></h2>
   </body>
   </html>
6. 發(fā)布運行應用程序，在瀏覽器地址欄中輸入http://localhost:8080/Struts2_i18n/HelloWorld.jsp ，出現(xiàn)圖1所示頁面。
   
   圖1 中文輸出
7. 將瀏覽器的默認語言改為“英語（美國）”，刷新頁面，出現(xiàn)圖2所示頁面。
   
   圖2 英文輸出

資源文件查找順序

之所以說Struts 2.0的國際化更靈活是因為它可以能根據(jù)不同需要配置和獲取資源（properties）文件。在Struts 2.0中有下面幾種方法：

1. 使用全局的資源文件，方法如上例所示。這適用于遍布于整個應用程序的國際化字符串，它們在不同的包（package）中被引用，如一些比較共用的出錯提示；
2. 使用包范圍內(nèi)的資源文件。做法是在包的根目錄下新建名的package.properties和package_xx_XX.properties文件。這就適用于在包中不同類訪問的資源；
3. 使用Action范圍的資源文件。做法為Action的包下新建文件名（除文件擴展名外）與Action類名同樣的資源文件。它只能在該Action中訪問。如此一來，我們就可以在不同的Action里使用相同的properties名表示不同的值。例如，在ActonOne中title為“動作一”，而同樣用title在ActionTwo表示“動作二”，節(jié)省一些命名工夫；
4. 使用<s:i18n>標志訪問特定路徑的properties文件。使用方法請參考我早前的文章《常用的Struts 2.0的標志（Tag）介紹》。在您使用這一方法時，請注意<s:i18n>標志的范圍。在<s:i18n name="xxxxx">到</s:i18n>之間，所有的國際化字符串都會在名為xxxxx資源文件查找，如果找不到，Struts 2.0就會輸出默認值（國際化字符串的名字）。

上面我列舉了四種配置和訪問資源的方法，它們的范圍分別是從大到小，而Struts 2.0在查找國際化字符串所遵循的是特定的順序，如圖3所示：

假設我們在某個ChildAction中調(diào)用了getText("user.title")，Struts 2.0的將會執(zhí)行以下的操作：

1. 查找ChildAction_xx_XX.properties文件或ChildAction.properties；
2. 查找ChildAction實現(xiàn)的接口，查找與接口同名的資源文件MyInterface.properties；
3. 查找ChildAction的父類ParentAction的properties文件，文件名為ParentAction.properties；
4. 判斷當前ChildAction是否實現(xiàn)接口ModelDriven。如果是，調(diào)用getModel()獲得對象，查找與其同名的資源文件；
5. 查找當前包下的package.properties文件；
6. 查找當前包的父包，直到最頂層包；
7. 在值棧（Value Stack）中，查找名為user的屬性，轉(zhuǎn)到user類型同名的資源文件，查找鍵為title的資源;
8. 查找在struts.properties配置的默認的資源文件，參考例1;
9. 輸出user.title。

參數(shù)化國際化字符串

許多情況下，我們都需要在動行時（runtime）為國際化字符插入一些參數(shù)，例如在輸入驗證提示信息的時候。在Struts 2.0中，我們通過以下兩種方法做到這點：

1. 在資源文件的國際化字符串中使用OGNL，格式為${表達式}，例如：
   
   validation.require=${getText(fileName)} is required
2. 使用java.text.MessageFormat中的字符串格式，格式為{ 參數(shù)序號（從0開始）, 格式類形（number | date | time | choice）, 格式樣式}，例如：
   
   validation.between=Date must between {0, date, short} and {1, date, short}

1. 使用標志的value0、value1...valueN的屬性，如：
   
   <s:text name="validation.required" value0="User Name"/>
2. 使用param子元素，這些param將按先后順序，代入到國際化字符串的參數(shù)中，例如：
   
   <s:text name="validation.required">
   ? ?<s:param value="User Name"/>
   </s:text>

讓用戶方便地選擇語言

開發(fā)國際化的應用程序時，有一個功能是必不可少的——讓用戶快捷地選擇或切換語言。在Struts 2.0中，通過ActionContext.getContext().setLocale(Locale arg)可以設置用戶的默認語言。不過，由于這是一個比較普遍的應用場景（Scenario），所以Struts 2.0為您提供了一個名i18n的攔截器（Interceptor），并在默認情況下將其注冊到攔截器鏈（Interceptor chain）中。它的原理為在執(zhí)行Action方法前，i18n攔截器查找請求中的一個名為"request_locale"的參數(shù)。如果其存在，攔截器就將其作為參數(shù)實例化Locale對象，并將其設為用戶默認的區(qū)域（Locale），最后，將此Locale對象保存在session的名為“WW_TRANS_I18N_LOCALE”的屬性中。

下面，我將提供一完整示例演示它的使用方法。

package tutorial;

import java.util.Hashtable;
import java.util.Locale;
import java.util.Map;

publicclass Locales {
? ?public Map<String, Locale> getLocales() {
? ? ? ?Map<String, Locale> locales =new Hashtable<String, Locale>(2);
? ? ? ?locales.put("American English", Locale.US);
? ? ? ?locales.put("Simplified Chinese", Locale.CHINA);
? ? ? ?return locales;
? ?}
}

上述代碼的原理為，LangSelector.jsp先實例化一個Locales對象，并把對象的Map類型的屬性locales賦予下拉列表（select） 。如此一來，下拉列表就獲得可用語言的列表。大家看到LangSelector有<s:form>標志和一段Javascript腳本，它們的作用就是在用戶在下拉列表中選擇了后，提交包含“reqeust_locale”變量的表單到Action。在打開頁面時，為了下拉列表的選中的當前區(qū)域，我們需要到session取得當前區(qū)域（鍵為“WW_TRANS_I18N_LOCALE”的屬性），而該屬性在沒有設置語言前是為空的，所以通過值棧中l(wèi)ocale屬性來取得當前區(qū)域（用戶瀏覽器所設置的語言）。

可能大家會問為什么一定要通過Action來訪問頁面呢？ 你可以試一下不用Action而直接用JSP的地址來訪問頁面，結(jié)果會是無論你在下拉列表中選擇什么，語言都不會改變。這表示不能正常運行的。其原因為如果直接使用JSP訪問頁面，Struts 2.0在web.xml的配置的過濾器（Filter）就不會工作，所以攔截器鏈也不會工作。

說明：

類適配器：

對象適配器：