Re: [soa-eerp] Architectural Requirements for BQoS

Subject: Re: [soa-eerp] Architectural Requirements for BQoS - first in a a series of notes

On Wed, Feb 18, 2009 at 8:23 PM, William Cox <wtcox@coxsoftwarearchitects.com> wrote:

Carl -

Not certain what you're suggesting: a use count (per consumer of a particular service), a total use count (per service), or something else?

Thanks!

bill

carl mattocks wrote:
I agree with having a focus on core factors.

I would like to suggest that one (additional) factor that would be considered as valuable is:

" use count" being number of actual uses to date

carl

On Wed, Feb 18, 2009 at 7:19 PM, William Cox <wtcox@coxsoftwarearchitects.com> wrote:

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

--
Chair OASIS Business Centric Methodology TC
co-Chair (ISO/TS 15000) ebXMLRegistry Semantic Content SC
Ontolog ONION Cop Leader
President Berkeley Town Underwater Search & Rescue Unit
CEO CHECKMi
vmail (usa) 908 322 8715
CarlMattocks@checkmi.com
www.CHECKMi.com
CHECKMi:Understanding Semantics at your Service

soa-eerp message