Considerations for SOA Architecture and business components (BC)

Service-Oriented Architecture (SOA) and business component (BC) thinking

In service-oriented architecture (SOA), "component" is a very important concept, how to "component" development is to build an enterprise-level Business foundation platform to consider an important issue, this article through the establishment of business component (BC) interface model and internal structure model, Provides a modular development model based on WEB services and OSGi standards in the context of a new development system.

1 reviews:

Xiao Jianguo, IT consultant, Wave Software

March 08, 2010

• Content

Develop and deploy your next application on the IBM Bluemix cloud platform.

Get started with your trial

What is a business component (BC)

Component, Modularization is a very important concept in software development, based on the service oriented Architecture,soa, how to implement the components, there are various implementation methods, the following through the various components of the concept of comparison, From the technical point of view, the definition of business COMPONENT,BC is presented, and the implementation scheme of the Enterprise service bus and class bus is given based on the analysis of bus mode.

Enterprise Architecture (EA)

An introduction to the corporate Architecture (Enterprise Architecture,ea) and Service Oriented Architecture (SOA) in the context of service-oriented architecture (SOA) and Data Warehousing (DW) (hereinafter referred to as "SOA and DW"), the Enterprise architecture includes enterprise strategy, Business architecture, it strategy, it architecture four parts, it architecture as shown in the IT architecture model, including the data architecture, application architecture, technology architecture and governance framework, including four aspects of the technology architecture including integration platform, public service platform, basic platform (software and hardware, network) and security platform, "SOA and DW" Focusing on how to construct data architecture, especially data storage, this paper discusses how to build an SOA system based on SOA and DW, and will focus on how to develop component based on extensible and flexible enterprise-level integrated platform and public service platform.

Figure 1. IT Architecture Model Business components (BC)

Currently, there are a number of concepts that refer to components (Component), such as distributed component DCOM, Java EE, CORBA, IBM's business component model (Component MODEL,CBM), service component architecture in SOA Component Architecture,sca) and so on. The business component referred to in this article is defined as a system or module that can be run independently, and the purpose of the business component is to achieve SOA and DW through a degree of separation, based on the basic principle of facilitating the independent upgrading of business components and reducing the interaction between unnecessary components COMPONENT,BC The reuse mentioned in (software reuse).

If the business components are shared, other business components need to be reused, called Public business components (public components), and all public components comprise a public service platform for the technical architecture of the enterprise architecture, such as master data management, System management, unified authentication management, general reporting, and so on, which are common components.

Component Business model (CBM)

Component Business Modeling (Component MODELING,CBM) is a methodology built by IBM SOA that identifies opportunities for improvement and innovation by re-grouping organizational activities into manageable, discrete, modular, and reusable business components, leading the business Control and execute three aspects of the modular analysis to effectively achieve the business of the organization to provide service capabilities. The value of CBM is to provide a framework that can be generalized to create operational guidance that adapts to an organization's strategy, while CBM is also used to build and adapt to the direction of the strategy based on the priorities and interrelated levels of business and resources, including the establishment of a communication mechanism to understand the direction of the overall business development. CBM establishes the direction of SOA planning and lays the groundwork for implementing SOA.

The business components mentioned in this article have a granularity that corresponds to the granularity of the component Business Model (CBM), but the business component (BC) in this article is more from a technical implementation perspective, or greater than, or less than, the business component concept referred to in the Business Component Model (CBM).

Service component Framework (SCA)

The Service component Framework (Component ARCHITECTURE,SCA) is a set of SOA-compliant specifications developed by middleware vendors such as BEA, IBM, and Oracle. The Service component Framework (SCA) provides a set of programming models that can build service-oriented application systems, and its core concepts are services and their associated implementations. SCA components make up an assembly, which is a service-level application that is a collection of services that are connected and configured correctly. Under the SCA Standard, SCA consists of three levels of domains (domain), composition components (Composite), Artifacts (Component), which correspond to fine-grained web services, and domains correspond to coarse-grained web services. The SCA assembly runs at two levels: in the first case, the assembly is a loosely connected set of serviced components for "large-scale programming" (programming in the Large or megaprogramming), and the assembly is "small-scale programming" in the other case A loosely connected set of components (programming in the Small). The difference is that "large-scale programming" corresponds to the application, "small-scale programming" corresponds to the module, in general, the service component corresponds to "small-scale programming", that is, the concept of modules.

The business component (BC) mentioned in this article is a broader concept than an SCA component, and the granularity of these concepts is from large to small in the following order: system (only one system per enterprise), applications, business components (BC), modules, SCA components (coarse-grained service).

Bus modes (buses) and SOA, OSGi

Bus: Generally refers to a set of transmission lines that transmit information to one or more destination parts by means of a time-sharing method. There are many applications based on bus mode, in the technology of microcomputer, there are three kinds of bus, address bus Address bus, data bus of the bus, control buses. In the communication architecture, the switch is also a kind of bus, in the SOA, the bus generally refers to enterprise service Bus (ERP), Enterprise service Bus can connect the various interfaces of all protocols, but the most ideal is XML-based WEB service standards (BUS,ESB).

Established by the Osgi--open Service Gateway initiative,1999, the OSGi Alliance aims to establish an open service specification that establishes an open standard for providing services to devices through the network and is the initiator of the open Business Gateway. OSGi is a Java framework that can load resources in bundles. Bundles can provide services or respond to processing requests, and the dependencies between them are managed, just as a bundle can get the management it needs. Each Bundle can have its own internal classpath, so it can be used as a standalone service unit. All of these OSGI-compliant bundles can theoretically be installed in any container that conforms to the OSGi specification. OSGi has dynamic system behavior changes, hot-swappable plug-in architecture, high reusability, efficiency, and so on. In the Java EE environment, the thought of bus-based mode can be further extended to a class bus (Java class BUS,JCB) based on the OSGi micro-kernel.

Through the analysis of the above concepts, we can see that the business component (BC) mentioned in this article refers to a specific software implementation, business components (BC) and the Business Component Model (CBM) mentioned in the IBM business components have a certain correspondence, but in general, business components (BC) may contain CBM Multiple business components or a CBM business component are encapsulated into multiple business components (BC). In addition CBM is considered from a business perspective and is a business concept, and business components (BC) are considered from a technical implementation perspective. The granularity and business components (BC) defined by the Service component Framework (SCA) are still very thin, and the business component (BC) is a more coarse-grained software implementation concept.

Back to top of page

Business Component (BC) model

Depending on the role of business components, business components can be divided into common business components and common business components, and common business components include unified user components, unified authentication components, Portal components, process components, report components, BI components, GIS components, etc. The common feature of these components is that the business components are used by multiple business components or systems.

The component's granularity and external interface design determine the reusable and loosely coupled (Loose coupling) characteristics of the component. Grain through the large, flexible, difficult to achieve reuse, grain through small, management costs, so that reusability is also difficult to improve; the separation of interfaces and implementations ensures that business components can replace a wide variety of optional implementations without compromising the implementation of other parts of the system and the design of the interface, There is a big impact on the coupling of the components.

Granularity of business components

The granularity of a business component can be different depending on the need, either as a standalone subsystem or as a program module. Business components are an important foundation for improving the flexibility and reuse of application systems. Business component size is too small, resulting in a large number of components, multi-component interaction, management difficulties, poor performance; business components are granular, complex, feature-intensive, and difficult to upgrade (independent upgrades can often be an important factor in determining the scope of a business component) and are difficult to reuse. So it's important to find the right business component granularity.

According to the definition of business component defined above, we call all the software of the whole enterprise as the system, that is, one enterprise has only one system, and the system is divided into several applications, each application completes a relatively independent business function, such as financial management, human resource management, etc. , if it is based on a business foundation platform, multiple vendors can be in one application), the application is divided into a number of business components, business components are relatively independent functions, which can be further divided into several modules, thus forming a system-application-business components-modules, such as the four-level model. According to the definition of SCA, the modules below can be further divided into assemblies for smaller granularity. From a software reuse perspective, the business component is the smallest particle that is deployed independently, and the module is the smallest particle that is reused.

In addition to granular control of business components, granular control of WEB services is also a very important design task. Typically, a coarse-grained interface is recommended for services that expose the entire system, whereas a relatively fine-grained service interface is typically used internally for enterprise and institutional system architectures. Technically, a coarse-grained service interface might be a complete execution of a particular service, while a fine-grained service interface might be a concrete internal operation to implement this coarse-grained service interface. While fine-grained interfaces provide more granular and more flexibility for service requesters, it also means introducing more difficult-to-control interaction pattern variability, meaning that the service's interaction patterns may vary with different service requesters. Exposing these easily changing service interfaces to external users of the system can make it difficult for external service requesters to support the fine-grained service interfaces exposed by changing service providers. The coarse-grained service interface ensures that service requesters will use the services exposed in the system in a consistent manner.

Loosely coupled design of business components

Coupling (coupling) is a measure of the correlation between modules in a program structure, depending on the complexity of the interface between the modules, how the module is called, and what information is passed through the interface. The coupling is loosely and tightly divided into seven types: non-direct coupling (nondirect coupling), data coupling (Date coupling), tag coupling (Stamp coupling), control coupling (controlled coupling), External coupling (External coupling), public coupling (Common coupling), content coupling (contents coupling). Non-direct coupling means that there is no direct relationship between the two modules, which is the strongest module independence. Data coupling, between each other through the data parameters (not control parameters, public data structures or external variables) to exchange input, output information, the module is relatively strong independence. Tag coupling refers to a set of modules passing the record information through the parameter table, that is, the tag coupling, which requires that these modules must be clear about the structure of the record, and according to the structure requirements of the record operation, should try to avoid this coupling, it makes the operation of the data structure is complicated. In the business component Design model, it is possible to implement non-direct coupling between business components (bus mode, recommended) and data coupling (Shared library mode, control usage), and to interact through a well-defined Web service that can be shared between modules within a business component through standardized Web services or data tables.

Back to top of page

Business components (BC) for business components loosely coupled design-osgi in the Java EE architecture

Business components provide interfaces in the form of WEB services, through Enterprise service bus connections, within business components for high reusability and efficiency, building modules based on OSGI standards for loose coupling between internal modules, modular design based on OSGI standards within business components, Further decomposition of business components into loosely coupled modules (bundles) makes the business component itself more flexible.

Based on the OSGi standard, the module inside the business component is managed by a micro-kernel connection with dynamic load class function, unified management of each module, in order to facilitate management, the class interface between different modules is managed by the way of service registration. The micro-kernel and class interface with class dynamic loading function is composed of the basic functions of the class bus (JCB), and some modules are common for reuse, such as data access module, log Management module and so on.

In one application, the functionality common to different business components, as a common component within an application, deploys a common component in one application and is shared across business components. In a business component, the functionality common to different modules, as a public module, is equivalent to a tool class, and public modules need to be deployed in each business component. The Public service platform provides enterprise-level WEB services, such as master data management, as an enterprise-class public service. The business components are composed as shown in the following:

Figure 2. Business Component Model (public class-public component-public service platform)

Note:

The difference between a public component and a public service platform in a business component is that the public component is internal to the application and provides an application-level service, while the public service platform is for the entire system of the enterprise and provides a system-level service, which can sometimes be replaced by one another, mainly by looking at that level.

Implementation based on IBM's product system

The integration platform mentioned in this article, based on IBM's product co-system, needs to include application server (product: Was), Process Integration Server (product: WPS, service bus and process orchestration), etc., for a detailed description of the integration platform, as described in the article "SOA and DW" Description of the implementation of the product system.

Deployment of business components (BC) in was

First take a look at the file format in the Java EE schema mode (in the case of was). In the Java EE architecture, there are three file formats, EAR, WAR, jar, and a special jar that is based on the OSGi standard Bundle, a total of four types of files:

• EAR file (file Enterprise Achieve) includes, in addition to JAR, WAR, EJB components, deployment files All enterprise Applications Application-client.xml, Web. XML, Application.xml, etc. The
• WAR file (file Web Achieve) contains Servlets, JSP pages, JSP tag libraries, JAR library files, html/xml documents, and other common resource files, and all Web pages, such as slices and audio files, should Use the program. There can be more than one WAR in an EAR file. (in the WAS environment, if you set a class loader in the EAR so that different wars can be called directly between Java Class,war is tightly coupled, it is not recommended to use.) The
• JAR file (Java Achieve) is a class package compressed in Java format, containing the content class, properties file, which is the smallest unit in the file encapsulation. But ordinary JAR files, just a collection of files, have no specific meaning.
• Bundle, a special JAR file based on the OSGi standard, each Bundle also contains a meta-inf/manifest. MF file, this file announces which packages are exported and which packages are imported. Only those classes in the exported package can be used by other bundles, while the other packages are only for the internal members of the package, and the classes in the package can only be used in their own bundles. A simplified approach is to adopt the package directly, but it is not possible to implement the dynamic loading of the class and manage the interface without loose coupling characteristics. (was Support Osgi)
starting from version 6.1

From the above file structure can be seen between the jar can make class calls, it is easy to implement the transaction between the different jars, and has higher performance, combined with OSGi, through the "class bus" to manage all the JAR (Bundle) Open interface, so as "bus" (Bus) to manage class calls between different jars. Different kinds of war between the various resources are not shared, in order to achieve reuse, you need to set up a number of public modules, that is, public bundles, the interaction between different wars, need to connect as a WEB service, need to establish an enterprise service bus (ESB) to manage all the Web services, to implement the WAR between the call. In one ear, you can set up a shared Session between different wars to facilitate single sign-on and other public information that will be shared in this ear environment.

Based on the definition of the business component (BC) described earlier, business components are suitable for partitioning at the war file level, i.e. a war as a business component, one or several wars consisting of an application (EAR), multiple applications constituting an enterprise system, and further partitioning of the business components into multiple modules (bundles) , each module is relatively independent and can be independently maintained, independently upgraded and installed, and connected via the class bus in a plug-in manner. In order to achieve reuse, at the EAR level, enterprise-level business components are deployed separately, such as master data, unified authentication, workflow, etc., to establish a public service platform; At the war level, the public business components of each vendor are packaged separately in common components (war), such as System management, system parameter management, and so on. At the module level, a common module is provided in each WAR as a tool module (Bundle), such as database access, logs (log4j), and so on. Common components (WAR), internal service Bus (ESB), and Class bus (JCB), tool modules (bundles) comprise the Business Foundation Platform (the Platform) of the application (such as the Loushang platform of the Tides).

When the system is deployed, a single Websphere instance is installed on one server, and one instance can install multiple nodes (node) depending on the performance of the host, each node can install multiple virtual machines (JVMS), each virtual machine can install multiple ear applications, each ear has multiple WAR , files between different wars do not conflict, and within the war, the OSGI standard is used to divide into multiple modules (bundles). The systems of different companies are different ears, and the same company can have multiple ears. As shown in the following:

Figure 3. was deployment model (System-Applications-business components-modules)

The data exchange between the EAR adopts the Enterprise service Bus (ESB) Web service, the big data volume data share on the data bus through the enterprise-level shared database, the data shared by the bus is not real-time, there is a certain delay or quasi-real-time. Shared libraries are assets of the enterprise and are not affiliated to any one vendor.

The data exchange between wars uses a WEB service through an enterprise or an internal service bus (ESB), a database is shared between different wars, but the data tables are divided according to the responsibilities of the war, and each war can read all the shared data tables only, but only the tables that it controls, the tables that are controlled by the other war, Tables with complex or variable table structures should be read through a WEB service to achieve loose coupling between wars. A shared database in an EAR (a private data layer for an enterprise) is more tightly combined between wars, typically in direct access, and not in the private data tier, where private data is simply a control class or business-independent data that does not need to be shared. Enterprise-class shared library generally from the performance, different manufacturers to control the angle of view, data synchronization is quasi-real-time, the data in each ear of the private data layer will generally have a copy, so that the ears are relatively more independent. The above is only the general principle, if it is a manufacturer, two ears can also share a database like an ear. The relationships between the ear and the shared library are as shown in the relationship between the ear and the shared library:

Figure 4. Relationship of EAR and shared library

The data exchange between Bundule can be similar to a WAR-like Web service invocation, or it can be called directly through the class bus, Bundule externally published interfaces, in particular the need for transactional processing power and higher performance requirements. A war in principle no longer divides the control of the data table, which is managed internally by the war itself.

In general, the WAR is relatively stable, does not require a full replacement upgrade, the daily change is implemented through bundles, because the bundle in the application is based on plug-in way of development, Data aspect because the business component itself is based on the standard Information service or as an Open data table, view (WEB service and data model, as the enterprise's two assets), it can be hot-swappable, ensure that the system can run continuously, And not because of the system upgrade to affect the operation of the business or the minimum level of marketing business operation.

In the case of actual deployment, it is possible for the entire enterprise to have only one EAR (simple, most extreme), or a vendor to deploy the application separately in different ears, depending on the size of the enterprise, host deployment, etc., from the perspective of performance, easy to manage. Because the war is loosely coupled, the Enterprise service Bus (ESB) and the Information Service Bus (ISB) enable flexible assembly, so one or more wars can be deployed flexibly.

The above Java EE-based application server was (IBM WebSphere application Server,was), analyzes the file system in the Java EE Architecture mode and provides an implementation recommendation for the business component model implementation mentioned earlier.

Business Component (BC) Implementation examples

Common enterprises commonly used in applications including human resources, collaborative office, financial management, marketing management, production management and several major applications, according to the architecture described above, based on the Java EE environment according to the following ways to build: first, human resources, collaborative office, financial management, marketing management, production management can recognize five applications, In general, it may be provided by five vendors, so it can be deployed as five separate ears, taking into account that to reduce the impact between different vendors, it is generally installed on five servers or installed on different virtual machines (sometimes a vendor may provide, in an EAR, such as financial management and human resources in one piece, so the WAR can be flexibly selected for deployment. If real-time interactions are required between the five systems, they are fully interacting with the ESB in the enterprise's integration platform. An enterprise-level shared database can be established between five apps.

For marketing management applications (EAR), its internal can be further divided into customer relations, supplier management, purchase and sale of multiple business components, as three separate WAR, three business components if the need for interaction through marketing management application EAR own ESB (from the enterprise point of view, the need to establish a federal ESB), or interact with an ESB in an enterprise's integration platform. All three share a database, logically dividing the table into three parts, managed by three business components, each with its own control table, read-only for other business component-controlled tables, and access, as described earlier, to services provided by other business components.

Customer relationship management can be further divided into market management, sales management, service management and other modules, in order to facilitate the management, can be divided on this basis on a more detailed layer, such as market management can be further divided into customer classification management, customer group management, customer visit Management module (Bundle), Modules (bundles) can be called directly between classes, and calls between different modules are implemented through the class bus. From the management and system upgrade scheduling considerations, the module should not be too small, also difficult too much.

The above-mentioned functions commonly used in general enterprises according to the model described above based on the specific implementation of the Java EE architecture is described, can be used as a reference for component development.

Back to top of page

Summarize

Through the definition of business components (BC), especially the relationship between the concepts of CBM, SCA and other components, this paper describes the technical implementation of component programming based on SOA, explains the technical requirements of business components in external interface and internal structure, and constructs a flexible and easy-to-expand and easy-to-maintain component development model, which provides a reference for the enterprise to build an integrated platform after the new component development.

Considerations for SOA Architecture and business components (BC)