[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm-ra] Service visibility
I've embedded my comments below: <comment> When do we need visibility between the consumer and the service vs. the consumer and the service provider? For example, if I've used the service before and saved the specifics of the execution context, I just interact with the service to realize the real world effects. If I am having difficulties with automated means for resolving policy differences, I probably need to interact with the service provider. Frank and I had a brief interchange on this during the RM. Do we need more resolution of the endpoint? </comment> <danny comment> Based on the comment, it is not synonomous to say consumer interacts with service and consumer interacts with service provider. This is a useful distinction, but I think it is a subtle distinction for most people in the IT industry. I think it might be worthwhile to clearly make this distinction in the Participants section of the RA. From an IT perspective, interacting with the service is the invocation of the service actions. Interacting with the service provider includes invocation of service action and things like contract negotiations, resolution of a breach of contract, etc. In terms of visibility, there are places where service provider may be used instead of just service but it is not always clear which one is a better fit. </danny comment> <original> Willingness is an intentional stance held by the participating entities that predisposes them to interact in a service interaction. </original> <suggestion> Willingness is an intentional stance held by the participating entities that predisposes them to take actions necessary to realize the real world effects of a service. </suggestion> <danny comment> updated wiki </danny comment> <original> Management of group discovery information can quickly become complex if the service consumers and service providers refer to each other directly. Discovery mediation can alleviate direct references between the consumer's and provider's discovery information. </original> <danny comment> This sentence should be discussed in the mediation section. I removed it from the Group section. </danny comment> <comment> The issue isn't one of consumers and providers referring to each other directly but rather how they refer to each other. For example, if I want to evaluate the risk in driving a certain route, I certainly want to refer to the same service (and possibly the same version of the service) each time I reevaluate the risk, because if the risk changes, I want to know why it changed, i.e. I can't have different services arbitrarily swapped in. On the other hand, this does not mean I need to interact through the same service interface each time as long as I can be assured that the differences aren't important to me. So if Danny provides the risk evaluation services for my group, I can get the same flexibility from a Web page with links that Danny provides as I can from a formal registry, and can probably do it more directly. Additionally, a registry may have a mechanism to read Danny's Web page and pull the descriptions into its catalog. </comment> <suggestion> A group is a collection of individuals and the level and complexity of the formalisms through which the group operates will vary. In a SOA context, if the domain expertise of the group can be organized into a dozen services, a Web page listing summary descriptions and a link to the full service description (including the address of the service interface) may be sufficient to accomplish awareness. If the group maintains several hundred services, a formal cataloguing mechanism, such as a service registry, is likely needed. This points to the transition when group resources exhibit aspects of global discovery, but that transition is likely to occur in stages over time and not be characterized by any hard criteria. </suggestion> <danny comment> There's a conflict in the use of personal, group, and global and I'm not sure how to resolve it at this point in time. It's perfectly valid to describe personal, group, and global in the way it has been described. From an SOA IT perspective, the implementation of visibility for personal, group, or global will likely be the same. For example, no matter what category I fall into I am likely to interact with a service registry product to achieve service visibility. </danny comment> <comment> When I start reading about Mediated Discovery, I feel we need to step back and include (somewhere) a definition of Mediation. </comment> <suggestion> Mediation is the process by which interaction is enabled between two entities where there is initially a difference between the abilities, protocols, formats, vocabularies, or other interaction or exchange requirements for the two entities to have a successful interaction. Mediation may be automated or require human intervention. For SOA, information in the service and consumer descriptions serve as an indicator of where mediation is needed. Establishing an execution context is often the process of identifying and assembling the mediation capabilities needed for continued interaction or collecting the results of mediation that has already resolved some subset of the initial differences. </suggestion> <comment> The dictionary definition of mediation implies a 3rd party to help resolve disputes. I think the suggested definition is consistent with this. So, how does this definition (or some variant) apply to the term "mediated discovery"? Should we modify the suggested definition to include mitigating complexity or does that over-stretch the term? </comment> <danny comment> Now we have a clash of two paradigms. The first paradigm was simple, complex, and mediated discovery and the second paradigm is personal, group, and global discovery. The first paradigm took a more IT centric approach and the second took more of a humanistic approach. We need to bridge the humanistic approach to the IT approach for the enterprise architects. </danny comment> <original> Mediation promotes loose coupling by keeping the consumers and services from explicitly referring to each other and the descriptions. </original> <comment> Loose coupling isn't necessarily that you don't point directly to something explicit but how easy it is to point to something else. The idea of the UDDI tModel is one can easily point to another service that uses the same tModel. </comment> <danny comment> It's easiest for me to point my service directly to another service without going through a mediation process, but by doing so I am more tightly coupling myself with the service I am referring to. The tModel example is going down another level in describing loose coupling, do we need to go down to that level for the RA? </danny comment> <original> The potential service consumers perform queries or are notified ... ... 2. A single point of control. If the central discovery service is owned by, or controlled by, someone other than the service consumers and/or providers then the latter may be put at a competitive disadvantage based on policies of the discovery provider. </original> <comment> Good capture here. Do we need more thought on who sets up a registry and why? Also, how do you search across registries? For example, if every ESB that proxies services has a local registry, it appears each ESB licensee has a separate registry. Is there a way across these? </comment> <danny comment> The question of who sets up a registry and why goes back to the human element. Expanding on DNS could provide one model for searching across registries. I don't think this is a problem we should try to solve at the level of the RA. </danny coment> <original> While there can be several mechanisms for service discovery in a SOA, a prevalent mechanism for mediation in the industry is a registry. </original> <comment> One might say a registry is the canonical mechanism but I'm not sure I'd say the prevalent one. </comment> <danny comment> chagned prevalent to common </danny comment> <original> Illustration 4 label: Register service description </original> <comment> As stated, register would be a push mechanism. Should also allow for pull, such as crawl? </comment> <danny comment> The sentence above the diagram allows for pull: Service descriptions can be pushed (publish/subscribe for example) or pulled from the register-repository mediator. <danny comment> <suggestion> Service Provider <arrowLabel> creates/maintains </arrowLabel> Service Description (new box) and arrow from Service Description to Mediation Facility is "Populate with service description". </suggestion> <danny comment> Added a box for Service Description. Changed the Service Provider to Mediation Facility arrow label to Populate/Maintain Service Description. </danny comment> __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]