I'm trying to manage a FHIR workflow based on API Rest for resources CRUD (as Patient, Practitioner and so on).
For workflow handling among different systems I want to use task resource, but I don't want to manage the Subscription resource and it's architecture.
So I have a doubt about manage of notifications.
The correct way is: the different systems must apply a polling operation on server to know if there's a task resource to consume? Or is it the server to warn the different systems?
The server FHIR I want to use is R4.
EDIT
We want to create a interoperability platform about the exchange of data among three systems. Every system is already in production developed by different software house and we can't work on them.
Every system, actually, hasn't got a server FHIR (as the Option B of Workflow architecture).
Every system is available about communication in HL7 v.3 / FHIR
So we want to add a layer with FHIR Server as the below image.
In this case:
if System A sends to FHIR server a resource (i.e. Appointment) then System B take this appointment to process in its environment. How works the schema of communication?
The FHIR workflow communication patterns page defines a number of architecture alternatives. One possibility is to create the Task on the fulfiller's system. In that case, no need for polling or subscription. If the Task is created on the placer's system or an intermediary system and you're sticking with pure REST, then the fulfilling system will need to either have a subscription that will result in them receiving a notification about the Task or they'll have to poll. Other non-RESTful options include POSTing to a "process task" operation on the fulfilling system or sending a FHIR message to the fulfilling system.
Related
Architecture Overview
Suppose we're building an SPA (Single Page Application) which depends on a couple of independent back-end systems. Basically a Microservice-ish implementation of SignalR-hubs.
Each of these back-end systems expose a separate SignalR endpoint with a separate set of hubs;
The separation of these hubs across different back-end systems is intentional in design (again, because of microservice-ish considerations).
Basically, a single browser session to the app will have to maintain a separate SignalR-connection for every endpoint on which we depend and connections will be managed (opened and closed) on demand by the relevant components.
A flow that I can think of for an example would be:
A request initiates a booking request -> booking request is dependent on n number of services in order to be "completed" (whether succeeded or failed) -> due to asynchronous communication between those services, the client will receive a "booking id" for reference and will be notified on booking process through the relevant "booking-hub" that handles certain events from different services -> leaving the "booking component" will cause the hub to disconnect.
This leads us to the following questions:
In an architecture overview, is it a right assumption that also a SignalR hub(s) should be completely decoupled?
Are there any best practices regarding the usage of "websockets" in combination of a microservice-ish architecture?
Are there any limitations (beside the fact that some browsers might limit the number of websocket connections) in manner of scaling?
In an architecture overview, is it a right assumption that also a SignalR hub(s) should be completely decoupled?
Many resources and what I have seen in my office implementations is that it is a better approach have a single Hub (core) that can be used from your services.
Are there any best practices regarding the usage of "websockets" in combination of a microservice-ish architecture?
It depends of how you want to handle your connection.
Are there any limitations (beside the fact that some browsers might limit the number of websocket connections) in manner of scaling?
Webscokets can have only 10 connections at once.
PS: About the connection, in the old SignalR version (#aspnet/signalr) the re-connections where managed by SignalR but in the new version you need to do that by yourself.
Is it possible to subscribe to mail events on an IBM Domino server?
I need a service similar to the one provided by Microsoft Exchange Event Notification, where you can subscribe to events and get notified when there are changes - eg. arrival of a new e-mail. I need the solution to be server side, since I can't rely on users having their client running.
Unfortunately, as per my comment above, there is no pre-packaged equivalent to the push, pull and streaming subscription services that EWS supports. A Notes client can get notifications via Notes RPC protocol, and there's also obviously some technology in IBM's Notes Traveler mobile product, but nothing that I'm aware of as a pre-packed web service or even as a notifications API. You would have to build it. There are a variety of ways you could go about it.
For push or streaming subscriptions, one way would be with a Notes C API plugin using the Extension Manager, running on the server and monitoring the mailboxes. You might be able to use a DSAPI plugin into Domino's HTTP stack to manage the incoming connections and feed the data out to subscribers, but honestly I have no idea if Domino's HTTP stack can handle the persistent connections that are implied in the subscription model. Alternatively, the Extension Manager plugin could quickly send the data over to code written in any other language that you want, running on any web stack that. Of course, you'll have to deal with security through all the linked-together parts.
For pull subscriptions, I guess it's really more of a polling archiecture, with state saved somewhere so that only changes since the last call will be delivered. You have any number of options for that. You could use Domino's built-in HTTP server, obviously, so you could write your own Domino-hosted web service for this. You could also use the Domino Data Service, which is a REST API, to do this -- with all necessary state information being stored on the client-side. (On quick look, I don't see a good option for getting all new docs since a specified date-time via Domino Data Service, but it might be possible.)
I do worry a bit about scalability of any custom solution for this. My understanding is that Microsoft has quite a bit of caching and optimization in their services in order to address scale. Obviously, you can build whatever you need for that into your own web service, but it will likely add a lot of effort.
What is the most sensible approach to integrate/interact NServiceBus Sagas with REST APIs?
The scenario is as follows,
We have a load balanced REST API. Depending on the load we can add more nodes.
REST API is a wrapper around a DomainServices API. This means the API can be consumed directly.
We would like to use Sagas for workflow and implement NServiceBus Distributor to scale-out.
Question is, if we use the REST API from Sagas, the actual processing happens in the API farm. This in a way defeats the purpose of implementing distributor pattern.
On the other hand, using DomainServives API directly from Sagas, allows processing locally within worker nodes. With this approach we will have to maintain API assemblies in multiple locations but the throughput could be higher.
I am trying to understand the best approach. Personally, I’d prefer to consume the API (if readily available) but this could introduce chattiness to the system and could take longer to complete as compared to to in-process.
A typical sequence could be similar to publishing an online advertisement,
Advertiser submits a new advertisement request via a web application.
Web application invokes the relevant API endpoint and sends a command
message.
Command message initiates a new publish advertisement Saga
instance.
Saga sends a command to validate caller permissions (in
process/out of process API call)
Saga sends a command to validate the
advertisement data (in process/out of process API call)
Saga sends a
command to the fraud service (third party service)
Once the content and fraud verifications are successful,
Saga sends a command to the billing system.
Saga invokes an API call to save add details. (in
process/out of process API call)
And this goes on until the advertisement is expired, there are a number of retry and failure condition paths.
After a number of design iterations we came up with the following guidelines,
Treat REST API layer as the integration platform.
Assume API endpoints are capable of abstracting fairly complex micro work-flows. Micro work-flows are operations that executes in a single burst (not interruptible) and completes with-in a short time span (<1 second).
Assume API farm is capable of serving many concurrent requests and can be easily scaled-out.
Favor synchronous invocations over asynchronous message based invocations when the target operation is fairly straightforward.
When asynchronous processing is required use a single message handler and invoke API from the handlers. This will delegate work to the API farm. This will also eliminate the need for a distributor and extra hardware resources.
Avoid Saga’s unless if the business work-flow contains multiple transactions, compensation logic and resumes. Tests reveals Sagas do not perform well under load.
Avoid consuming DomainServices directly from a message handler. This till do the work locally and also introduces a deployment hassle by distributing business logic.
Happy to hear out thoughts.
You are right on with identifying that you will need Sagas to manage workflow. I'm willing to bet that your Domain hooks up to a common database. If that is true then it will be faster to use your Domain directly and remove the serialization/network overhead. You will also lose the ability to easily manage the transactions at the database level.
Assuming your are directly calling your Domain, the performance becomes a question of how the Domain performs. You may take steps to optimize the database, drive down distributed transaction costs, sharding the data, etc. You may end up using the Distributor to have multiple Saga processing nodes, but it sounds like you have some more testing to do once a design is chosen.
Generically speaking, we use REST APIs to model the commands as resources(via POST) to allow interaction with NSB from clients who don't have direct access to messaging. This is a potential solution to get things onto NSB from your web app.
We've got a Windows service that is connected to various client applications via a duplex WCF channel. The client and server applications are installed on different machines, in different locations, potentially at widely different times, and by different people. In addition, the client can be pointed at a different machine running the same Windows service at startup.
Going forward, we know that the interface between the client and the server applications will likely evolve. The application in the field will be administered by local IT personnel, and we have no real control over what version of either of these applications will be installed when/where or which will be connecting to the other. Since these are installed at various physical locations and by different people, there's a high likely that either the client or server application will be out of date compared to the other.
Since we can't control what versions of the applications in the field are trying to connect to each other, I'd like to be able to verify that the contracts between the client application and the server application are compatible.
Some things I'm looking for (may not be able to realistically get them all):
I don't think I care if the server's interface is newer or older, as long as the server's interface is a super-set of the client's
I want to use something other than an "interface version number". Any developer-kept version number will eventually be forgotten about or missed.
I'd like to use a computed interface comparison if that's possible
How can I do this? Any ideas on how to go about this would be greatly appreciated.
Seems like this is a case of designing your service for versioning. WCF has very good versioning capabilities and extension points. Here are a couple of good MSDN articles on versioning the service contract and more specifically the data contracts. For backward and "forward" compatible versioning look at this article on using the IExtensibleDataObject interface.
If the server's endpoint has metadata publishing enabled, you can programmatically inspect an endpoint's interface by using the MetadataResolver class. This class lets you retrieve the metadata from the server endpoint, and in your case, you would be interested in the ContractDescription which contains the list of all operations. You could then compare the list of operations to your client proxy's endpoint operations.
Of course now, comparing the lists of operations would need to be implemented, you could simply compare the operations names and fail if one of the client's operations is not found within the server's operations. This would not necessarily cover all incompatiblities, ex. request/response schema changes.
I have not tried implementing any of this by the way, so it's more of a theoretical view of your problem. If you don't want to fiddle with the framework, you could implement a custom operation that would return the list of operation names. This would be of minimal effort but is less standards-compliant.
What tools will come in handy to debug and monitor SaaS services built on WCF in production environment ?
FYI - No access to the actual server whatsoever. No remoting in, and no access to the file system.
There are dozens of 'dotcom-monitors' (eg site24x7.com) but they can only monitor parameters that are publicly available, like site uptime, response times etc.
If you want to monitor memory usage and other parameters known only from 'inside', then you have two choices: either install some monitoring agent on a server (in most cases it would be a pain).
You can also send 'signals' from your code to some external event handling and notification service. I recommend AlertGrid (http://alert-grid.com) for the latter purpose it is very flexible and extremely easy to integrate.
AlertGrid doesn't require installation, access to the file system etc. it just gathers data you send and allows to build some notification rules. Examples:
you can send some parameter like memory usage and built rule 'if memory_usage > threshold -> send SMS to admin'
you can send data related to your applicatioin. If you have application proceeding orders, you can send number of processed orders in the signal and build notification rules around that
If you have some logic trigerred periodically (cron, windows service) you can send signal each time your logic is executed to check if it is executed on a scheduled basis.
(I am a developer in AlertGrid's team, in case of any question, please feel free to ask.)
What exactly do you want to monitor? If you only care about availability then good old ping might be enough :)