| Contact | Customer Login

Flink-ESB Message Gateway

One access point for all your services

Use Flink-ESB Message Gateway Config Console or SQL scripts to configure façade entries, security policies, request validation rules, request/response transformation rules, routing rules

You can access both internal services within your corporate network, or external services over proxies

Define different groups per façade entries and have several gateway instances handling services on different URLs

Start as many gateway instances as you need to handle the traffic

Add security layer to your services

Security is important topic when you expose your internal services to the internet, or when you migrate them to the cloud

Flink-ESB Message Gateway offers you very flexible options on how you want to protect these services. You can assign zero (no authentication needed) or multiple roles (authentication needed) to every façade entry

You can choose between authenticating with LDAP, Database or File. With LDAP authentication you can enhance it by using a custom route, so that you can authenticate users with your corporate LDAP, but still have flexibility of assigning user roles in a way that fits your needs

Access JMS services over HTTP

Flink-ESB Message Gateway handles protocol conversion (HTTP to JMS) automatically

You can expose internal services, that are available over HTTP/HTTPS or JMS. Gateway converts the message into appropriate format and sets all required JMS properties or HTTP headers

If needed, you can configure in Config Console or with SQL script message properties, that will be added as JMS properties or HTTP headers

Use different message formats

Flink-ESB Message Gateway allows you to configure multiple entries pointing to the same internal service. This way you can call the same services using different message formats

Internal SOAP service can be presented to the outside world as REST service, or the data can be exchanged in JSON format

For example, you can call SOAP service that expects HTTP POST with message body using REST GET

Access internal and external services

If part of your applications are in your corporate network, and part are in cloud or any other kind of external network, you can still create one access point to all of them, provided TCP access is possible

Configure proxies in Config Console and assign them to destinations, where direct connection is not possible

You can create any number of proxies, and Message Gateway will just use them without need to restart anything

Handle huge data (> 500 GB supported)

Configure façade entry to be in stream mode if you want to process huge data over that URI without consuming RAM

Flink-ESB Message Gateway can transfer files bigger than 500 GB over HTTP to any remote location

Create one access point to all your services

Use Flink-ESB Message Gateway Config Console or SQL scripts to configure façade entries, security policies, request validation rules, request/response transformation rules, routing rules

You can access both internal services within your corporate network, or external services over proxies

Define different groups per façade entries and have several gateway instances handling services on different URLs

Start as many gateway instances as you need to handle the traffic

Add security layer to your services

Security is important topic when you expose your internal services to the internet, or when you migrate them to the cloud

Flink-ESB Message Gateway offers you very flexible options on how you want to protect these services. You can assign zero (no authentication needed) or multiple roles (authentication needed) to every façade entry

You can choose between authenticating with LDAP, Database or File. With LDAP authentication you can enhance it by using a custom route, so that you can authenticate users with your corporate LDAP, but still have flexibility of assigning user roles in a way that fits your needs

Access JMS services over HTTP

Flink-ESB Message Gateway handles protocol conversion (HTTP to JMS) automatically

You can expose internal services, that are available over HTTP/HTTPS or JMS. Gateway converts the message into appropriate format and sets all required JMS properties or HTTP headers

If needed, you can configure in Config Console or with SQL script message properties, that will be added as JMS properties or HTTP headers

Use different message formats to call services

Flink-ESB Message Gateway allows you to configure multiple entries pointing to the same internal service. This way you can call the same services using different message formats

Internal SOAP service can be presented to the outside world as REST service, or the data can be exchanged in JSON format

For example, you can call SOAP service that expects HTTP POST with message body using REST GET

Access internal and external services

If part of your applications are in your corporate network, and part are in cloud or any other kind of external network, you can still create one access point to all of them, provided TCP access is possible

Configure proxies in Config Console and assign them to destinations, where direct connection is not possible

You can create any number of proxies, and Message Gateway will just use them without need to restart anything

Handle huge data (> 500 GB supported)

Configure façade entry to be in stream mode if you want to process huge data over that URI without consuming RAM

Flink-ESB Message Gateway can transfer files bigger than 500 GB over HTTP to any remote location

Use Flink-ESB Message Gateway Config Console or SQL scripts to quickly configure instances of Gateway

Any number of Message Gateway instances can be started from one DB configuration. You can even have Message Gateway instances in different environments use the same database

Use different config groups to have different running instances handling different URIs

Clone configuration on multiple environments just by running SQL scripts. No adjustments in the database needed to create more environments from existing one

Any environment specific data in the database can and should be replaced by project variables

Apply changes to configuration and post them to running instances with no downtime

100% flexibility on defining your rules for validating requests, transforming requests/responses and selecting destinations

Despite its flexibility it is very fast and is able to handle any traffic

Quickly apply security policies to selected entries. Following authentication mechanisms are supported: LDAP, Database or File. With LDAP authentication you can enhance it by using a custom route, so that you can authenticate users with your corporate LDAP, but still have flexibility of assigning user roles in a way that fits your needs

Transform any message format to any message format. No exceptions to that rule. For example have rules for receiving REST GET requests, converting them to SOAP and sending to JMS queue, setting any custom JMS properties

Easily convert between transports HTTP / HTTPS / JMS

If needed provide credentials (user/password) to reach destinations

If not possible to reach some destinations directly, define and assign any number of different proxies to be used

Work with huge data (> 500 GB) without consuming internal memory for this

Easy configuration

Does not matter whether it's only few or hundreds of services that you would like to access using Flink-ESB Message Gateway. Configuration will be as easy as running couple of SQL statements or entering data in Config Console

Configure it just once in test or development environment. Clone your configuration to create production environment within seconds

Disable and/or enable configuration entries in Config Console or using SQL scripts without having to delete entries

Assign one or multiple groups to config entries and be able to start multiple gateway instances handling different URLs from the same configuration

Flexible authentication / authorization

Define what services should be password protected by assigning one or multiple roles to corresponding façade entries

Three types of authentication are supported: FORM, BASIC and DIGEST. Choose whether you want to authenticate against LDAP, Database or File. With LDAP authentication you can enhance it by using a custom route, so that you can authenticate users with your corporate LDAP, but still have flexibility of assigning user roles in a way that fits your needs

Configure user/password for HTTP destinations which expect user to authenticate

Use project parameters

Some configuration entries contain environment specific parameters. For example, destination expression usually contains HTTP hostname and port, where a certain service is available, or if service is password protected, username and password are defined. Such environment specific values differ from environment to environment

Replace such environment specific values with "project parameters" if you want to be able to clone configuration quickly for multiple environments

As a rule of thumb should be: no environment specific values should be in database configuration. All such values should be replaced by project variables

Migrating applications to cloud

Whether you are planning to migrate existing applications to the cloud, set up new applications in the cloud or both, having a central access point to all the services makes this task much easier

For users of your services in the internet and your corporate network, or for applications using the services, this change will be absolutely transparent if they access your services via Message Gateway

They will continue using same URLs, no changes to existing applications will be needed

You can add security layer per facade entry, and control who can access which services

Migrate the applications one by one or several at once. Just make sure you configure Message Gateway to reflect the changes

With Message Gateway you can plan this task with no service downtime at all. Set up your application in cloud, add new configuration in Message Gateway, make sure

all services on new place are accessible (Flink-ESB Admin Console will help you to test all relevant services), then just reassign existing URLs on Message Gateway to point to the new destinations

You don't need to restart anything, just post the new configuration, and you are good to go

In case you want to roll back for one or several applications to fix some issues, this also can be done with no outage. Just reassign old destinations for those applications, test them, and then post the configuration to activate it to everyone. Rolling back the whole activity is even easier. Since all the configuration is stored in the database - just restore the database to the previous state and post the configuration

If you are worried about having one point of failure for all your services with Message Gateway - you can start as many Gateway instances as you need it to handle your traffic and assure smooth operation even in case some instances crash

Video Tutorials

Use case 1: Ticketing service is available over 3 JMS queues. Tickets with priority 1 are served on queue "urgent", priority 2 and 3 - on queue "normal", priority 4 - on queue "slow". Messages are expected in XML format as defined in schema file "ticket.xsd". Task is to create HTTP POST entry on Flink-ESB Message Gateway, which would validate requests against XSD file and route them according their priority to the relevant queue. Use Flink-ESB Config Console to create new facade entry. Use Flink-ESB Admin Console to test new HTTP POST service and verify its functionality

Show use case 1 video

Use case 2: CD catalogue service is available on remote server under POST http://192.168.2.110:9090/catalogue/cd. This service searches for CD in the catalogue by ID. Messages are expected in XML format. Task is to create REST GET entry on Flink-ESB Message Gateway with URI /catalogue/cd/{id}, which would generate message in XML format as catalogue service expects and send it to the catalogue service. Response should be transformed using XSLT script. Message Gateway should also add HTTP "Content-Type" header to request and response

Show use case 2 video

Use case 3: CD catalogue "AddCD" service is available on remote server under POST http://192.168.2.110:9090/add/cd. This service adds CD from the request XML to the catalogue. Task is to create façade entry on Message Gateway for HTTP method POST on URI /calalogue/cd. Request must be validated (mandatory fields "id", "title", "artist" must be checked). Message must be sent to http://192.168.2.110:9090/add/cd over HTTP proxy. HTTP header "Content-Type" must be added

Show use case 3 video

Use case 4: CD catalogue "ModifyCD" and "DeleteCD" services are available on remote server under POST http://192.168.2.110:9090/modify/cd and http://192.168.2.110:9090/delete/cd. These services modify or remove CD from the catalogue. Messages are expected in XML format. Task is to create façade entries on Message Gateway for HTTP PUT on URI /calalogue/cd and for HTTP DELETE on URI /catalogue/cd/{id}. Request for "ModifyCD" must be validated (mandatory fields "id", "title", "artist" must be checked). Message must be sent to 192.168.2.110:9090 over HTTP proxy created in tutorial for use case 3. HTTP header "Content-Type" must be added to requests and responses. Also authentication must be added to all catalogue services "SearchCD" from tutorial 2, "AddCD" from totorial 3, "ModifyCD" and "DeleteCD". Only users having roles "user" or "admin" should be able to search. Only users having role "admin" should be able to insert, modify and delete

Show use case 4 video

Define Façade Entries (URI where the service can be reached)

Use Message Gateway Config Console or SQL scripts to define façade entries

These entries contain: URIs where façade entries can be reached; HTTP method (GET, POST, PUT or DELETE); security roles (you can define no roles, which means no authentication needed, or one or multiple roles - to protect this URL); group: one or multiple strings, which help to group services

You can define URI as regular expression, like "/.*". In this case all requests hitting Message Gateway will be handled by this channel

Mark façade entry as "stream_mode" to handle huge files without consuming internal memory (files bigger than 500 GB are supported)

Mark façade entry as "disabled" to disable entry (for example temporarily) without having to delete it completely. You can reenable it any time later, or delete it

Define Validation Rules you might apply to incoming requests

Use Message Gateway Config Console or SQL scripts to define validation rules

These are rules you might want to apply to incoming requests to check their validity. There are two types of rules: SCHEMA and CUSTOM

With SCHEMA rule type define URL of XSD schema file (can be on file system, HTTP URL or FTP URL). Message gateway will parse incoming requests against this schema file, if that rule is assigned to façade entry. If parsing against schema file fails - request is rejected

With CUSTOM rule type define any MVEL expression, which should return either "true" or "false". If it returns "false" - request is considered failed validation and is rejected. Using this rule type you can apply any kind of checks. MVEL expression is either static or dynamic. Dynamic means it can give different results based on incoming message content

You can assign zero or multiple validation rules to every façade entry. Request succeeds validation only if all relevant validation rules succeed

Define a custom exception message (if you want) for some rules, and it will be returned to the caller if that rule fails

Define Transformation Rules you might apply to requests or responses

Use Message Gateway Config Console or SQL scripts to define message transformation rules. These rules can be assigned to requests and/or responses

There are three types of transformation rules: XSLT, TEMPLATE and CUSTOM

Use XSLT transformation rule if a message is expected to be in XML format, which can be converted to some other format using XSLT. Define URL of XSLT file (can be on file system, HTTP or FTP)

Use TEMPLATE transformation to convert message of any format to any other format. For example you can easily transform XML into JSON, JSON into SOAP, REST GET URL into message of any format

Use CUSTOM to define MVEL expressions to convert message. MVEL expression is either static or dynamic. Dynamic means it can give different results based on content of request and/or response or any other parameter

You can apply zero or one transformation rule on request or response messages

Define Message Properties you might add as HTTP Headers or JMS Properties to requests or responses

Use Message Gateway Config Console or SQL scripts to define message properties. These properties can be added to requests and/or responses as HTTP headers or JMS properties

Define message property name (static string value) and value expression, which is either static or dynamic MVEL expression. Dynamic means it can give different results based on content of request and/or response or any other parameter

You can assign zero or multiple message properties to any request / response

Define Destinations where the final service should be reached

Use Message Gateway Config Console or SQL scripts to define destinations. These are HTTP URLs or JMS queues, where a service you are exposing via Message Gateway URI is internally available

Destination could be either HTTP/HTTPS URL, or JMS queue. For HTTP/HTTPS select HTTP method among GET, POST, PUT or DELETE. For JMS select between REQUEST_REPLY or REQUEST_ONLY

Define user/password for destinations that require authentication

If HTTP/HTTPS destination is only reachable via proxy, you can assign proxy to relevant destinations. You can add/modify/remove any number of proxies if needed

Assign Validation Rules, Transformation Rules, Message properties, Destinations to Façade Entries

Use Message Gateway Config Console or SQL scripts to assign validation and/or transformation rules,message properties and destinations to façade entries

Assign zero or multiple validation rules to façade entries. Define "Condition" as MVEL expression to apply a rule only if that condition returns "true". Set "Ranking" to the rules to define order of their application. If needed, you can enable/disable any assignment without having to delete assignment or rule

Assign zero or multiple transformation rules to façade entries (only zero or one rule is applied, chosen by matching "Condition" and/or "Ranking"). You can separately assign rules for requests and response. Define "Condition" as MVEL expression to apply a rule only if that condition returns "true". Set "Ranking" to the rules to define which rule should be applied. If needed, you can enable/disable any assignment without having to delete assignment or rule

Assign zero or more message properties to façade entries. You can separately assign message properties for requests and response. Define "Condition" as MVEL expression to add a message property only if that condition returns "true". For requests if destination is HTTP destination - message properties will be added as HTTP headers, for JMS - as JMS properties. For responses message properties are added as HTTP headers. If needed, you can enable/disable any assignment without having to delete assignment or property

Assign one or more destinations to façade entries. You can assign destinations of different types (JMS and HTTP) to the same façade entry. Destination is chosen based on "Condition" and/or "Ranking". If needed, you can enable/disable any destination without having to delete assignment or destination

Publish configuration to running Message Gateway instances

Use Message Gateway Config Console to publish config changes to all running instances or use Flink-ESB Admin Console to reinitialize on every instance separately

Changes applied via Config Console or SQL scripts are reflected right away on running instances of Message Gateway without restarting them

Legal Disclosure Contact Copyright (C) Verbundo GmbH - All Rights Reserved