Architectural Requirements for BQoS - first in a a series of notes

[William Cox <wtcox@CoxSoftwareArchitects.com>]

This brief note addresses architectural requirements for the EERP component technology, Business Quality of Service (BQOS).  Later notes will address the other components of EERP from a similar architectural perspective.

Following Andy's terminology in the contributed tutorial, the attributes of a service are defined in BQOS), the reliability of the stated attributes is described in WS-Rating, Service Level Agreements in a Business SLA.

Consistent with the Service Oriented Architecture (SOA) approach, we need to be careful to avoid modeling at too fine a level, as we lose sight of business interoperation. For example, I don't care about the holiday, vacation, and work schedules of the provider of a service, only what it costs, that the service will be provided, it will happen by or on a committed date/time, the quality of the work, and how good the estimates of the service provider are (WS-Rating).

Note that SOA works well in enterprise deployments BECAUSE it defines large components with simple interactions.

So the core information, common to most if not all services to which BQOS might be applied, would seem to be

• Price (including currency)
  
• Start Time and Duration, or in the alternative, Start and End Time. (I suggest thinking about the IETF iCalendar; WS-Calendar is nearing its start point, and likely will finish  in an appropriate timeframe)
  
• A hook to identify the appropriate ratings -- this could be an identifier, a name, a company name/department, a DUNS number (used in ebXML for business identification) or something else. So I think of this as "Service Provider Identity" perhaps combined with "name of service" and "version of service" as separate items
  
• A means of attaching additional attributes
• In conjunction with additional attributes, I suspect that a means for registering attribute profile names will be necessary to avoid collisions.

So by moving the "additional attributes" out of the base schema, or referencing them, we should be able to have a simple schema and XML artifact to pass around, while allowing additional information to be associated with it, either through a database, including in an extensions area, other other means (maybe even WS-Addressing to point to a service endpoint to obtain additional information, but I'm getting ahead of myself here.)

There are some important ideas here:

(1) Don't include a lot of detail that might be releveant to some particular service, include the base and allow for different extensions/variations

(2) Don't include deep business details -- UDDI failed as a public business directory (in my opinion) because to participate you needed to express your deep business processes and service definitions.

(3) Don't pass more information than is needed to make a decision on selecting a service.

(4) Define [large] components/services with simple interactions -- the complexity can be in the service, but we may not need that information to select.

Of course, in real life, some of us want to know everything about a service before buying it. But in the more stylized business process world, this is done by looking at the attributes we have and considering additional ones that may be available through other means.

In summary, I think this approach is simple, usable for many problem domains, and with extensible attributes allows domains we might not even be thinking of to be processed in an EERP environment.

bill

--
William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax