DataSnap server - redirect HTTP requests to another DataSnap server - delphi

My application consists of a 'gateway' DataSnap REST server that is the first point of access for all clients. Depending on the username the clients pass in their requests (basic authentication), the request needs to be redirected to another DataSnap server. My question - is there anyway of building the 'gateway' server so that it simply redirects whatever the request is to another server based on the username, or other values in the HTTP request headers? I'm trying to avoid having to repeat all the server methods in the 'gateway' service i.e. I'd rather not 'chain' 2 requests together but somehow just have 1 request redirected.
Not sure if this is possible, but thought somebody might prove me wrong? I'm using Delphi XE2 and the DataSnap servers are Windows services.

I can see two options here:
use the first server only to return the address of the real server after logging in
or
use a Apache or NGINX reverse proxy in front of the Datasnap servers and RewriteRules based on the authentication data (however my Google-Fu for today seems to be exhausted, maybe this can be placed as a HTTP / Apache specfifc question here on SO)

Short version: the solution will depend on which level (HTTP, DataSnap, in between) you know where to target the request to.
If you can make the decision on the DataSnap level, there are two kinds of solutions:
The purists way to do this is write a generic DataSnap gateway that can interrogate a datasnap target server, dynamically creates both a proxy server and client for it, then intercepts the traffic and decides which datasnap target server to hand over the request to.
A more pragmatic approach would be the one you are afraid of.
Another approach would be on the HTTP level. That will only work if you can determine at the HTTP level to which target server a request should be handed over to.

Related

Web balancing for ASP.NET Web API

I have created simple ASP.NET Web API(self-host OWIN) which has endpoint http://MyIp:80/process/file. It can accept only five simultaneous requests and takes about 30 seconds to proceed it, if requests number exceeded the Rest Api brings HTTP exception. To increase number of requests I am planning to host the ASP.NET Web API application on another server but in that case I will get different IP address for Rest Api. I know that there are load balancing solutions but can't find good source how to use it with ASP.NET Web API. Any advise would be appreciated!
The easiest way for you would be to use cloud. Especially for Microsoft technologies I would recommend Microsoft Azure. You will get scaling and load balancing out of the box as well as a lot of other benefits of using cloud.
This is a poor man's load balancing... bear with me.
You can declare one server as primary and the second one as secondary.
If a request hits the primary, but it is already with those 5 requests processing, it can issue a HTTP 307 Temporary Redirect to the secondary one. If the secondary is also overloaded, then throw an error.
Using a 307 temporary redirection, the caller knows that can retry the same HTTP verb to the new location. So if the caller was doing a POST call to the primary, and gets a HTTP 307 pointing to the secondary, will reissue the POST request to the secondary.

Design pattern: ASP.NET API for RPC against a back-end application

I'm designing an API to enable remote clients to execute PowerShell scripts against a remote server.
To execute the commands effectively, the application needs to create a unique runspace for the remote client (so it can initialise the runspace with an appropriate host and command set for that client). Every time the client makes a request, the API will need to ensure the request is executed within the correct runspace.
An (over-simplified) view of the flow might look like this:
Client connects to Web API, POSTs credentials for the backend application
Web API passes these credentials through to the backend app, which uses them to create a RunSpace uniquely configured for that client
Web API and app "agree" on a linked session-runspace ID
Web API either informs client of session-runspace ID or holds it in memory
Client makes request: e.g. "GET http://myapiserver/api/backup-status/"
Web API passes request through to backend app function
Backend app returns results: e.g. "JSON {this is the current status of backup for user/client x}"
Web API passes these results through to remote client
Either timeout or logout request ends 'session' and RunSpace is disposed
(In reality, the PowerShell App might just be a custom controller/model within the Web API, or it could be an IIS snap-in or similar - I'm open to design suggestions here...).
My concern is, in order to create a unique RunSpace for each remote client, I need to give that client a unique "session" ID so the API can pass requests through to the app correctly. This feels like I'm breaking the stateless rule.
In truth, the API is still stateless, just the back-end app is not, but it does need to create a session (RunSpace) for each client and then dispose of the RunSpace after a timeout/end-session request.
QUESTIONS
Should I hack into the Authentication mechanism in ASP.NET MVC to spin-up the RunSpace?
Should I admit defeat and just hack up a session variable?
Is there a better SOA that I should consider? (Web API feels very neat and tidy for this though - particularly if I want to have web, mobile and what-have-you clients)
This feels like I'm breaking the stateless rule.
Your application is stateful - no way around it. You have to maintain a process for each client and the process has to run on one box and client always connecting to the same box. So if you have a single server, no problem. If you have multiple, you have to use sticky session so client always comes back to the same server (load balancers could do that for you).
Should I hack into the Authentication mechanism in ASP.NET MVC to
spin-up the RunSpace?
If you need authentication.
Should I admit defeat and just hack up a session variable?
No variable, just use plain in-memory session. In case more than 1 server, use sticky session as explained above.
Is there a better SOA that I should consider? (Web API feels very neat
and tidy for this though - particularly if I want to have web, mobile
and what-have-you clients)
SOA does not come into this. You have a single service.

EHR intercommunication / client

So, I'm researching methods for building a client interface for existing EMRs. I've read tons of info on HL7, as well as the various coding schemes, but I'm still really clueless.
For anyone whose worked with an EMR before: is it possible to build a web interface that can use HTTP-POST and HTTP-GET requests to pull/push data to the server database? Or would you have a separate database for the client, say a web application, then use some interface engine like Mirth to communicate between the EMR database and the web application?
A web service API is definitely a way to go. One benefit to this is that you can get https almost out-of-the box for encryption of data in transit.
The way we have configured our EMR is that we have a tcp server accepting incoming hl7 messages from certain IPs which connects directly to our EMR database. This can be beneficial by separating emr and interface processes (You don't have to restart your whole EMR if the interface goes down, for instance).
Another good feature would be to have a token system for pseudo-authentication. This only works if you are going over a secure connection though.
If you aren't into writing your own tcp server (not that hard), an api-based server is probably just as good.
EDIT: What language(s) do you think you'll be using?
Other things that you might run into:
Some applications prefer file drops to direct calls (either url or tcp)
Some vendors will have their own software that sits on a server of yours
Don't forget the ACK.
I don't see why you couldn't do this. You would need to build the web service to handle requests with a specific Uri. When this Uri is called the web service uses the data sent with the request to make changes in the database.
Once you had the web service built, you could build some sort of front-end that displays your information to the user. And makes HTTP-GET and HTTP-POST calls.
There is a lot of flexibililty in what you are trying to do... so go with a plan for sure.
In general though you should be able to accomplish what you need to do by building your own web service and front-end application that is able to manipulate an EMR database.
It really depends on your architecture and requirements.
Architecture 1
If you want your client to be web based, but your client is a separated app from your backend, then the web sends the info using HTTP to your client app server side, and then, that will send info to your EHR backend (another app). That second communication might be written using a standard, that will help you on integrating more systems with your backend in the future. So that interface can be HL7 based, if HL7 v2.x is used, take a look at the MLLP protocol: http://www.hl7.org/implement/standards/product_brief.cfm?product_id=55
This is the most performant way of communicating HL7 data. If you don't want to deal with TCP, there is a proposal for HL7 v2.x over HTTP. HAPI implemented that: http://hl7api.sourceforge.net/hapi-hl7overhttp/
If you don't want to use HL7 v2.x but HL7 v3 (a different standard, not really a version of 2.x) or CDA, you can use HTTP or SOAP.
Architecture 2
But, if you want your client just to be a UI on the user side (browser), HTTP POST will suffice to send info from the browser to the server. That means your EHR is a centralized EHR with a web iu.
In the 1st architectural case, first case you'll probably have multiple client apps (full EMRs apps) and a backend EHR server (centralized backend). On my developments I follow this second architecture.
Also there Mirth might help to manage all the communications between client apps and backend apps. In the 2nd case, using Mirth is nonsense, is just a web application and the client communicates directly with the web server. Of course, you can use Mirth as a web server, but that's not it's role, it is an ESB no a web server.
Hope that helps!

Delphi SoapServer application

Is it possible to convert Delphi SoapServer application to use TCP/IP?
From your comment to your question it sounds like you are looking to get rid of SOAP, and use something else to communicatie over a TCP/IP connection.
The question one could ask is why do you want to convert to non-SOAP comm over TCP/IP?
But the answer to whether it is possible is: of course this is possible, there are many application servers using TCP/IP for communication without using SOAP as their communication's protocol.
You will need some kind of protocol for communication between server and clients. You could roll your own, but doing what SOAP is doing for you now: receiving and responding to commands from clients (or method invocation) and marshalling data/objects between server and clients is not a trivial task.
So I'd suggest you have a look at other remoting libraries for client/server communication, such as:
Remobjects: http://www.remobjects.com/
kbmMW: http://components4developers.com/
As others have said, SOAP is just XML on http/https, and usually does already use TCP.
That said, you could simply treat it as raw socket data or http data. i.e. you could make a client that just uses http POST to send a string to the server. The string would contain an XML SOAP request, and would be treated by the server as if it were SOAP. Likewise, you could build the server in a non-SOAP fashion, just accepting XML and returning XML, and the client wouldn't know the difference.
You can use Fiddler2 to play with this. You can build requests and send them via HTTP Post. The server has no idea that you're not a SOAP client.
Chris
If you're talking about pre-Delphi
2009 DataSnap, meaning COM based
DataSnap, then you have to use a third
layer utility to do the communication.
That utility named sockets.exe is
included with Delphi, and is in the
same dir as Delphi (Program
Files\\\\bin
If it is Delphi 2009 or better, then
DataSnap has built-in TCP/IP
functionality. You use
TDSTCPServerTransporter component.
Update: Ups! for some reason I did read DataSnap SoapServer (wich neither exists, but I did think of Soap Connection).
A Soap Server Application needs the "server" part, meaning a web server. SOAP is an technologie that runs over HTTP protocol, so I don't think it could be "converted".
DataSnap could do the job, or Indy TIdTCPServer or some of the derived classes.

Delphi 7 SOAP Authentication and SessionID HowTo

I am developing a 3 tier database application.
1.) MS SQL DB
2.) Middle tier SOAP Server (with Delphi 7) connected to the DB
3.) Clients (first win32 gui (with Delphi 7) - later other platfomrs) connected to the SOAP server
I chose a SOAP Server to be open to various clients at a later stage (also some of the win32 gui clients will be stationed abroad - so the clients need to be thin) (this as suggested by Dr. Bob).
I am new to SOAP and have been looking at different examples and papers about authentication. But cant quite get my head around it.
I have made a SOAP server and client with Delphi's SOAP Server Application Wizard and added a SOAP SERVER Data Module, added a database connection and some datasets and providers. Connected the client with dbgrid etc and that part works fine.
But I want the client first to login and then be able to access data and I want the server to log each connection and also when the client logs off or is disconnected, so I am guessing I need the sessionID and a timeout. I also want the server to be able to tell the clients who else is "connected" (or whos session is still active) at any given time.
I have gathered that I need to make a authentication header, but cant figure out where or who I can get a sessionID. I presume that each time a client connectes to the server the server generates a sessionID? How do I get this?
Any help or suggestions/pointer would be appreciated,
thanks
Justin
Soap servers do not provide sessions by default. Your server has to implement Session life cycle managment (Login / Logout) etc.
A basic solution is documented here: Managing sessions with Delphi 6 Web services
Note however that this solution is far from perfect (see comments), for example it does not provide a session timeout mechanism.
OK - figured it out - I had not:
InvRegistry.RegisterHeaderClass(TypeInfo(IThorPayServerDB), TAuthHeader);
in the initialization
But I still cant figure out how to get the session ID - or some unique way of know which client session is loged in to the server - any ideas?
Delphi XE uses a newer version of SOAP, maybe that is the answer:
https://forums.embarcadero.com/thread.jspa?messageID=200793

Resources