Flink-ESB Message Gateway
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
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
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
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
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
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
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