Microservice Hosting and Deployment Model

Neuron ESB 3.6 has been built on the principal of SOA and Microservices, hence it is the natural choice to build Microservice based APIs. In previous versions of Neuron ESB, organizations could easily create REST APIs or SOAP based services. However, in this release, they can now control the deployment aspect of it as well. Using Neuron ESB 3.6, organizations can now choose to run a service, (or group of services), as a fully independent service that can be scaled in or out based on consumption using platform services like Docker.

Endpoint Level Hosting

Previous Hosting Model

In previous versions of Neuron ESB, the Neuron ESB Runtime Windows Service (esbservice.exe) was used to host all Adapter and Service Endpoints, as well as all Messaging Publishing Services and all internal Services. These services were isolated in their own .NET AppDomains within the Neuron ESB Runtime service.  However, a fault tolerant hosting environment was provided for the Neuron ESB Workflow Engine. The hosting was embodied by Neuron ESB Availability Groups. Availability Groups were used to load balance the execution of Workflow Instances across multiple servers in dedicated/isolated host processes.

Neuron ESB 3.5 Hosting Model – Workflow Endpoints are hosted in dedicated hosts named “Availability Groups” (i.e. esbhost.exe). Any number of Availability Groups can be created. All internal services, Messaging services, Service Endpoints and Adapters Endpoints are isolated in .NET App Domains and hosted in the Neuron ESB runtime (i.e. esbservice.exe). Parties and Business Processes run in the host process of their respective Endpoint.

These Availability Groups were designed with built in clustering to achieve high availability and fault tolerance without the need to deploy Microsoft Windows Failover Cluster Services. Servers within a Neuron ESB Deployment Group could be assigned either Primary or Failover roles which allowed failed workflows to automatically rollover onto available servers and start where they left off, providing both resiliency and reliability for mission critical functions.

Neuron ESB Availability Groups – In Neuron ESB 3.5, Availability Groups provide isolated high availability clustered hosting for Neuron ESB Workflows. Servers can be defined for load balancing Workflow execution as well as dedicated failover.

Users could create any number of Availability Groups which in turn would be assigned to any number of Workflow Endpoints. Availability Groups were isolated into their own process space and executed as child processes (hosts) of the Neuron ESB Runtime service. If a fatal error occurred that caused an Availability Group host to fail, the Neuron ESB Runtime service could restart the Availability Group on the same server, or on a different server assigned the Failover role.

Endpoint Hosts

In Neuron ESB 3.6, we’ve refactored and extended Availability Groups to allow them to host Adapter and Service Endpoints. As a result, Availability Groups have been renamed to Endpoint Hosts and have taken on a new and expanded role within Neuron ESB.

Endpoint Hosts can be used to:

• Host a single endpoint
• Facilitate Microservice deployment
• Host multiple endpoints of the same type (i.e. Adapter, Service or Workflow)
• Host multiple endpoint of different types (i.e. Adapter, Service or Workflow)
• Host endpoints under a unique service account (different from that of the Neuron ESB Runtime service)
• Isolate endpoints for system wide fault tolerance
• Reduce memory utilization
• Scale processing power

In previous versions of Neuron ESB, every Adapter and Service endpoint competed for the CPU processing of a single executable (i.e. esbservice.exe). Other competitors for those processing cycles and threads included Neuron ESB’s own internal services, which would sometimes take precedent. In some cases, either an internal service or a specific endpoint could consume the majority of processing cycles, leaving other endpoints waiting for available threads to be returned to the pool before being allowed to service requests. Additionally, even though all endpoints and internal services were encapsulated in their own .NET AppDomain, it did not preclude the possibility that one misbehaving Business Process, Adapter Endpoint or, custom code writing by a customer could crash the Neuron ESB Runtime process (i.e. esbsevice.exe).

Endpoint Hosts relieves these issues as each runs as an isolated process (i.e. NeuronEndpointHost.exe), with its own allocation of resources and threads. Using Endpoint Hosts, endpoints can be isolated into discreet, lightweight processes and deployed across multiple machines.

Neuron ESB 3.6 Hosting Model – All Adapter, Service and Workflow Endpoints can now be hosted in dedicated hosts named “Endpoint Host” (i.e. NeuronEndpointHost.exe). All internal services and Messaging services are isolated in .NET App Domains and hosted in the Neuron ESB runtime (i.e. esbservice.exe).

In Neuron ESB 3.6, Endpoint Hosts are more lightweight than their immediate predecessor, Availability Groups. Their executable has renamed and the communication mechanism and been changed to use an HTTP based API (default port 51004 can be changed in appSettings). Additionally, endpoints using this hosting model are no longer encapsulated in .NET AppDomains.

NOTE: By default, all new endpoints will run in the Neuron ESB Runtime service unless they are specifically assigned to an Endpoint Host using the “Endpoint Host” property located on their respective UI configuration screens. However, if migrating a solution saved in a previous version of Neuron ESB, those endpoints will automatically be assigned to run in the new Endpoint Host environment.

Monitoring

Neuron ESB Endpoint Health has been refactored to accommodate real time activity monitoring for the Endpoint Host environment as well as the different endpoints that they host. The new user interface provides users the ability to group and sort, and now lists all machines in the selected deployment group.

Neuron ESB Endpoint Health – Real time monitoring of both Neuron ESB Messaging and Workflow. Endpoint Hosts (child process) and their Endpoints can be stopped and started from here. Real time activity of Endpoints can be monitored.

The Neuron ESB Endpoint Health interface has a scalable horizontal divider, separating Neuron ESB Messaging entities such as Topics, Adapter and Service Endpoints that are hosted in the Neuron ESB Runtime service from those hosted in the Endpoint Host environment. A context menu is exposed at the entity level that allows users to restart any selected endpoint or Endpoint Host.

Security

Neuron ESB has always provided options for managing runtime security. In previous versions of Neuron ESB, the Neuron ESB Runtime could be set to run under the context of a specific Windows local user or domain account, providing it had the necessary permissions and was granted the “Log on as a Service” right. Any service or endpoint hosted by the Neuron ESB Runtime would essentially inherit that security context during execution. If an Availability Group was created, it would inherit those same credentials. Unfortunately, this meant that there was no way to run a given Workflow Endpoint under a set of credentials other those set at the Neuron ESB Runtime level. Only Adapter Endpoints had a “Run As” option which allowed users to specify an alternate set of credentials for an Adapter Endpoint to use at runtime.

NOTE: Requirements for changing the Neuron ESB Runtime service account can be found in the “Neuron ESB Runtime – Running under User Account” section of the Readme.html document installed in the default location of the Neuron ESB installation folder.

Microsoft Windows Service Control Manager – Displays the Neuron ESB Runtime service set to use the Local System Account credentials.

We modified this capability in Neuron ESB 3.6, introducing a Run As option at the Endpoint Host level. Unlike the service account used for the Neuron ESB Runtime service, these credentials do not require the “Log on as a Service” right. However, all other caveats that apply to the Neuron ESB runtime service account apply to the Endpoint Host credentials as well. Using Neuron ESB 3.6, users can create the appropriate Windows Credential by navigating to Security->Authentication->Credentials within the Neuron ESB Explorer. Once created, this credential will appear as an account that can be assigned to an Endpoint Host via its Run As property.

Neuron ESB Explorer – Endpoint Host – Run As property can be set with a Windows Credential stored in the Security repository of the Neuron ESB solution. The Endpoint Host will run under the credentials context at runtime.

The Run As capability for Endpoint Hosts functions much like the Run As for Adapter Endpoints. Everything executing in the Endpoint Host process space will execute under the context of the Run As credential. That means any resource that the endpoint, its underlying Party or Business Processes access will be under the context of the assigned credential. Essentially this provides the ability to change the security context at the endpoint level or for a group of endpoints, regardless of their type (i.e. Adapter, Service or Workflow).

Memory Consumption

While developing the new hosting model for Neuron ESB 3.6, we took the opportunity to reevaluate the memory utilization footprint of both the Neuron ESB Runtime and Endpoint Host. Historically, the Neuron ESB Runtime made liberal use of memory to enhance execution time. It also provided the configuration and document repositories as in memory objects that could be retrieved and manipulated at runtime, by developers as well as internal Neuron ESB services. But there was a price, especially due to our usage of .NET AppDomains. It wasn’t unusual where large solutions with 100’s of Business Processes, 100s of Service Endpoints and 100s of Adapter Endpoints could easily consume 10+ Gigabytes of Working Set memory on startup.

In Neuron ESB 3.6, we completely changed how we manage and share configuration objects internally as well as shared resources. Users will find that solutions which required 10+ gigabytes of memory on startup, will consume anywhere from 2X to 5X less memory.

We tested this with a large solution, containing almost 200 Adapter Endpoints. We chose Adapter Endpoints as they tend to consume more memory than Service or Workflow Endpoints due to the proprietary assemblies that must be loaded with each one. Additionally, the solution contained a couple of hundred large Business Processes, 50 Topics, several Service Endpoints and other Neuron specific entities. When this solution was loaded and started in Neuron ESB 3.5.4, it consumed over 11 gigabytes of Working Set memory and took several minutes to startup.

We migrated the solution to Neuron ESB 3.6. We assigned all the Service and Adapter Endpoints to a single Endpoint Host. The Neuron ESB Runtime was relegated to Messaging Publishing Services (i.e. Topics) and our internal services. A noted observation was the startup time. The entire solution took less than 1 minute to startup, whereas under Neuron ESB 3.5, several minutes was required.

Neuron ESB Explorer – Endpoint Health in 3.6 – Endpoint Health screen showing 52 started Topics, 176 started Adapter Endpoints, 6 started Client Connectors, 3 started Service Connectors and 1 started Workflow. This solution also included 212 Business Processes. Total startup time was approximately 1 minute.

Once the solution was completely started in Neuron ESB 3.6, we noticed a significant reduction in the Working Set memory. By default, an Endpoint Host startup memory footprint is just under 200 MB of memory (no endpoints assigned). The total combined Working Set memory of the Neuron ESB Runtime and Endpoint Host was under 2.3 gigabytes. This represents about a 5X improvement in memory utilization.

Windows Resource Monitor – Displays CUP and Memory statistics of the Neuron ESB Runtime (ESBService.exe) and the Endpoint Host (NeuronEndpointHost.exe) after startup.

Adapters/Connectors

Adapters are a key piece of capability in the world of an integration broker. They serve as the bridge to and from the bus between applications, databases, transports and protocols.  The completeness of “what” you ship as well as how easy it is for others to build their own adapters is critical in accelerating the development of any solution. Not only is Neuron ESB one of the easiest adapter frameworks to learn in the industry, it also has pre-built adapters for most commodity transports, queuing technologies, databases and on-premise/cloud applications. Staying true to our roots, several changes have been introduced in this release to make connectivity easier, more intuitive as well as performant.

Messaging Configuration

Historically, Neuron ESB used its powerful messaging sub system to abstract and decouple service and adapter endpoints from one another. In essence, endpoints would adopt either a publisher or subscriber role, where neither would have to know about the other and, where modifying one would not affect the other. This model remains incredibly beneficial for those systems requiring a loosely coupled design. New subscribing or publishing endpoints could be added without impacting the processing of the other endpoints. However, those designs usually employ one way, multicast patterns. There are other scenarios (request/response patterns for example) though where inserting messaging as a decoupling agent makes little sense. In those scenarios it imposes unnecessary overhead, configuration and restrictions. For example, it’s unusual in request/response patterns that there would ever be more than one subscribing endpoint at a time fulfilling a request.

This depicts Messaging being used to decouple Service and Adapter Endpoints. Prior to the 3.5 release all endpoint communication was brokered by using the Neuron ESB Messaging sub system.

In Neuron ESB 3.5, we introduced the capability for users to call Adapter and Service Endpoints directly (without the messaging sub system) using either the Business Process engine or the Workflow engine. However, messaging elements would still need to be created, even though those elements were not used at runtime. For example, to create an Adapter Endpoint that could be used in the Business Process or Workflow Designer users were still required to first create a Topic, Publisher and Subscriber, and then associate those elements with the Adapter Endpoint using the Neuron ESB Explorer user interface.

In Neuron ESB 3.5, Adapter and Service Endpoints can be executed directly by a Neuron ESB Business Process rather than having the original request forwarded across the Neuron ESB Messaging sub system.

In this release we’ve made it a lot easier for developers to create Adapter Endpoints that they intend to execute directly within our Business Process or Workflow engines. Starting with Neuron ESB 3.6, users can choose to simply disable the Messaging option located on the General tab of an Adapter Endpoint for all subscribe mode type of Adapter Endpoints. This allows the developer to create an Adapter Endpoint without needing to first create a Topic or Subscriber. At runtime, the Adapter Endpoint can be called directly within the Business Process or Workflow Engine but will not be a “live” subscriber to messages published by other systems. Some immediate benefits this provides are:

• Reduced Complexity
  • No need to create a Topic or Subscriber before configuring an Adapter Endpoint.
• Reduced Runtime Utilization
  • The Adapter Endpoint does not need to be loaded in memory with its own resources.
  • The Topic Publishing Service is never created.
• Faster Startup Time
  • Since there is no subscribing Adapter Endpoint, the master runtime does not attempt to start it as a manageable endpoint.
  • The Topic is also not created and loaded by the master runtime.

Neuron ESB Explorer – Adapter Endpoint User Interface. This has been refactored in 3.6. This now has a Message option which can be enabled or disabled by selecting the “Publish/Subscribe” checkbox encircled in Red.

Hosting Model

The Neuron ESB 3.6 release introduces a new hosting model that allows Adapter Endpoints (and all endpoints) to be hosted either independently or with other endpoints in a configured Endpoint Host. This is in contrast to previous releases where, although each Adapter Endpoint was isolated in their own .NET App Domain, they were hosted within the main Neuron ESB runtime process (i.e. esbservice.exe) with all other internal services, Messaging Publishing services and Service Endpoints.

Using this new model, one or more Adapter Endpoints can be assigned to a dedicated Endpoint Host to provide resiliency, failover, and scale as well as process isolation. The latter becomes important in the case of a misbehaving endpoint or, Business Processes associated with that endpoint, which have the potential to crash a process/host. If isolated to an Endpoint Host, the misbehaving endpoint or Business Processes can’t affect any other running endpoints or the core Neuron ESB runtime process.

Neuron ESB 3.6 Hosting Model – All Adapter, Service and Workflow Endpoints can now be hosted in dedicated hosts named “Endpoint Host” (i.e. NeuronEndpointHost.exe). All internal services and Messaging services are isolated in .NET App Domains and hosted in the Neuron ESB runtime (i.e. esbservice.exe).

In the Neuron ESB 3.6 release, users can configure an Adapter Endpoint to run in either the existing Neuron ESB runtime host (as in previous versions) or the new Neuron Endpoint Host. The default behavior is for new Adapter Endpoints to run in the existing Neuron ESB runtime host. Users can change the hosting model by selecting a configured Neuron Endpoint Host in the Endpoint Host property dropdown box located on the General tab of the Adapter Endpoint.

Neuron ESB Explorer – Adapter Endpoint User Interface. This has been refactored in 3.6. This now has an Endpoint Host dropdown box property that lists all available Endpoint Hosts. When none is selected, the original Neuron ESB Runtime Host (i.e. esbservice.exe) will be used.

Services Endpoints

Neuron ESB includes a Service Broker that enables organizations to deploy Neuron ESB as a Service Gateway, providing mediation, security, hosting and a number of other services. Service Connectors are essentially registrations within Neuron ESB that point to existing services (i.e. REST or SOAP APIs) hosted within an organization, partner or cloud domain. Client Connectors on the other hand are REST or SOAP APIs created using the Neuron ESB toolset and hosted by Neuron ESB. These are live services that can accept external requests, initiate business processing logic and/or broker to external services or applications.

Messaging Configuration

In this release, Service Endpoints have been redesigned to use the same Messaging option as introduced to Adapter Endpoints. Users can choose to simply disable the Messaging option located on the respective tab of the Client Connector (i.e. publisher role) and Service Connector (i.e. subscriber role) of the Service Endpoint. Unlike Adapter Endpoints though, this is not limited to subscribe mode Service Endpoints (i.e. Service Connectors). Messaging can be disabled on Client Connectors as well.

Service Connectors

Just as with Adapter Endpoints, subscribe side Service Endpoints (i.e. Service Connectors) can be executed directly within a Business Process or Workflow.

In Neuron ESB 3.5, Adapter and Service Endpoints can be executed directly by a Neuron ESB Business Process rather than having the original request forwarded across the Neuron ESB Messaging sub system.

Because of their similarity with subscribe mode Adapter Endpoints, in Neuron ESB 3.6 we made it just as easy for developers to create Service Connectors that they intend to execute directly within our Business Process or Workflow. Users can now specifically choose to disable the Messaging option located on the Service Connector tab of the Service Endpoint. This allows the developer to create a Service Connector without needing to first create a Topic or Subscriber. At runtime, the Service Endpoint can be called directly within the Business Process or Workflow but will not be a “live” subscriber to messages published by other systems. The immediate benefits to this approach are identical to Adapter Endpoints:

• Reduced Complexity
  • No need to create a Topic or Subscriber before configuring a Service Connector.
• Reduced Runtime Utilization
  • The Service Connector does not need to be loaded in memory with its own resources. The Topic Publishing Service is never created.
• Faster Startup Time
  • Since there is no subscribing Service Connector, the master runtime does not attempt to start it as a manageable endpoint.
  • The Topic is also not created and loaded by the master runtime.

Neuron ESB Explorer – Service Connector User Interface. This has been refactored in 3.6. This now has a Messaging option which can be enabled or disabled by selecting the “Subscribe” checkbox encircled in Red.

Client Connectors

In this release, although Messaging can also be disabled for Client Connectors, it is for a different purpose than that of Service Connectors. Rather than disabling live hosting of the Service Endpoint, disabling Messaging allows the user to configure a Client Connector to call and execute Business Processes directly, without the need to configure the Client Connector with a Publisher and Topic.

In previous releases, users could always expose a Business Process as a web service (REST or SOAP) indirectly. The steps were simple, but like everything with multiple parts, complexity introduces itself. For example:

1. Create a Topic
2. Create a Publisher
3. Create a Business Process
4. Configure the Publisher to call the Business Process
5. Create a Client Connector
6. Configure the Client Connector to send the inbound message to the Publisher, which executes the Business Process and forwards to the Topic

Using Neuron ESB 3.6, we can reduce this to a 3 step task and eliminate unnecessary dependencies i.e.

1. Create a Business Process
2. Create a Client Connector
3. Configure the Client Connector to call the Business Process

Selecting the Business Process option of the Processing Mode section of the Client Connector effectively disables the Messaging option and allows users to select one or more Business Processes to execute directly from the Service Endpoint UI.

Neuron ESB Explorer – Client Connector User Interface. This has been refactored in 3.6. This now has a Processing Mode group box which contains a Messaging and Business Process mode option. If Messaging is selected, controls appear to allow users to select a Publisher and Topic. If Business Process is selected, users can select the Edit Processes toolbar button to select Business Processes to execute (encircled in Red).

Selecting the “Edit Processes” toolbar button, displays the same Processes dialog used to select Business Processes for Publishers and Subscribers.

Processes dialog – Launched from the Edit Processes toolbar button of the Client Connector. Allows user to select one or more Business Processes for the Client Connector to directly execute.

Once a Client Connector is configured to execute Business Processes directly through the new Processing Mode option, developers will no longer need to create a Publisher or Topic as part of the configuration process. Additionally, when creating Business Processes, users can forego the placement of the Cancel Process Step as the last step in the Business Process when dealing with request/reply patterns. Client Connectors directly executing Business Processes incur other benefits as well including

• Reduced Complexity
  • No need to create a Topic or Publisher before configuring a Client Connector.
  • No mapping of Business Process to Publisher and Publisher to Client Connector
  • No need to use a Cancel Process Step in Business Processes to return the reply message to the calling client or prevent a message from being forwarded to a Topic.
• Reduced Runtime Utilization
  • The Topic Publishing Service is never created.
  • Less processing and memory consumed by the Client Connector
• Faster Startup Time
  • The Topic is not created and loaded by the master runtime.
• Better Performance
  • All requests are no longer being brokered by a Publisher object

In Neuron ESB 3.6, Client Connectors can execute Business Processes directly, without an intermediate Publisher brokering messages across the Neuron ESB Messaging sub system.

Limitations

Client Connectors configured for direct execution of Business Processes should be the preferred mode of operation for users. This will generally provide simpler and more efficient execution of messages and Business Processes. Even though in this configuration there is no Publisher or Topic associated with an endpoint, messages received by the Client Connector can still be published to topics using the Publish Process Step within the Business Processes it’s executing. All Topic transports are supported. The only use case that is not supported is using MSMQ based topics when the Publish Step is configured with the Request Semantic.

Hosting Model

Just as with Adapter Endpoints, in previous releases each Service Connector and Client Connector were isolated in their own .NET App Domain. They were hosted within the main Neuron ESB runtime process (i.e. esbservice.exe) with all other internal services, Messaging Publishing services and Adapter Endpoints.

Neuron ESB 3.5 Hosting Model – Workflow Endpoints are hosted in dedicated hosts named “Availability Groups” (i.e. esbhost.exe). All internal services, Messaging services, Service Endpoints and Adapters Endpoints are isolated in .NET App Domains and hosted in the Neuron ESB runtime (i.e. esbservice.exe).

In this release, Service Endpoints have been redesigned to use the new Neuron Endpoint Host model that Adapter Endpoints can now use. In Neuron ESB 3.6, all endpoints (Workflow, Service and Adapter) share the same hosting model. That means that both Client Connectors and Service Connectors can be configured to run using either the existing Neuron ESB runtime host (esbservice.exe) or the newer Endpoint Host for process isolation.

Neuron ESB 3.6 Hosting Model – All Adapter, Service and Workflow Endpoints can now be hosted in dedicated hosts named “Endpoint Host” (i.e. NeuronEndpointHost.exe). All internal services and Messaging services are isolated in .NET App Domains and hosted in the Neuron ESB runtime (i.e. esbservice.exe).

In the Neuron ESB 3.6 release, users can configure a Service Endpoint to run in either the existing Neuron ESB runtime host (as in previous versions) or the new Neuron Endpoint Host. The default behavior is for new Service Endpoints to run in the existing Neuron ESB runtime host. Users can change the hosting model by selecting a configured Neuron Endpoint Host in the Endpoint Host property dropdown box located on the General tab of the Service Endpoint.

Neuron ESB Explorer – Service Endpoint User Interface. This has been refactored in 3.6. This now has an Endpoint Host dropdown box property that lists all available Endpoint Hosts. When none is selected, the original Neuron ESB Runtime Host (i.e. esbservice.exe) will be used.