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