ACM Queue - Component Technologies

Cluster-level Logging of Containers with Containers

Satnam Singh — Tue, 28 Jun 2016 17:45:02 GMT

This article shows how cluster-level logging infrastructure can be implemented using open source tools and deployed using the very same abstractions that are used to compose and manage the software systems being logged. Collecting and analyzing log information is an essential aspect of running production systems to ensure their reliability and to provide important auditing information. Many tools have been developed to help with the aggregation and collection of logs for specific software components (e.g., an Apache web server) running on specific servers (e.g., Fluentd and Logstash.) They are accompanied by tools such as Elasticsearch for ingesting log information into persistent storage and tools such as Kibana7 for querying log information.

How OSGi Changed My Life

Peter Kriens — Tue, 04 Mar 2008 08:35:36 GMT

How OSGi Changed My Life

The promises of the Lego hypothesis have yet to materialize fully, but they remain a goal worth pursuing.

PETER KRIENS, AQUTE

In the early 1980s I discovered OOP (object-oriented programming) and fell in love with it, head over heels. As usual, this kind of love meant convincing management to invest in this new technology, and most important of all, send me to cool conferences. So I pitched the technology to my manager. I sketched him the rosy future, how one day we would create applications from ready-made classes. We would get those classes from a repository, put them together, and voila, a new application would be born.

Today we take objects more or less for granted, but if I am honest, the pitch I gave to my manager in 1985 never really materialized. The reuse of objects never achieved the levels foreseen by people such as Brad Cox with his software-IC model, and many others, including myself. Still, this Lego hypothesis remains a grail worth pursuing.

ASPs: The Integration Challenge

Len Takeuchi — Fri, 30 Jun 2006 10:31:10 GMT

ASPs: The Integration Challenge

LEN TAKEUCHI, SALESCENTRIX

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.

Web Service API

The integration APIs provided by ASPs are usually based on Web services. The ASPs provide documentation and WSDL (Web Services Description Language) files for the APIs. The user of the API uses the WSDL files to generate the Web service client using a Web service toolkit (e.g., Apache Axis). An ASP may provide a feature in its software to create custom fields for various entities. For example, CRM (customer relationship management) systems are likely to provide custom fields on such entities as customer accounts, since organizations will have specific information they want to track about a customer. If an ASP supports custom fields, it will usually provide two separate WSDL files: one generated specifically for an organization based on the custom fields defined by that organization, and one that is generic.

Untangling Enterprise Java

Chris Richardson — Fri, 30 Jun 2006 10:31:09 GMT

Untangling Enterprise Java

A new breed of framework helps eliminate crosscutting concerns.

Chris Richardson, CONSULTANT

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.

Examples of crosscutting concerns in enterprise Java applications include transaction management, security, persistence, and application assembly. Scattering the code that handles those concerns across multiple components is undesirable, however. This is because doing so would make each component more complex. Also, duplicating code in multiple modules can cause maintenance problems. Consequently, there has been a flurry of activity in recent years to develop frameworks and new forms of modularity that try to untangle these crosscutting concerns from the application’s business logic.

The Rise and Fall of CORBA

Michi Henning — Fri, 30 Jun 2006 10:31:08 GMT

The Rise and Fall of CORBA

There’s a lot we can learn from CORBA’s mistakes.

MICHI HENNING, ZeroC

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.

A Brief History

In the early ’90s, persuading programs on different machines to talk to each other was a nightmare, especially if different hardware, operating systems, and programming languages were involved: programmers either used sockets and wrote an entire protocol stack themselves or their programs didn’t talk at all. (Other early middleware, such as Sun ONC, Apollo NCS, and DCE, was tied to C and Unix and not suitable for heterogeneous environments.)

From COM to Common

Greg Olsen — Fri, 30 Jun 2006 10:31:07 GMT

From COM to Common

Component software’s 10-year journey toward ubiquity

GREG OLSEN, COGHEAD

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.

An Amazon search for the term yields more than 500 titles. Countless companies and open source projects use component software in describing what they do. Any summary or historical overview of the subject of component software rightfully belongs in a multivolume book. This article, then, simply looks at the highlights of how the concept of component software has evolved, and what we might expect in the future.

Leveraging Application Frameworks

Douglas C Schmidt, Aniruddha Gokhale, Balachandran Natarajan — Tue, 31 Aug 2004 13:57:06 GMT

Leveraging Application Frameworks

Why frameworks are important and how to apply them effectively

Douglas C. Schmidt, Aniruddha Gokhale, and Balachandran Natarajan, Vanderbilt University

In today’s competitive, fast-paced computing industry, successful software must increasingly be: (1) extensible to support successions of quick updates and additions to address new requirements and take advantage of emerging markets; (2) flexible to support a growing range of multimedia data types, traffic flows, and end-to-end QoS (quality of service) requirements; (3) portable to reduce the effort required to support applications on heterogeneous operating-system platforms and compilers; (4) reliable to ensure that applications are robust and tolerant to faults; (5) scalable to enable applications to handle larger numbers of clients simultaneously; and (6) affordable to ensure that the total ownership costs of software acquisition and evolution are not prohibitively high.