DEV Community: Ushnash (Ush) shukla

Solace PubSub+ vs Kafka: The Basics

Ushnash (Ush) shukla — Mon, 31 May 2021 18:16:51 +0000

This is the first in a series of blog posts in which we’ll compare Solace PubSub+ Event Broker with Apache Kafka. Our goal is to help you understand the salient differences between the platforms, arming you with the knowledge you need to select the right streaming platform for your organization. For a quick 5-minute overview, check out this video.

About Apache Kafka

Apache Kafka is a distributed data-ingest and event streaming platform developed in 2011 by engineers at LinkedIn for consuming large volumes of log data. Although commonly called a broker, Kafka is more akin to a distributed data store than a traditional message broker. For example, Kafka only supports publish/subscribe messaging by default, and uses the concept of an ever-increasing commit log, where messages are generally retained indefinitely.

Operationally, Apache Kafka brokers run in a cluster coordinated by Apache Zookeeper. Producers publish records to consumers on named topics. Messages, termed records, are prepended to predefined topics and identified with an offset. Topics may be spread across multiple Kafka brokers using a strategy known as topic partitioning, wherein each broker stores a subset of records intended for a given topic. Consumers ingest messages from all partitions (i.e., the entire topic).

About PubSub+ Event Broker

Solace PubSub+ Event Broker offers event streaming along with traditional message broker functionality. Initially developed in 2001 as a purpose-built messaging appliance for the capital markets, the broker has since been virtualized and implemented in both standalone software and SaaS form-factors.

Solace PubSub+ supports several messaging exchange patterns including publish/subscribe, FIFO queueing, and asynchronous request/reply, and both persistent and non-persistent qualities of service. With persistent messaging, producers send events to consumers using queues; events arrive at the queue in FIFO order and are removed only once receipt is confirmed by the consumer. Non-persistent messaging supports pub/sub whereby one or more publishers send messages to multiple subscribers across topics. Unlike Apache Kafka, topics in Solace PubSub+ Event Broker are not partitioned or persistent — senders and receivers exchange messages across a single, reliable session that does not persist messages when consumers are offline.

To understand more about Solace topics vs Kafka topics, check out this popular video by Developer Advocate Aaron Lee or check out his blog post Solace Topics vs. Kafka Topics: What’s the Difference?

Conclusion

As you can see, Kafka and Solace PubSub+ have two very different internal architectures. In the next post, my colleague Himanshu Gupta will compare each platform’s publish/subscribe functionality in greater detail. Meanwhile, you can visit our website to read more about how Solace PubSub+ compares to Kafka or check out this handy one-page datasheet.

The post Solace PubSub+ vs Kafka: The Basics appeared first on Solace.

How a Strong Digital Backbone is Transforming Life Insurance

Ushnash (Ush) shukla — Thu, 22 Oct 2020 13:00:10 +0000

Like many industries today, the insurance industry is being inundated with changing customer demands and expectations — especially as main demographic segments change. However, the digital transformation necessary to meet these challenges is happening much slower for life insurance companies.

Digital transformation for life insurance companies means improved customer experience, better employee engagement, and dramatic bottom-line benefits. The insurance companies that are making the change in this industry are leaping ahead of the pack — not just because they’re serving their customers and employees better, but because so many of their competitors are simply slow to change.

In one recent example, a well-known American life insurance and annuities (L/A) provider identified the changes in their customers’ expectations and preferences, and took action. They moved from a batch-based approach to an event-driven communication model to improve actuarial data collection and analysis, marketing, customer experience, and more. This set the company apart from competitors in many unique ways.

Read on to learn more about the market shifts driving digital transformation in the insurance industry, and how leaders like our American life insurance client are transforming to keep up — and better yet, to keep ahead.

Why Insurance Customer Experience Matters Now More Than Ever

In their recent report, The Growth Engine: Superior Customer Experience in Insurance, McKinsey notes that customer experience can do far more to drive profitable growth than raising advertising spend or lowering prices.

They point to a joint J.D. Power study to illustrate this: In the last five years, U.S. auto insurance carriers that have consistently provided best-in-class experiences to their customers generated two to four times more new business growth and around 30% higher profitability. This is likely because happy customers are 80% more likely to renew their policies than unhappy customers, and the cost of retaining customers is lower than the cost of generating new customers.

With that in mind, it’s easy to see why better customer experience drives growth and profit for insurance companies. But as is the case across every industry today, customer expectations are changing, and insurance companies are struggling to figure out what this means for them.

While insurtechs are stepping in to satisfy the increasing demand from customers for instant digital transactions across channels, they haven’t yet captured a meaningful share of the market. This leaves room for incumbent life insurance providers to step up to the plate with digital transformation that serves their customers in this way. However, this gap is closing quickly.

Our life insurance customer saw this happening and were concerned that if they didn’t move quickly, they’d fall behind not only their competition, but insurtech startups.

They were moving data in batches, point-to-point through REST-based APIs, so data collection and analysis were periodic at best. Their IT infrastructure and data were not well-integrated across different agencies, states, and lines of business, so leveraging data across these environments to deliver better customer experience was nearly impossible. This also resulted in poorly timed and impersonal marketing, and the inability to give their agencies and support agents a complete, real-time view of the customer’s profile.

To get ahead of the problem, they designed a digital transformation plan that prioritized real-time data movement across different environments so the entire company could serve life insurance customers better and faster.

Digital Transformation Is Creating a More Personal Life Insurance Customer Experience

One common problem across the life insurance industry is a difference in how the customer journey is viewed. Customers view each touchpoint with an insurance provider as a step in a single journey toward a personal goal — while insurers tend to look at each touchpoint as a discrete event. This is likely the result of the fact that insurance providers have historically been very siloed, which makes coordination across silos a huge challenge.

Creating a strong digital backbone and tools that connect all customer events through choreography, eliminates these siloes, while improving customer experience while offering greater personalization and speed.

The reality is that customers and partners want digital tools today. Digital natives (younger generations that have grown up with technology) prefer to purchase for and interact with insurance companies digitally — which poses a problem for carriers that don’t have these capabilities.

McKinsey sums it up this way in their life insurance and annuities state of the industry report:

Financial advisers and captive general agents will expect a digital interface and automated tools in their interactions with insurance home offices and wholesalers — same as their customers. Successful insurers will focus on improving the partner experience to help elevate the customer experience.”

Our life insurance client addressed these challenges with a new core policy administrative system called FAST. This was a more agile and flexible alternative to their traditional application, and exposes events in real-time. To enable the event-driven interactions within the new system, they adopted Solace PubSub+ as the digital backbone.

How Digital Transformation Benefits the Employee Experience

While a recent Aon Global Employee Engagement report found that a 5% increase in employee engagement has been shown to lead to a 3% increase in revenue, the insurance workforce is operating under some unique circumstances.

Baby boomers made up one-fourth of the insurance workforce in 2018 (31% of insurance agents and 24% of underwriters) — but they are rapidly approaching the traditional retirement age. As these seasoned professionals exit the industry en masse, a wealth of institutional knowledge will go with them. And to fill these nearly 400,000 job openings and close this talent gap, the industry needs to shift tactics to appeal to younger generations.

Part of this shift must include an emphasis on the high-tech, flexible work environment an insurance career can offer. And those can’t be empty promises.

A digital backbone with event streaming can help make sure data gets to the right place at the right time. Digital tools also enable remote work and better cross-organizational collaboration. For generations of workers who value flexibility and digital communication, these tools aren’t just perks, they’re critical.

The right technology backbone can also help insurance employees shift the conversation from sales to service. In an industry where most communications are sales-focused, putting the focus on serving the customer and building trust can have far-reaching effects. In fact, proactive communication about insurance-related activities or events (such as a burglary in the customer’s neighborhood, or an impending flood), faster approval/denial of insurance coverage decisions, and quicker claims processing can mean the difference between customer loyalty and attrition.

Our insurance client used their new digital backbone with event-streaming to equip their call center agents with a real time, 360-degree view of the customer profile which includes details on the customer’s interactions with the company. Now agents are empowered to answer questions on the spot when customers call in and they have the information required to be of greater service.

The Bottom-Line Benefits of Digital Transformation for Life Insurance Companies

The life insurance industry may be lagging behind others when it comes to digital transformation, but as more insurance companies reap the bottom-line benefits, the faster the transformation will happen across the industry. The leaders who are leaping ahead already are seeing benefits like:

AI and data working together to make the business more agile and easier to scale.
Leveraging the wealth of information they have in mainframes and legacy tech.
Penetrating large, untapped market segments like younger, digitally native customers.
Capitalizing on faster-growing emerging markets, such as Asian consumers who are more open to making financial decisions online, on mobile devices or through social media.
Improving the company risk profile overall, and company risk with individual policyholders, by leveraging data collected through wearable devices.
More easily leveraging new applications and cloud services.
Smoother integration of acquired lines of business with different tools and technologies.
Knowing their customers better to improve cross-selling and upselling across lines of business.

Digital Transformation Is Already Making a Difference in the Life Insurance Industry — What’s Holding You Back?

In their recent Insurance | Digital Transformation Remaking an Industry report, Accenture found that executives believe the biggest obstacles to achieving desired results from technology investments are lack of systems integration or compatibility and lack of collaboration with the IT function.

Finding technology solutions that allow the different parts of the business to work together efficiently is key to solving these challenges — and a digital backbone can help solve this problem.

The post How a Strong Digital Backbone is Transforming Life Insurance appeared first on Solace.

Using PubSub+ Event Portal for Support and Visualization of your Kafka Streams

Ushnash (Ush) shukla — Mon, 31 Aug 2020 14:51:40 +0000

One of the persistent challenges with a distributed architecture—like with Kafka—is the ability to design your streams for reuse and supportability. This is especially true for large enterprises, where you may have hundreds, if not thousands, of streams, publishers, and consumers interacting with each other. In this post I’ll briefly introduce PubSub+ Event Portal and explore several features that help streamline the visualization, development, and support of your Kafka streams.

PubSub+ Event Portal

PubSub+ Event Portal is a revolutionary event management tool to design, create, catalog, discover, share, visualize, secure, and manage your enterprise’s entire event-driven ecosystem.

For more information about PubSub+ Event Portal, read Solace Documentation.

In the next sections, I will touch on a few of the salient aspects of the Event Portal which make it a great tool for application development and support.

Event Designer: Improved Application Visibility

Visibility is key to robust distributed applications. It allows you to easily get answers to questions like:

Who are the publishers and consumer groups?
Which topic(s) are they connecting across?
What data is being exchanged, and in what format?

Event Designer, a tool in the Event Portal, significantly enhances visibility for support engineers and developers with microservices visualization – a feature which lets them visualize which microservices are members in Kafka event streams as well as the events and schemas (Avro, JSON, XML, …) they are exchanging across topic(s).

From the developer’s perspective, they can now build their microservice with a fuller understanding of how it plays into the broader enterprise ecosystem. Similarly, support engineers can immediately narrow their focus to only the systems that may be affected by a misbehaving service.

Another key aspect of Event Designer is its ability to enumerate events and schemas. Since the portal validates schemas during design time, developers can be certain they are publishing data that is structurally consistent, which then significantly reduces errors related to schema mismatches between publishers and consumers.

Event Catalog: Event and Application Searchability

Event Catalog, another Event Portal tool, provides a searchable index of all event-related objects within an enterprise.

For developers, this increases opportunities for reuse since they need only search for an object (event, topic, schema, application) of interest to determine what is already available for use. From a support perspective, Event Catalog again lets engineers quickly sift out related objects during a troubleshooting exercise.

AsyncAPI Code Generation: Application Consistency

A final feature that enables consistency from design through to development and support is the Event Portal’s code generation capabilities. Once architects complete their modeling in Event Designer, developers can export an AsyncAPI spec of the model to any number of code generators. The resulting code stubs use the schemas, topics, and names as envisioned by the enterprise architect, leaving the developer to focus on core business logic. This level of deep consistency greatly reduces the number of elements that the application support staff needs to consider when doing root cause analysis.

For example, a developer could pass the model through a Spring Cloud Streams generator and apply a Kafka binder to the stream. This results in a publisher/consumer in far fewer steps—and with potentially greater design integrity—than writing the code from scratch.

Conclusion

PubSub+ Event Portal is truly disruptive. It offers architects, developers, and support engineers an unprecedented level of control when creating distributed applications that are better designed for reuse and supportability across the enterprise. Its features are ideal for Kafka streams visualization and development.

The post Using PubSub+ Event Portal for Support and Visualization of your Kafka Streams appeared first on Solace.

How to use Solace PubSub+ Event Broker and Postman for RESTful Request/Reply

Ushnash (Ush) shukla — Mon, 25 Nov 2019 15:32:59 +0000

Postman is perhaps the most popular tool for quickly bootstrapping RESTful interactions. Since Solace PubSub+ Software Event Broker natively supports several protocols including HTTP, it makes sense to explore some of what PubSub+ Event Broker offers using Postman.

In this tutorial, we’ll use a rudimentary request and reply scenario to produce HTTP to the broker and consume the request as JMS on the backend. Notice that we don’t need to write any API transformation. PubSub+ Event Broker seamlessly translates between HTTP and JMS for us.

Specifically:

Postman sends an HTTP request to PubSub+ Event Broker: Cloud
A Springbootbackend application consumes the request using JMS.
The backend application replies to Postman with a “Hello World” type string.

Figure 1: Simple Application for Postman

For brevity we avoid the use of TLS on either end. Also, the reply is sent on a dynamically generated reply topic, which I haven’t shown.

Downloads

Simple Springboot JMS Consumer

Set up an Instance of PubSub+ Event Broker: Cloud Free Plan

This is probably the easiest step in the entire tutorial! We setup a cloud instance of the broker to allow for communication between Postman and our backend consumer, as depicted in Figure 1.

If you already have an account, you can skip this step.

Go to https://cloud.solace.com
Click Get started.
Fill up the form and click Sign Up to create a free account.
Log in using the link you receive in the activation email. You’ll see the Services page and a single + tile.
Click the + tile to get to the Create Service
Follow the steps outlined in the image below to create a free event broker service on an available AWS region. Note: Currently, the Free tier is offered only on AWS. Your service is up and running in a few seconds.

Set up Postman

Before we wire up any applications, let’s set up Postman to interact with the broker.

Fire up Postman and click New > Request.
Save the request in an existing Collection or create one for this tutorial. Personally, I created a new one named Postman to Solace ** PubSub ***+*.
Change the METHODto POST for the blank request as PubSub+ Event Broker only handles HTTP POST requests by default. You can enable other HTTP verbs using Microgateways.
To communicate with PubSub+ Event Broker, head over to the instance of PubSub+ Event Broker: Could that you created earlier and click the Connect tab.
Select View by: > Protocol in the top right hand and scroll down to the REST Expand the section to view the Connection Details for your service. In our case, we are interested in Username, Password, and REST Host.
Back in Postman, enter the POST Host, Username, and Password details from the above step, paste them into the related fields, and click Save.
Append /T/service/requestto the Host URL in Postman. This routes the request to the T/service/request topic on the broker. Note 1: PubSub+ creates the topic dynamically on the server side. Note 2: The request body is left empty intentionally.
Save the request and click Send. You should get an empty response with an HTTP 200 Postman and our instance of PubSub+ Event Broker: Cloud are now talking!

Our Springboot Consumer

Our Springboot JMS consumer replies to any requests received on T/service/request. Spring handles the JMS configuration boilerplate, leaving us free to focus on the relevant application logic.

Using JMS with Spring is a deep topic outside the scope of this tutorial. Read this tutorial to learn the details.

Maven Configuration

We import Solace’s Springboot starter to make life easier.

<dependency> <groupId>com.solace.spring.boot</groupId> <artifactId>solace-jms-spring-boot-starter</artifactId> <version>3.2.0</version> </dependency>

Java Code

This is the primary class that processes messages received on T/service/request and replies appropriately. As you can see, all the code does is reply with “Hello” prepended to the request body.

package com.solace.jmshelloworld; import org.springframework.jms.annotation.JmsListener; import org.springframework.stereotype.Component; @Component public class Receiver { @JmsListener(destination = "${app.jms.topic}", containerFactory = "myFactory") public String receiveMessage(String message) { System.out.printf("Received <%s>\n", message); return "Hello " + message + "!"; } }

Application Properties

We set the various properties used by both our service and the Solace PubSub+ Springboot starter.

You can get the PubSub+ Event Broker properties from Solace Messaging > Solace JMS API under the Connect tab of your Solace PubSub+ Event Broker: Cloud instance. Be sure to select View By: Protocol in the top right hand.

#Solace propertiessolace.jms.host = tcp://mr1ilyoa01l8fn.messaging.solace.cloud:20352solace.jms.msgVpn = msgvpn-1nljqp0y1addsolace.jms.clientUsername= <u>solace-cloud-clientsolace.jms.clientPassword= <u>a29qovgiu8io1buvub6pm3gbv4#Topic for incoming requestapp.jms.topic = T/service/request

We start the service from the command line using mvn clean spring-boot:run

Assuming everything was configured correctly, the application should fire up and begin listening for request messages.

Finalizing our Postman Setup

Since this is a request/reply exercise, we need to ask PubSub+ Event Broker to keep the HTTP session open for a reply. We do this by setting the Solace-Reply-Wait-Time-In-ms to a reasonable value in milliseconds. This also has the effect of creating a temporary reply-topic on the broker where our Springboot service will send responses.

Finally, put your name (or any string, really) in the Body.

Testing the Integration

Time to test what we built! You should have the following configured and running:

A PubSub+ Event Broker: Cloud instance
Postman configured to send requests to the PubSub+ Event Broker and wait for responses
A SpringbootJMS application listening for messages on T/service/request

Save your Postman request and click Send. If everything goes well, Postman will receive a greeting from the backend service.

Conclusion

That’s it! In a few easy steps, we were able to:

Send an HTTP request to PubSub+ using Postman.
Consume the request in Java using JMS and respond back to Postman using HTTP.

The PubSub+ Event Broker took care of all the necessary API and protocol transformations for us.

The post How to use Solace PubSub+ Event Broker and Postman for RESTful Request/Reply appeared first on Solace.

Setting up a REST Delivery Point for SOAP Endpoints

Ushnash (Ush) shukla — Thu, 18 Apr 2019 20:54:45 +0000

Fronting synchronous HTTP endpoints with queues and topics allows senders and receivers of information to actively participate in event-driven systems, which are usually the domain of asynchronous messaging interactions.

Solace PubSub+ lets you front HTTP endpoints with queues and topics by proxying RESTful calls via REST Delivery Points (RDPs) and API Microgateway software. In this post I’ll discuss the differences between those options and show you how to use the API Microgateway to proxy a SOAP Web service. To keep things interesting, our sample Web service requires clients to use both TLS and WS-Security.

Here’s a visual overview of what we’ll be doing:

Prerequisites

You should know:

How to set up, configure and use PubSub+, and obviously you’ll need a copy of PubSub+, which you can download here.
How to install and use Docker and Linux
About SOAP Web Services

Differences Between the API Microgateway and RDP

Solace PubSub+ supports two approaches to RESTful messaging, namely REST messaging mode and the API Microgateway or REST gateway mode. The table below summarizes some of the key differences between the two approaches.

	REST Messaging Mode	REST Gateway Mode (Microgateway)
Default mode	Fire & Forget (request/reply optional)	Request/Reply
Propagates HTTP headers?	No	Yes
Supports all HTTP verbs?	No	Yes
Receive requests on	Queues	Topics

In short, we tend to use RDPs when the use case calls for sending vanilla HTTP POSTs, with optional request/reply semantics. Since we want a reply from the postoffice endpoint and may need to optionally set the SOAPAction header, the Microgateway approach is the better choice.

Find a Secure SOAP Web service

First, we need to find a SOAP Web service that supports HTTPS and WS-Security. Fortunately, Canada Post offers several APIs that match these criteria once you register with their free Developer Program. Why Canada Post? Because we’re a proud Canadian company!

For this tutorial, we’ll be querying the GetNearestPostOffice operation to find postal outlets near Solace’s headquarters in Ottawa, Canada.

Fire Up a Solace PubSub+ Instance

Next, we need to set up a PubSub+ instance. The simplest way to achieve this is via the PubSub+ Docker Compose YAML. Be sure to uncomment the line exposing the REST Default VPN port, i.e. 9000. Without this, we won’t be able to execute an HTTP POST against the PubSub+ instance.

Log in to Your Broker Instance

Once the container boots up, log in to http://localhost:8080 in your browser with the username admin and password admin.

You should now have a secure SOAP Web service from Canada Post, a PubSub+ instance, and be logged in to your broker instance.

Set up the Microgateway

In this section I’ll explain how to enable the Microgateway connectivity, then create the RDP, a REST consumer, and a queue binding.

Enable the Microgateway Connectivity

To enable the Microgateway connectivity:

Navigate to Message VPN > Connectivity > REST.
Change the service’s mode to Gateway.

Keep in mind that microgateways operate at the VPN level, which means you cannot mix and match REST Delivery Points and gateways for a given VPN.

Create the RDP

Although distinct, gateways leverage RDPs internally to achieve service connectivity. Consequently, we still need to set up an RDP to connect to our Canada Post service.

Click on the default VPN and go to *Client Connections > REST. * This will bring up the RDP configuration page.
Click on the green REST Delivery Point button in the top right corner.
Give your RDP a name (e.g. Canada Post) and click Create. Keep in mind that this step does not do anything functional. We’re simply establishing a top-level bucket for the actual SOAP configuration.
Leave the defaults and click Apply. Do not turn on Enabled yet.
The newly created RDP is displayed in the Downstate along with some operational data.

Create a REST Consumer

To create a REST consumer:

Click on the newly created RDP to drill down to REST Consumers: Canada Post > REST Consumers. This is where we define the connection parameters for the Web service.
Click on the green REST Consumer button to add a new REST consumer.
Give the new REST consumer a name that reflects the SOAP endpoint (e.g. postoffice if the URL is http://www.canadapost.ca/ws/soap/postoffice). Though not strictly necessary, naming your endpoint this way helps to keep things identifiable in situations with multiple endpoints.
Click on your new consumer endpoint, complete the host details, and set the port to 443 for HTTPS. Do not enable the consumer yet.
Click Apply.

Create a Queue Binding

Along with the host, you need to identify the exact endpoint to connect to. Since PubSub+ is primarily an event broker, clients interact with it via queues and topics. Consequently, we need to attach the endpoint to a queue to receive SOAP payloads. This is done through queue bindings.

To bind a queue, you need to define a queue, bind the queue to the SOAP endpoint, and subscribe the queue to a topic.

Define a Queue

Navigate to the Queues tab and click on the green + Queue button in the top right corner.
Create a queue in the form of [rdpname].[consumername] and click Create. This format is not mandatory but useful when you need to quickly identify the queue related to a given SOAP endpoint.
Tune the queue settings as necessary for your implementation and click Apply.

Bind the Queue to the SOAP Endpoint

Now that we have a queue defined, you can bind it to your SOAP endpoint.

Navigate to Connections > REST > Canada Post > Queue Binding.
After clicking on the green + Queue Binding button, select the queue we previously created and click Create.
In the dialog that pops up, enter the SOAP endpoint in the Post Request Target field and click Apply.

Note : Don’t forget the leading “/”.

Set Up a Topic to Queue Subscription

Microgateway mode requires users to send service requests on a special topic consisting of the HTTP Method + HTTP Resource Path. This is then mapped to the queue binding you created above. Listing 1 demonstrates how a topic may be constructed.

Resource path from WSDL: https://ct.soa-gw.canadapost.ca /rs/soap/postoffice
HTTP Method: POST
Resulting PubSub+ topic: POST/rs/soap/postoffice

To subscribe our queue to this topic, navigate to Queues > postoffice > Subscriptions and click + Subscription.
Enter the relevant subscription and click Create.

Once subscribed, any requests POSTed to /rs/soap/postoffice on the broker are forwarded to the associated queue, triggering a call to the example Web service.

Set Up TLS

In this section I’ll explain how to upload the TLS certificates, load the certificate authority and add Trusted Common Names.

Phew! The service is now set up… well, almost. You’ll notice that we have not enabled anything yet since TLS has not been configured. We will do this by adding the appropriate certificate authorities (CA) to the PubSub+ trust store in PEM format.

Note: Certificate Authorities can currently only be setup using the PubSub+ CLI and the Solace Element Management Protocol (SEMP).

Upload the TLS Certificates

PubSub+ requires that the entire certificate authority chain for a given site be uploaded to the /certs directory on the broker. Initially obtaining the certificates can be accomplished using a browser or openssl. However, the exact process is outside the scope of this post.

Note: The root & all intermediary CAs must be installed individually on the PubSub+ instance. PubSub+ does not support bundled CAs.

Once you have the individual certificates, connect to the container’s shell and save each certificate under /usr/sw/jail/certs. The easiest way is to open a text editor in the directory and copy and paste the contents of each certificate to a new file.

C:\Users\UshShukla\>docker exec -it \<PubSub+ container name\> /bin/bash The Solace PubSub+ Standard is proprietary software of Solace Corporation. By accessing the Solace PubSub+ Standard you are agreeing to the license terms and conditions. [root@f0fb1e6fe45d ~]# cd /usr/sw/jail/certs [root@f0fb1e6fe45d ~]# vi geotrust-rsa-ca.pem …paste contents… …save file… …repeat for other certificates…

Load the Certificate Authority

Now that our CAs are saved, we need to load them into the PubSub+ trust store, as documented here. An example of loading the root certificate authority is provided below.

[root@f0fb1e6fe45d certs]# /usr/sw/loads/currentload/bin/cli -A Solace PubSub+ Standard Version 9.0.0.17 The Solace PubSub+ Standard is proprietary software of Solace Corporation. By accessing the Solace PubSub+ Standard you are agreeing to the license terms and conditions. To purchase product support, please contact Solace at: https://solace.com/contact-us/ Operating Mode: Message Routing Node f0fb1e6fe45d&amp;gt; enable f0fb1e6fe45d# configure f0fb1e6fe45d(configure)# authentication f0fb1e6fe45d(configure/authentication)# create certificate-authority DigiCert-Global-Root-CA f0fb1e6fe45d(.../authentication/certificate-authority)# certificate file digitrust-root-ca.pem

We name the certificate authority according to the Common Name (CN) (e.g. DigiCert…). This approach reduces the likelihood of duplicating CAs in the trust store.

Once uploaded to the trust store, the original CA file can be removed from the /certs/ directory.

Add the Trusted Common Names

For PubSub+ to identify the appropriate certificate(s) to use when interacting with the Web service, we need to update our RDP configuration with the Common Names of each certificate. The example below uses openssl to get this information, though you could just as easily inspect the TLS output of your browser.

[root@f0fb1e6fe45d certs]# openssl s\_client -connect ct.soa-gw.canadapost.ca:443 CONNECTED(00000003) depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = GeoTrust RSA CA 2018 verify return:1 depth=0 C = CA, ST = Ontario, L = Ottawa, O = Canada Post Corporation, OU = Information Technology-2, CN = stg10.canadapost.ca

In the listing above, we care about all the CN entries.

In the WebUI, log in and navigate to Client Connections>REST>Canada Post>REST Consumers>postoffice>TLS Options
Click on the green + Trusted Common Name button to add the individual CNs.

The completed setup looks like this:

Note: We added the CN of the leaf certificate too, i.e. stg10.canadapost.com.

Enable the RDP and Test the Setup

In this section I’ll explain how to enable the RDP and test the setup.

Enable the RDP

We are ready to fire up the REST Delivery Point! Individually enable each of the configuration elements below:

REST Consumer > postoffice > Enabled
Client Connections > REST > Canada Post > Enabled

If everything has been configured correctly, the RDP status should be Up.

You can drill down to ensure the REST Consumer is Up, too.

Test the Setup

We can test our setup using SOAPUI.

** **

\<?xml version="1.0"?\> - \<soapenv:Envelope xmlns:pos="http://www.canadapost.ca/ws/soap/postoffice" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"\> \<soapenv:Header/\> -\<soapenv:Body\> -\<pos:get-nearest-post-office-request\> \<!--You may enter the following 3 items in any order--\> \<!--Optional:--\> \<locale\>${#Project#language}\</locale\> \<!--Optional:--\> \<maximum\>2\</maximum\> -\<search-data\> \<d2po\>true\</d2po\> \<postal-code\>K2K 3B8\</postal-code\> \</search-data\> \</pos:get-nearest-post-office-request\> \</soapenv:Body\> \</soapenv:Envelope\>

Notes:

The service host in this case is the broker, and we are POSTing to the resource path configured in our topic-queue mapping.
We enable basic authentication and select the option to Authenticate pre-emptively. Why? Since PubSub+ acts as a proxy to the final service, it needs to have the entire payload available to send. Otherwise our call will fail. Selecting the option above essentially ensures SOAPUI pre-builds the entire request payload, including the WS-Security headers.
Be sure to set the SOAPAction HTTP header if necessary. This example does not require it.

Conclusion

With a little effort, PubSub+ can let you expose SOAP Web services across an asynchronous messaging architecture, allowing them to fully enjoy the benefits of an event-driven architecture.

Learn more about:

The post Setting up a REST Delivery Point for SOAP Endpoints appeared first on Solace.

DEV Community: Ushnash (Ush) shukla

Solace PubSub+ vs Kafka: The Basics

About Apache Kafka

About PubSub+ Event Broker

Conclusion

How a Strong Digital Backbone is Transforming Life Insurance

Why Insurance Customer Experience Matters Now More Than Ever

Digital Transformation Is Creating a More Personal Life Insurance Customer Experience

How Digital Transformation Benefits the Employee Experience

The Bottom-Line Benefits of Digital Transformation for Life Insurance Companies

Digital Transformation Is Already Making a Difference in the Life Insurance Industry — What’s Holding You Back?

Using PubSub+ Event Portal for Support and Visualization of your Kafka Streams

PubSub+ Event Portal

Event Designer: Improved Application Visibility

Event Catalog: Event and Application Searchability

AsyncAPI Code Generation: Application Consistency

Conclusion

How to use Solace PubSub+ Event Broker and Postman for RESTful Request/Reply

Downloads

Set up an Instance of PubSub+ Event Broker: Cloud Free Plan

Set up Postman

Our Springboot Consumer

Maven Configuration** **

Java Code

Application Properties

Finalizing our Postman Setup

Testing the Integration

Conclusion

Setting up a REST Delivery Point for SOAP Endpoints

Differences Between the API Microgateway and RDP

Find a Secure SOAP Web service

Fire Up a Solace PubSub+ Instance

Log in to Your Broker Instance

Set up the Microgateway

Enable the Microgateway Connectivity

Create the RDP

Create a REST Consumer

Create a Queue Binding

Define a Queue

Bind the Queue to the SOAP Endpoint

Set Up a Topic to Queue Subscription

Set Up TLS

Upload the TLS Certificates

Load the Certificate Authority

Add the Trusted Common Names

Enable the RDP and Test the Setup

Enable the RDP

Test the Setup

Conclusion

Maven Configuration