OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm-ra] Groups - Modification of Policy_Contract_Business diagram (OASIS_Policy-Contract_Diagram.JPG) uploaded


Michael,

Responses to points 1 through 7.

> 1. A SOA service can have multiple 
> interfaces but the same service 
> component(s)/implementation

Ok, Franks discussion does not discount this
possibility.

> 2.  A SOA service interface includes all the actions
> that you may perform against  the service  while the
> service component(s) includes any behavioral models
> associated with those actions. 

One common interpretation of service component is
IBM's service component architecture.   According to
that architecture, it is true the implementation of
the behavioral model would be in one or more service
components.  However, as defined by the OASIS SOA RM
the reference to the behavioral model could be
referenced through the service description of which
the service interface is a part of which the
behavioral model is a part.  See the UML model for
Service Description.

http://wiki.oasis-open.org/soa-rm/TheArchitecture/ServiceView/ServiceDescription


> That is, I have clear
> separation between the service interface and the
> service component. It is the same separation as
> between business interface (user activities
> associated with the services) and the business
> service itself.

This does not seem to leave room for a behavior model
being a part of the Service Description, the behavior
model seems to be associated with the service
component.  I am wondering what the UML diagram would
look like that would give a service consumer access to
the service artifact that is equivalent to the
behavior model.

> 3.	A SOA service interface includes
> access/communication mechanism/protocol and detailed
> definitions of the exposed operations, related data
> models (not the service data models but only
> interface specific ones), message exchange or
> communication pattern(s) and physical definition of
> the point of the service contact/access

This is pretty much inline with Service Description as
we've defined in the Service Description for the SOA
RA.

> 4.	One SOA service can have none or many Service
> Contracts. 

Ok, but in my interpretation Service Contract does not
equal Service Description or Service Interface.

> A Service Contract may include a subset
> of the service interfaces exposed to particular
> client.
> For example, if a service have HTTP-, HTTPS-
> and IIOP-based interfaces, a concrete client may be
> contracted to use HTTP- and HTTPS-based interfaces
> only, i.e. if this client tries to access the
> service via IIOB-based interface, the request may be
> legally denied.

It could be true that service interfaces are specified
as part of a service contract as given in the example,
however, it is also true that service interfaces may
not be part of a service contract.  

> 5.	Due to differences in the interface usability
> characteristics, the same service may have many SLA
> depending on the interface used/agreed. For example,
> a throughput of the service accessed via HTTP may be
> 10 times higher than via HTTPS. The nature of the
> service does not change.

This could be true as an example.  I am having a hard
time finding a relationship between this example and
an underlying SOA principle that applies to all SOAs.

> 6.  A SOA service (especially 
> business service) may
> have certain behavior that is not visible through
> its interface.

Ok, the statement could apply equally to any type of
service.
 
> Variations of this behavior may be
> specified in the different service contracts. 

Ok  

> Since many people consider that SLA are run-time
> measurable characteristics only, and the service
> behavior may last much further than the run-time
> (long-running business transactions), I am afraid to
> merge SLA with Contract.

Should we qualify SLAs in the SOA RA as run-time only
measurable characteristics?  It is a stab at trying to
find an underlying principle that could apply to all
SLAs in all SOAs.


In the discussion above, it is not clear that there
was agreement or disagrement with Frank's statements. 
I'll add the following discussion to relate policies
and contracts to one another.

I'll start with Webster's definition for contract:

1 a : a binding agreement between two or more persons
or parties; especially : one legally enforceable b : a
business arrangement for the supply of goods or
services at a fixed price <make parts on contract> c :
the act of marriage or an agreement to marry
2 : a document describing the terms of a contract
3 : the final bid to win a specified number of tricks
in bridge
4 : an order or arrangement for a hired assassin to
kill someone <his enemies put out a contract on him> 

We can eliminate definitions 1b, 1c, 2, 3, & 4 since
they do not apply to this discussion.  To me it seems
a bit odd to discuss contracts without some legal
context behind them.  

What Frank has done has defined the root difference
between policy and contract.  This difference applies
to how humans define policies and contracts, not how
the IT mechanisms operate on them.  To IT mechanisms
they are both just measurable and enforceable rules. 
The current standards for these IT mechanisms favor
policy over contract - Policy Decision Points, Policy
Enforcement Points.  Based on the definition for
policy and contract, you could define an IT
relationship where a contract inherits from a policy,
however, for people it is usually clear that it is a
contract or a policy but not both.  There are an
infinite number of combinations for how one business
can define a policy versus a contract and how another
business defines a policy versus a contract.  Any
given example of a policy or contract can be negated
by a counter example of the rules specified in reverse
- policy rules become contract rules and contract
rules become policy rules.   Frank nailed this down
when he stated:

> The contract description may include 
> references to policies  and other 
> contracts -- either by reference or by 
> direct inclusion -- depending on the 
> language used to describe the contract.
>
> A policy description may contain 
> references to other policies and  
> contracts; again either by a link or by 
> inclusion.

There are some generalities about SLAs that can be
described in relation to contracts, but there are an
infinite number of templates that can be created for
SLAs.  I am not sure we can find some commonality that
holds true for all SOA SLAs for all organizations. If
we can not tie our SOA RA models to an underlying
truth that can hold true for all SOAs, then we will
define SOA RA models that are not true for many
organizations.

Danny

--- michael.poulin@uk.fid-intl.com wrote:

> Thank you, Frank, you answer is quite clear to me
> and it helps me to find where my model does not
> match yours, precisely. I will describe the
> differences and offer you to look into them  may be
> you find something useful for the standard in my
> views
> 
> I totally share your definition of the SOA service.
> And the differences are:
> 
> 1.	A SOA service can have multiple interfaces but
> the same service component(s)/implementation
> 2.	A SOA service interface includes all the actions
> that you may perform against  the service  while the
> service component(s) includes any behavioral models
> associated with  hose actions. That is, I have clear
> separation between the service interface and the
> service component. It is the same separation as
> between business interface (user activities
> associated with the services) and the business
> service itself.
> 3.	A SOA service interface includes
> access/communication mechanism/protocol and detailed
> definitions of the exposed operations, related data
> models (not the service data models but only
> interface specific ones), message exchange or
> communication pattern(s) and physical definition of
> the point of the service contact/access
> 4.	One SOA service can have none or many Service
> Contracts. A Service Contract may include a subset
> of the service interfaces exposed to particular
> client. For example, if a service have HTTP-, HTTPS-
> and IIOP-based interfaces, a concrete client may be
> contracted to use HTTP- and HTTPS-based interfaces
> only, i.e. if this client tries to access the
> service via IIOB-based interface, the request may be
> legally denied.
> 5.	Due to differences in the interface usability
> characteristics, the sane service may have many SLA
> depending on the interface used/agreed. For example,
> a throughput of the service accessed via HTTP may be
> 10 times higher than via HTTPS. The nature of the
> service does not change.
> 6.	A SOA service (especially business service) may
> have certain behavior that is not visible through
> its interface. Variations of this behavior may be
> specified in the different service contracts. Since
> many people consider that SLA are run-time
> measurable characteristics only, and the service
> behavior may last much further than the run-time
> (long-running business transactions), I am afraid to
> merge SLA with Contract.
> 7.	Finally, I used terms explicit and implicit with
> regard to Contract itself, not to the acts described
> in the contract (The act of agreement may be
> implicit or explicit). Notice how difficult it can
> be at the level of IT to distinguish  implicit from
> explicit agreement.  -  I disagree because explicit
> agreement just requires preliminary sign-off from
> the participants ( and following posting/publishing
> of the Contract in the Service Contract Repository)
> while an  implicit agreement takes place when a
> client or provider accepts constraints of another
> party without any additional actions; this is how
> Policy works. Please, believe me  that in my IT such
> things happen every day, in development and at
> run-time.
> 
> - Michael



 
____________________________________________________________________________________
Finding fabulous fares is fun.  
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]