Gateway architecture - HxGN EAM - 12.0 - Customization & Programming - Hexagon

HxGN EAM Architecture and Server Management

Language
English
Product
HxGN EAM
Search by Category
Customization & Programming
HxGN EAM Version
12

As was mentioned in the introduction, SOA itself is an abstract architectural concept of how software should be put together. From an implementation perspective, it relies on the more concrete ideas and technologies implemented in XML and Web services. In addition, it also requires the support of security, policy management, reliable messaging, and accounting systems to work effectively. One can improve on it even further with the addition of distributed transactional processing, and distributed software state management.

The distinction between SOA services and Web services lies in design. The SOA concept does not exactly define how services are specifically to interact, just how services can understand each other and how they can interact. It is the difference between defining a strategy of how a process is to be done, and the tactics of how it is done. Web services on the other hand have specific guidelines on how messaging between services need to interact; i.e., it is the tactical implementation of an SOA model most seen in SOAP messages delivered over HTTP.

While SOA is not restricted to Web services, we felt it is the best way to accomplish our design goals. Other protocols that also directly implement service interfaces with WSDL, and communicate with XML messages, can also be involved in SOA. As indicated elsewhere, CORBA and IBM MQ systems can now also participate in an SOA, using new features that work with WSDL. If two services need to exchange data, they will still need to use the same messaging protocol, but the data interfaces allow the same exchanges of information.

To establish proper control of all such messaging as well as to apply the needs of security, policy, reliability and accounting, there is a new software object that enters the picture of an SOA architecture. This is the Enterprise Service Bus (ESB), which is responsible for the proper control, flow and even perhaps translations of all messages between services, using any number of possible messaging protocols. The ESB is not absolutely required but is a vital component of properly managing your business processes in SOA. The ESB itself can be a single engine or even a distributed system consisting of many peer and sub-peer ESBs all working together to keep the SOA system operational. Conceptually, it has evolved from the store-and-forward mechanism found in earlier computer science concepts such as the Message Queue and distributed transactional computing.

On the developer side, use of the SOA architecture allows for almost complete separation between back-end and front-end development, relying on a set of well-defined SOAP interfaces.

Another huge advantage that was achieved by using Web services-based SOA implementation was almost software and hardware agnostic integration with the 3rd party software systems. This integration is usually done using XML development kit, supplied as the part of the HxGN EAM product.

The following diagram represents SOA gateway architecture implemented in the HxGN EAM product:

Gateway architecture_Figure3_Gatewayarch

Figure 3. Gateway architecture.

Gateway can be subdivided into the following logical units: clients, XML documents, SOAP-based gateway implementation. This is a look at the gateway functioning scenario.

  1. Client submits the request. Request must be not only well-formed XML but must also be valid. Each request is validated using XML Schema defined for this request at the design stage (along with the format of the response). In other words, each XML request represents "service" definition application will fulfill upon receiving it.

    Sophisticated XML Schema specification allows for a high level of re-usability of the pre-defined business components using mechanisms like inheritance in the Object-Oriented paradigm. Most basic entities used in the schema definition are based on the OAGIS specification3 insuring high compatibility with new and upcoming 3rd party services and systems.

  2. Request received by application gateway front-end. Front-end is implemented using AXIS implementation of the SAOP 1.2 protocol and runs as servlet in the application server, insuring high performance (due to the light-weight nature) and compatibility (compliance with J2EE standard) of the application.

  3. Request processed by the security plug-in. Gateway security is designed with two major goals in mind

    1. Declarative, service-oriented nature. Permissions to perform (fully or to the certain extend) requested services stored in the XML file. This file describes the rules based on the user permissions, licensing, and data supplied in the request that will be applied to authenticate the request. These rules can be either easily customized for specific installation or applied to the specific customer in the ASP installation.

    2. Extensibility. Overall design of the security system allows mostly seamless integration with the 3rd party security and authentication systems (LDAP, Kerberos, etc.).

  4. Request processed by versioning plug-in. Versioning plug-in allows product to ensure backward compatibility with previous (but still supported) releases in single line of code and support custom (developed for specific customer) functionality. Both features proved to be invaluable for customers and ASP installations.

    At this stage, old version of the request is either transformed into the new form of the request (if possible) or routed to the components that implements functionality available in the previous releases. In case of a transformation, response will also be converted to the old response schema on the way back to the client.

    Transformation is done using highly optimized XSLT style sheets.

  5. After passing through security and versioning plug-ins, request is parsed into the Java object, passed for processing into the business tier of the application. Transformation is done using Castor framework (one of the few available JAXB implementations). All Java binding (used for request parsing) is being generated during the build process using pre-defined request and response XML schemas, so there is no overhead usually associated with generic XML parsing process.

On the way back to the client, response produced by the business tier in the form of Java objects is transformed back to XML using Castor generated binding classes and forwarded to the client application.

Implemented gateway architecture also contributes to the speed and the quality of the development efforts. Request and response schemas can be designed by analysts (instead of the development staff) thus ensuring traceability between formal business and functional requirements and implementation. This also contributes to the productivity of the development staff being relieved from this task and dealing only with formal and well-defined functional requirements in the form of the XML schemas.

Gateway architecture also represents an in-depth implementation and extension of the Model-View- Controller (MVC pattern). The Model View Controller (MVC) design pattern contains a clear distinction between processing control, data model and displaying the data in the interface. These three areas are formally distinguished from each other by three objects: model, view, and controller. As a result, you can easily split Web applications into logical units.

The model is used as an application object of the application data administration. It responds to information requests about its status which usually come from the view, as well as to statements for status changes which are usually sent by the controller. In this way, only the model is used to process data internally, without making reference to the application and its user interface.

There can be different views for a model, which can be implemented using different view pages (or XML responses in our case).

The view handles the graphical and textual output at the interface and therefore represents the input and output data in each interface element, such as pushbuttons, menus, dialog boxes and so on.

The view takes care of visualization. To visualize the status, the view queries the model, or the model informs the view about possible status changes.

The controller interprets and monitors the data that is input by the user using the mouse and the keyboard, causing the model or the view later to change if necessary. Input data is forwarded and changes to the model data are initiated. The controller uses the model methods to change the internal status and then informs the view about this. This is how the controller determines reactions to the user input and controls processing.

The view and the controller together form the user interface.

Since the model does not recognize either views or the controller, internal data processing is detached from the user interface. As a result, changes to the user interface have no effect on internal data processing and the data structure.

3 The Open Applications Group Integration Specification (OAGIS) is an effort to provide a canonical business language for information integration. It uses XML as the common alphabet for defining business messages, and for identifying business processes (scenarios) that allow businesses and business applications to communicate. Not only is OAGIS the most complete set of XML business messages currently available, but it also accommodates the additional requirements of specific industries by partnering with various vertical industry groups.