My ODM application uses interceptors. I am trying to deploy my rules on the Business Rules service on Bluemix. How do I configure the Business Rules service to use interceptors?
I found that the use of interceptors is not supported by the Business Rules service on Bluemix. I redesigned my rules so that my application did not depend on interceptors.
Related
At present we have a lot of ASP.net WebAPI service applications hosted on premises. We are planning to move these to Azure AKS. We've identified a lot of common code across these applications which is mostly implemented as ASP.Net reusable middleware components so that the logic is not duplicated in code.
In a K8s environment it makes sense to offload this common functionality to one or more proxy applications which intercepts the requests being forwarded from the ingress to the services (assuming this is the correct approach). Some of the request inspection / manipulation logic is based on the service host and path to be defined in the ingress and even on the headers in the incoming requests.
For e.g. I considered using OAuth2_proxy but found that even though authentication is quite easy to implement, Azure AD group based authorization is impossible to do out of the box with that. So what's the idiomatic way one goes about setting up such a custom proxy application? (I'm familiar with using libraries such as ProxyKit middleware in ASP.Net to develop http proxies.)
One approach that comes to mind is to deploy such proxies as sidecar containers in each service application pod but that would mean there'd be unnecessary resource usage by all such duplicate container instances in each pod. I don't see the benefit over the use of middleware components as mentioned previously. :(
The ideal setup would be ingress --> custom proxy 1 --> custom proxy 2 --> custom proxy n --> service where custom proxies would be separately deployable and scalable.
So after a lot of reading and googling I found that the solution was to use API Gateways that are available as libraries (preferrably based on .Net):
Ocelot placed behind the nginx ingress fits the bill perfectly
Ocelot is a .NET API Gateway. This project is aimed at people using .NET running a micro services / service oriented architecture that need a unified point of entry into their system. However it will work with anything that speaks HTTP and run on any platform that ASP.NET Core supports.
Ocelot is currently used by Microsoft and Tencent.
The custom middleware and header/query/claims transformation solves my problem. Here are some worthy links
Microsoft Docs: Implement API Gateways with Ocelot
Ocelot on Github
Ocelot Documentation
Features
A quick list of Ocelot's capabilities for more information see the documentation.
Routing
Request Aggregation
Service Discovery with Consul & Eureka
Service Fabric
Kubernetes
WebSockets
Authentication
Authorisation
Rate Limiting
Caching
Retry policies / QoS
Load Balancing
Logging / Tracing / Correlation
Headers / Query String / Claims Transformation
Custom Middleware / Delegating Handlers
Configuration / Administration REST API
Platform / Cloud Agnostic
some examples of application service, domain service and infrastructure serviceapplication service, domain service and infrastructure service
Logging is an infrastructure service (In general, they are not related with the business logic).
Retrieving all invoices is a domain service (In general, they are CRUD operations).
Changing a password is an application service (In general they involve many CRUD operations included in a workflow).
Take a look at this: http://www.bennadel.com/blog/2385-application-services-vs-infrastructure-services-vs-domain-services.htm
Within Jhipster the documentation states:
Generating entities in a microservices architecture
If you choose to generate the entity from a microservice, you will need to enter the path to this microservice on your local computer, and then JHipster will generate the front-end code on the gateway.
No lets say I have multiple Gateways. Does this mean if I have a common Microservice Application. I create the Microservice Application entity then run the generator within each Gateway that would use this service?
Is this the intent of the generator?
Yes, you can have multiple gateways which use the same microservice. As you said, you will have to run the generator within each Gateway and enter the path for your microservice.
The main intent was having one gateway communicating with multiple microservices.
I want to expose a REST-ful service as an API to the outside world on Bluemix Public. Therefore I have a liberty app, containing a REST service implemented in JAX-RS.
Additionally I leverage the "API Management Service" to secure that app, via Plans, Authentication etc. So thanks to the API Management Gateway I have a secure proxy to my service exposed.
Yet, the app that provides my service remains accessible to the outside via the Bluemix route. So, it can be called without any credentials or whatsoever.
Is there a way, to only have my API Management gateway access the service implementation app?
One approach would be to delete the route of the service implementing app, but how would you then bind the API Management to the service?
Happy to hear your thoughts or alternative solutions.
If your API is running on Bluemix Public as a Cloud Foundry application, there is currently not a way to create a route such that it is only accessible by the API management service, but not the the outside world. You should implement security within your jax-rs application (easy to with web.xml security-constraint) and add those credentials to APIm service if you still want to use APIm to get monitoring, throttling, discovery, etc.
Another option would be to deploy the application in a VM and then use Secure Gateway to connect to it:
https://github.com/IBM-Bluemix/onprem-integration-demo
I have configured the Hosted Transparent Decision Services (HTDS) web application for ODM. Can I apply similar configuration changes when using the Business Rules service on Bluemix?
The Business Rules service on Bluemix does use HTDS to execute rules, however it is not possible to configure the HTDS web application for the service.