Con più domande
The Microsoft SQL Server Service Broker External Activator (EA) is distributed in the Microsoft SQL Server 2008 Feature Pack. It is an extension of the internal activation feature and lets you move the logic for receiving and processing service broker messages from the database engine service to an application executable that runs outside the database engine service. This can provide a higher level of scale-out performance by moving processing loads from the database server to another computer. The activation application process can also run under a different windows account from the database engine process. This gives administrators additional control over the resources that the activation application can access. Installation packages for x86, x64, and ia64 architectures can be downloaded from here.
Specifically, here are a list of benefits a user can get from using EA:
· Access non-database resources such as files, network connections in their message processing applications
· Offload computation-intensive work out of SQL box and deploy it to a different machine
· Leverage legacy code libraries that are not accessible within T-SQL stored procedures
· Message processing solution that adapts and scales well by specifying the MIN and MAX number of instances of application processes to run
After installed, EA runs as a NT service. It watches the user configured notification queue for QUEUE_ACTIVATION events. As soon as a notification message is seen, it responds by launching an activation application specified in the configuration file to process messages received in the notification-related user queue. The notification queue, the user queue and the event notification associating them must be predefined before EA can run. A configuration file will tell EA which notification queue to watch on and what application to launch when a QUEUE_ACTIVATION event is received. In addition, a user can configure EA in a way that EA can launch enough number of application instances to consume messages from the user queue in a timely manner without a wasteful use of system resources.
In v1 release, EA only supports:
· Listening on a single notification service for queue activation events
· Only integrated security is allowed in notification database connection string. SQL login and password are not supported just yet.
· All user applications are launched under the same user credential as what EA is running under
Please check out more details on how to setup and start using EA by reading the installed user doc bin\<culture_code>\SSBEA.doc in your install folder (for example, the English culture code is EN).
We'll blog more about EA on topics such as configuration and deployment, tracing and trouble-shooting, some corner cases in our next several posts. Stay tuned! :-)Please check out service broker team blog site for more technical articles http://blogs.msdn.com/sql_service_broker/.
Tutte le risposte
The EA service should be running on the machine in which a process is activated. However, SQL Server is not required on the machine running the service. The EA service controls the thresholds based on the configuration information which a user provides for concurrency min and max values.
Adding to Jang's reply, here's what happens between Sql Server instance and External Activator.
External Activator listens for event notifications that are sent by Sql Server when new messages get enqueued in an application queue and are ready to be received. Upon receiving such event notifications, External Activator will try to launch the configured application (it is launched on the same machine that External Activator runs on, but this doesn't have to be the Sql Server machine).
If the application is written properly, it will shortly proceed to receive some message(s) from the application queue. This receive is recognized by Sql Server, and based on the rate of incoming and received messages, Sql Server may send additional event notifications to External Activator if it assesses that your application is not keeping up. External Activator may in turn launch another instance of your application, but will make sure to keep the number of running applications within the range you defined in configuration file (min and max parameters).
so i'm think'n of a situation where app's exist out there on my network'd world...and these app's all employee an atypical polling mechnizm to maintain a cache in their respective address spaces of some data pulled/polled from some sqlsrvr...
would EA be able to be configured to 1.) notify all my app's that the cache their using has changed...or 2.) would i have to write a specific app called by EA that would in turn perform the notification to app's that cache requires a refresh!? Again app's could be on a variety of machines...i'm envisioning somekind of broadcast employeed to notify app's of cache state change.
Is there a EA example or sample application, which I can download,
There are several downloads avaliable on the Microsoft SQL Server 2008 Feature Pack, October 2008
If I download "Microsoft SQL Service Broker External Activator", is that sufficient to test the EA
Please let me know.
Thanks in advance,
- Modificato swordfish8 lunedì 13 luglio 2009 23:41
We don't have a sample application at hand. Check out this page http://blogs.msdn.com/sql_service_broker/archive/2009/05/18/get-started-with-using-external-activator.aspx, it should be fairly easy for you to ramp up. Let me know if you need more help.
Does anyone know what happened to the EA blog? I exected to see a follow up to the may 18, 2009 entry, especiall considering the summary paragraph:
If you have done all the above necessities, now try to start your external activator service, and send a few messages to your user queue, you should probably be able to see the messages are read and processed. But if not, in our next EA blog article, and we'll show how you can trouble-shoot external activator to find out what have gone wrong. Stay tuned! :)
but so far nothing.
Also would be nice to have a complete sample application per Swordfish reply above. Does the relative silence indicate that this is an easy technology to master, because the examples and samples using ssb fall short of providing guidance to me.
A sample application to use with External Activator has just been published on Service Broker blog: http://blogs.msdn.com/sql_service_broker/archive/2010/03/10/Sample-activated-application.aspx .
Well, over two years later, and no such article and, after much searching, I have still not been able to find a complete, end-to-end example that will show Service Broker external activation in action; it has got to be one of the most poorly-documented features within the entire SQL Server stack. Given this, I am extremely reticent to use the technology. I'm sure with enough effort I can construct an example myself (though I shouldn't have to just to see it working) but it is so poorly documented I really question whether the technology will be deprecated or even evolved. It appears that nobody at MS is even working on this.
Well, over two years later, and no such article and, after much searching, I have still not been able to find a complete, end-to-end example that will show Service Broker external activation in action
I created an example that launches an SSIS package using a stored procedure: http://www.dbdelta.com/service-broker-external-activator-example/
Dan Guzman, SQL Server MVP, http://weblogs.sqlteam.com/dang/
Yes. But everything with the external activator service takes a lot of code. In fact I rather hate the External Activator, and so I just published a stand-alone sample of how to process a Service Broker queue with a Windows Service: http://code.msdn.microsoft.com/Service-Broker-Message-e81c4316
The External Activator requires a bunch of setup, for Notification Queues which aren't really useful, and for installing the service, and it _still_ requires you to write all the Service Broker handling code yourself. Yuck.
Anyway you _could_ do this with external activation, but you could also do this with Service Broker routing, and let Service Broker send the message from Service Broker on database B to a queue on Database C, and then use internal activation on Server C.
- Modificato davidbaxterbrowneMicrosoft employee martedì 15 gennaio 2013 16:33