Introduction to IBM provided hybrid cloud services and products
In Chapter 2, “Hybrid cloud architectures: Three pillars of integration” on page 15, we saw three domains or pillars of cloud integrations that are important for a hybrid cloud. We provided users with an understanding of architectures and patterns that lay the foundation. In this chapter, we look at specific IBM services and products that can be used to seamlessly integrate different cloud environments in a robust and efficient manner. We can put these services and products under two categories. The first category is services hosted on
IBM Bluemix. The other is stand-alone IBM products. We provide a definition, a description, and use cases to help users understand which services or products are applicable for their scenarios or problems. As discussed, we are relating these products to use cases in later chapters so that you can read the relevant chapters to further understand the functionality of the product.
IBM Bluemix. The other is stand-alone IBM products. We provide a definition, a description, and use cases to help users understand which services or products are applicable for their scenarios or problems. As discussed, we are relating these products to use cases in later chapters so that you can read the relevant chapters to further understand the functionality of the product.
This chapter has the following sections:
3.1 Services hosted on IBM Bluemix
Bluemix integration services offer a range of composable services to connect to data and endpoints (application programming interfaces (APIs) or services) behind the firewall securely and easily. These endpoints can be easily exposed and managed as APIs for consumption by omni-channel applications. In-flow data cleansing and movement ensure that applications have the correct and relevant data. In this section, we provide an overview of these Bluemix services and explain use cases. You can use these building blocks to compose a solution to connect disparate clouds incrementally.
Services on Bluemix can be categorized in three main areas:
•API-centric
•Data-centric
•Event-centric
Refer to Chapter 2, “Hybrid cloud architectures: Three pillars of integration” on page 15 for a detailed explanation of these categories.
In the following sections, we cover Bluemix provided services that fit within these categories.
|
Additional references on Bluemix integration services: You can refer to the following as additional references on hybrid cloud:
•5 Things to Know about Hybrid Cloud
•Creating Hybrid Clouds with IBM Bluemix Integration Services, REDP-5270
|
3.1.1 API-centric service: IBM API Management
The API Economy is where companies (providers) expose their internal digital business assets or services in the form of APIs to third parties (consumers) with the goal of unlocking additional business value through the creation of new assets. Figure 3-1 illustrates the API Economy value chain described.
Figure 3-1 The API Economy value chain
The IBM API Management solution provides a single, comprehensive solution to design, secure, control, publish, monitor, and manage APIs. It delivers the following sets of capabilities:
•An API developer can create, secure, control, deploy, analyze, and manage SOAP and Representational State Transfer (REST) APIs and services for internal or external consumption quickly through a single console.
– Policy-driven assembly that enables custom rate-limiting scenarios, which are enforced by the API Gateway (IBM DataPower®).
– Fine-grained ability to set API quotas and rate limits.
– Visibility and control with ability to deploy across runtime environments.
– Ability to easily create different versions of an API and understand where those versions are deployed, such as in test, staging, or production.
– Ability to search for, add custom labels to, and mark favorite APIs and services for easier discovery in API Manager to work with APIs.
– Ability to notify within API Manager to understand who is working on the APIs and any issues the APIs might be having.
– Support for SOAP-based web services.
– Discovery of web services from WebSphere Service Registry and Repository (WSRR).
– Ability to create an API by assembling REST-based and SOAP-based services.
– Role-based access for viewing and working with the APIs.
– Support for OAuth 2.0, an open standard for authorization.
•An API business owner can advertise, market, socialize, and sell APIs as a product in developer communities worldwide:
– Ability to have more than one developer portal in order to support more than one developer community (private, partner, and public), with controlled visibility.
– Ability to create API plans, which treat the APIs as product offerings, allows several APIs and resources per plan.
– Improved application developer management, with the ability to send an email to all application developers in a particular community.
•An application developer (also API consumer) can explore API documentation and provision application keys:
– Developers can register their application, select API entitlement levels, and monitor their API usage.
– A single ID allows a developer to be a member of multiple API Management communities.
– Allows role-based access for viewing APIs.
•IT Operations can easily manage and upgrade the API Environment using existing investments in DataPower with the ability to monitor and scale without disruption to service:
– Simplified operations environment for API assembly using DataPower Gateway.
– Improved environment console experience.
– Improved tenant management with the introduction of organization and owners.
– Integration with enterprise authentication systems by using Lightweight Directory Access Protocol (LDAP) that enables administrators to streamline the user login process.
– Simplification of deployment architecture to only two tiers:
• Gateway tier: DataPower appliance (virtual or physical appliance).
• Management tier: API Management virtual appliance.
IBM API Management is available in four different deployment options. Table 3-1 on page 26 compares the different options. For more information, see the following sites:
Table 3-1 Comparing the IBM API Management deployment options
|
Offering name
|
Deployment model
|
Offering management
|
Infrastructure details
|
Capabilities
|
|
IBM API Management
|
On-premises
|
Customer owned and managed
|
•Can be installed on VMWare, Xen, and PureApplication System
•Requires IBM DataPower Gateway
|
Provides functionalities to define, secure, control, version, and publish API, and monitor API usage
|
|
IBM API Management on Cloud
|
Off-premises, SaaS
|
IBM owned and managed
|
IBM SoftLayer
|
Provides functionalities to define, secure, control, version, and publish API, and monitor API usage
|
|
IBM Bluemix API Management
|
Off-premises, SaaS
|
IBM owned and managed
|
IBM SoftLayer
|
Provides functionalities to define, secure, control, version, and publish API, monitor API usage, and share APIs with Bluemix developers
|
|
IBM Bluemix Dedicated API Management
|
Off-premises, SaaS
|
IBM owned and managed
|
IBM SoftLayer
|
Provides functionalities to define, secure, control, version, and publish API, monitor API usage, and share APIs with Bluemix developers
|
The rest of this section focuses on the IBM API Management Service in Bluemix.
When you create an instance of the API Management service in Bluemix, you are presented with the launch page shown in Figure 3-2 on page 27. From this launch page, you can launch and go to the API Manager.
Figure 3-2 API Management launch page
The API Manager is shown in Figure 3-3 on page 28. Following are the tasks that you typically need to perform to get started with API Manager:
1. Create an API
2. Create a plan
3. Add the API to the plan
4. Stage the plan
5. Test the API
Figure 3-3 on page 28 shows the APIs section of the API Manager. You see that to create an API, you can compose the API manually, or import a Swagger file representing a REST service, or import a Web Services Description Language (WSDL) file representing a SOAP-based web service. The links on the left enable you to navigate to other sections of API Manager.
Figure 3-3 API Manager: Compose an API or import a Swagger or WSDL file
For illustrating the typical tasks and windows, we imported a Swagger file that represents an Airport Status service published by the Federal Aviation Administration (FAA). More details can be found at the following URL:
Example 3-1 contains the Swagger file that we created. You can import this file and try it.
Example 3-1 Swagger file for FAA Airport Status service
{
"swagger": "2.0",
"info": {
"title": "FAA Airport Status",
"description": "",
"version": "1"
},
"host": "services.faa.gov",
"basePath": "/airport",
"paths": {
"/status/{iata}": {
"get": {
"summary": "",
"operationId": "",
"parameters": [
{
"default": null,
"description": "",
"name": "iata",
"required": true,
"type": "string",
"in": "path"
},
{
"default": "json",
"description": "",
"name": "format",
"required": true,
"type": "string",
"in": "query"
}
],
"responses": {
"200": {
"schema": {},
"description": ""
}
}
}
}
},
"definitions": {}
}
Figure 3-4 shows the APIs section of API Manager where the created APIs are listed.
Figure 3-4 API Manager: List of APIs
Before you can use an API, you need to add it to a plan. A plan treats APIs as product offerings, allowing several APIs and resources to be included in a plan. With a plan you can perform the following functions:
•Include multiple APIs and resources per plan
•Version your plans
•Apply entitlement by plan or resource
•Fine-grained control over plan deployment
•Enforce hard or soft limits
Figure 3-5 shows a Free Plan that has been created and the FAA Airport Status API has been added to that plan.
Figure 3-5 API Manager: Created plan with API added
At this point, the plan is still not available for use. APIs and plans exist as authored artifacts visible in the API Manager. To become available to consumers, APIs must be deployed to an environment, and published to some or all organizations. An environment has an associated runtime capability. By default, a provider organization has a sandbox environment. Apps are registered to consume APIs via a selected plan, which determines the API quota. The plan needs to be staged into an environment.
When a plan is staged in an environment, you can test and start using the APIs that are included in the plan. You need to edit the API to access the test feature. In edit mode, you can change any configuration, such as security or add additional documentation for consumers of the API. Figure 3-6 on page 31 shows the Free Plan staged in the default sandbox environment.
Figure 3-6 API Manager: Testing an API
From an API security standpoint, you have two aspects. First, the identity of the application that is consuming the API, and second, the identity of the users of that application that is consuming the API. The identity of the application can simply be established by using a client ID or by using a client ID along with a client secret. For authentication/authorization of users of the application, basic authentication or OAuth can be configured.
The API is now also available as a Custom API in the Bluemix Catalog as shown in Figure 3-7. The API can now be instantiated, bound to an application, and used with the same developer experience as any of the other services in the Bluemix Catalog.
Figure 3-7 APIs shared from API Management appear as Custom APIs in the Bluemix Catalog
Following are some common use cases for API Management:
•Provide omni-channel access to business information for accelerating internal app development.
•Collaborate with business partners faster, in an open but secure and managed way, while providing a complete self-service experience.
•Power Mobile apps with enterprise business logic to innovate and provide high value to customers: Digital transformation focus.
•Power Internet of Things (IoT) apps with enterprise information to drive innovation: Digital transformation focus.
•Centrally manage the consumption of business logic, across the enterprise, for both Systems of Record and Systems of Engagement.
•Publish APIs publicly to drive innovation, tap into broad developer ecosystem, and promote brand.
•Extend brand reach from Systems of Record to bridge to Systems of Engagement.
•Provide secure composite services in the cloud.
•Provide managed access to third-party cloud services to app dev teams to achieve centralized governance and cost optimization.
•Enable new business channels by monetizing enterprise data.
|
5 Things to Know about API Management in Bluemix blog post: For more information about API Management, check out 5 Things to Know about API Management in Bluemix:
|
3.1.2 API-centric service: Secure Gateway
The IBM Secure Gateway service in Bluemix provides a secure way to access your on-premises or cloud data from your application running in Bluemix over a secure passage that is the gateway. The basic scenario for Bluemix to on-premises integration is the integration between the new born on the cloud Systems of Engagement (SOE) and the existing legacy Systems of Record (SOR). Data is typically accessed from a SOR, such as a database or an application/web service.
The Secure Gateway works by using a client on the on-premises side to connect to your Bluemix organization, as shown in Figure 3-8.
Figure 3-8 Secure Gateway high-level architecture overview
Table 3-2 defines some key terms.
Table 3-2 Key terms for Secure Gateway
|
Term
|
Definition
|
|
Client
|
The process that establishes the on-premises or cloud side of the gateway and forwards requests to the destinations.
|
|
Gateway
|
The tunnel between your Bluemix app and on-premises or cloud environment.
|
|
Destination
|
The point at which your on-premises data can be accessed.
|
|
Application-side TLS
|
Security between your Bluemix app and on-premises or cloud client.
|
|
Client-side TLS
|
Security between the client and on-premises or cloud destination/data.
|
The basic steps to set up and use the Secure Gateway service are as follows:
1. Provision a Secure Gateway service and bind it to your application.
2. Create a gateway (Name It).
3. Connect the gateway to a client (Connect It).
4. Add a destination to the gateway (Add Destinations).
5. Use the destination in your application.
|
Note: You can provision only one Secure Gateway service per space. You can have multiple Bluemix applications bind to the same Secure Gateway instance.
|
The gateway contains the configuration information for establishing a tunnel between the Secure Gateway client running in your environment and Bluemix. When adding a gateway, you can choose to enforce increased security over who is able to start a gateway. An optional security token can be provided when they connect the Secure Gateway client.
Figure 3-9 shows the Add Gateway window of the Secure Gateway showing the three steps to set up the gateway and destination.
Figure 3-9 Add Gateway window
When you name your gateway, you can connect your gateway to a client. At the time of this writing, the following two options were available for the client:
•A Docker container running the secure gateway client. Docker provides a convenient run anywhere option.
•IBM DataPower providing an appliance-optimized solution with the same base features as the Docker client, but with additional security enforcement capabilities.
The gateway client is a process that runs in the on-premises or cloud side of the gateway. It has network visibility to the Bluemix application and to the destinations. Multiple destinations might need multiple clients. The gateway client initiates a connection with the gateway in Bluemix and forwards requests from the gateway to the destinations.
When you connect your gateway to a client using one of these listed clients, you can add a destination to your gateway. Figure 3-10 on page 35 shows the window to create a destination. The destination specifies how to connect to the system resource that is a SOR, database of record, and so on. You need only one destination per system resource. The destination consists of a name, host name or IP address, the port, and protocol.
Figure 3-10 Create Destination window
Each destination can optionally use Transport Layer Security (TLS) protocol:
•Application-side TLS
Secures access between the Bluemix app and the cloud environment client.
•Client-side TLS
Secures access between the cloud environment client and the destination.
•The two can be set independently
For application-side security, the following protocol options apply:
•TCP
– No TLS: No certificates, no encryption
– No authentication is provided
– Bluemix application communicates directly to the gateway
•TLS Server Side
– TLS is enabled
– Secure gateway generates a certificate to prove its authority
– You need to accept the server certificate into your Bluemix application truststore
•TLS Mutual Auth
– Option 1: Auto-generate certificate and private key
– Option 2: Upload existing keys to the gateway
•HTTP
•HTTPS
For client-side security, you can Enable Client TLS. Client TLS is required for connecting to an HTTPS backend. The destination’s certificate is verified against known certificate authorities. If the certificate (PEM) is self-signed, it must be attached to the cloud environment client. Attaching the certificate can be done during the creation and edit of the destination or via the Secure Gateway REST API.
Additionally, the IP Table Options can be used to limit the IP addresses or ports that can access the destination. The IP or port number entered into the IP table must be the external IP address that the Secure Gateway server sees, not the local IP address of the machine.
Figure 3-11 shows the details of a destination. The Cloud Host:Port is used by the application to connect securely to the destination.
Figure 3-11 Destination details contain Cloud Host and Port
Figure 3-12 shows a typical simple use case. An SOE web application developed in Java Platform, Enterprise Edition runs in a Java Liberty run time in Bluemix. The web application needs to access data that is stored in a MySQL database that is hosted in a corporate data center. In this case also, the Secure Gateway service is used to securely connect from the Public Bluemix to the corporate data center to enable making JDBC calls over a secure channel.
Figure 3-12 Bluemix SOE web application requiring integration with an on-premises relational database
Figure 3-13 shows a more complex use case for the Secure Gateway. An SOE mobile application uses Bluemix as the Mobile Backend as a Service (MBaaS). An IBM Cloudant® NoSQL DB service provides data storage for the mobile application. A NodeJS run time provides the necessary orchestration of service calls to fulfill the needs of user-interface interactions. The mobile application needs to call a SOAP-based web service that resides in the corporate data center. The Secure Gateway service is used to securely connect from the Public Bluemix to the corporate data center. SOAP requests go through the Secure Gateway over the secured channel.
Figure 3-13 Bluemix based MBaaS requiring integration with a SOAP-based on-premises web service
In summary, the Secure Gateway service brings hybrid integration capability to your Bluemix environment. It provides secure connectivity from Bluemix to other applications and data sources running on-premises or in other clouds.
3.1.3 API-centric service: Connect & Compose
Connect & Compose is a new service offering in Bluemix for API creation. As shown in Figure 3-14 on page 38, the service offers to create API in two ways:
•Connect to and create a Representational State Transfer API to interact with a single source of data or service.
•Compose by using a flow editor and API that performs complex functionalities in each API call, such as relay further requests to backend services, sending email, interacting with persistence, and various third-party services.
Figure 3-14 Connect & Compose landing
Connect
The Connect option in Connect & Compose provides a RESTful interface to interact with a growing option of data source and services in Bluemix, on-premises, and on cloud. Figure 3-15 shows supported sources as of this publication.
Figure 3-15 Connector options at different locations
To start, the user selects where and the type of source to connect to. For databases on Bluemix, it is required that the service to be provisioned and bound to your app, before Connect & Compose can connect to it. Similarly, Secure Gateway service is required to access enterprise sources behind a corporate firewall or in a secured network.
With successful connection to a data source, the user then selects the model to which the API acts on. Depending on the type of source that the user is connecting to, Connect & Compose allows users to exclude optional parameters and REST endpoints during the API creation process. This is a valuable feature when the user only wants to externalize non-destructive endpoints. A sample swagger is shown for the user to check the API formation before save. With the host and port provided by Connect & Compose after creation, the user can now interact with the API via REST calls.
Compose
The more robust option to create an API with complex functionality is with the Compose option. API composition is delegated to a Node-RED composition interface. The interface allows user to compose an API by dragging and connecting wanted nodes. Figure 3-16 is a sample flow how an API can be composed to perform multiple functions within one call (extra payload handling function nodes are required to wrap services nodes in most cases shown, but are eliminated to provide a generic concept). All four APIs initiate in an http request, and ends with an http response:
•First API endpoint accepts a POST request with location information, retrieves Google Places data, checks the weather, and pushes the result to email, twitter, and pinterest.
•Second API endpoint accepts a GET request. The function node can provide adjustments, such as putting query parameters into payload, or adjusting and reformatting input values. The adjustment is then relayed to the SAP node to invoke a function that has been configured. The returned data is then uploaded to Dropbox, and submitted for debugging at the same time.
•Third API endpoint accepts a GET request and passes the information to a bus schedule service, and adds the information to Google Calendar.
•Fourth API endpoint demonstrates a chain of http requests, which ends with persisting the final result into an SAP Hana database.
Figure 3-16 Sample Composition with various types of nodes
As long as there is a node to support it, there is also no limitation on what sources to act on in the composition flow editor, which distinguishes it from the Connect counterpart. Figure 3-17 shows a sample node called salesforce output. This node provides the functionality to interact with data stored on Salesforce database. Notice also in the left panel shown in Figure 3-17, Salesforce-related nodes come in two options. The salesforce output node performs POST, PATCH, and DELETE operations, and provides no output, does end the flow. The salesforce function node alternatively, performs GET operations, and provides output that can be passed on to the next node in the flow diagram.
Figure 3-17 Configuration for salesforce output node
Table 3-3 shows the categories and their respective nodes available as of the time of this publication.
Table 3-3 Category of nodes
|
Category
|
Nodes
|
|
input
|
inject, catch, http, websocket
|
|
output
|
debug, http response, websocket
|
|
function
|
function, template, delay, trigger, comment, http request, switch, change, range, csv,
html, json, xml, rbe |
|
social
|
email, twitter, delicious, foursquare, swarm, google plus, google places,
google calender, instagram, pinboard |
|
storage
|
amazon s3, box, dropbox
|
|
advanced
|
feedparse
|
|
connectors
|
db2, sap, salesforce, saphana
|
|
weather
|
forecastio, openweathermap, wunderground
|
|
location
|
google geocoding, google directions
|
|
Google
|
google calender
|
|
transport
|
tfl underground, tfl bus
|
Using APIs
When an API is created in Connect & Compose, the API becomes immediately available on the host and port provided. Figure 3-18 on page 42 shows detailed information about the new API.
The top section of the page displays the general information about the API, including shared name, state, time stamp, and API running status. The running status is only an indicator of whether the API is available. The user is responsible to keep all connections from the API to the data source (such as Secure Gateway, virtual private network, and the data source itself) running.
The second section of the API details page shows the base Uniform Resource Locator for the API, and the access key to include in the header when sending requests to the API.
The third section includes an interactive Swagger UI that allows the user to visualize and test the API.
The fourth section provides SDK package downloads for ease of development in different languages. If the user uploaded more documentation for this API during the creation process, they are also displayed for download.
Figure 3-18 Sample API created from connecting to DB2
For advanced utilization of the API, user has the option to share to Bluemix, share to API Management, or both. When an API created in Connect & Compose is shared to Bluemix, the user obtains the ability to bind the API to an app in the same space. The API detail is also available for all users in the Bluemix Space to see. Alternatively, sharing the created API to API Management allows the API to be managed with more policies and all the functionalities that API Management has to offer.
|
Important: At the time of writing this book Connect & Compose was not publicly available, so some of this information might slightly change when the service becomes generally available.
|
3.1.4 Data-centric service: IBM DataWorks
IBM DataWorks is a service on Bluemix that can be used for data load, migration, refinement, transformation, and gaining insights from the data. As depicted in Figure 3-19, DataWorks helps the IT team, developers, and business users to get access to meaningful and appropriate data and provides the tools and APIs to perform the jobs. Data can be collected from various sources (web, mobile, social media, enterprise systems, document repository, IoT, and so on) and processed by DataWorks for use by various applications as shown in the diagram.
IBM DataWorks provides useful data services, such as:
•Load data
•Provision masked data
•Profile data
•Classify data
•Secure on-premises load to cloud targets and cleanse addresses
Figure 3-19 IBM DataWorks providing data services, capabilities, and insights to IT team, developers, and business users
Figure 3-20 DataWorks use case in combination with Secure Gateway to access an on-premises database or without a Secure Gateway to access a public database
Figure 3-20 shows conceptually how DataWorks service can connect a user or an application to a public database or an enterprise database behind a firewall. Although the datagram indicates a Java application, the use case is not restricted to an application of a particular type. It can be an application using any programming language. A developer can use DataWorks Forge to get data from one data source (for example, SQL DB), shape the data and finally put the refined data in another database (maybe another SQL DB). An application can use the DataWorks APIs to load data, cleanse address, and profile the data. The two options in terms of the presence of a Secure Gateway are:
•Option 1
In this scenario, an application or a user is connected to a public database (for example, SQL service hosted on Bluemix) through DataWorks. DataWorks service provides the APIs or DataWorks Forge manipulates the data (step 1) and then copies data from source to target (step 2). The data in the target is ultimately used by the application.
•Option 2
In this scenario, an application or a user is connected to an on-premises database (for example, MySQL as shown in the diagram) through DataWorks. DataWorks service provides the APIs or DataWorks Forge manipulates the data (step 1) and then copies data from source to target (step 2). The data in the target is ultimately used by the application.
DataWorks service is composed of two offerings: IBM DataWorks Forge and DataWorks APIs.
IBM DataWorks Forge
IBM DataWorks Forge service on Bluemix can be used to find, shape, or transform data and deliver the refined data to applications and systems for seamless integration. A series of screen captures in this section gives you an overview of this service. For detailed step-by-step instructions, refer to Chapter 8, “Watson Analytics in hybrid cloud using Secure Gateway and DataWorks” on page 195. Developers can create a DataWorks service instance by choosing the DataWorks service from Bluemix catalog, as shown in Figure 3-21 on page 45.
Figure 3-21 IBM DataWorks service on Bluemix Catalog
Figure 3-22 shows an example of creating a DataWorks service. We chose dev for Space:, Leave unbound for App:, and DataWorksDemo for Service name:. You can choose the appropriate parameters for your Bluemix environments:
1. If you want to bind this service to an application, you can choose one from the App: dropdown list.
Figure 3-22 IBM DataWorks contains DataWorks Forge and APIs
2. After the DataWorks service is created, choose DataWorks Forge, which leads to a window similar to Figure 3-23. Because this is created for the first time, the data registry is empty. Choose the arrow in the prompt to add the first data source. A window similar to Figure 3-24 that shows the currently supported data sources is displayed. Choose SQL Database here.
Table 3-4 on page 47 lists the source and target data sources combination supported by DataWorks Forge.
Figure 3-23 DataWorks Forge prompting to add the first data source
3. As a demonstration here, we add SQL database services from Bluemix, which has been populated with a database containing a table named visitors. This database is used as the source database. You can easily create a .csv file with relevant data and then use SQL database data import features to populate a table in the database.
Figure 3-24 Currently supported data sources for DataWorks
As mentioned earlier, Figure 3-24 shows currently supported data sources by DataWorks Forge. This is presented in a tabular form in Table 3-4 on page 47.
Table 3-4 DataWorks Forge supports the following source and target
|
Source
|
Target
|
|
Amazon Redshift
|
|
|
Cloudera Impala
|
|
|
IBM Cloudant NoSQL DB
|
|
|
IBM dashDB™
|
|
|
IBM DB2
|
|
|
IBM Informix®
|
|
|
IBM Netezza®
|
IBM Cloudant NoSQL DB
|
|
IBM SQL Database
|
IBM DashDB
|
|
Microsoft Azure
|
IBM SQL Database
|
|
Microsoft SQL Server
|
IBM Watson™ Analytics
|
|
MySQL
|
|
|
Oracle
|
|
|
Pivotal Greenplum
|
|
|
PostgreSQL
|
|
|
Salesforce.com
|
|
|
Sybase
|
|
|
Sybase IQ
|
4. Next, as shown in Figure 3-26 on page 49, either select an existing connection (for example, by selecting connection_to_demo_sql from the table) or choose Add a connection and then complete the details for the table.
|
Note: If you are connecting to a Bluemix database service, for example SQL Service, get the Host, Port, User, Password and so on, from VCAP_SERVICES variables. See Figure 3-25 as an example.
|
Figure 3-25 VCAP_SERVICES variables for SQL database service
5. We have obfuscated username, uri, and password fields here in Figure 3-25. For your SQL service on Bluemix, find the parameters from VCAP_SERVICES variables and use these to create a new connection.
Figure 3-26 Adding a SQL connection
Figure 3-27 Selecting the intended database table from database schema
7. When the data is ready for IBM DataWorks Forge to use, we choose Shape to shape (sort, filter, or join), as shown in Figure 3-28.
|
Screen captures: The intent of the screen captures shown here is mainly to introduce the features. The detailed step-by-step instructions are provided in Chapter 8, “Watson Analytics in hybrid cloud using Secure Gateway and DataWorks” on page 195.
|
Figure 3-28 DataWorks Forge allows you to shape the data and copy the shaped data to a target database
Figure 3-29 shows the overall quality, size, and type of the data, and issues identified with the data.
Figure 3-29 Overall quality of the data
DataWorks Forge also allows you to look at the quality metrics for each column, as indicated in Figure 3-30.
Figure 3-30 Column metrics from DataWorks Forge
8. When the developers or IT team or the business users are happy with the quality of data after shaping (sorting, filtering, or joining), it is time for this shaped data to be copied to a target database as indicated by Figure 3-31 and Figure 3-32 on page 52.
Figure 3-31 Selecting a target database to copy the shaped data to
Figure 3-32 Selecting Watson Analytics as the target
9. A developer might choose Watson Analytics in this instance. Choose IBM Watson Analytics as shown in Figure 3-32, and select Add a connection to complete the relevant details.
Thus, IBM DataWorks Forge allows a user to easily find data, shape it, and copy it to a target data source. This was a quick demonstration to introduce you to DataWorks Forge.
IBM DataWorks APIs
IBM DataWorks provide three APIs. These are discussed in this section.
•Data Load
Data Load REST API is useful for loading data from cloud and on-premises database via Secure Gateway and then finally provisioning the data to a target. The following source and target data sources are supported as mentioned in Table 3-5 on page 53.
Table 3-5 DataWorks APIs support the following source and target
|
Source
|
Target
|
|
Amazon Redshift
|
|
|
Amazon S3(CSV files)
|
|
|
IBM Analytics for Apache Hadoop
|
|
|
Apache Hive
|
|
|
IBM Cloudant NoSQL DB
|
|
|
IBM DashDB
|
|
|
IBM DB2
|
|
|
IBM Informix
|
|
|
IBM Netezza
|
IBM Analytics for Apache Hadoop
|
|
IBM Object Storage for Bluemix version 1 (CSV files)
|
IBM Cloudant NoSQL DB
|
|
IBM SQL Database
|
IBM DashDB
|
|
Microsoft Azure
|
IBM SQL Database
|
|
Microsoft SQL Server
|
IBM Watson Analytics
|
|
MySQL
|
|
|
Oracle
|
|
|
Pivotal Greenplum
|
|
|
PostgreSQL
|
|
|
Salesforce.com
|
|
|
Sybase
|
|
|
Sybase IQ
|
•Address Cleansing
Address Cleansing API is useful for standardizing US addresses. It expects five address input fields and returns extra address information when input parameters match Coding Accuracy Support System (CASS) reference files containing United States Postal Service (USPS) standard addresses.
|
Note: Address Cleansing API is only available in the United States Bluemix instance.
|
Request body of the REST call supports 64 characters maximum for address1 and address2 fields and 42 characters for other input fields. Up to 100 addresses can be included for verification with each API call.
Example 3-2 shows the input parameters for an address request.
Example 3-2 Input parameters for an address request
{
"addresses": [{
"zipcode": "27709",
"state": "NC",
"address1": "3039 East Cornwallis Rd",
"address2": "",
"city": "Research Triangle Park"
}]
}
•Data Profiling
The Data Profiling API classifies, analyzes, and validates data. This API is useful for understanding the content and structure of the data. This API can be explained with an example. Suppose CompanyC acquired CompanyB. CompanyC requires to integrate CompanyB’s data assets with their existing data assets. A developer from CompanyC has been tasked to analyze the data from CompanyB in this regard. The developer can use the Data Profiling API to understand the following information:
– Type of the data in various fields of a database table or document, for example, date, numeric, string, and so on.
– Length and format of the fields.
– Whether fields contain data, such as customer names, credit card numbers, telephone numbers, and so on.
The Data Profiling API supports the following formats and sources as shown in Table 3-6.
Table 3-6 Formats and sources supported by DataWorks Data Profiling API
|
Data format
|
Source
|
|
Comma-separated value (CSV) file
|
•Amazon Simple Storage Service (S3)
•SoftLayer Object Storage
|
|
Delimited file
|
•Amazon Simple Storage Service (S3)
•SoftLayer Object Storage
|
|
Relational table
|
•SQL Database
•dashDB
|
In summary, IBM DataWorks service on Bluemix helps with data loading, shaping, profiling, and standardizing by means of DataWorks Forge and DataWorks APIs.
|
5 Things to Know about IBM DataWorks blog post: For more information about IBM DataWorks, check out 5 Things to Know about IBM DataWorks:
|
3.1.5 Event-centric services: Message Hub and Event Hub
Various applications software and services provide capabilities for publishing events when certain conditions occur. To develop innovative composable applications in a hybrid environment, it makes more economical sense to use existing functionality provided by third parties. However, building the integration points involves much work and effort and as new services are available, more development work is needed.
A better solution is to use the concept of connectors that are configurable for a particular service. The configuration could include information such as credentials, API Keys, and end points. As an example for such external services, Twitter Inc.® provides an API to receive a stream of tweets based on some search criteria; likewise, Salesforce.com enables publishing messages when specific events occur or data changes within the system. A messaging system that supports the publish/subscribe mechanism helps downstream applications to consume these events in a reliable manner.
Figure 3-33 depicts the Event Hub and Message Hub integration architecture.
Figure 3-33 Event Hub and Message Hub integration architecture
Event Hub provides intelligent connectors for these services in addition to more traditional publish/subscribe tooling found in products like MQ Light, RabbitMQ, and so on. Each Event Hub connector is built against a specific service or technology (for example, Twitter, Cloudant, Force.com, MQ Light, and so on), and provides configuration options for entering connection credentials, search parameters, and so on.
Event Hub aggregates events from configured services into a single publish/subscribe service called Message Hub (available from the Bluemix Catalog), which then provides several mechanisms for subscribing to configured event streams. Subscription methods can include REST APIs, and other proprietary APIs.
After a connector has been configured, it is initialized and can begin receiving data from the target system. When the data begins flowing across the Message Hub topic, cloud-connected services can begin consuming the data by using one of the mechanisms provided.
Streams ultimately have simple lifecycles. After initialization, they can be stopped, restarted, or deleted. Event Hub is broken up into several components:
•Service broker
•IBM Container Extensions broker
•WebSocket proxy
•HTTP/REST proxy
•Premium connectors and Streaming services
Event Hub is built atop Message Hub service. Message Hub provides the backend for managing large volumes of publish/subscribe messages using a high-performance, robust, distributed system cluster. Event Hub uses this highly distributed architecture.
Event Hub requires the following steps:
1. When a new event stream is created (the connection between some service and the Event Hub system), this “connector” first establishes a connection to the Event Hub service broker in order to provide a “heartbeat” status for each stream, as well as enable passing status and debug messages back to the broker.
2. The connector establishes a connection to the target system and begins listening for events generated by that system.
3. When a new event is received, it is passed via a third concurrent connection to the Message Hub service.
|
Important: At the time of writing this book Event Hub and Message Hub were not publicly available, so some of these details might slight change when these services become generally available.
ITSO Redbooks team is going to publish a companion book titled “Hybrid Cloud Event Integration: Integrate Your Enterprise and Cloud with Bluemix Integration Services, SG24-8281 in 1Q 2016. This book will focus exclusively on hybrid cloud scenarios with Bluemix using Event Hub and Message Hub.
|
3.2 Other IBM products
In this section, we describe other IBM products that are not part of IBM Bluemix offerings. These products fall under the following categories:
•Utility software
•Physical device
•Virtual appliance
•Cloud-based solution
3.2.1 z/OS Connect
z/OS provides critical business value with systems such as CICS and IBM IMS™ to the largest enterprises across all industries. Those systems are often backed by DB2 and store vast amounts of business transactional and other data. Systems of Engagement (SOE) like mobile applications need to be able to access the transactions and data on IBM z Systems™. The question is how to connect the cloud environment to the core z Systems environment in a way that is consistent and manageable.
Modern cloud applications use RESTful services and JSON Data. z/OS Connect is software function written by IBM that runs inside an instance of WebSphere Liberty Profile z/OS, and uses existing connector technology to get to the backend systems. It is supplied as part of WebSphere Application Server z/OS, CICS, or IMS. At a high level, it exposes z/OS applications via a REST/JSON interface making consumption of those services consistent with other services that mobile/cloud developers are used to consuming.
Figure 3-34 on page 57 shows where x/OS Connect fits in-between the SOE running in the cloud and the Systems of Record (SOR) such as CICS and IMS running on z Systems.
Figure 3-34 Where z/OS Connect fits in
The following list provides the features of z/OS Connect:
•There is no additional cost to use z/OS Connect, and it is packaged with WebSphere Application Server, CICS, and IMS software products.
•Built on Liberty Profile for z/OS, which means it is lightweight and dynamic. It can run as a z/OS Started Task, which means it can run within your current operational procedures and routines.
•Provides a RESTful API and accepts JSON data payloads.
•Configurable so that you control what backend programs or applications are exposed and accessible.
•Provides a discovery function so application developers can query for a list of configured services as well as query for details about the services.
•Capable of performing data conversion from JSON to the data format required by the backend configured service.
•Optional authorization checking using the System Authorization Facility (SAF) to allow or deny users access to z/OS Connect services. SAF is the System Authorization Facility element of z/OS. Its purpose is to provide the interface between those products requesting security services and the external security manager installed on the z/OS system.
•Optional activity recording using System Management Facilities (SMF) to track requests by date and time, bytes sent and received, and response time. SMF collects and records system and job-related information that your installation can use in the following functions:
– Billing users
– Reporting reliability
– Analyzing the configuration
– Scheduling jobs
– Summarizing direct-access volume activity
– Evaluating data set activity
– Profiling system resource use
– Maintaining system security
|
Key point: z/OS Connect is a REST/JSON interface to a z/OS LPAR. It provides a common and consistent REST/JSON interface to many different backend systems.
|
You can achieve the same goal of accessing CICS or other z/OS systems without z/OS Connect. So why use z/OS Connect? Here are some benefits to using z/OS Connect:
•Provides a common and consistent entry point for mobile access to one or many backend systems.
•Written in Java, so it runs on specialty engines.
•Shields backend systems from requiring awareness of RESTful Uniform Resource Identifiers (URIs) and JavaScript Object Notation (JSON) data formatting.
•Provides point for authorization of user to invoke backend service.
•Provides point for capturing usage information using SMF.
•Simplifies front-end functions by allowing them to pass RESTful and JSON rather than be aware of or involved in data transformation.
Figure 3-35 provides a summary of the key features and capabilities of z/OS Connect.
Figure 3-35 Summary of z/OS Connect key features and capabilities
Following is an explanation of the diagram:
1. z/OS Connect is a software function that runs in Liberty Profile for z/OS.
2. z/OS Connect is described and configured in the Liberty server.xml file.
3. z/OS Connect is designed to accept RESTful URIs with JSON data payloads.
4. One part of z/OS Connect is a servlet that runs in Liberty Profile z/OS.
5. A Service Provider is software that provides the connectivity to the backend system.
6. z/OS Connect provides the ability to transform JSON to the layout required by backend.
7. Interceptors are callout points where software can be invoked to do things such as SAF authorization and SMF activity recording.
8. Initially, the backend systems supported are CICS, IMS, and Batch.
Figure 3-36 shows the high-level application architecture of a typical mobile SOE application that needs to execute CICS transactions on z/OS. The application uses the Mobile Cloud boilerplate and leverages the Mobile Data, Mobile Quality Assurance, and Push Notifications services. A NodeJS run time provides orchestration of service calls mapping to the UI interactions in the mobile application.
On the z/OS side, z/OS Connect exposes CICS transactions via a REST/JSON interface. The Secure Gateway service is used to securely connect from Bluemix to the client’s z/OS mainframe. A DataPower Gateway virtual appliance v7.2 running on x86 provides access into the corporate data center.
The API Management service in Bluemix makes the z/OS Connect exposed REST/JSON interface available as APIs in the Bluemix Catalog over the Secure Gateway. The NodeJS run time makes calls to these APIs.
Figure 3-36 Mobile app using an existing CICS transaction using z/OS Connect
z/OS Connect is designed to enable better and more manageable connectivity between mobile systems and your backend z/OS programs, applications, and systems. It provides a consistent front end interface for mobile systems using REST and JSON, and it shields backend systems from having to understand those protocols and formats. It enables enterprises to leverage their existing investments in z/OS in modern applications and accelerate the development of these applications using the Bluemix platform.
|
5 Things to Know about z/OS Connect blog post: Refer to 5 Things to Know about z/OS Connect:
|
3.2.2 IBM WebSphere Cast Iron Integration
Enterprises today have a wide variety of packaged, commercial off the shelf (COTS), and custom applications running in their environment. There is much investment that went into these applications that are not necessarily for cloud consumption. However, the benefits of cloud rely on the enterprises’ ability to integrate their current applications with the new services and take advantage of them to make their business more efficient and serve their customers.
The primary objective that enterprises are looking to achieve from hybrid cloud at the enterprise level is the ability to integrate applications that are geographically separated but accessible through network in a secure fashion. The locations where applications reside could be on-premises behind a client firewall, in the cloud service provider environment like a hosted private cloud, or a third-party data center. They are looking to tap into the external application services that cloud service providers are able to offer to gain agility and innovate faster and be a disruptor in the marketplace.
In a hybrid cloud environment, specifically between on-premises environment and external public/private clouds, there is a need for easier application integration. IBM WebSphere Cast Iron® Cloud Integration solutions are designed to connect hybrid environments composed of cloud and on-premises applications integrating with SaaS and mobile applications. The Cast Iron portfolio includes process integration, data integration, UI mashups, and combinations.
IBM solution to achieve application integration in the hybrid cloud comes in three different deployment models:
•WebSphere DataPower Cast Iron Appliance XH40: This is a self-contained physical appliance. The appliance can be installed and managed within a local data center. It provides all the functionality needed to connect the cloud and on-premises applications.
•WebSphere Cast Iron Hypervisor Edition: This is a virtual appliance that can be installed on client’s existing servers using virtualization technology. Virtual appliances allow better utilization of hardware and faster response to demands for newly deployed systems on the real appliance, thus helping to reduce the costs of both hardware and software operation and maintenance. Deploying virtual images can help businesses reduce the potential for errors and enable the rapid deployment of working systems for development, test, or production because virtual images are built with known, stable, and tested configurations.
•WebSphere Cast Iron Live: A complete multi-tenant cloud offering to connect cloud and on-premises applications. WebSphere Cast Iron Live enables clients to design, run, and manage integrations in the cloud without any infrastructure footprint onsite.
Figure 3-37 on page 61 shows the different configurations that are available for integrating the Cast Iron appliance. The figure also depicts the four different ways to integrate cloud native applications with the system of record (SOR) residing in the client data center:
1. The System of Engagement applications running in the public or hosted private cloud can access SOR by using the Cast Iron live SaaS solution over secure network connection leveraging the APIs.
2. A Cast Iron hardware appliance XH40 can be installed in the client data center and integrated into the network infrastructure and provide connectivity to the SOR client applications.
3. A Cast Iron virtual appliance for XH40 can be installed in the client data center on a virtual machine and integrated into the network infrastructure and provide connectivity to the SOR client applications.
4. Cloud Native applications can use the Bluemix PaaS Cloud Integration Services to connect to client SOR backend applications.
Figure 3-37 Cast Iron integration options
An integration solution must bridge the gap between the on-premises existing systems and new cloud applications, platform, and infrastructure, providing a rapid and easy-to-use method of setting up the integrations. IBM WebSphere Cast Iron provides a solution that meets the challenge of integrating cloud applications with on-premises systems, cloud applications-to-cloud applications, and on-premises to on-premises applications.
With WebSphere DataPower Cast Iron Appliance XH40 supporting the on-premises environments, IBM continues to enhance its capabilities to address the needs of hybrid environments. It provides rapid access to application data for application developers and driving towards an on-premises API Management solution. The API Management solution includes the most important features that are necessary to support the three most significant players in the API economy: Application developers, business owners, and IT personnel.
WebSphere DataPower Cast Iron Appliance XH40 is a 1U, 4.4 cm (1.75 in.), rack-mountable appliance, which is designed to fit into industry-standard racks, and can be attached to the network via Ethernet.
Clients are looking for a platform that can enable rapid, configuration-based, no-coding construction of integration among SaaS applications, on-premises packaged applications, custom applications, and generic systems such as databases, files, and web services. The Cast Iron “configuration, not coding” approach helps numerous companies go live with their SaaS application initiatives in days or weeks, in contrast to a traditional coding approach, which could easily take many months. The term licensing pricing options help enable clients to get started at a low cost and grow into larger cloud integration projects over time. Following are the key features that Cast Iron Cloud Integration makes available:
•Connect enterprise-grade packaged applications, such as large ERP and CRM applications, and enable access to the target application contents with no coding required.
•Support for a wide range of integration paradigms. Allows connectivity and data integration between salesforce.com applications and other applications.
•Synergy with other IBM integration products: Companies with significant application integration investment can use Cast Iron as the cloud gateway, allowing SaaS applications to become part of the larger integration framework.
•Ability to collaborate with IBM Mobile Foundation: Cast Iron works cooperatively with IBM Mobile Foundation to externalize enterprise data and processes in mobile applications.
WebSphere DataPower Cast Iron Appliance XH40 provides the following comprehensive integration capabilities (Table 3-7).
Table 3-7 WebSphere DataPower Cast Iron Appliance XH40 integration capabilities
|
Category
|
Feature
|
Benefit
|
|
Integration
|
Cloud Data Migration
|
Allows data handling using the data cleansing and data migration capabilities from existing applications to cloud applications in real time.
|
|
Integration
|
Cloud data synchronization
|
Provides connectivity, workflow, and transformation features, enabling coordination or orchestration of integration processes across multiple applications in real time. SaaS and cloud users can view data that is hidden in applications, minimizing any duplicate entries and maximizing decision making and productivity.
|
|
Integration
|
Integration in visualization (UI mashups)
|
Provides the capability to mashup information from disparate sources and to display this information using the native user interface of a cloud application in real time.
|
|
Integration
|
Integration that drives mobile applications
|
Supports mobile applications by harnessing data and processes from other parts of the enterprise.
|
|
Connectivity
|
Connectors
|
Comes with built-in connectivity to hundreds of cloud, packaged, and proprietary on-premises applications, including ERP, CRM, databases, web services, and flat files. WebSphere DataPower Cast Iron Appliance XH40 is completely self-contained and includes everything needed to complete integrations in one place.
|
|
Connectivity
|
Endpoints
|
This approach to integration makes no distinction between local and remote applications because they establish connectivity to the endpoints by using native application protocols. The advantage to this approach is that no additional adapters are required, and there is nothing to install or change at the endpoints.
|
|
Connectivity
|
Customization
|
Connector Development Kit, provided with this offering, allows skilled developers to use WebSphere Cast Iron to add connectors to custom applications. With connectors built by using the Connector Development Kit, users get the same development experience on IBM WebSphere Cast Iron Studio as with the built-in connectors. Cast Iron Studio is a downloadable development tool that can be used to design, test, and publish integration projects to a WebSphere Cast Iron Integration appliance.
|
|
Reusability
|
Template Integration Processes (TIPs)
|
This online library contains templates for many of the most common cloud integration scenarios. These templates encode common connectivity, known mapping, as well as best practice integration workflows.
Templates provide a question-and-answer-based wizard that walks users through a common integration scenario, customizing as needed. Often, users simply complete the credentials, customize mappings, test, and deploy. Cast Iron clients and partners can create their own wizard-driven, reusable templates with the point-and-click TIP Development Kit and make them available to the entire WebSphere Cast Iron Cloud Integration user community.
|
|
Packaging options
|
Editions
|
Standard, Enterprise, Development
|
For the latest information about Cast Iron Cloud Integration, refer to the following URL:
3.2.3 IBM DataPower Gateway
IBM DataPower Gateway appliances are security and integration gateways that help secure, control, integrate, and optimize the delivery of the full range of mobile, web, API, SOA, cloud, and business-to-business (B2B) applications and services. As illustrated in Figure 3-38, DataPower Gateway can reside either in a DMZ or trusted zone or both. In the DMZ, it serves the purpose of security gateway for web services or applications or APIs and B2B partner gateway. Besides these, DataPower Gateway provides network caching, intelligent content routing, and load distribution functionalities. In the trusted domain, DataPower Gateway appliances offer the functionalities of internal security enforcement, integration, runtime SOA governance, web service management, and integration with legacy services.
Figure 3-38 DataPower Gateway appliance
In summary, IBM DataPower Gateways are dedicated network devices that help with the following functions:
•Secure: Secure and protect back-end systems from harmful workloads and unauthorized users and applications. It does so by offering the following capabilities:
– Authentication, authorization, auditing
– Security token translation
– Threat protection
– Schema validation
– Message filtering and semantics validation
– Message digital signature
– Message encryption
•Integrate: Convert payloads, bridge transports, and connect to existing services at wire-speed. The capabilities are:
– Any-to-any message transformation
– Transport protocol bridging
– Message enrichment
– Database connectivity
– Mainframe connectivity
– B2B trading partner connectivity
•Control: Limit and shape traffic based on service level agreements, and route based on message content. The features are:
– Service level management
– Quota enforcement, rate limiting
– Message accounting
– Content-based routing
– Failure rerouting
– Integration with governance and management platforms
•Optimize: Improve response times, reduce load on back-end systems, and intelligently distribute load. The capabilities are:
– SSL/TLS offload
– Hardware accelerated crypto-operations
– JSON, XML offload
– JavaScript, JSONiq, XSLT, XQuery acceleration
– Response caching
– Intelligent load distribution
Figure 3-39 depicts how IBM DataPower Gateway consolidates the previously mentioned four functionalities in just one device.
Figure 3-39 IBM DataPower Gateway providing four functionalities in one device
IBM DataPower Gateway is the consolidation of WebSphere DataPower Service Gateway XG45, WebSphere DataPower Integration Appliance XI52, and WebSphere DataPower B2B Appliance XB62. It is available in two form factors:
•IBM DataPower Gateway appliance
•IBM DataPower Gateway Virtual Edition (IDG VE)
IBM DataPower Gateway Virtual Edition provides deployment flexibility with multiple options to deploy to on-premises and cloud environments. This deployment flexibility reduces the costs for development and test environments. IDG VE can run on VMware or Citrix XenServer hypervisor on x86 servers, IBM PureApplication System W1500 and W2500, and SoftLayer dedicated server or bare metal instance. It offers the ability to upgrade and downgrade firmware similar to physical appliances. Configuration of the appliance can be migrated seamlessly between physical and virtual type. It supports SoftLayer instances and Amazon EC2 deployment.
IBM DataPower Gateways are modular. Additional functionalities through modules can be added to both form factors (physical or virtual) as needed. Base firmware provides mobile, web, and SOA workload support. Extra modules are:
•Integration module
•B2B module
•IBM Security Access Manager (ISAM) proxy module
•Application Optimization module
•TIBCO EMS module
Integration module
Integration module extends the capabilities of the IBM DataPower Gateway by providing seamless integration with legacy systems. It provides protocol transformations at network speeds, and supports the most common application protocols including: XML, JSON, REST, SOAP, HTTP, HTTPS, IBM MQ. Integration module offers the following capabilities:
•Offload and optimization capabilities for XML, JSON, REST, SOAP, and binary workloads.
•Mapping between formats such as XML, SOAP, JSON, REST, binary, and COBOL.
•Content and context-based routing and data enrichment facilities.
•Adapters to other connectivity options (IBM MQ, FTP, IMS Connect, TIBCO EMS, and so on).
•Database connectivity for DB2, Oracle, Microsoft, and others.
B2B module
This module is used as a high-throughput, secure entry point for trading partners in the DMZ. This gateway consolidates B2B trading partner connectivity and transaction management, and reduces heterogeneous integration challenges. B2B module is an add-on to standard IBM DataPower Gateway. Besides all features and benefits of DataPower Gateway, B2B module offers:
•Support for B2B messaging protocols, such as AS1, AS2, AS3, and ebMS.
•Includes message mediation, transformation, and database connectivity features as provided by the Integration module, except for IMS support.
•Support for B2B documentation formats, such as EDI-X12, EDIFACT, XML, and Binary documents.
•On-appliance transformation of data.
•Trading partner profiles, covering variables like multiple business locations, business identifications, and partner-specific certification and policy handling information.
•B2B Viewer tool for monitoring and managing B2B communications and transfers.
•A resend facility if a partner loses a message.
•Ability to accept large payloads from partners.
•Specific integration with IBM MQ Managed File Transfer capability.
IBM Security Access Manager proxy module
ISAM module provides enhanced web and mobile access control security. It offers the following benefits:
•Highly scalable reverse proxy for user access control and web single sign-on.
•Integrated enforcement point for context-based access policies for IBM Security Access Manager for Mobile.
•Compliance reporting and security intelligence integration with IBM Security QRadar® SIEM (see http://www.ibm.com/software/products/en/qradar-siem).
•Integrated DataPower Gateway monitoring, event and message logs for improved serviceability, and a single operations and management view.
•Pattern-based configurations, by using the DataPower Gateway pattern console, to simplify the process of creating new Access Management proxy instances.
Application Optimization module
Application Optimization module is useful for enhanced load balancing algorithms within the DMZ. It offers the following benefits:
•Routing of traffic and optimization of the full capacity of the bandwidth available in the customer’s infrastructure.
•High availability support for the network traffic enabling multiple DataPower appliances to operate as a single logical system, which eliminates any single appliance as a point of failure in the DMZ.
•Sophisticated routing within the application zone, tight integration with WebSphere servers, and functionalities as an on-demand router for multiple WebSphere servers or clusters.
TIBCO EMS module
This is an add-on module to IBM DataPower Gateway to provide integration capability to TIBCO EMS application servers.
Chapter 5, “Connecting IBM Containers with on-premises Docker” on page 91, presents a scenario involving IBM POWER8®, Secure Gateway, and DataPower appliance. In this scenario, an open source enterprise resource planning (ERP) system hosted in IBM Containers on Bluemix accesses the data from a PostgreSQL database residing in a Docker container on a POWER8 server. This POWER8 server and a DataPower Virtual Appliance are behind a firewall. A secure connection is made from the ERP application running on Bluemix to PostgreSQL database through Secure Gateway service on Bluemix and DataPower Gateway appliance behind the firewall.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.