1.1 preface
Current distributed applications have more and more, but there are some troublesome processing performance of how to balance distributed applications and stand-alone applications. It is also difficult to migrate from a distributed technology to another. One reason is that our upper application code and the underlying distributed technology (CORBA, ICE, Socket) are closely related, and it is difficult to split. This article gives a design plan for separating specific distributed technology, which is to emphasize: For application software, specific distributed technology such as CORBA, ICE, Socket is not the core, the core is the business function required by our customers.
This separation architecture is described below with CORBA and Socket (ASN.1 protocol) as an example.
1.2 implementation method
1.2.1 Principles:
1. All business features are defined by interface;
2. All code to use business features must obtain an instance of business interfaces through the interface factory
1.2.2 software structure
Interface class factory. Ensure that all services provided by any business module (components) (including between individual business modules or components within large platforms) are interfaces, and provide an implementation of an interface to an external access business module (component).
Description:
1) IEXPAND is an interface that requires external customization, of course, there may be multiple, if a business module (component) does not need external customization, there is no such interface;
2) IPLATFORM is a functional interface that provides external use, of course, there may be multiple;
3) iplatformfactory is an interface of a factory, and the factory is also defined by interface, because it is necessary to communicate with external shielding, such as ASN.1, CORBA, etc .; Of course, this interface should be rarely changed; in general, one Business modules or components require only one type of factory interface definition;
4) TFactory is an implementation of a class factory, which is the only one of the uniquely visible implementations.
5) PlatformIMPL is a functional implementation of internal development of standard C , which is invisible to the outside.
All services are implemented using this core architecture. The following considerations are considered in the adaptation method of the CORBA, the ASN.1 interface. These two methods can be seen as a Client / Server structure, and we need to provide Client / Server External interface between the two ends
1.2.3 Adaptation CORBA Services
Use Adaptor and Delegate mode to block CORBA technology details.
Description:
1) iServerIDL uses the IDL language to define the interface of the IPLATFORM, which is unasible for external;
2) CORBASERVERIMPL inherits from iServerIDL and IPLATFORM, transfer any call of iServerIDL to the interface implementation; at the same time CORBASERVERIMPL also uses the delegate mode, transfer IPLATFORM interface call to PlatformIMPL, so CorbaserverImpl is just a CORBA object. Just The CORBA data structure is converted to a standard C interface, converts the CORBA call to a normal C API interface call, and there is no complex business logic inside, which is very simple.
3) TCORBASERVERFACTORY is internal responsible for creating a CorbaserverImpl object, and the outside can not see any information from CORBA.
4) There is no Iexpand interface here because it is not related to any details of CORBA 1.2.4 Configure the CORBA client.
Using DELEGATE mode to achieve
Description:
1) iClientIDL is an IPLATFORM interface that uses IDL, which is the interface after the IDL compiler, which is an unassable externally.
2) CORBACLIENTIMPL IPLATFORM is inherited at the same time, and transfer the IPLATFORM interface to the iClientIDL interface, it is an unassable externally
3) TCORBACLIENTFACTORY is responsible for creating a CorbaclientImpl instance, and the implementation details of the external mask CORBA
4) The IEXPAND interface is not appeared in the figure because it is not related to any details of CORBA.
1.2.5 Adaptation ASN.1 server
With the adaptor and delegate models with the CORBA
Description:
1) IASN interface definition send messages and receives two interfaces
2) ASN.1ServerIMPL is implemented using the AdPator mode and the delegation mode, and the IPLATFORM interface transfer is implemented with PlatformIMPL. In addition, it analyzes all ASN.1 messages received, and converts the message content to the interface call of IPlatform, and then Pack the return value called the IPLATFORM interface to an ASN.1 message
3) TASN.1ServerFactory is responsible for the creation of an ASN.1ServerImpl instance, any technical details of external shielding ASN.1
4) The IEXPAND interface does not appear because it is not related to any details of ASN.1
1.2.6 Adaptation to the ASN.1 client
Adaptor mode is used.
Description:
1) ASN.1ClientIMPL converts the IPLATFORM interface call to the ASN.1 message, and then convert the received ASN.1 response message to the return value and output parameters called for the standard C data as the IPLATFORM interface.
2) Tasn.1ClientFactory technical details of external shielding ASN.1
1.2.7 Summary of the final application
As can be seen from the above, there is no difference between the internal use of CORBA, ASN.1 or pure C API interfaces. We can even provide these three ways, and users can choose as needed. For example, all business modules (components) are running with the same machine, we can give up CORBA, ASN.1 technology, and later change to distributed networking, only need to replace a class factory library. In the future, a new distributed technology is to be supported, and it is only necessary to implement a fitting layer, all implementations of the service of the upper business can be reused.
Finally, return to a point: The core of the application software is that the business is not underlying distributed technology.