In parts one and two, I described a model whereby long running processes, including physical processes, can be advertised and invoked within service architectures. A system can advertise when it is willing to offer a service, set prices for different schedules, indicate limitations in its ability to respond, and otherwise describe what it is bringing to market. A system seeking a service can efficiently compare performance characteristics and prices for acquiring / invoking these services. Client and server can negotiate when and how a service is provided. These information exchanges are at the heart of smart grid communications. In this post, I examine some other examples.
Long time readers know that I have long been concerned with getting buildings to respond to their occupants, or, in particular, to the schedules of their occupants. Many of us use our mail or calendar systems to coordinate meetings. It is common practice to invite the room as well, so the others can review the availability of the room for other meetings. Using WS-Calendar, one can post from the enterprise calendar of the resource [room] to the building automation system. This interaction does not require any service advertisement.
Sometimes the meeting organizer wants to compare several rooms. Some of the potential meeting rooms may charge rent or booking fees. There may be a lag the first time a room is scheduled on a given day, as the room is heated up or cooled down before use. Some rooms may use more or less energy, and the building automation through metering and introspection and weather predictions, may be able to calculate this energy requirement. If the building receives price signals from its energy supplier, it may be able to provide comparative prices for different rooms. These prices can be advertised in the service that books each meeting room in a building. A room can be scheduled with less advanced notice than it needs; when this happens the organizer can be notified that the conditions offered by the room will be sub-optimal for some or all of the meeting.
But this information model is useful beyond energy, buildings, and rooms. The patterns of information and communication described above are common to the processes of business and people. Their use opens the processes of business and people to automated negotiation.
Maybe the local coffee shops offer meeting support services. One is less expensive, but needs one day’s notice. The other is more expensive, but can respond with a two-hour’s notice. A scheduling system can search out the options, and offer the organizer choices and prices. Just as the BAS was notified of a meeting for 20, so, too, is the chosen caterer. The service provided by the coffee shop may be a process that arrives with coffee half an hour in advance. The service request can be the same as received by the BAS. The facility’s housekeeping service, whether in-house or outsourced, can receive the same notification, even though the service it offers is to arrange the furniture in advance and to clean up afterwards.
This pattern is a general pattern. Consider scheduling medical facilities. An expensive resource, such as an MRI system, is often scheduled day and night. A one-hour apointment using the MRI may require considerable set-up time. A single patient visit may involve multiple groups with multiple lead times and costs that vary by time of day. Medical groups may provide disabled veterans with transportation to and from the hospital. This transport service may be provided between 7:00 AM and 3:00 AM by in-house staff, requiring three-hour’s notice. After hours, the group may arrange for taxi or medical transport service. Depending upon schedule, patient medical state, origination and destination, and costs, the scheduler may be offered a number of decisions. The software presenting the choices needs only a limited amount of information to filter the services and to present them to the scheduler.
For each of the examples described above, a system is able to select from among services advertised, by schedule, by price, and by requirements, and narrow down to services that fit the need. Such a system may make a final decision of which service to use, or can present the final candidates to an end user with properly distinguishing characteristics. The distinguishing information can easily be exchanged using WS-Calendar and EMIX Terms.
In today’s new economy, people are inventing their own jobs based on radical outsourcing. New service markets are being built around services such as TaskRabbit. Local cooperatives such as LoadedBikes in Chicago offer just-in-time delivery to local and national services through aggregation of peers. Within a class of service, the WS-Calendar and EMIX Terms provide the information needed to select services and to assemble seamless aggregates.
The common information models of schedule and of EMIX Terms are the foundation for even more interesting applications that can be built using peer-to-peer interactions. Peers can compete for constrained resources over time, trading slight changes in schedules using market-like interactions. Because of the simplicity of the interactions, systems assembled in this way can be self-integrating and self-optimizing. This offers interesting possibilities for microgrids and other systems of systems. That conversation is out of scope in this series, but it can begin through thinking about these common information exchanges.