Ten years ago, the term component software meant something relatively specific and concrete. A small number of software component frameworks more or less defined the concept for most people. Today, few terms in the software industry are less precise than component software. There are now many different forms of software componentry for many different purposes. The technologies and methodologies of 10 years ago have evolved in fundamental ways and have been joined by an explosion of new technologies and approaches that have redefined our previously held notions of component software.
Depending on exactly when one starts counting, CORBA is about 10-15 years old. During its lifetime, CORBA has moved from being a bleeding-edge technology for early adopters, to being a popular middleware, to being a niche technology that exists in relative obscurity. It is instructive to examine why CORBA—despite once being heralded as the “next-generation technology for e-commerce”—suffered this fate. CORBA’s history is one that the computing industry has seen many times, and it seems likely that current middleware efforts, specifically Web services, will reenact a similar history.
Separation of concerns is one of the oldest concepts in computer science. The term was coined by Dijkstra in 1974.1 It is important because it simplifies software, making it easier to develop and maintain. Separation of concerns is commonly achieved by decomposing an application into components. There are, however, crosscutting concerns, which span (or cut across) multiple components. These kinds of concerns cannot be handled by traditional forms of modularization and can make the application more complex and difficult to maintain.
The promise of software as a service is becoming a reality with many ASPs (application service providers). Organizations using ASPs and third-party vendors that provide value-added products to ASPs need to integrate with them. ASPs enable this integration by providing Web service-based APIs. There are significant differences between integrating with ASPs over the Internet and integrating with a local application. When integrating with ASPs, users have to consider a number of issues, including latency, unavailability, upgrades, performance, load limiting, and lack of transaction support.
To explore this month’s theme of component technologies, we brought together two engineers with lots of experience in the field to discuss some of the current trends and future direction in the world of software components. Queue Editorial board member Terry Coatta is the director of software development at GPS Industries. His expertise is in distributed component systems such as CORBA, EJB, and COM. He joins in the discussion with Leo Chang, the cofounder and CTO of ClickShift, an online campaign optimization and management company. Chang also cofounded a company called flyswat, which was purchased by NBCi, and served as the vice president of software development at Savi Technology.
Building software components and then integrating them with applications built by others has always been one of the most difficult challenges for any development team. In today's Web environment, developers are now being asked to build components that can be dynamically plugged into any application anywhere on the Web. In a conversation with Queuecast host Mike Vizard, David Johnson, CTO of IPCommerce, a company that specializes in distributed payment systems, explains how his company is rising to that very challenge.
The ultimate alternative human computer interface is speech. Mastering the development skills to integrate speech into applications, however, has never been simple. But as time goes on, significant strides are being made, particularly in applications that leverage embedded processors. In an interview with ACM Queuecast host Mike Vizard, Roberto Sicconi, manager for mobile conversational computing at IBM, explains how and why speech technologies will become a standard element of most mainstream applications.
A call to Transylvania may be needed.
Dear KV, I've been stuck with writing the logging system for a new payment processing system at work. As you might imagine, this requires logging a lot of data because we have to be able to reconcile the data in our logs with our customers and other users, such as credit card companies, at the end of each billing cycle, and we have to be prepared if there is any argument over the bill itself. I've been given the job for two reasons: because I'm the newest person in the group and because no one thinks writing yet another logging system is very interesting. I've not gotten a lot of help from the other people on the team, who claim to have written "far more logging systems in their time than they want to think about." Do you have any advice on doing up a proper logging system?