Anne wrote "Therefore it's not necessarily appropriate to configure QoS with
the service definition... The QoS should be configured based on the contract,
not on the service."
I agree that QoS is managed/modified based onthe Service Contract. However,
what to do with the case where the service sell point is performance? I think,
that it makes sense to publish some minimal characteristics of QoS with the
service description while QoS configuration better be based on the Contract.
- Michael
Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
On 7/31/07, Shashank D. Jha <[EMAIL PROTECTED]> wrote:
>
> On 7/22/07, Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
> >
> > On 7/21/07, Shashank D. Jha <[EMAIL PROTECTED]> wrote:
> > >
> > > On 7/20/07, Rob Eamon <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > Too simplistic.
> > > >
> > > > Perhaps.
> > > >
> > > > > What about deterministic and reliability aspect of
> > > > > such software systems?
> > >
> > > I think QoS aspect of a service should be first class concept/aspect
> > > to be addressed by SOA to ensure that SOA doesn't go OO or CBD way but
> > > is more comprehensive and meaningfully usable.
> >
> > One of the core principles that I espouse for SOA is separation of
> > concerns between the service and the infrastructure that supports it.
> > The infrastructure is responsible for QoS. The service requirements
> > dictate what type of infrastructure is required to support the service
> > and may influence the technologies used to implement the service.
> >
> > The specific QoS capabilities required by a service/interaction are
> > specified as policies as part of a runtime contract. The
> > infrastructure is responsible for ensuring that policies are enforced.
>
> Like we did in component technology, where we had components and
> deployment platform/infrastructure. But one of the difference from
> component and object is that "configuration" is inherently part of a
> component specification, as in CCM, other than specification for
> services provided and services required by the component. Similarly I
> feel QoS should be part of service definition itself. May be that will
> complicate the "Service" so may be assigned to "Infrastructure"
Would you agree that QoS requirements have a different lifecycle from
a service? Based on today's requirements (contracts with consumers), a
service requires this level of security, auditing, and performance.
But tomorrow a new consumer might come along that requires more
stringent QoS. And here's the rub: QoS requirements may be a function
of a particular contract between a consumer and provider -- not just
the service. Therefore it's not necessarily appropriate to configure
QoS with the service definition. The QoS should be configured based on
the contract, not on the service.
>
> > >
> > > > IMO, those characteristics would be driven by other constraints,
> not
> > > > SOA principles. The primary (only?) "-ility" SOA explicitly
> addresses
> > > > is flexibility.
> > > >
> > > > > Do we need prefabricated services to collaborate or it will
> ad-hoc?
> > > >
> > > > I'm not sure what this means.
> > >
> > > Remember we are doing Enterprise Architecture. So service
> > > specification should have enterprise features including consistency,
> > > certain deterministic behavior, robustness etc. after from
> > > governance, contracts, business behavior, so these characteristic
> > > should be able to specify for a service.
> >
> > I think you're talking about what I refer to as infrastructure
> > services. The bits and pieces of the infrastructure that implement
> > common, reusable capabilities like security, auditing, reliability,
> > persistence, etc.
>
> I was not sure if the current definition of SOA differentiates between
> Infrastructure services and business services. So my suggestion.
As far as I'm aware, there is no "current definition" of SOA. I tend
to use the following taxonomy to describe different types of services:
- functional services (services that expose a single, relatively
discreet business function)
- data services (services that expose data or information)
- infrastructure services (services that implement non-functional capabilities)
- composite services (services that expose a more comprehensive
business function, typically orchestrating one or more other services)
Anne
>
> regards,
> Shashank D. Jha
>
>
> > >
> > > > > How to model a Service?
> > > >
> > > > SOA cares only that there is a defined interface and that it is
> > > > separate from the implementation. SOA is mum on the details of the
> > > > service itself. Modelling a service will be guided by other
> > > > principles (e.g. OO, etc.).
> > >
> > > OO (Real world entities) principals were fundamentally different from
> > > SOA (Industry's best practices for business agility) principals. they
> > > were not developed to address enterprises IT concerns, but were to
> > > address software development concerns. So same modeling concept is
> > > limiting for a Service modeling.
> >
> > I agree that we don't have an effective modeling notation to represent
> > policy-driven infrastructure.
> >
> > Anne
> > >
> > > regards,
> > > Shashank D. Jha
> > >
> > > > > We need to address minimum set of requirement to start adopting
> SOA.
> > > >
> > > > To make sure I understand, are you saying "if you have this list of
> > > > requirements, use SOA?"
> > > >
> > > > -Rob
> > > >
> > > >
> > >
> >
>
>
>
>
---------------------------------
Boardwalk for $500? In 2007? Ha!
Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.
