Designing Scalable Business Components with SOA, OSGi, and ESB

Abstract: In Service‑Oriented Architecture (SOA), componentization is crucial for building enterprise business platforms. This paper proposes a component‑based development model using Web services and OSGi standards.

What is a Business Component (BC): A BC is a software module that can run independently, designed for easy upgrades and minimal inter‑component interaction, supporting reuse. Public BCs form the common service platform (e.g., master data, authentication, reporting).

Enterprise Architecture (EA): EA comprises strategy, business, IT strategy, and IT architecture, which includes data, application, technology, and governance layers. The technology layer contains integration platforms, common service platforms, and foundational platforms. This paper builds on prior work to describe component‑centric development on a flexible, scalable integration platform.

Component Business Modeling (CBM): IBM’s CBM groups organizational activities into manageable, reusable business components, guiding strategic alignment and innovation. While BC granularity roughly matches CBM, this paper focuses on technical implementation, which may be larger or smaller than CBM’s definition.

Service Component Architecture (SCA): SCA defines a programming model for SOA, organizing services into domains, composites, and components. Components correspond to fine‑grained Web services, while domains represent coarse‑grained services. SCA components are smaller than the BCs discussed here.

BCs are positioned in the granularity hierarchy as follows: system → application → business component (BC) → module → SCA component (fine‑grained service).

Bus Pattern and OSGi: The bus (e.g., Enterprise Service Bus, ESB) enables message routing among components. OSGi provides a Java framework for modular bundles that can be dynamically loaded, offering hot‑plug, high reusability, and efficiency. Combining a bus with OSGi yields a class‑bus (Java Class Bus, JCB) for modular integration.

BC Model: BCs are classified as public or ordinary. Public BCs (e.g., unified user, authentication, portal, workflow, reporting, BI, GIS) are shared across multiple components or systems.

Granularity and Interface Design: Proper granularity balances flexibility and manageability; overly large BCs hinder reuse, while overly small BCs increase management overhead. Loose coupling is achieved through well‑designed interfaces, favoring non‑direct and data coupling, and using standardized Web services for interaction.

BC Interface Model: BCs expose interfaces that can be assembled on a standard integration platform comprising an enterprise portal, ESB (Web service standard), and data bus.

Figure 2. Enterprise Integration Platform Model

After establishing the integration platform, BCs can be plugged into applications.

Loose‑Coupling Communication: Web services can be read‑only (data retrieval) or write‑only (data submission). Two implementation styles are discussed: (1) BC actively calls ESB to retrieve data and writes directly; (2) BC provides a write service to ESB, allowing any system to invoke it, ensuring interface stability despite external changes.

Figure 3. Service Call Sequence

Stateless service design is recommended; transactions should be confined within a single BC or orchestrated via BPEL.

J2EE Implementation of BCs: In a J2EE environment, BCs are packaged as WAR files (one WAR per BC). An EAR may contain multiple WARs (applications). Inside a WAR, OSGi bundles (JARs with OSGi metadata) implement modular components, forming a class‑bus (JCB) for internal communication.

Figure 4. BC Model (Public Classes – Public Components – Public Service Platform)

Deployment on IBM WebSphere Application Server (WAS) follows a hierarchy: system → application (EAR) → business component (WAR) → module (OSGi bundle). Multiple EARs can run on a single server, each with its own nodes, JVMs, and virtual machines.

Figure 5. WAS Deployment Model

EARs exchange data via ESB Web services; large data sets are shared through a data bus and shared databases with near‑real‑time synchronization. WARs share a database but enforce read‑only access to others' tables, using Web services for cross‑WAR interactions to maintain loose coupling.

Figure 6. EAR and Shared Database Relationship

Bundles can also communicate directly via the class‑bus for high‑performance, transactional scenarios.

Overall, the proposed BC model enables modular, reusable, and maintainable enterprise systems, guiding developers on component granularity, interface design, and deployment strategies within a SOA‑based integration platform.