Using Netkerne to implement a restful ESB

Background

The University of New England has launched a multi-year infrastructure modernization project designed to progressively replace outdated systems and provide as much of it functionality as possible while maximizing the return on all IT investments. This project involves hardware upgrades, buying new software, developing training and training for the operations team, and so on. The center of this modern strategic project is the implementation of a service-oriented architecture (oriented Architecture-soa).

SOA is the overall platform architecture approach that focuses on distributed application design, rather than on specific technologies. The key to SOA is the definition and implementation of software services, which map directly to a system or to a number of business process services, regardless of the location of the service and the ownership of the services, including the interfaces and policies that manage them at run time. The benefits of SOA include loose coupling between interacting systems and platforms, ubiquitous enterprise-standard integration mechanisms, support for on-demand (on-demand) creation of composite services, and the ability to take full advantage of existing assets while increasing operational efficiencies.

Figure 1 Service-oriented architecture

The shift from a traditional application to a service based approach is huge and cannot be done overnight. The IT department of the University of New England worked with Capgemini Consulting to paint a roadmap for incremental adoption of SOA. One advantage of the incremental approach is the ability to immediately see the return on investment and to choose the sequence of transitions to best fit the school's short-and long-term goals. This article will describe in the following sections how this 6-month project is leveraging 1060 's netkernel to implement a resource-oriented enterprise service bus (Resource oriented Enterprise service Bus) to start the adoption process of SOA.

Problem areas

Higher education institutions are constantly under pressure from students, employees and alumni to provide a wide range of online services to accommodate the growing habits of these users, such as providing real-time, 7*24-hour information access through intuitive user interfaces and automated processes. At the same time, the pressure on boards from management, steering committees (Steering committees) and control overhead has grown. As a result, IT departments in higher education institutions such as universities must be more alert and pragmatic when investing in new features.

The University IT department supports a wide range of applications, such as PeopleSoft (commercial off shelf--cots) products, created in the Customer Information control system System--cics, a large host legacy system, and a modern Java EE Web application built using the Oracle Application Server portal. In addition, many of these applications interact with third party application service providers (ASPs) to provide historical data to the Data Warehouse (DW). In this project, all of these applications must be integrated and coordinated with the new SOA approach.

The university used to integrate business systems by using IBM MQ and FTP. These traditional approaches result in a large number of peer-to-peer integrations, all of which are costly to maintain and lead to tight coupling between customers and suppliers. However, the existing environment already uses the lightweight messaging Exchange state transfer--mest, which leaves room for further innovation. The Enterprise Service Bus (ESB) is a subtype of the message bus architecture that provides a more decoupled environment, but when its upfront deployment costs are relatively high, the value of the ESB increases exponentially over time, while the cost of extending the system grows linearly and is expected to be 1.

The university's IT department has a development team of specialized architects and software engineers, many of whom have become experts in the field of higher education through their positions. Because the development team is small, each member often has to play multiple roles in the development process, including support and management of the software. For this reason, IT departments urgently need a solution that can achieve the following:

Meet growing customer needs by leveraging reusable services and composite applications

Reduce or avoid peer-to-peer integration

Make full use of existing resources and technologies to improve operational efficiency

Solution 1. General overview

SOA can be implemented through a number of different patterns and technologies. The traditional approach is to select the patterns listed in the ws-* specification and to choose from a wide range of technology offerings such as the Apache ServiceMix, open source solutions or Cape Clear and sonic software business kits. Unfortunately, the ws-* specification is still in constant revision, and developers have to digest 1300 of pages of documentation to get technical details that are daunting enough for many people. For example, implementing a SOAP service requires the following steps if you fully adhere to all the specifications:

Use Business Process Modeling notation (BPMN) to model the process.

Use WSDL to define service interfaces, and to register services using UDDI (Universal Description,discovery and integration--Unified Description, Discovery, and integration) libraries.

Generate Business Process Execution Language (BPEL) by using BPMN that registers access services from the service.

Use Ws-policy to define administrative policies for access services.

The commercial ESB suite on the market has been evaluated by all parties, as the IT team is relatively small, the final team decides to look for a solution that ultimately leads to a small contradiction or conflict between systems; it needs the innovation that is within the reach of the smaller IT team's human resources. ; It should not force the team to use a centralized service-centralized model that relies on a single vendor. The university's field is highly liquid, has the changeable flow, the changeable application, as well as the changeable integration, therefore, it needs is can reflect the university true natural characteristic the overall structure and the strategy.

Because the message request was previously a central transport mechanism across the university, the team decided to choose a rest type or resource-oriented (resource-oriented) approach to implement SOA. Rest is based on a smaller set of widely accepted standards, such as HTTP and XML, that do not require a lot of development steps, a lot of toolbox, and an execution engine. There are three main advantages to implementing SOA in a rest-type manner: lower overhead, faster market, and flexible architecture. Resource-oriented approaches provide a broader base of extended and independent communications based on a restful style. Rest design mode advocates the use of HTTP, while resource-oriented schemas support connecting services to HTTP and communication protocols such as JMS or SMTP.

Although there are some ESB implementations like Codehaus mule that support rest, only 1060 NetKernel is built on the resource-oriented computing platform 2 (resource-oriented Computing Platform, "ROC"). The core of resource-oriented computing is the separation of the logical request for information (resources) from the physical mechanism (code) that sends the request. Services built using ROC are proven to be small, simple, flexible, and less code than the traditional way to implement. These advantages determine that it is the ideal technology choice to create a technology platform.

2. Technology Platform

NetKernel is a resource-oriented middleware that provides the core capabilities of the Enterprise Service Bus (ESB): Addressing, routing, and data transformation, and can work like a service registry (orchestration) engine. NetKernel offers a number of features that provide advanced functionality such as XML transformation, cache management, multithreading, and a variety of transport protocols, including HTTP and JMS, while the SOAP engine enables it to provide traditional Web services. NetKernel is a solid foundation for heterogeneous enterprise integration.

Conceptually, NetKernel provides access to resources that are identified by a Uniform Resource Identifier (URI) address. All URI addresses are managed uniformly in a logical address space. The rest based micro-core handles all resource requests, resolves the URI address from the address space, and returns the representation of the resource. Requests sent to a micro-issue can also be used to create new resources, update or delete existing resources.

Physically, the NetKernel system is composed of modules that expose public service interfaces and resources through URI addresses. Like the Java ear, each module contains source code and resource configuration. A module can logically introduce the public services and resources of another module and include them in the address space. Multiple versions can be run and updated on the same system because of the introduction of the logical name of the module and the ability to identify the version number. Service requests are injected into the netkernel via the transmitter, which is the event detector at the edge of the system. The customer of the service can send the request through any supporting transmitter, such as HTTP or JMS.

Figure 2 Technology Platform