Distributed application case interactions

With Pega Web Mashup, you can embed mashup code in any website architecture. Use this option when you need to embed Pega UI content into the website of your organization whether it is hosted on-premises or the cloud. For example, you can embed a credit card application case type into a bank's corporate website. The following figure shows a mockup of what the embedded channel might look like when embedded in external web site:

For more information, see Pega web mashups for embedding Pega Platform UI in external web pages.

Beginning with Pega Platform version 8.3, the Pega domain in mashups is based on semantic URLs that contain the application name and its unique identifier. With this solution, you can run multiple mashups of the same application or different applications on a target website. 

For example, a manager who logs in to their internal bank website should show approval cases from loan and credit card applications. Now, this feature of multiple mashups will help to achieve this requirement.  

For more information, see Include multiple mashups on a single page (8.3) and Best practices for using multiple mashups

Web Embed is the same method as Web Mashup but is specific to Constellation UI architecture applications. The benefit of Web Embed is that it works well with any of your current adopted front-end framework tools. Web Embed in a Constellation UI architecture application relies on HTML5 web components. Web Embed supports defining custom full-fledged HTML elements. 

For more information, see Embedding Constellation UI in web pages.

The microservices architecture is a method for developing applications using independent, lightweight services that work together as a suite. In a microservices architecture, each service participating in the architecture:

• Is independently deployable.
• Runs a unique process.
• Communicates through a well-defined, lightweight mechanism.
• Serves a single business goal.

The microservice architectural approach is usually contrasted with the monolithic application architectural approach. For example, instead of designing a single application with Customer, Product, and Order case types, you might design separate services that handle operations for each case type. Exposing each case type as a microservice allows the service to be called from multiple sources, with each service independently managed, tested, and deployed.

The following diagram compares a Multiple Responsibility Monolithic Application to a Microservices Architecture. In the Multiple Responsibility Monolithic Application, multiple case types (Customer, Product, and Order) are tightly coupled, which makes their intelligence difficult to reuse. By breaking up the monolithic application into multiple independent, loosely coupled built-on applications (in this case, Customer, Product, and Order), each component becomes modular and cohesive. The applications are more straightforward to document, understand, expose as a single responsibility microservice, and reuse across the enterprise. The Multiple Responsibility Monolithic Application is then built on the single responsibility microservice applications that use multiple built-on applications.

While Pega Platform itself is not a microservice architecture, Pega Platform complements the microservices architectural style for the following reasons:

• You can expose any aspect of Pega Platform (including cases) as a consumable service, allowing Pega Platform to participate in microservices architectures. For more information about Pega API, see Pega API for the Pega Platform. 
• You can create a service as an application or as an individual service that exists in its own ruleset.
• You can reuse services that you create across applications, implementing the Situational Layer Cake™ for additional flexibility in what each service can do without overloading the service.

Check your knowledge with the following interaction: