Azure Thoughts, EAI Challenges

In the previous blog post I demonstrated how I can secure my internal BizTalk services application with requirements for Federated Security based on SAML tokens. The goal was to enable my BizTalk service to be a “claims-aware” application. Just like with all other cases of virtualizing BizTalk services through Sentinet, turning the BizTalk service application into a “claim-aware” application did not require any coding or configuration changes, the existing BizTalk application remained deployed and configured as is. In this post I would like to continue where I left off in the previous post, and demonstrate how to set up yet another endpoint in the virtual service. This will be the endpoint that leverages the Microsoft Azure Service Bus so that my internal BizTalk services application can be accessible from outside of the internal network through the Azure Service Bus Relay Service. The Microsoft Azure Service Bus Relay service enables you to build hybrid applications that run i...

In the previous post I have demonstrated how I can secure my internal BizTalk services application with X.509 certificates security (that might represent a hypothetical B2B application-to-application scenario). For that, I did not have to change anything in the way my internal BizTalk application is deployed or configured. I accomplished that by simply virtualizing the BizTalk service through a Sentinet virtual endpoint that requires X.509 certificate. I also showed how Sentinet provides additional managed access control (authorization) and messages exchange monitoring. In this post I would like to continue, where I left off in the previous post, and demonstrate how to set up my virtual service with yet another endpoint that will enable my BizTalk application with a different security mechanism based on SAML claims. I will use a SAML token to demonstrate a Federated Security scenario. Effectively, the objective of this use case will be to enable my BizTalk service to be a “claims-a...

In the previous post I have discussed the benefits of the service virtualization concept for BizTalk applications that have to provide many alternative endpoints configured with different security requirements. I have demonstrated how Sentinet provides easy means to achieve this goal where I configured Sentinet virtual service with two endpoints that route messages to the same single BizTalk Receive Location. Both endpoints provide secure HTTPS access to the BizTalk application with one endpoint configured with anonymous access, and the second configured with the username/password authentication and access control based on specific username/password credentials. In this post I would like to continue where I left off in the previous post, and demonstrate how to set up another endpoint in the virtual service. This time I want my BizTalk application to make use of a different security mechanism based on the client X.509 certificate. Digital certificates are often used in an applicatio...

In the previous post I have discussed the protocol mediation between SOAP and REST services by the Sentinet product. I also demonstrated how Sentinet provides monitoring capabilities for service and API message exchanges. In this post I would like to continue my exploration of the Sentinet and share my experiences of using Sentinet together with the BizTalk Server. In this scenario I want to expose the data of my LOB systems through the BizTalk Server. The BizTalk Adapter Pack includes WCF LOB Adapters that will give me access to LOB systems like SAP, Oracle eBusiness suite, and databases like SQL Server or Oracle. After BizTalk Send Port is configured with the WCF LOB Adapter to interface with LOB system, I can provide BizTalk with inbound endpoints that will expose my LOB data as a SOAP or REST service. I can expose BizTalk service endpoints using regular BizTalk WCF Adapters with bindings for HTTP or SOAP protocols. The access to these endpoints must be secured with authenticat...