Hi,
Please excuse me if I get some terms wrong - I am not a developer!!
I am working for a company who has a requirement to interface to a customer to query for work. The customer has an established Web Services that it uses for external interfacing, these services are passive at their end, in that it will be my clients who initiate all the communications using SOAP, receiving responses in XML.
There are, as I see it, seven conversations.
Receiving Datasets
1. Requests All new Jobs - This will be a post to a HTP with a list of job numbers sent back, These jobs will then need to be polled from the same webservice.
2. Job Changes - existing jobs that have changed definitions (costs etc..)- simular to above
3. Job Changes - Appointment Times
Sending Datasets
1. Completed Jobs - one at a time
2. Cancelled Jobs
3. Appointments (I believe this is responses to 1 and 3 above)
4. Subsequent Jobs - new work derived from initial Job.
I believe the sending datasets will be one way only (ie POST).
I have suggested using Service Broker for this application, with a custom App sitting inbetween ServiceBroker and the Web Service to deal with the HTTP POSTS and GETS, and communicating with the Service Broker, posting to queues and reading from them.
Is this viable?
Many Thaks
Lawrenso
We have found customers using Service Broker services to talk to webservices, a common scenario. If you build your apps as internally activated stored procedures (written using CLR), they will always run under the security context of the database engine service account and hence that principle will need access to the web from the machine on which the database engine is running. The other option is to use external applications (running as whatever user you want on whatever machine you choose) that connect to the database to RECEIVE messages from the queue and post requests to the web service. The second pattern does not have a built-in activation mechansim, but you could look at our External Activator sample (on GotDotNet codegallery and www.sqlservicebroker.com).
Rushi
No comments:
Post a Comment