[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]