How an orchestration engine works [closed] - orchestration

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have several questions on this topic. For example, I have found a lot of papers like
"Towards Dynamic Orchestration of Semantic Web Services"
"Decentralized Orchestration of Composite Web Services"
and so on... but in practice, I have only found orchestration linked to Bitztalk or ESB (I mean big software programmers).
Is it possible to develop and orchestration language yourself?
What is the best way to develop an orchestration engine?

Perhaps the best source of information on Purpose and Application of Orchestration are the papers themselves which you quoted.
Background
We surf the web on Firefox, type a document on Microsoft Office. These are centralized applications. These types of software sit and work from one place. They work on your computer, they work on my computer.
You go to a supermarket, pickup an item and check-out from one of the many cash counters. Each clerk at each desk has his own barcode scanner and his own swipe card reader. Each of the cash registers on these counters are linked to one server in a back room somewhere. In this setup, the billing software is distributed across the clerk's counters, but the whole application is still centralized. The server manages the stock and records the sales. It is the center of the centralization.
Then you write an email and send it. Say you send an email from your Gmail account to my Hotmail account. There is Gmail's server, and there is Hotmail's server. There are two centers, instead of just one. Now things are no longer centralized - we have a distributed system. Here, failure of one center does not cripple the whole system. If Hotmail goes down, Gmail still survives.
Rather than purchasing from local supermarket, purchase something from an online store. Say eBay or Amazon. In this example, there is eBay's server, and there are the suppliers to eBay. The suppliers manage their own inventory on their own servers, not on eBay's server. There is also the courier company which brings the package to the buyer. The buyers have their own servers as well. The online payment that the buyer made was through MasterCard, yet another separate server. Now we are talking about a really big distributed system.
Purpose
Now that you are making an online purchase, a hell lot of things are bout to happen, which would need more than a bunch of servers. There has to be a master puppeteer who synchronizes activities among these servers. An account has to be deducted. An email has to sent. A warehouse has to be notified. A courier needs to be arranged. who controls this intricate dance? This is your orchestrator.
Application
Most of the time there are many different and independent servers, each owned by different entities. Yet when all these entities need to work together to create a business flow, a "user interaction session", we need orchestration.
Orchestration of the activities among a set of servers is achieved through a master-puppeteer server. In reality, the orchestrator is itself a set of servers. So one set of servers directs another set of servers. These second set of servers is where actual work is being done. eMails are being sent. Images are being compressed. Addresses are being sorted, and so on. The first set of servers (the orchestrator) makes sure things happen in the order they needs to happen.
Implementation
One answer: queues. The one activity that started this whole story was an attempt to make an online purchase. From there, the clicks you made, the commands you sent, were all queued up in these orchestration servers. The command like purchase-this-item or make-a-payment and then payment-received are all queued and then processed one after another.
The orchestration system accepts these commands on one thread, and on a different thread, the orchestration server asynchronously dispatches them to the respective worker servers. So the purchase-this-item command is dispatched to eBay's server while make-a-payment command is dispatched to MasterCard's server.
The worker servers might produce further commands. The MasterCard server, after validating your card number, might decide to send you an SMS. so it add a send-sms command to the queue. That command is dispatched to, say, a Vodaphone server.
This queuing and dispatching logic is called the "orchestration engine". From there, things can complicate. Vodaphone server might be offline. MasterCard might reject the card. The warehouse server might return an out-of-stock response. Then that response will need to be routed to eBay's server which could re-queue the purchase command to some different warehouse. There are server crashes. Disk failures. Power outages, and so on.
Finally
Orchestration is to make sure that so many diverse components, distributed geographically, in different points of time, some are parallel, some are faulty, some are slow, some are malicious, some are illegal,.. all work together towards getting you the damn headphones that you purchased over internet.

Related

Erlang/Elixir on Docker and Hot Code Swap

One of the features of Erlang (and, by definition, Elixir) is that you can do hot code swap. However, this seems to be at odd with Docker, where you would need to stop your instances and restart new ones with new images holding the new code. This essentially seem to be what everyone does.
This being said, I also know that it is possible to use one hidden node to distribute updates to all other nodes over network. Of course, just like that is sounds like asking for trouble, but...
My question would be the following: has anyone tried and achieved with reasonable success to set up a Docker-based infrastructure for Erlang/Elixir that allowed Hot-code swapping? If so, what are the do's, don'ts and caveats?
The story
Imagine a system to handle mobile phone calls or mobile data access (that's what Erlang was created for). There are gateway servers that maintain the user session for the duration of the call, or the data access session (I will call it the session going forward). Those server have an in-memory representation of the session for as long as the session is active (user is connected).
Now there is another system that calculates how much to charge the user for the call or the data transfered (call it PDF - Policy Decision Function). Both systems are connected in such a way that the gateway server creates a handful of TCP connections to PDF and it drops users sessions if those TCP connections go down. The gateway can handle a few hundred thousand customers at a time. Whenever there is an event that the user needs to be charged for (next data transfer, another minute of the call) the gateway notifies PDF about the fact and PDF subtracts a specific amount of money from the user account. When the user account is empty PDF notifies the gateway to disconnect the call (you've run out of money, you need to top up).
Your question
Finally let's talk about your question in this context. We want to upgrade a PDF node and the node is running on Docker. We create a new Docker instance with the new version of the software, but we can't shut down the old version (there are hundreds of thousands of customers in the middle of their call, we can't disconnect them). But we need to move the customers somehow from the old PDF to the new version. So we tell the gateway node to create any new connections with the updated node instead of the old PDF. Customers can be chatty and also some of them may have a long-running data connections (downloading Windows 10 iso) so the whole operation takes 2-3 days to complete. That's how long it can take to upgrade one version of the software to another in case of a critical bug. And there may be dozens of servers like this one, each one handling hundreds thousands of customers.
But what if we used the Erlang release handler instead? We create the relup file with the new version of the software. We test it properly and deploy to PDF nodes. Each node is upgraded in-place - the internal state of the application is converted, the node is running the new version of the software. But most importantly, the TCP connection with the gateway server has not been dropped. So customers happily continue their calls or are downloading the latest Windows iso while we are upgrading the system. All is done in 10 seconds rather than 2-3 days.
The answer
This is an example of a specific system with specific requirements. Docker and Erlang's Release Handling are orthogonal technologies. You can use either or both, it all boils down to the following:
Requirements
Cost
Will you have enough resources to test both approaches predictably and enough patience to teach your Ops team so that they can deploy the system using either method? What if the testing facility cost millions of pounds (because of the required hardware) and can use only one of those two methods at a time (because the test cycle takes days)?
The pragmatic approach might be to deploy the nodes initially using Docker and then upgrade them with Erlang release handler (if you need to use Docker in the first place). Or, if your system doesn't need to be available during the upgrade (as the example PDF system does), you might just opt for always deploying new versions with Docker and forget about release handling. Or you may as well stick with release handler and forget about Docker if you need quick and reliable updates on-the-fly and Docker would be only used for the initial deployment. I hope that helps.

Social network scheme without server software

(I realize that this question might cost me a reputation score I still want to ask:)
Imagine a social networking software much like a trivial Facebook (Adding friends, sharing statuses and chatting) where the only software component needed is a client app. With no server farms and with no sensitive data stored on servers with no government control and with no server software at all.
Well while this is theoretically almost possible (If there is at least known one user address) still I cant figure out a way how can clients discover each other in the internet (Not in local IP range) if there is not some server where all client addresses are recorded in a least case.
Please drop any ideas how client can discover each other in the internet without server software if you got one or if there is already precedence case.

How to set a permanent link between 2 iPads [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 8 years ago.
Improve this question
I need to build a simple interface between 2 instances of the same app running on 2 different iPads, which can communicate between themselves.
The idea is to create a permanent link between them (by exchanging some kind of Id), that would be possible to keep (possible by storing the Id) even after one or both the iPads reboot, without the need of user intervention.
For the sake of context, that interface could be used, for instance, on a shared grocery list app, or on a 1-to-1 turn base game.
The Apps would not need to be nearby, nor both would need to be active when data is sent (the receiver could be turned off when data is sent, and receive it later)
I imagine that, if this is possible, it would need to be done using gamekit. Can this be done? If so, how?
Thank you
There are so many ways to do this. But in general:
Database: you'll want a server side database to store the common data. The most common options for this are i) host your own database server and create REST API endpoints to access the datastore, ii) use on of the many Platform as a Service (PaaS) companies out there (Parse, Stackmob, Azure, etc). Generally, the PaaS provide a cheaper faster way to get up and running and you'd probably only want your own server if the app was fairly complex. You could always start PaaS and transition to proprietary later if needed.
Synchronization: To communicate between the devices your options are i) client side polling (ie. check for updates to the database every n secs/mins), or ii) push notifications from the server when a record is inserted/updated). For push, you'll want to avoid using APNS (Apple Push Notification Service) as message delivery is not guaranteed (users can decline to receive push notifications) and you'll want to either create your own sockets connection or use a push service like Pusher or PubNub which provide reliable message delivery from server to client. You'll only want to implement APNS for when the app is closed (to notify the user of new activity). When the app is open, use one of the more reliable methods listed above.
That's the general methodology.
EDIT: To be clear, there is no reliable way to do this without using a) a server to store the messages/state, b) a third party service like Pusher or PubNub to reliably deliver the messages between devices, whether the other device is active or not (and really you are then just using their server instead of your own). You could skip using your own server/database and simply send messages back and forth with a reliable service and have them each maintain state locally and synchronize. But note, APNS is not a reliable message delivery service for maintaining synchronization like this.

What is the best distributed Erlang in-memory cache? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
I need some suggestion for the erlang in-memory cache system.
The cache item is key-value based storage.
key is usually an ASCII string; value is erlang's types include number / list / tuple / etc.
The cache item can be set by any of the node.
The cache item can be get by any of the node.
The cache item is shared cross all nodes even on different servers
dirty-read is permitted, I don't want any lock or transaction to reduce the performance.
Totally distributed, no centralized machine or service.
Good performance
Easy install and deployment and configuration and maintenance
First choice seems to me is mnesia, but I have no experence on it.
Does it meet my requirement?
How the performance can I expect?
Another option is memcached --
But I am afraid the performance is lower than mnesia because extra serialization/deserialization are performed as memcached daemon is from another OS process.
Yes. Mnesia meets your requirements. However, like you said, a tool is good when the one using it understands it in depth. We have used mnesia on a distributed authentication system and we have not experienced any problem thus far. When mnesia is used as a cache it is better off than memcached, for one reason "Memcached cannot guarantee that what you write, you can read at any time, due to memory swap out issues and stuff" (follow here). However, this means that your distributed system is going to be built over Erlang. Indeed mnesia in your case beats most NoSQL cache solutions because their systems are Eventually consistent. Mnesia is consistent, as long as network availability can be ensured across the cluster. For a distributed cache system, you dont want a situation where you read different values for the same key from different nodes, hence mnesia's consistency comes in handy here. Something you should think about, is that, it is possible to have a centralised Memory cache for a distributed system. This works like this: You have RABBITMQ server running and accessible by AMQP clients on each Cluster node. Systems interact over the AMQP interface. Because, the cache is centralised, consistency is ensured by the process/system responsible for writing and reading from the cache. The other systems just place a request for a key, onto the AMQP message bus, and the system responsible for cache receives this message and replies it with the value.
We have used the Message bus Architecture using RABBITMQ for a recent system which involved integration with banking systems, an ERP system and Public online service. What we built was responsible for fusing all these together and we are glad that we used RABBITMQ. The details are many but what we did is to come up with a message format, and a system identification mechanism. All systems must have a RABBITMQ client for writing and reading from the message bus. Then you would create a read Queue for each system, so that other system write their requests into that queue, whose name inside RABBITMQ, is the same as the system owning it. Then, later, you must encrypt the messages passing over the bus. In the end, you have systems bound together over large distance/across states, but with an efficient network, you wont believe how fast RABBITMQ binds these systems. Anyhow, RABBITMQ can also be clustered, and i should tell you that it is Mnesia which powers RABBITMQ (that tells you how good mnesia can be).
Another thing is that, you should do some reading and write many programs until you are comfortable with it.

Building Turn-based Multiplayer Game Server [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I started to make multiplayer game but as I have no expirience I tried it different ways but something doesn't feel right to me.
So, I really need an advice about which platforms/tools/languages/techniches I should use best.
I must say that I don't believe in things such as: Photon, AppWrap, Skiller, Gamooga and others. I dont believe they will scale great and it won't be too pricey, or they are too big (I don't mean size, I mean how much things they has that I don't need) for my needs.
First, I'll describe simplified game session proccess.
Three players starting the game session
Each player receives a question and should answer within 10 seconds.
When player answered he should be able to see any answers that were given already by any other players (if any) and he should be able to see any answer given as soon as it was given. Basically, any answers should be received by other clients in realtime but only after we answered (to avoid cheating). If time is out then any who doesn't answered will receive no score and next question goes.
Deciding winner and goes to the next question. Finish the game session after N rounds.
Second, I'll explain few requirements that I taken into consideration.
Game should be run on iOS/Android/Web. This leaves me no choice but to make it based on HTTP.
I looked for Google Cloud Endpoints about which I was really enjoyed. It has iOS/Android/JS SDKs, Google Cloud Platform has Google BigQuery, and many other great things. But because I need realtime answer delivery I don't know if that suitable (there is Channel API but no client SDK for iOS, and people saying its not that good).
Then I looked for Node.js and long polling (AFNetworking on client side) but it is so hard to manage. I need to serve game state updates to clients (and I need to send deltas). That way I need to track all changes individually for each player. And when player connects I should check if there any changes already; if it is then send right away; if it isn't then listen for 'change' event and then send. In the end code looks so awkward and hard to understand and I don't know how to make it right. There is socket.io which should make things better on the server side but again no iOS SDK for client.
I don't know where to go from here. Any help would be very appreciated.
Turn based architectures are actually not too complicated as lag is really not a huge concern, and data is not being sent constantly.
I would create two web services, one for matchmaking and another to handle the actual game.
The matchmaking would simply queue up players, when there were enough for a match, the service would pick a group of players and assign them a sessionID and pass the players to the game service.
For the game service, it is important to differentiate what can be handled on the client and the service.
The game service would store all game information for each sessionID including clients. This would allow a single service to manage hundreds of games at once with ease. When a player answered a question it would send that in a request to the server with the sessionID. The server would iterate over the clients in the session and send the information to them.
The client could handle hiding questions until the user has answered. (You could even encrypt the other question information if you were concerned about hacking).
The server would also track the timer for the session, when the timer expired it would send a response to all the clients, as well as ignore any later answers. A round integer could be stored in the session, and wrapped in communication with sessionID so as to differentiate answers to past questions. You could have a timer for prediction on the client, but the server needs to be the authority over the timer to avoid cheating.
Use secure ssl https protocols using your own auth tokens to keep the cheaters out.
The client would need to keep track of time span for each player not the actual time. The individual times spans are sent to the server after the round ends on each client.
Think of it like this. There are 3 clients, all polling a server as when they start the round. Because the three could have varying network speeds you don't know who will actually start first. So when each client finally receives the green light then the timer starts for that device, on that device at that time it is received on that client device. You wait until all 3 report back to the server with their time spans to determine who won the round.
There as some topics of concern out of the logic of just the game. Here are some examples.
User Identity and Authorizing. (Game Center)
Game Data Persistence and Storage. (Cloud Database like AWS DynamoDB)
Game Match Queuing. (AWS SQS) Don't attempt this with a database using pessimistic concurrency.
Notifications of Match Players are ready for sleeping clients. (AWS SNS to APNS to Endpoint(this mobile device))
Polling or Notification for Next Move. (AWS SQS or SNS) I wouldn't poll the Database.
Those services are just example recommendations. I don't work for Amazon, they are the easiest to get up and running but there maybe better services out there.
Basically what I am getting at you are going to want more than a traditional MySQL database on some basic hosting site. Some of these cloud services have become very affordable as compared to creating all the infrastructure yourself on dedicated servers.
The are exponentially more scalable also.
You could do all that listed above to start out for under $15 a month using cloud services. The best thing is if your idea takes off you simply bump up the thresholds on those with a flick of a switch from an admin portal.
That would be a good problem to have.

Resources