How OSGi and Service Buses Enable Loosely Coupled Business Components

Bus (Bus) generally refers to a set of transmission lines that, through time‑division multiplexing, deliver information from one or more source parts to one or more destination parts. In micro‑computer technology there are three buses: address bus, data bus, and control bus. In a communication architecture a switch can also be considered a bus, and in SOA the term usually denotes an Enterprise Service Bus (ESB), which can connect interfaces of any protocol, ideally based on XML‑based Web Service standards.

OSGi – Open Service Gateway Initiative – was founded in 1999 to create an open service specification for delivering services to devices over a network. OSGi is a Java framework that loads resources as Bundles. A Bundle can provide services or handle requests, and its dependencies are managed by the framework; each Bundle has its own classpath, allowing it to act as an independent service unit. Any Bundle that conforms to the OSGi specification can be installed in any compliant container. OSGi offers dynamic system behavior, hot‑plug plug‑in architecture, high reusability, and efficiency. In a J2EE environment, the bus‑based thinking can be extended to Java classes, forming a micro‑kernel based on OSGi that creates a Java Class Bus (JCB).

From the above concepts we see that the article’s Business Component (BC) refers to a concrete software implementation. BC corresponds partly to IBM’s Component Business Model (CBM) components, but a BC may contain multiple CBM components or encapsulate a single CBM component into several BCs. CBM is business‑oriented, while BC is considered from a technical implementation perspective. Compared with Service Component Architecture (SCA), which defines finer granularity, BC represents a coarser‑grained software implementation.

Loose‑coupled design of Business Components – OSGi

Business components expose interfaces as Web Services and connect via an ESB. Inside a business component, to achieve high reusability and efficiency, modules are built according to the OSGi standard, achieving loose coupling. The component is decomposed into Bundles, making the component more flexible.

Based on OSGi, internal modules are linked by a micro‑kernel with dynamic class loading, which uniformly manages all modules. Common modules such as data‑access or logging are shared. The micro‑kernel and class‑interface management together form the basic functions of a Java Class Bus (JCB).

Component Container

To load and configure components, the Service‑Support Bus (SSB) provides container functionality, divided into a component container and a service container. The component container offers the basic runtime environment for components, while the service container exposes services so that they can be seamlessly accessed by other containers or external systems.

UI Component and Loading

The UI unit loader provides a framework for the main interface, allowing menus, buttons, images, toolbars, and text to be loaded, laid out, and rendered according to user customization. It obtains hierarchical relationships, ordering, links, and parameters from UI configuration files, and offers a loosely coupled mechanism for page calls, unifying parameter handling to improve development efficiency.

Traditional web and presentation layers struggle to package a page as an independently deployable unit. The open‑source web framework Tapestry can package the web layer as an independent WAR for management and deployment.

FS Unit Loader

The Façade Service (FS) unit loader acts as a unified façade for DS units; UI objects interact with DS objects through the FS, providing a high‑level interface that simplifies DS usage, reduces system complexity, and enhances extensibility.

DS Unit Loader

The DS unit loader provides a core service layer framework with non‑intrusive high extensibility. Code does not need to reference container‑specific classes; modules can be managed by the container. Dynamic invocation avoids hard‑coded constraints, allowing references to other objects to be set at runtime via configuration files.

DA Unit Loader

The DA unit loader offers a mechanism to load DA units, providing a unified interface for different DA units, masking differences, simplifying development, and improving code reusability.

Device Loader

The device loader supplies a generic mechanism for device services, including loading, unloading, hot‑plug, initialization, shutdown, and configuration of device adapters.

Component Manager

The component manager handles component management within the container, using self‑descriptive information to obtain interfaces, maintain coupling relationships, and manage registration, activation, stopping, and disabling throughout the component lifecycle.

Service Container

Service components are the sole interface for business components to interact with the outside world, handling both service consumption and invocation. Technical components implement the service component’s functionality and business rules.

Service consumption: a business component consumes external services, including technical services, workflow services, and services provided by other business components.

Service exposure: the service support framework can expose methods implemented in SSB components as SOAP or RESTful Web Services.

Service description generation: users can access REST or Web Service description URLs via HTTP to obtain service descriptions of business implementation classes.

Service access control: before granting access, the framework validates the requester’s identity; unauthorized requests are denied.

Session encapsulation: the framework creates a Session object for each client, storing identity and request information, allowing business implementation classes to preserve context via the Session.