[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Architectural Requirements for BQoS - first in a a series of notes
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
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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]