A Service-Oriented Enterprise

The following is an idea I pitched to the head of our IS department. It's an SOA-like architecture, with some implementation details thrown in.
Unfortunately, he wasn't impressed.

A Transaction Queue-Based System
· All requests for processing have a strict definition and structure.
· All requests are sent to a request processing service on a central server and saved to a queue on disk.
· A completely different service on the same or different server deserializes these requests in order of priority or time of request, performs the task, and reports back to the user.
· All duplicate requests are logged, and the initial request is always given priority.

Priority for tasks is determined statically by Quality as well as dynamically based on previous TTC (Time To Completion). TTC priority is used mostly for short tasks like "Submit ATT Reading" or "Mark Piece".

Framework:
Functionality is based around a singular, remotable, serializable object representing a request to perform a task.

Base Request object contains:
· Requestor - Network Name, IP, User, etc.
· Request - Definition, Time of submission, TTC (delta)
· Destination - Automatically determined destination service for horizontal scalability.

Base Interface contains:
· Above Signature
· Manual Success Check (Fail-Safe)
· Security Context – Credentials required to access secure sources. This does NOT consist of passwords and the like, rather a security “context” which describes why the information is requested. Actual credentials are handled by the lower layers.

All layers of the system have access to Business Objects for easy translation of messages and objects.

Services:
Service Broker:
· Liaison between a floor application and SQL Server or other back-end.
· Accepts requests and places them in the Queue.
· Reports back to user when completed.
Request Processing Service:
· Sifts through request queue, processing requests by priority.
· Reports back to user when completed.
Request Reporter:
· Reports back to user when completed.
· This may reside in the Secretary or Processing service. The location of said functionality depends on how the completed requests are stored.

Anytime Request Viewer:
· A Windows Event Viewer-type application that allows viewing of pending requests, and after a logon, manual manipulation of priority and On-Demand execution.

Associated Applications:
Service Manager:
· Validates users and provides simple application management capabilities.
· Manages Enterprise/Machine/User-level settings.
Front-End apps:
· All front-end apps will only have access to the Request Secretary, to maintain security.

Scalability:
Vertical:
· Multiple client access is a native capability.
Horizontal:
· Each Service maintains metrics about its load, and can split up processing tasks among its instances.
· Instances are referred to by name, just as in SQL Server.

Fail-Safe Facilities:
· All Requests have a FS/MCS (Fail-Safe/Manual Success Check) in case the reporting service is not available. This contains the steps necessary to validate that the task was completed successfully.
· Tasks will be defined by the Request Library and will not be editable by developers.
· Tasks that take more than 30 seconds are reported on early, tasks taking more than 2 minutes are reported on periodically.
· Failed requests are logged, and reported to the user. Successive failures are reported to a higher authority.

I have a majority of the code completed, but since my boss refuses to read C# for fear of embarrassment over the fact that he has no clue what a delegate is, until I have something substantial, he's clueless.
As soon as I have a working prototype, I'll post some code.