I have 2 microservices Identity & Communication. When user signs up, I want to send him an activation link to his email. Activation link is generated on Identity side, how can I pass it to Communication Microservice to send an email? or Communication microservice shoudn't exist as a separate microservice, but each microservice can use IEmailSender utility to send emails?
Communication Bounded Context is wrong for my system. Its just a technical Help SErvice which every Bounded Context should have in Order to fulfill its business capabilities. For example Identity in order to Activate Account needs this infrastructural posibility. Removed communication BC, and sending emails directly from Identity.
I typically have an endpoint that handles e-mails. I use my Shuttle.Esb open-source service bus to facilitate messaging but any service bus will do or you may opt for coding the messaging directly using something like RabbitMQ.
Integration between endpoints is handled by an orchestration endpoint for the bounded context in question. This orchestration layer would send a SendEMailCommand to the e-mail endpoint and then receive confirmation once the e-mail has been successfully dispatched. In this way there is a single point that handles e-mails.
When you have every bounded context access something like an IEMailGateway it means that you may need to do a bit more legwork in terms of getting the e-mail going since you need access to the relevant mail server and that may mean dealing with firewalls, ports, security
Related
I have a set of RESTful services that my Angular 5 client uses to perform CRUD and business operations for the application. These are a set of micro services and they use pub/sub message queues to communicate between them, e.g. when a user is created the user server publishes a UserCreated event to the message queue and subscribers can listen for this event and act upon it as required.
Now, this is all good but i was thinking that wouldn’t it be better if the Angular 5 application itself published the event to the message queue rather than making HTTP POST/PUT or DELETE and only make GET requests against the API?
So repeating the example above the Angular 5 client would publish a CreateUserEvent to the message bus (in my case cloud pub/sub), I could then have services subscribe to these events and act upon them. My RESTful services would then only expose GET /users and GET /user/:id for example.
I know that this is doable and I guess what I am describing is CQRS, but I am keen to understand if publishing events to a message bus from the UI is good practice?
The concept of Messaging Bus is very different than Microservices. Probably, the answer to your question lies in the way you look at these two, from architectural perspective.
A messaging bus(whether it is backend specific or frontend specific) is designed in such a way, that it serves the purpose of communication of entities within the confined boundary of an environment, i.e. backend or frontend.
Whereas on the other hand, microservices architecture is designed in such a way that, two different environments that may be backend-frontend or backend-backend, can "effectively" communicate.
So there is a clear separation of motivation behind both the concepts. Now, from your viewpoint, you may use a hybrid approach which might work, and it may also lead to interesting findings related to performance, architectural design or overheads as well.
Publishing directly from the client is possible, but the caveat is that it means that the client needs to have the proper credentials to publish. For this reason, it may be preferable to have the service do the publishing in response to requests sent from the clients.
I am using On-Premise Service Bus 1.1 for communication between processes.
I need to perform request-response methods between end points and need to decide if I will use WCF or the bus (Service Bus Relay for WCF is not currently available for on premise).
WCF would be easiest to talk to via a generated client proxy, potential complexity with IIS host (or self host) and versioning of clients calling the service.
For Service Bus create two queues per remote service (i.e.
userService, userServiceResponse) and then use sessions. Flexible versioning with different commands. Management of these queues could become complex.
For my project everything is within the same subnet and if required WCF endpoints could talk directly to one another
To help me decide which technology to use, my questions are:
Where would WCF be used over request-response service bus?
Are there any libraries for Service Bus queues to implement
request-response messaging (or any robust code examples)?
If we have multiple publishers on a queue, how would we return a reply to a specific sender? Would we have multiple serviceReponse queues, or can a single return queue be used?
Service Bus messages can have a SessionID unique for that request where the service will receive the message, do something with it and reply with a message that has the same ID in the ReplyToSessionID. This allows the requesting party to receive based on the Session ID like this
MessageSession sessionReceiver = _queueClient.AcceptMessageSession(_mySessionID,TimeSpan.FromSeconds(5));
sessionReceiver.Peek();
I think the big question here is Sync vs Async whether you want the requesting party to sit back and wait for a response (WCF) or back later and check if the response is ready yet Service Bus but that is a business decision.
This link or this MSDN article might help you get started with Req/Rep for SB.
I don't think that deciding which technology should be used is a business decision. At first, it's a technical one.
I would not go with a product which is very operating system dependent, and worst, it's so premature. We can be creating coupling (OS x Bus) and stepping over a mined field.
But, this is only a personal opinion and might be biased as I'm not a Azure SB specialist.
I agree with #Tom, your decision is more related to sync/async model.
Some questions I usually answer before deciding on this subject:
Can we preview the rate of requests/minute and the amount of clients?
What is the nature of the service? Heavy processing logic or simple queries against a database?
I can list some others if you wish, but those two can easily help on the decision, forcing you to think broadly.
I have asp.net site where I call my WCF service using jQuery.
Sometimes the WCF service must have an ability to ask user with confirmation smth and depend on user choice either continue or cancel working
does callback help me here?
or any other idea appreciated!
Callback contracts won't work in this scenario, since they're mostly for duplex communication, and there's no duplex on WebHttpBinding (there's a solution for a polling duplex scenario in Silverlight, and I've seen one implementation in javascript which uses it, but that's likely way too complex for your scenario).
What you can do is to split the operation in two. The first one would "start" the operation and return an identifier and some additional information to tell the client whether the operation will be just completed, or whether additional information is needed. In the former case, the client can then call the second operation, passing the identifier to get the result. In the second one, the client would again make the call, but passing the additional information required for the operation to complete (or to be cancelled).
Your architecture is wrong. Why:
Service cannot callback client's browser. Real callback over HTTP works like reverse communication - client is hosting service called by the client. Client in your case is browser - how do you want to host service in the browser? How do you want to open port for incoming communication from the browser? Solutions using "callback like" functionality are based on pooling the service. You can use JavaScript timer and implement your own pooling mechanism.
Client browser cannot initiate distributed transaction so you cannot start transaction on the client. You cannot also use server side transaction over multiple operations because it requires per-session instancing which in turn requires sessinoful channel.
WCF JSON/REST services don't support HTTP callback (duplex communication).
WCF JSON/REST services don't build pooling solution for you - you must do it yourselves
WCF JSON/REST services don't support distributed transactions
WCF JSON/REST services don't support sessionful channels / server side sessions
That was technical aspect of your solution.
Your solution looks more like scenario for the Workflow service where you start the workflow and it runs till some point where it waits for the user input. Until the input is provided the workflow can be persisted to the database so generally user can provide the input several days later. When the input is provided the service can continue. Starting the service and providing each needed input is modelled as separate operation called from the client. This is not usual scenario for something called from JavaScript but it should be possible because you can write custom WebHttpContextBinding to support workflows. It will still not achieve the situation where user will be automatically asked for something - that is your responsibility to find when the popup should appear and handle it.
If you leave standard WCF world you can check solutions like COMET which provides AJAX push/callback.
The scenario is a follow:
I have multiple clients in which they can register themselves on a workflow server, using WCF requests, to receive some kind of notifications. The information of the notifications will be received from an external system using another receive activity. The workflow then should get the notification information and callback all registered clients using send activity and callback correlations (the clients are exposing callback interfaces implemented in there and the end-point addresses passed initially with the registration requests). "Log-running workflow service" approach is used with a persistent storage.
Now, I'm looking for some way to correlate the incoming information of the notifications received from the external system with the persisted workflow instances created previously when the registration requests, so that all clients will be notified using end-points that already passed with the registration requests. Is WF 4.0 capable of resuming and executing multiple workflow instances when the information of the notification received without storing end-points somehow manually and go though them? If yes, how can I do that?
Also, if my approach of doing so is not correct, then please advice me about the best practice of doing such system using WCF services.
Your help is highly appreciated.
When you use request correlation with workflow services the correlation key must always match a single workflow instance, you can't have multiple workflow instances react to a single message. So you either need to multicast the message using all the different correlation keys or resume you workflow instances in some other way. That other way could be to store the request somewhere, like a SQL table, and have the workflows periodically check that location if they need to notify the client.
I'm whiling to add a support of Server Side events to CppCMS. I understand the technical part of what to do on the
level of communication: Client sends long polling XmlHTTPRequest, and waits for respond,
server accepts the connection and does not respond until server side event occurs and sends
the response to the client. The client repeats the procedure.
However, this is too "low" level for most of web developers. There are many questions: how do I manage events, how do I manage connections and so on.
I thought about two possible models:
There are some named events defined and the server side,
for example "New Message in Chat Room no 134";
when the request accepted the server side application checks the messages
in the room (for example in DB) and if there is no new messages for the client
it subscribes to event and waits on it.
When some other client posts data to the server, it notifies all applications on
the "New Message in Chat Room no 134" event and they wake up and send these messages
to clients, and so on.
This model is still looks like quite "low level" model, but it hides all
notification methods.
Another option is to define some named queues, so each client creates such
queue upon connection to server and waits for new messages. When some client
posts a new message to "Chat Room no 134", on the server side it is broadcasted
to all queues connected to this "Chat Room no 134", and the message is delivered
to client.
However there are many questions that are risen:
How do I manage queues and the session level, at the level of single page?
How do I delete queues and create timeouts on them?
What happens if more then one "window" subscribes to same queue?
Create a persistent object on server side that glues between server side events
and user side events. It may communicate over distinct XHR requests that are
redirected to it.
So client (JavaScript) registers events and waits for them with XHR
and server side dispatched event notifications, until the page is rebuild.
So, I would like to know, what are most popular and recommended
API models behind server side push technologies?
Thanks
Edit: Added third option
You should check out XMPP PubSub, which defines a generic publish/subscribe protocol over XMPP. There's also an XMPP extension called BOSH (lower-level protocol details are documented separately in XEP-0124) that defines a mechanism that allows HTTP clients to bind to XMPP servers using long-polling (i.e., comet). Combining these two specifications gives you a robust event subscription model for web-apps using comet. Even if you don't end up using XMPP/BOSH, the specs contain some valuable insight into how this sort of system can be built.
If you do end up using XMPP and BOSH here are some tools you may find useful:
StropheJS: A library for writing client-side XMPP clients that speak BOSH.
Idavoll: A generic publish-subscribe service component for XMPP servers.
Punjab: A BOSH connection manager that acts as a sort of "translating proxy" between BOSH HTTP clients and your XMPP server.
Admittedly this is a very heavy-weight solution, and it may not be appropriate for your particular application, but a lot of thought was put into these standards so they may be helpful.
Try Bayeux, it's very much like your first model. The client subscribe to channel "chatroom/new-message/134". If there are new message, the server will broadcast to the subscribers.
You can use wildcard channel name to subscribe to multiple rooms "chatroom/new-message/*" (trailing only)
There's no general solution that fits all applications. If you want to learn about some general patterns, have a look at Event-Driven Architectures.
There are some slides online from a presentation I attended once (it's a quite high-level view of the topic).