Patent Application
20080301685
Generally, the present invention relates to computing system environments and products involved with time-based events, such as workflow systems and enterprise applications in need of job-scheduling. Particularly, it relates to methods and systems for scheduling time-based services, according to client identity. In this regard, a scheduling solution, decoupled from underlying applications in need of scheduling services, is usable across an enterprise (or beyond), by client applications written in any language, on various computing machines in diverse environments, with flexibility as to communication protocols. Various features relate to account creation, job registration, payload delivery, computing arrangements and computer program products. Monitoring jobs, establishing communication channels, noticing, encryption, authentication, and mash-up applications are other noteworthy features, to name a few.
In workflow systems, enterprise applications, or anywhere a time-based reminder is needed (e.g., calendaring functions), there have been long felt needs for job-scheduling. While many implementations exist for setting timer functions, scheduling jobs, etc., many are hard-wired or coupled directly with underlying applications, which unduly entangles the scheduling with the application in need of the scheduling. Adverse programming side effects are the result upon evolution of the application, including, but not limited to, needing to constantly revisit and rework the code for job scheduling as the application evolves.
Also, code for job scheduling that is entangled with an application is unable to find utility in other applications. That is, the code is often so embedded in the application that others cannot find it readily or exploit it. This makes code reuse impractical thereby complicating scheduling functionality. Code entanglement is also an issue in that system administrators, users, etc., are unable to monitor progression of scheduling events for various purposes. Similarly, code entanglement inhibits use with other evolving technologies, such as service buses, public-facing APIs, bulletin boards, or the like.
While there exist certain general-purpose job-scheduler libraries and APIs (including open-source ones like Quartz, available at http://www.opensymphony.com/quartz, for instance) that can be made available on a Java classpath or run inside a container on an application server, etc., so that more than one application can use the same scheduler code, they fail in purpose because the machine that hosts the scheduler code may not be the machine that runs the various enterprise applications that need access to the scheduler. Even if a scheduler can be accessed remotely via RMI, CORBA, etc., the client must rely on the remote host being operational, with sufficient connections available, etc. High availability becomes a nontrivial consideration. Also, remote debugging and error notification are concerns.
Moreover, enterprises rely increasingly on compliance-aware (or “governanced”) provisioning systems for managing user privileges and entitlements. These systems often have policy-driven recurrence requirements. For example, a user may be required to change his or her password every 30 days, or she or he may be required to renew a group membership every 90 days, etc.
Accordingly, a need exists in the art of time-based scheduling for a service uncoupled from underlying applications to avoid unnecessary entanglement. In turn, the service should be usable across an enterprise, by client applications written in any language, on various machines in diverse environments, with flexibility as to communications protocols. Such should also embrace governance scenarios, while simultaneously enabling code reuse, integration with multiple applications and evolving technologies, and monitoring and noticing capabilities. Naturally, any improvements along such lines should further contemplate good engineering practices, such as relative inexpensiveness, stability, ease of implementation, low complexity, security, unobtrusiveness, etc.
The above-mentioned and other problems become solved by applying the principles and teachings associated with the hereinafter-described identity-aware scheduling service. Techniques and computing arrangements include, in a basic sense, an enterprise-grade scheduling solution usable across an enterprise, or beyond, by client applications written in any language, on various computing machines in diverse environments, with flexibility as to communication protocols. During use, clients create accounts with the scheduling service and register scheduling jobs in order to accomplish time-based tasks, without unnecessarily entangling the tasks with underlying or other applications having need of the task. Upon reaching the appropriate time, the scheduling service delivers necessary payloads to recipients at locations indicated with the registered job. In this manner, separation of functionality exists between applications and scheduling so that multiple applications, in high availability, can use the same scheduler code. Intuitively, this adds robustness and economic and computing costs are downplayed while physical and hacking security is enhanced.
In one embodiment, methods and computing systems include a client and scheduling service arranged together for scheduling time-based services. Representatively, the client and scheduling service engage in an http session whereby the client creates an account (if the first usage) indicating various identities and rights of the client for use with a scheduling job. Thereafter, scheduling jobs are registered with the scheduling service including an indication of what payloads are needed, where payloads are needed and when they are needed. Upon the arrival of the appropriate time, the payloads are delivered to the proper locations. In this manner, scheduling of events is bifurcated from the underlying applications in need of scheduled events. Monitoring of registered jobs is another function as is establishing the appropriate communication channels between the client and the scheduling service and third parties, if any. Noticing, encryption, and authentication are other aspects as are launching third party services before payload delivery. Still other embodiments contemplate publishing necessary information about the scheduling service, such as the API, so it can be used in mash-up applications.
Regardless of form, the foregoing contemplates a system for exposing a scheduling service as part of a Services Oriented Architecture (SOA). Features include, but are not limited to: 1) a runtime implementation (opaque to clients except for a public API) that runs on one or more host machines; 2) a manner of expressing, in a standardized document (e.g., WSDL), all of the runtime's available modes of communication, its functional capabilities, its quality-of-service capabilities, and its actual API; 3) a discovery mechanism (e.g., WSIL or UDDI) to make the aforementioned document (and therefore the service's capabilities, API, etc.) discoverable by remote clients; 4) a mechanism to allow publishing events about the scheduled tasks to a message queue (which MAY be a JMS or MOM queue/topic, or MAY also be an RSS/Atom server) such that an administrator or other appropriately qualified user can monitor a “feed” (using standard RSS feed aggregation tools) as a way of tracking events; 5) a capability for clients to call the scheduler service with arbitrary application data expressed as XML, where it will be cached for later use: for example, a workflow can send state data to the service, and the service will store that data in a data store until the next scheduled job event, then send the data back to the client; 6) a way to allow application data confidentiality, data exchange integrity and client/server control access and authorization through the utilization of WS-Security and XML encryption; 7) a registration mechanism to enforce authorizations for clients to submit scheduler jobs to the scheduler service, query the state of stored data and jobs and provide some level of job administration; 8) a multiple tier authorization and registration mechanism—the first level of which would allow some identifier that was created at registration time to be used as an authentication credential to allow any party presenting the credential to gain access to the job-monitoring feeds or other events; 9) a method for a scheduling client to handle the authentication and creation of tokens, where the token would be the embodiment of established assertions about the authorizations that the scheduling client has defined for the authenticated user; 10) making job scheduling amenable to governance; 11) enabling a process-agnostic scheduler to parse user data (via, for example, XPath) at user-specified times in the future, and thereby be able to send meaningful messages to various addresses at various times via various protocols; and 12) using existing web standards to make a scheduling system web-friendly, and thus usable in mash-up or other applications.
Still other embodiments contemplate computer program products with executable instructions, available as a download or on a computer-readable media, for implementing some or all of the foregoing on one or more computing devices.
These and other embodiments, aspects, advantages, and features of the present invention will be set forth in the description which follows, and in part will become apparent to those of ordinary skill in the art by reference to the following description of the invention and referenced drawings or by practice of the invention. The aspects, advantages, and features of the invention are realized and attained by means of the instrumentalities, procedures, and combinations particularly pointed out in the appended claims.
The accompanying drawings incorporated in and forming a part of the specification, illustrate several aspects of the present invention, and together with the description serve to explain the principles of the invention. In the drawings:
In the following detailed description of the illustrated embodiments, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration, specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention and like numerals represent like details in the various figures. Also, it is to be understood that other embodiments may be utilized and that process, mechanical, electrical, arrangement, software and/or other changes may be made without departing from the scope of the present invention. In accordance with the present invention, methods and apparatus for an identity-aware scheduling service are hereinafter described.
With reference to
In either, storage devices are contemplated and may be remote or local. While the line is not well defined, local storage generally has a relatively quick access time and is used to store frequently accessed data, while remote storage has a much longer access time and is used to store data that is accessed less frequently. The capacity of remote storage is also typically an order of magnitude larger than the capacity of local storage. Regardless, storage is representatively provided for aspects of the invention contemplative of computer executable instructions, e.g., code or software, as part of computer program products on readable media, e.g., disk 14 for insertion in a drive of computer 17. Computer executable instructions may also be available as a download or reside in hardware, firmware or combinations in any or all of the depicted devices 15 or 15′.
When described in the context of computer program products, it is denoted that items thereof, such as modules, routines, programs, objects, components, data structures, etc., perform particular tasks or implement particular abstract data types within various structures of the computing system which cause a certain function or group of functions. In form, the computer product can be any available media, such as RAM, ROM, EEPROM, CD-ROM, DVD, or other optical disk storage devices, magnetic disk storage devices, floppy disks, or any other medium which can be used to store the items thereof and which can be assessed in the environment.
In network, the computing devices communicate with one another via wired, wireless or combined connections 12 that are either direct 12a or indirect 12b. If direct, they typify connections within physical or network proximity (e.g., intranet). If indirect, they typify connections such as those found with the internet, satellites, radio transmissions, or the like, and are given nebulously as element 13. In this regard, other contemplated items include servers, routers, peer devices, modems, T1 lines, satellites, microwave relays or the like. The connections may also be local area networks (LAN) and/or wide area networks (WAN) that are presented by way of example and not limitation. The topology is also any of a variety, such as ring, star, bridged, cascaded, meshed, or other known or hereinafter invented arrangement.
With the foregoing representative computing environment as a backdrop,
At step 44, a time-based scheduling job is registered with the scheduling service. As before, this contemplates the avoidance of entanglement between the registered job and whatever underlying application or other service may need the tasks associated with the job. As a working example, later described in detail, a registered job might consist of a user notification of imminent password expiration at 60, 75, and 89 days, in time to renew registration before password expiration on the 90th day relative to a workflow designed to give the user access to an Oracle database, but having a predetermined policy requiring the user renew his account every 90 days. In this regard, the registered job of password notification is decoupled from the underlying user access to the database and its contents. In turn, the scheduling service will provide the appropriate notices to the user on the specified days, and it too will avoid unnecessary entanglement with the underlying user access to the database and its contents. In other words, the service to give notice to the user is bifurcated from the actual application giving user access to the database. In turn, the avoidance of entanglement yields separation of tasks enabling the afore-mentioned advantages of enterprise-wide access, or beyond, for applications of clients 5 (
In order for the scheduling service to know where user notices are to be sent (e.g., a URI or URL endpoint, such as an http address, perhaps, and such may be different or the same as the location of the client), what type of information is required to notify the user (e.g., a payload, such as a statement of password expiration in 30, 15 or 1 days from now relative to the Oracle database account), and when such notices are needed (e.g., at the 60th, 75th and 89th days), the registration of the scheduling job further contemplates the providing of this information from the user to the scheduling service as part of the job registration. For this, various web pages of questions, for example, are provided to the client on the monitors of their respective computing devices. Then, once provided, the scheduling job is completely registered with the scheduling service. To the extent more than one scheduling job is required, clients will be able to register multiple jobs together or re-access their account in the future to add more. They may even cancel jobs, rearrange priorities, modify existing jobs, or other, provided, of course, their identity enables such functionality.
At step 46, it is then determined by the scheduling service whether the scheduling occasion of the registered job has arrived. If so, the payload is delivered to the location indicated with the registered job, step 48. Alternatively, the scheduling service does not provide a payload, but simply pings the location indicated with the scheduling job so the appropriate recipient can go and retrieve the payload. Still alternatively, the client can ping or contact the scheduling service and order the scheduling service to send the payload.
If, on the other hand, the scheduling occasion of the registered job has not arrived, the determining process 46 is later attempted after an appropriate amount of time elapses, step 50. During this time, an optional step of monitoring the progress of the requested job can occur, such as by one or more of the identities of the client account monitoring feeds according to one or more various rights allocated per their identity. In other optional steps, user identities may obtain reports/logs on the progress of in-flight or existing jobs or be able to receive/create audits of same. Eventually, however, the time occasion of the registered job will come to pass and the payload will be delivered to the appropriate recipient.
Appreciating the above, password-expiration scenario may lend itself to a user actually responding to the first reminder, the removal of future or remaining reminders creates opportunity for another scenario. Namely, a periodic attestation scenario provides that after assigning access to a resource, the entity of the client is that which receives the payload at step 48. In turn, appropriate entity personal, such as a manager, attests that one or more clients still need access to the resource. In this manner, the registered job invokes a new workflow and supplies the details about the resource, employee who has access to the resource, based on the information stored at step 44, for instance.
Detailing the high-level process of identity-aware scheduling services,
Once discovered, the identities of the client account, and their attendant rights, are made known to the scheduling service, step 64. For this,
Returning to
Additionally, the establishment of communication channels (step 66,
In particular,
Alternatively,
In
In conjunction with
Returning back to
As a diagrammatic example of each, FIGS. 6F1 and 6F2 show the notion of certificate or token T being passed and presented, while
In
With reference to
For the what-results needed component (payload), the client indicates items necessary for the task. Continuing with the previous example, this may consist of providing a “statement” to a user of an Oracle database that their password registration is imminently set to expire. It may also consist of providing an actual compilation of data, code, correspondence or other “content” that the client informs the scheduling service needs to be delivered to a party at a specific time. As an example, an underlying software application may have limited storage capabilities unable to locally store genome sequencing information. But, at a particular point in time, such as after processing a DNA sample, the software application may desire to download or obtain the genome sequencing information for comparison to the sample. Thus, the client may deliver the future-needed genome sequencing information that gets provided back to the software application upon the time instance of completing processing on the DNA sample. In that an infinite number of examples are possible as representative scenarios for this step, the foregoing is only to be construed as representative, and not limiting.
For the when-needed component of the job scheduling, timing data can consist of: 1) a precise instance of time, e.g., 12:01 a.m. on Saturday, Feb. 4th, 2008; 2) a window or interval of time, e.g., between Saturday and Tuesday of this week; or 3) an endpoint-conditioned occasion of time, e.g., no later than [or no earlier than] 4:00 p.m. today, to name a few. Alternatively, instances of time can be specified in multiples. For instance, the previous password expiration example contemplated providing a user-statement at the 60th, 75th, and 89th days, in time for renewing a password before the 90th day. Thus, multiple instances of time can be any of multiple instances of items 1), 2) or 3) above or set as “every x number of . . . ” minutes, hours, days, years, etc. Alternatively still, the timing data can be created as an algorithm, code, heuristically or in other manners not actually specifying time, per se, and all can be established by either the client or the scheduling service, or both, or another party.
For the where-needed component of the job scheduling, the client indicates a location, such as a URI or URL address, an email address, or the like. More narrowly, the location may be a precise location within an underlying application of code in need of the scheduling service. The location may also be found at multiple places or single places, and have multiple or single delivery of payloads at either. For actual delivery of the payload to the location(s), representative examples will be provided in relation to
At step 104, that which the client indicates or sends to the scheduling service needs to be stored or cached for later retrieval. It is contemplated that clients will call the scheduling service with arbitrary application data expressed as XML, where it will be cached for later use: for example, a workflow can send state data to the service, and the service will store that data in a data store until the next scheduled job event, then send the data back to the client or other recipient. Preferably, this would be made available through a WS-Addressing compatible API, since WS-Addressing provides a way to perform asynchronous invocation and callback.
Finally, at step 106, queries are scheduled by the scheduling service so that the registered job will receive the scheduling services it requests. For example, and continuing the earlier password expiration example, the scheduling service schedules queries to ensure that the statements to a user are indeed sent at the 60th, 75th, and 89th days, in time for renewing a password before the 90th day. Of course, other examples are within the scope of the invention.
With reference to
In
In
In
In a representative scenario of the invention, a workflow is designed to give a user access to an Oracle database, but policy requires that the user renew his account every 90 days. The user is to be notified of imminent password expiration at the 60th, 75th, and 89th days. On the 90th day, his account must expire.
On the “approved” branch of the workflow is an activity that schedules the execution of a repeating or renewal job.
The runtime scenario includes these events:
1. The workflow engine creates an instance of a provisioning flow based on a user request. The flow is officially active.
2. The engine creates its own key or keys for the workflow instance that include a GUID or other unique identifier, a timestamp, and any identity tokens or governance artifacts (or hashes derived therefrom) that the engine sees fit to craft.
3. Upon reaching the “schedule the Renewal job” node of the flow graph, the engine encodes state information about the flow (which MAY include the initiator DN, the approver DN, various e-mail addresses, the aforementioned key or keys, and/or other pieces of flow instance data) in XML, and optionally encrypts the XML. This is the userData XML.
4. The engine creates XML containing the actual parameter data for the scheduler service. This includes an array of time intervals, all relative to a certain date (the starting date of the user's Oracle access). The intervals are 0, 60, 75, 89, and 90. One or more addresses are associated with the respective intervals. Also, zero or more XPath expressions are associated with each.
5. The engine creates an account with the scheduler service under the workflow instance's identity. The service sends back a “receipt” or confirmation containing the account credentials.
6. The credentials are deposited in a place where an administrator identity can get to them if necessary.
7. The engine logs into the account and posts the job request (via SOAP). The caller receives a receipt. (This, too, is deposited somewhere.)
8. The scheduler service un-marshals everything and notices that the first pingback has a deadline of zero. It obtains the address(es) associated with that event and also the XPath expressions (and the bindings between the two). It runs each XPath query against the userData XML and sends the result to the appropriate addressee. One possible result is that at deadline zero (i.e., when the job is created), an e-mail is sent to the system admin saying “User cn-jdoe,ou=sales,ou=acme has received credentials for Oracle and the scheduler has scheduled a first renewal notice for 18 Mar. 2007.”
At 60 days, the scheduler runs new XPath queries and sends an e-mail to the user reminding him to renew within 30 days. It also posts an XPath:userData query result to an RSS server or message queue that is monitored by an administrative process.
At 75 days, the same events as the day 60 events occur, but with a reminder to renew within 15 days.
At 89 days, the same events as the day 60 events occur, but with a reminder to renew today, and including an extra log event and e-mail to the user's boss or manager indicating failure of the user to renew his Oracle account after two reminder notices.
At 90 days, the scheduling service sends a particular piece of parsed userData to a particular URL or URI, which causes an event that ultimately leads to deactivation of the user's Oracle account. The scheduler also sends e-mail to the system administrator that the user's Oracle account should by now be inactive.
In
In a representative embodiment, the API is (in at least one embodiment) expressed in WSDL and published to a service registry. Clients who need a scheduling service can thus discover the service (e.g., step 62,
It can be appreciated that services meeting these requirements can be exposed as SOAP endpoints or by other means, and data can be passed as XML or JSON payloads, and that payloads can be encrypted or not, and wire transmission can involve TLS or not, etc.
In another representative embodiment, the runtime executables that provide the core functionality might consist of Java classes in a JAR or WAR file deployed on a web server. (They could just as easily be C# classes running on Mono on a server, etc.) The classes in question could come from an open-source project such as Quartz.
An extra set of classes (also appropriately packaged, perhaps in the same WAR) would exist to provide a bridge between the core classes and the actual request-handler classes (e.g., servlets) that face the outside world, effectively translating API requests into method calls that the core objects can understand.
In at least one embodiment, the communication layer would handle requests via http, but it might also be able to “speak” JMS, SMP, or use protocols yet unknown. The preferred embodiment will at least handle http requests.
A representative embodiment would offer at least the following functionalities (exposed through a public API, defined, e.g., using WSDL).
As a result, certain advantages of the invention over the prior art are readily apparent. For example, it is heretofore unknown to promote job scheduling to a position of first-class citizenship in an SOA architecture and (in doing so) make scheduled processes more governanceable, which is to say, make it possible to log, track, audit, attest to, policy-control, and administer time-domain aspects of processes in a standard way across the enterprise. It is also unknown before now to promote scheduling to a higher level of abstraction so as to decouple the scheduler implementation (and its platform dependencies) from the public-facing API, such that a scheduler can be written in any language, on any machine, and yet still used by any client in accordance with the published API. Still further advantages include, but are not limited to: the promotion of scheduling code reuse; the elimination of unnecessary intimacy between applications, components, containers, frameworks, and connected systems at the enterprise level, thereby eliminating hard-to-predict side effects in the course of system evolution; the registering of jobs with a scheduler in a secure way and passing encrypted data to the scheduler for later reuse by the client or other recipient; the monitoring or tracking of job events, such as by an administrator subscribing (in identity-managed way) to an RSS or Atom feed; the facilitating the use of schedulers as first-class entities in a message bus or enterprise service bus (ESB) environment; and the enabling of AJAX components and web applications to leverage externally supplied job scheduling functionality in so-called “mashups.”
Finally, one of ordinary skill in the art will recognize that additional embodiments are also possible without departing from the teachings of the present invention. This detailed description, and particularly the specific details of the exemplary embodiments disclosed herein, is given primarily for clarity of understanding, and no unnecessary limitations are to be implied, for modifications will become obvious to those skilled in the art upon reading this disclosure and may be made without departing from the spirit or scope of the invention. Relatively apparent modifications, of course, include combining the various features of one or more figures with the features of one or more of other figures.
