Use netkerne to implement a rest-style ESB

The University of New England launched a multi-year infrastructure modernization project to gradually replace outdated systems, it also provides as many IT functions as possible while maximizing the return on all IT investments. This project involves hardware upgrades, purchasing new software, development training, and Operation team training. The center of this modern strategic project is to implement a Service-Oriented Architecture (SOA ).

SOA is an overall platform architecture that focuses on Distributed Application Design, rather than specific technologies. The key to SOA lies in the definition and implementation of software services. Regardless of the service location and ownership, these services are directly mapped to a system or several business process services, including interfaces and policies for managing them at runtime. SOA has the following advantages: loose coupling between systems and platforms, ubiquitous enterprise-standard-based integration mechanisms, and on-demand support) create a composite service and make full use of existing assets while improving operational efficiency.

Figure 1 Service-Oriented Architecture

The transformation from traditional application development and deployment to service-based methods is huge and cannot be completed overnight. The IT department at the University of New England, working with kaijie Consulting, has drawn a roadmap for incremental adoption of SOA. One advantage of the incremental mode is that you can immediately see the return on investment, and you can select the order of conversion to better adapt to the short-term and long-term goals of the school. This article will describe how this six-month project uses 1060 Research's netkernel to implement a Resource-Oriented Enterprise Service Bus (Resource Oriented Enterprise Service Bus) to start the SOA adoption process.

Problem area

Higher education institutions are constantly under pressure from students, employees, and alumni. They require colleges and universities to provide a variety of online services to adapt to the habits of these users, for example, you can use intuitive user interfaces and automatic processing procedures to provide real-time information access. At the same time, the pressure from the management department, the Steering Committee (Steering Committees) and the Council that controls overhead is also growing. Therefore, IT departments of higher education institutions such as universities must be more agile and pragmatic when investing in new functions.

The University's IT Department supports a wide range of applications, including non-customized commercialization such as eaglesoft) products, legacy systems of large hosts built on the customer information control system (CICs), and modern J2EE Web applications built on the Oracle Application Server Portal. In addition, many of these applications interact with third-party application service providers (ASP) to provide historical data to the Data Warehouse (DW. In this project, all these applications must be integrated and coordinated with the new SOA method.

Previously, the University used ibm mq and FTP to integrate business systems. These traditional methods result in a large number of point-to-point (P2P) integration. All these P2P integration requires a great deal of cost during maintenance and lead to close coupling between customers and suppliers. However, the current environment already uses the lightweight message exchange state transmission (message exchange state transfer -- MEST) method, which leaves room for further innovation in the future. The Enterprise Service Bus (ESB) is a sub-type of the message bus architecture. It provides a more decoupled environment, but the deployment cost is relatively high in the early stage, the value of ESB increases exponentially by time, while the cost of the extended system increases linearly and is predictable.

The IT department of the University has a development team composed of specialized architects and software engineers. Many of them have become experts in the higher education field through their own positions. Since this development group is relatively small, each member often has to assume multiple roles in the development process, including support for and management of software. For this reason, the IT department urgently needs a solution that can implement the following key points:

• Meet increasing customer needs by using reusable services and composite applications
• Reduce or avoid P2P Integration
• Make full use of existing resources and technologies to improve operational efficiency

Solution 1. Overview

SOA can be implemented through many different models and technologies. The traditional method is to select the mode listed in the WS-* specification, in addition, you can choose from open-source solutions such as Apache ServiceMix or a wide range of technical products such as Cape clear and sonic software commercial suite. Unfortunately, the WS-* specification is still constantly being modified, and developers have to digest the 1300-page documentation for technical details, which is enough to discourage many people. For example, if you fully adhere to all the rules, the following steps are required to implement a soap service:

1. Use the Business Process Modeling symbol (BPMN) to model the process.
2. Use WSDL to define service interfaces, and use the UDDI (Universal Description, discovery and integration-unified description, discovery, and integration) library to register services.
3. Use BPMN registered from the service to access the service to generate the Business Process Execution Language (BPEL ).
4. Use WS-policy to define management policies for service access.

The commercial ESB suites on the market have been evaluated by all parties. As this IT team is relatively small, the final team decided to find such a solution: this solution will eventually cause less conflicts or conflicts between systems; the innovations it requires must be within the limits of the human resources of this small IT team; it should not force the team to use a centralized service model that relies on the only vendor. The fields of a university are extremely mobile, with Changeable Processes, applications, and integration. Therefore, what it needs is an overall framework and strategy that reflects the true natural characteristics of a university.

Since message requests were previously used as a central transmission mechanism across universities, the team decided to use the rest type or resource-oriented (Resource-Oriented) method to implement SOA. Rest is based on a small set of widely accepted standards, such as HTTP and XML, which do not require many development steps, many toolboxes, and execution engines. There are three main advantages of implementing SOA using the rest method: low overhead, fast market input, and flexible architecture. The resource-oriented approach provides more extensive extension and independent communication based on the REST style approach. The rest design model advocates the use of HTTP, while the resource-oriented architecture supports connecting services to HTTP and communication protocols such as JMS or SMTP.

Although some ESB implementations like codehaus mule support rest, only 1060 of netkernel is built on the Resource-oriented computing platform 2 (resource-oriented computing platform, "ROC. The core of Resource-oriented computing is to separate the logic requests of information (resources) from the physical mechanism (CODE) for sending requests. Services built Using ROC are proven to be small, simple, flexible, and less code to be implemented than traditional methods. These advantages determine that it is the ideal technology choice for creating a technology platform.

2. technical platform

Netkernel is a resource-oriented middleware that provides core functions of the Enterprise Service Bus (ESB): Addressing, routing, and data conversion, and can work like the orchestration engine. Netkernel provides many features, such as XML Conversion, Cache Management, multi-thread processing, and multiple transmission protocols including HTTP and JMS, the SOAP engine enables it to provide traditional Web Services. Netkernel is a solid foundation for heterogeneous enterprise integration.

In terms of concept, the resources accessed by netkernel are identified by Uniform Resource Identifier (URI) addresses. All URI addresses are centrally managed in a logical address space. The rest-based microkernel processes all resource requests, parses the URI address from the address space, and returns the representation of the resource. Requests sent to micro-core can also be used to create, update, or delete existing resources.

Physically, the netkernel system is composed of modules that expose public service interfaces and resources through URI addresses. Similar to Java ear, each module contains source code and resource configuration. The module can introduce the public services and resources of another module logically and include them in the address space. Because the introduction needs to specify the logic name of the module and identify the published document number, multiple versions can be run and updated in the same system. Service requests are injected into netkernel through the transmitter, which is an event detector located at the edge of the system. Service customers can send requests through any supported transmitter, such as HTTP or JMS.

Figure 2 technical platform

HTTP is a stateless request/reply application protocol. The request message structure includes a command, header, and body. A Response Message consists of the status, header, and body. The customer and the server use TCP socket to exchange this information. The customer/Server transport layer can use the SSL protocol to protect the interaction between the two, while the message itself can use encryption and digital signature to ensure security. Finally, the customer can identify by using HTTP-basic or http-digest authentication mechanism 3.

The jms api provides a platform for implementing asynchronous services. However, this API requires the provider. In this case, this vendor is IBM WebSphere MQ. Ibm mq is a message-oriented middleware (MOM) that provides queue-based communication channels between applications. Channels are implemented using point-to-point or hub & spoke topology. In addition to transmitting messages, MQ can also process workflows, Process Automation, data conversion, monitoring, and management.

3. Resource-Based Services

Resource-based services provide stateless Resource Access unrelated to transmission. Resources are abstract information. For example, a student registration is an abstraction that can be expressed in Web pages, XML documents, or PDF files. The Service uses resource identifier or address to represent each resource. Resource identifiers are actually relative to uniform resource identifiers (URIs. Each URI contains two parts: the mechanism (such as HTTP and FTP) and the address. The second part of URI is relative. The address/domain/account/45322 is relative unless it is directly associated with a mechanism, such as HTTP, http: // domain/account000022.

Figure 3 resource-oriented service concept model

A service defines a series of actions that may occur on resources: Create, read, update, and delete. In addition, some specific actions may trigger rules or business logic. When a resource is requested, the abstract representation of a physical resource that cannot be modified is returned. Based on the business logic, such as the customer type, the returned resource representation types vary according to different conditions. For example, most backend processing requires XML documents, while front-end processing may require JSON objects. The service can also receive representations about creating resources or updating existing resources. Finally, the service can also receive requests to delete resources.

Figure 4 Resource-oriented service interaction model

Transmission usually exists at the system boundary. When an event is detected, it sends a corresponding internal request. For example, the HTTP transmission listens to the URL requested by the customer. The URL specifies the access method (such as get, put, post, and delete ). The URL is converted to an internal relative Uri, And the access method is parsed as an action. When a request is transmitted through JMS, The URI and action are transmitted as the message header parameters. In addition, if a resource indicates that a message needs to be returned, a response queue parameter is stated in the response message header.

In a rest-style system, access to resources is stateless, that is, each request must be able to pass the content as meta-information. In general, transmission defines a message structure that includes the header and body. The header is used to transmit metadata, while the body is used to transmit the representation of resources. For example, if a Resource-oriented service is published over HTTP, the authentication information can be transmitted in the header. if the service is published through JMS, the same information can be transmitted as an encrypted header parameter.

Resource-oriented services can be built using maven4 and packaged as the netkernel module. Maven is a tool used to build and manage software within the scope of a "project. Maven projects are defined by the Project Object Model (POM) XML. Pom defines software dependencies, build processes, and deployment structures (such as jar, war, and ear ). In addition, Maven projects can be used to generate websites and deploy software for projects. In this case, Maven packs the service in the netkernel module and publishes the service-related information to the registration item.

Figure 5 Resource-oriented service development

4. Resource-Oriented Enterprise Service Bus (ESB)

Resource-Oriented Enterprise Service Bus (ESB) is implemented using netkernel. The center of netkernel is a restful or resource-oriented microkernel. It is responsible for parsing logical URI requests for physical code and arranging execution requests on idle CPUs. The ing between logical addresses and physical code is defined in the application structure. The actual binding of logical addresses and physical Code only occurs during request processing. Then, the binding is automatically discarded.

Because each request sent to the microkernel creates a new bundle, therefore, the system administrator can freely modify the association between the logical address and physical code in an environment similar to the real-time code update function. The actual performance does not seem to decrease because of this detour and bundling, but it can indeed improve the performance when the URI address is used as the primary key cached inside the netkernel. If a resource is requested again and the dependency is not modified, the cached resource is directly returned, and the system no longer needs to calculate it.

The use of resource-oriented micro-core has several major advantages. First, inter-service interaction is performed on the logical layer rather than the physical layer, which determines loose coupling interaction and reduces the impact of modifications made on the physical layer on customers and service providers. Second, the request results are cached, which can reduce the overall overhead of the synthesis service and compilation. For example, if a set of compiled services depend on the same service, the physical code behind the service is rarely executed. Finally, all internal requests sent to the microkernel are asynchronous. Therefore, as the number of CPUs on the host server increases, the processing capability will also linearly increase.

ESB is mainly responsible for service supply and security. Service provision includes publishing resource-oriented services to users through transmission protocols such as HTTP or JMS. The Transport Layer maps external Uris and access methods to an internal resource-oriented service and action. Skip transmission without looking at it. The request experience constructed in XML document or JSON object form is passed as a parameter named "Param. The result is that resource-oriented services are decoupled from the details of specific logic transmission. In fact, adding additional protocols at any time does not affect the existing code.

Figure 6 Resource-oriented service supply

Resource-oriented services are sequentially delegated to a set of customized basic services and core services provided by netkernel. Netkernel can provide a large number of core services, such as some core services that can process XML and soap, cron task scheduling, and SMTP interaction. Core Services can greatly reduce the amount of code required to implement a Resource-oriented service. Customized basic services can be used to serve the higher education field.

Each request sent to the ESB is first authenticated, then authorized, and sometimes audited. The transmitter authenticates an input request based on the username and password combination, and then delegates authentication and audit to the security service. The authorization process involves verifying that a verified user has the correct permissions. Each permission contains a relative Uri and action. For example, a user can have the read permission, but does not have the permission to update or delete the student archive resources identified by Uri/domain/student/identifier/profile. Unauthorized requests can be automatically audited. Audit Based on authenticated users or permissions is also optional. Accounts, permissions, and audit information are stored in an embedded hypersonic database.

Figure 7 Resource-oriented service security

Summary

Unlike runtime service management solutions such as actional or managedmethods, the middleware used to implement ESB is a required condition for any SOA success. Without an ESB, organizations can add P2P interactions simply by using Web Services. However, there are many different opinions on the composition and purpose of ESB, but most people are certain that it is a set of core functions, including service addressing, message conversion, and message routing. The ESB implemented using netkernel middleware not only provides these features, but also provides some advanced features such as service registration and service preparation.

The netkernel product enables the University to implement a Resource-Oriented ESB. Resource-Oriented ESB is essentially an open, standard-based enterprise integration framework. This framework allows enterprises to reduce or avoid the cost of P2P interaction and reduce the time to introduce new functions to the market. Further, this framework requires less startup money than the traditional WS-*-based enterprise integration framework. In addition, because the integration provided by netkernel and ROC is based on each service, the University can push the integration function to the edge of the network (such as URI ), it can be converted into better service management and better scalability. To put it simply, the Framework provides organizations with unprecedented and flexible enterprise architecture.

Within six months, a team composed of three software architects implemented a Resource-Oriented ESB and some initial resource-oriented services using netkernel middleware. This successful ESB implementation started the pace of transformation to SOA for the university. The resource-oriented approach enables the entire team to make full use of existing resources and technologies. In the future, the IT department of the University will be able to cope with increasing user needs by using reusable services and combined applications, while also reducing or avoiding P2P integration.