I have read Why not publish NServiceBus messages from a web application and another similar question about this but I am not clear if this applies to service layer as well. For example, if the service layer is composed of web services or REST services built using WCF or Web API or any other way, should those services publish events or send commands? If those services are hosted in load balanced web servers, the problems outlined in the articles apply to this layer as well. How would the recommendation change or not change?
If I look from the definition of Event vs Command, the messages I am talking about are Events e.g. "a user was created" and so an event should be published. As a matter of fact, the service that created the user doesn't even know what else to do i.e. may be another application is supposed to create a customized portal for it and yet another application is supposed to send a welcome kit to the user. This would be an event and not a command. I guess I am hung up on the definition of a web application and application service when application service itself is composed of one or many web applications.
The definition of Web Application
A web application is an application that is accessed by users over a
network such as the Internet or an intranet.
However, to me, the users can be computers and thus web services are web applications and that is the reason for this question.
EDIT:
Let's consider a concrete example. An ASP.NET website (MVC or Web form - doesn't matter) displays the form to the operator, gets a post with data about user creation (Name, UserName, Password) and invokes a WCF service to create the user. In between website and WCF service we can put ServiceBus and send command to create the user (Request/Response) so that we get all the benefits described in the first article. WCF service is the actual business processing layer i.e. it would create the user. That is where I have the question. After the user is created, it should announce that a user has been created and other systems can react to it and do whatever they are supposed to do. So it fits perfectly the pattern of publish the message. However, the WCF service itself is a web application and thus has most of the traits of the web applications and thus the confusion.
As mentioned in the answer to the SO question you linked to, publishing event has more to do with where the actual processing takes places. Just as a side-note: it is not a matter of Send instead of Publish since that would imply that the two are interchangeable whereas they have rather different intentions. When you want to publish, you want to publish.
The same questions should arise if you find yourself publishing from your web-exposed integration layer: should you be performing the business processing in that code or rather sending it off to another endpoint for processing? Typically you should just send it off to another endpoint. You may even consider how you would perform the relevant action should anyone wish to invoke it. For instance, if you are publishing a UserCreatedEvent message it implies that you created a user. How would a user be created? Would I be forced to use the WCF / Web-Api layer or can I send a CreateUserCommand message on the bus that is processed by some application endpoint? If it is the former then you may need to rethink your design. However, if the latter you should be sending the command from your WCF / Web-Api anyway and the processing endpoint will perform the Publish bit :)
update:
My take on it is that it is more about cohesion / concerns. You would typically interact with your domain, from within your business, via a service bus for commands and events, and a simple query layer for reads. If you need to expose anything to a third-party (or simply via the web) then you use WCF / WS / Web-APi. The point is that you should try to avoid business processing in an integration endpoint (or in a front-end like a website). Business processing is better suited to application servers. There are usually exceptions to the rule but if you are in a position to influence the structure then you are in a better space.
The fact is, whatever code is truly responsible for performing the action should be the same which publishes the event. If you've got a MVC app and in the controller itself you're using Entity Framework to insert the User record, then that is exactly where the Publish should be, right after the SaveChanges call. If however, the controller calls a referenced binary or service which does the actions involved in the "add user" call, then the Publish should be there. My thought is the event should be right alongside the code that does the action whose event you are trying to publish.
Related
I am trying to use rabbitmq and express to build a web application. I am very confused about the producer and receiver.
The tutorial said
Producing means nothing more than sending. A program that sends messages is a producer, Consuming has a similar meaning to receiving. A consumer is a program that mostly waits to receive message.
Is that mean the server should be both producer and receiver? Because the server needs to get the client's request and send a response to the client. If that's the case, why we need to run the 2 scripts (producer.js and receiver.js) separately?
Thank you
Your question appears to be mixing two different conceptual models.
"the server needs to get the client's request and send a response to the client" - That, in a nutshell, is the "client-server" paradigm/architecture, as typically used by web applications, where the client is the browser ("show me this web page, please") and the web app is the server ("OK, here is that page you requested").
Rabbit supports a very different paradigm/architecture (messaging), where (typically) the producer generates messages as they naturally occur (not based on any request). Those messages sit in one or more queues, waiting to be consumed by whoever has subscribed to those queues (the consumers). The consumer does not typically send requests to the server; instead it periodically checks to see if there are any new messages on the queue - and then consumes them.
Which paradigm you use depends on the purpose of your web application. Your app may even use both paradigms.
Update
"Could you please give an example that uses messaging paradigm? I couldn't imagine how a website works without request and response."
When you say "a web site" then I will assume you mean web pages displayed in a browser, provided by a web application running on a server. In that specific case, then, yes, the standard approach is the "client-server" model. There is typically no messaging involved. Messaging is not a good fit for that type of model. Client-server is a great model.
But imagine that "web application" which is sending those web pages to the browser. It is quite possible that the web application may also provide additional services, not accessed directly via web page requests. One such service may be messaging-based: The application produces messages - for example, notifications of events relevant to the application. And users can consume those messages.
A very crude example: Imagine an auction web site. You can log on to the site and see web pages where you can place bids to buy items.
But you may also want to receive messages (e.g. via texts) telling you when there have been new bids from other people, placed on specific items that you are interested in. You don't want to have to constantly refresh a web page to get the latest data; and you don't want to receive updates about every bid on every product. This is a better fit for a different type of client - not one which requests web pages, but one which consumes messages.
So, I also can't imagine a web site which uses messaging to provide web pages (although I bet someone somewhere has built that). But I can imagine a web-based application which serves web pages (client-server) and which maybe also produces messages. Or a web-based application which produces messages, and may not even have any web pages at all.
Your producer.js is a tiny example of a program which is only a message producer. Your consumer.js program is a tiny example of a program which is only a message consumer. And sitting in between them is the message broker program (Rabbit) which is where the queues exist, and where messages are sent (and retrieved).
I have a sample web API hosted in an OWIN process (self hosted, not in IIS). I get a JWT token in my controller and I want to be able to retreive it in another part of the application, a class that implements NserviceBus IMutateOutgoingTransportMessages. In my other web application POC (hosted in IIS), I used a simple session variable and it works just fine. But I'd like to know what would be the best way to do it in my new OWIN self hosted environment ? Static property in static class ?
This question is really broad and difficult to answer without detailed knowledge of your specific needs. Here's my interpretation of your issue:
You're already signing each request, perhaps storing the token in the browser sessionStorage (or even localStorage), but this does not suffice
You need to retrieve the token outside of or not in relation to any request cycle (if not, this is probably where you should be looking for answers)
Your application does not need to be stateless
Just one static property for one token in a static class would of course start breaking as soon as more than one request hits the application at the same time. Implementing a class that maintains a list of tokens may be a solution, although I can't tell what key you should use to identify each token. Interface details would vary depending on things like if you need to retrieve the token more than once.
Thread safety issues would apply to all handling and implementation of such a class. Using Immutable Collections and functional programming practices as an inspiration may help.
If lingering tokens poses a problem (and they probably would from a security perspective, if nothing else), you need to figure out how to make sure that tokens do not outstay their welcome, even if the cycle is for some reason not completed.
Seeing how you used Session as a solution in your POC, I'm assuming you want some similar behavior, and that one user should not be allowed to carry two tokens at the same time. You could store the tokens i a database, or even in the local file system, making maintenance and validity a separate issue all together.
There are implementations of cache-like functionality already available for OWIN self-hosted applications, and maybe one of those would serve as a shortcut to implementing everything yourself.
If this token business in fact is the only reason for introducing state in your application, then the best solution IMHO would be to rethink your architecture so that the application can remain stateless.
I'm facing a similar dilemma on a server i'm currently developing for a customer. My problem is that the server must make calls (and retain a live connection) with a legacy, multithreaded DLL, (aka the SDK).
I struggled to get this working on IIS with a regular Web API project. Failed badly since IIS recycles threads when it determines that a thread is going rogue... witch is what the SDK thread looks like in that perspective. Also, the SDK must be able to callback on the caller (client - single page app) and for this I'm using SignalR.
I then tried a multi-part system (single page + web api on IIS + WCF service for the SDK integration). But it is a real nightmare to manage because of the 2 way async communication that must occur between all apps. Again: failure.
So I reverted to a single self hosted OWIN + WebAPI service in a console app (for now). My problem is that some of the calls are lengthy and are processed in a worker thread. I managed to pass the SignalR client id in each ajax calls via headers. I can extract the id when in web api controller. But when the task goes async, I need to get the id (via an Unity injected service) from the class that manages the async task. This is where my problem is similar to yours. In IIS hosted apps, we have HttpContext. It is contextualized on each client calls, and follows any thread changes in the pipeline... But not in self hosted OWIN WCF apps...
I'm looking into Thread Local Storage, CallContext... and other means of keeping track of the original caller info during the lifecycle of the async call. I have read about OWIN pipeline, I can capture the info in a OWIN middleware... but how to safely keep that info for use in injected services? I'm still searching for an answer...
I was wondering if you have found a solution to this rather interesting problem ?
I prefer adding to your thread rather than start another parallel thread / SO question.
We have an asp.net mvc3 application which publishes a number of events. Recently, someone pointed out that we should be sending messages rather than publishing events from the web application and referenced this excellent blog post which makes perfect sense. However, I want to confirm that the points made in the post are still valid for NServiceBus v3.x?
Thanks!
I would imagine that the reasoning behind the post would always hold true, irrespective of the version of NServiceBus.
That being said, there is nothing stopping you from publishing a message from a web-site. The idea behind publishing a message is that the message represents an event that is typically produced by some processing endpoint. Since a web application should not really be processing anything but rather be sending commands off to a processing endpoint it would stand to reason that a web application should not be publishing events.
So if you find yourself in a situation where it seems to make sense to publish from your web application it indicates that you need to make a design decision: either the design is not optimal (so the web application is performing processing) or you are constrained in some way the prohibits the implementation of a processing endpoint (maybe a shared hosting environment).
We currently have a WCF Service which is beginning to reach it's limits performance wise.
We have decided to add another server which will host another instance of the WCF Service.
We have web applications which must communicate with a specific server based on context... e.g. If the web application is dealing with objects from ServiceInstance1 then requests must be directed to ServiceInstance1's EndPoint. If the web application is dealing with objects from ServiceInstance2 then requests must be directed to ServiceInstance2's EndPoint.
I initially thought that a "Intermediate Service" or "Service Manager" could be created, the web application's Service Reference would be updated from the individual Service Instance to the "Intermediate Service" or "Service Manager" and said service would act as a "Broker" to the various Service Instances.
How is this accomplished?
I have currently added a ServiceReference to each service from the Manager however it seems that once a Service is "Referenced" it's types becomes specific to the that of the ServiceReference e.g.
ServiceInstance1's type's are all {ServiceInstance1}.
ServiceInstance2's type's are all {ServiceInstance2}.
I need the types to be the same on the web application end, so this obviously seems like the wrong way to do it.
I would also like that when methods are called on the client generated from referencing the "Intermediate Service" or "Service Manager" that the correct Service Instance is invoked, e.g.
IServiceManager.GetProjectById( {GUID} ) ->
Comes Back to ServiceManager ->
Determines which host has the project and returns the ProjectObject from the correct ServiceInstance.
Where ProjectObject is a Type Defined in ServiceInstance1 and ServiceInstance2.
I think the original service needs to have some of the DLL's pulled out so they can be referenced from the web application side and ServiceManager and a GenericWCF Client can be made.
If I am right hooray for me If someone can point me in the right direction I would appreciate it. If I am wrong can someone please scold me and show me how this is properly done!
The way to solve your problem is to create shared assembly with types used by both services. Reference this assembly on the client consuming your services (manager) and when creating proxies by Add service reference mark Reuse types from referenced assemblies.
What you are building is very simple message router. In WCF 4.0 there is additional support for routing services so you should check those features before developing your own. For WCF 3.5 MSDN magazine contains articles about building message router - part 1, part 2.
Just to Answer this and close it I wound up utilizing the Routing Strategy in .Net 4.0 and custom client class which I modeled after the generated classes from the Proxy.
Before I had the custom client ready I used the auto generated client code and I derived a class from it which allow me to change which service it was connecting to. I determined which service via a property which was made available on all service objects which were serialized.
Long story short this is working 100% as expected including the ServiceManager which can even be bypassed on certain calls which we allow.
We even have the ability to move a project from server to server during run time!
Thanks to everyone who helped! (Especially myself for actually doing the work without being spoon fed)
The easiest way to accomplish what you're trying to do is to stop generating your proxies using the server-hosted URL of the service. Instead, generate your proxies from the *.xsd and *.wsdl locally, and merely change the URL of the endpoint. Alternatively, you can use ChannelFactory<T> to generate proxies on-the-fly, and reference your interface .dll on the client side.
Once you've done that, you can use any common webserver load balancing technique to balance the load between the servers.
Not to put too fine a point on it, but Visual Studio's "Service Reference" is not useful, and should not be used, for services you develop. It's useful only for services developed externally, whose URL and contracts are likely to NEVER change. I personally have never had occasion to use it. For your own services, you should probably be using ChannelFactory<T> or a class based on ClientBase<T> to work out the proxies.
The application that I'm designing will retrieve and store content from a variety of disparate sources on a schedule. In some cases, the content will be retrieved based on a time interval (think stock quotes), and in other cases the content will be retrieved based on a custom schedule (MWF # 2pm). Many of the processes lend themselves to MS Workflow. The built-in SQL tracking service will provide a lot of value. The content sources are sufficiently different that each different type of content retrieval will be a custom workflow.
My question is, how should I host, monitor,schedule, and expose the Workflows?
Requirements:
Must be able to monitor the health of each content "agent" via admin UI
Must be able to start and stop individual workflows via admin UI
Workflows are recurring based on a schedule, but not necessarily "long-running"
"Service" must have high availability
Windows service, Workflow Service, ASP.Net, WCF are all available to me, and I'm open to other suggestions as well.
WF and WCF can be hosted as one WindowsService,
You can create a set of services to expose the state/information from the Workflow in WindowsService via WCF web service.
Therefore the WCF service should have a reference to your workflow exchange contract
( somehow can reference to workflow engine to deliver the request info from client UI).
Must be able to monitor the health
of each content "agent" via admin UI
The Admin UI can retrieve the data from the webservice which
Must be able to start and stop
individual workflows via admin UI
Let the workflow instance to handle a specific event to start or stop
Workflows are recurring based on a
schedule, but not necessarily
"long-running"
Let the workflow instance to handle a specific event to do so
"Service" must have high
availability
WindowsService is daemon alike application, it runs forever if it doesn't crash
I found this post helpful as well:
http://www.dotnetconsult.co.uk/weblog2/PermaLink,guid,77c334e8-0ec1-4f91-ab7e-0bcfa7f2f47d.aspx
You may want to look into Dublin, Microsoft's upcoming integrated host for workflow services. It's not out yet, but offers some of the features you're looking for.