Interview with C++ Guru Herb Sutter Multi- and many-core chips are entering the mainstreamand one of the first software development authorities to take note was C++ expert Herb Sutter. He took time recently to speak with Go Parallel about the multi-core chip revolution and how it's affecting software developers. Read More>>>   Scalable Parallelism with Intel® Threading Building Blocks This paper discusses the approach to parallelize the Data Encryption Standard (DES) algorithm with Intel. Threading Building Blocks and how it can scale for future processors. Read More>>>   Visit ThreadingBuildingBlocks.org Threading Building Blocks (TBB) is now open sourced and supported by some very impressive veteran parallelism experts. Come check it out! Read More>>>   Intel Threading for Multi-Core Community The Intel® Threading for Multi-Core Community provides technical information, tools, conversation and support for the development of parallel programs and multi-threaded applications on multi-core and multi-processor platforms. Read More>>>   Download a Sample Chapter of the Book: Threading Building Blocks Intel Threading Building Blocks: Outfitting C++ for Multi-core Processor Parallelism, by James Reinders. Get your copy now!>>>

Top 10 Articles Web Developer's Virtual Library: Encyclopedia of Web Design Tutorials, Articles and Discussions JavaScript Tutorial for Programmers Design JavaScript Tutorial for Programmers - Objects JavaScript Tutorial for Programmers - JavaScript Grammar JavaScript Tutorial for Programmers - Versions of JavaScript Cascading Style Sheets JavaScript Tutorial for Programmers - Embedding JavaScript JavaScript Tutorial for Programmers - Functions Authoring JavaScript

Domain Name Lookup Search to find the availability of a domain name. Just enter the complete domain name with extension (.com, .net, .edu)

As we've observed in previous articles, Web sites are becoming more like applications and vice versa. At the same time, the trend toward hosted applications is gathering steam. But many Web applications still depend on scripting languages that were designed to work within the limitations of HTML and slow dial-up connections. And much existing data interchange depends on proprietary, Web-unfriendly technology.

A group of vendors that includes Microsoft is hoping to clean up the situation with the proposed Simple Object Access Protocol (SOAP) standard. This XML-based protocol lets you activate an application, or even an individual object or method within an application, across the Internet. SOAP could revolutionize the whole process of developing Web applications (as well as providing plenty of opportunities for cute puns). Will SOAP scrub away the friction that inhibits cross-enterprise applications, or will it be a washout? We'll try to explain how SOAP fits in to the complex world of online computing, and why it represents such an important milestone.

At first glance, SOAP may seem like nothing to get into a lather about. After all, it's not even a new technique — it merely codifies the existing practice of combining XML and HTTP to invoke methods (in an object-oriented programming language such as C++ or Java, a method is a bit of computer code that performs a specific action) across networks and across platforms. And even that is merely another way to do something which has been possible for some time using other methods (such as DCOM or CORBA/IIOP).

However, SOAP is significant because it represents a major step forward in the process of moving applications (and eventually the entire Universe!) to the Web and XML. Boosterism aside, the XML- based Web represents openness, extensibility and true platform independence, so moving business processes thither has to be a good thing.

To translate for the less technically-inclined, what we're talking about here is sending a request from one computer to an application on another computer (and possibly a completely different platform), instructing that application to do something. There are several ways of doing this, but the XML/HTTP combination is far more Internet-friendly, and that's the significance of SOAP.

Not Bubble Bath, but Business to Business

One much-touted application of XML is business-to-business integration. "B2Bi" is the latest teen idol in the business world, much as "e-commerce" was a couple of years ago. The basic idea is that a business can integrate its computer systems with those of its business partners (suppliers, vendors, customers), eliminating redundant data entry, speeding up order turnaround times, and generally reducing the "friction" involved in business-to-business transactions.

For example, under the old-fashioned way of doing things, a clerk might receive a purchase order by mail or fax, then have to key the information into the computer network. In a more modern scenario, the supplier company maintains a Web site (a so-called "extranet") which lets workers at the buyer's company enter purchase orders online. But in the absence of true integration, the workers still have to key the information again to put it into their own accounting or ERP program. B2Bi software lets the supplier's and buyer's applications talk to each other, so that the information goes automatically to both. It also lets workers at one company run queries to applications at another, so that (for example) the availability and price of an item can be checked before placing an order.

Of course, companies have been doing things like this for years by means of EDI ( Electronic Data Interchange). EDI is a standardized way of exchanging various types of data among applications, using the ANSI X.12 (United States) and EDIFACT (international) standards (Confusingly, the meaning of "EDI" has expanded, and some writers now use the term to refer to all forms of data interchange, including those based on XML). But traditional EDI, developed for a world in which proprietary applications talked to each other over private networks (sometimes called Value Added Networks or VANs), is looking a bit elderly in the more open world of XML and the Internet. By all accounts, it can be complicated and expensive to implement.

EDI messages must follow rigid formats, and the companies on either side of the transaction must have EDI software installed. EDI code was optimized to conserve bandwidth, so it's cryptic and hard for humans to read. XML is a far more flexible standard that requires no proprietary software. Furthermore, EDI has not proven to be very easy to implement over the Internet, as it doesn't fully support popular Internet security technologies such as SSL and HTTP Authentication. For some early ruminations on EDI vs XML, see XML: Evolution or Revolution?. For an in-depth discussion of the differences, see XML and EDI: Peaceful Co-Existence.

Companies Prepare to Clean Up