[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Architectural Scope of Reference Model
I think one can have metadata about a contract or contracts as a class, but I don't think contracts are metadata in themselves. Such agreements ought to be distinct transactions/interactions, while the concept of a contract is really nothing more than published/advertised service with some metadata about it which a service consumer can agree to or not. The agreement/contract is a transaction/interaction that has several stages, each of which may or may not have a need for metadata to be included in service description, so I think the published service description is the metadata, not the contract. Those stages may or may not include parts for security measures, specific processes that may need orchestration, and other components relevant to the particular service. I have no quibbles with the visio diagram that Duane submitted yesterday, except that I don't happen to have visio, but I would rename the Contract in Gregory's UML diagram to Service Description. The contract only comes about later, when the wsdl bindings are exchanged and validated ready to receive the service software components, or engage the service remotely, or however the service is configured to be consumed. Ciao, Rex At 12:23 PM -0700 4/21/05, Breininger, Kathryn R wrote: >Not sure I understand here; in my view, these are two separate things >that are related, in that one describes the other, but they are not of >types such that one could be a specialization of another... > > >Kathryn Breininger >Boeing Library Services >425-965-0182 phone > > > > > >-----Original Message----- >From: Duane Nickull [mailto:dnickull@adobe.com] >Sent: Wednesday, April 20, 2005 1:48 PM >To: Francis McCabe >Cc: Gregory A. Kohring; Ken Laskey; soa-rm@lists.oasis-open.org >Subject: Re: [soa-rm] Architectural Scope of Reference Model > > >Would it be fair (and legal) to state that "contract" is a >specialization of the abstract metadata class and also stereotype it as >an abstract class? > >Duane > > >Francis McCabe wrote: > >> The problem with this diagram is that it assumes that a contract *isa* >> metadata. I could not disagree more. And UML makes this awkward. >> >> The relationship between a contract (which is an abstract entity) and >> its description (which is a document) is one of *describes*. >> >> On the other hand, a QoS agreement *isa* contract. >> >> I also included the stuff on choreography, business policy etc. >> >> I believe that choreography is part of the syntax -- it is part of >> what you need to know about the mechanics of using the service. But it > >> is separate from business logic and semantics. >> >> Frank >> >> >> >> On Apr 20, 2005, at 2:09 AM, Gregory A. Kohring wrote: >> >>> OK, here is a slightly different view using UML. In this view >>> metadata is the higher level abstraction, while contract is a more >>> specialized abstraction. >>> >>> -- Greg >>> >>> Duane Nickull wrote: >>> >>>> Francis: >>>> >>>> Cool! This is perhaps a place where using UML to avoid ambiguity >>>> may be >>>> good. >>>> >>>> If I read your diagram, it asserts that "realized as" implies an >>>> "abstract-concrete" association. I had viewed that the other >>>> concepts are more of a "can be aggregated as part of" association. >>>> My observation is that usually the abstract-concrete association is >>>> often used for mapping a specific protocol or specification to a >>>> concept in a reference model or reference architecture. I guess the >>>> question we need to consider is "what is the association between the > >>>> higher level abstract concept of metadata and specialized metadata >>>> concepts?". >>>> >>>> Anyone care to take a stab at this as a UML class diagram (or >>>> answering the question)? >>>> >>>> Cheers (and beers next week) >>>> >>>> Duane >>>> >>>> >>>> >>>> >>>> Francis McCabe wrote: > >>> >>>>> I prefer the following diagram :) >>>>> >>>>> >>>>> Frank >>>>> >>>>> On Apr 19, 2005, at 9:51 AM, Duane Nickull wrote: >>>>> >>>>>> <Drawing1.png> >>>>> >>> <metadata.pdf> >> >> > >-- >*********** >Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com >Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/ >Adobe Enterprise Developer Resources - >http://www.adobe.com/enterprise/developer/main.html >*********** -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]