[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] David Linthicum Says: "ESB versus Fabric.Stop It!"
Ken: Yes - it explains very well. This is a good scenario to explain the relationship between the RM and architecture. While the two different components (UDDI and SWS) are incompatible, the scoping of components aligns to a core RM so there is no overlap or duplication. Duane Ken Laskey wrote: > Duane, > > Let's try a variation with a hint of reality. > > There is a UDDI spec for describing services and also a Semantic Web > Services (SWS) spec. I don't recall if UDDI 3 supports using OWL for > defining vocabularies but for the current discussion let's say it > only supports XML Schema (or RELAX) and SWS uses OWL. So our RM > would have the concepts of a service, a service description, a > service interface, ... but the RAs derived would follow a UDDI > pattern or a SWS pattern. The two could conform to the RM but could > have parts that were incompatible. > > Does this illustrate some point we are after? > > Ken > > > On May 24, 2005, at 1:33 PM, Duane Nickull wrote: > >> This case is actually so simple that it probably would never be >> done. The advantage is that both architectures have clearly scoped >> the messages as a concrete manifestation of the data model. They >> will probably both use something like XML Schema since it is clearly >> scoped to do this and nothing more. >> If, however, there was not consensus, one architecture may write the >> messages, but also include the processing models in each message, >> while the other architecture does not. The disadvantage is that the >> message processors would have to be custom built each time as a >> component if there is no clear divisions. Because we use XML Schema >> and XML for the messages in concrete architectures, we have a >> component (a validating XML parser) that is exactly matched to the >> area of functionality. We do not see that the XML parser would also >> have to examine and control the processing model for a service. >> When building your own implementation, it allows you to get >> components to match each area of functionality. >> Another big advantage is that the other components can be re-used, >> even if XML and XML Schema are not used for the messages (from data >> model). If you use EDI instead, you should be able to simply swap >> out one message processor for the other one and use everything else. >> >> Duane >> >> >> Chiusano Joseph wrote: >> >>> Yes - thanks Duane. So taking the data model/messages route: >>> 2 concrete architectures that are being compared for some purpose are >>> each themselves mapped to 2 different reference architectures. >>> However, >>> it so happens (for our purposes) that both reference architectures >>> were >>> derived from the SOA-RM reference model (whatever it eventually turns >>> out to be in its final version). >>> >>> The messaging component of each CA (concrete architecture) is >>> mapped to >>> messaging component of each RA, then to the data model component of >>> the >>> SOA-RM RM. This enables the messaging component of each CA to now be >>> associated/compared as needed. >>> >>> Q: How many folks would go so far back as the RM to perform such a >>> comparison, when each RA itself has a messaging component? >>> >>> Joe >>> Joseph Chiusano >>> Booz Allen Hamilton >>> Visit us online@ http://www.boozallen.com >>> >>> >>>> -----Original Message----- >>>> From: Duane Nickull [mailto:dnickull@adobe.com] Sent: Tuesday, May >>>> 24, 2005 1:06 PM >>>> Cc: soa-rm@lists.oasis-open.org >>>> Subject: Re: [soa-rm] David Linthicum Says: "ESB versus >>>> Fabric.Stop It!" >>>> >>>> Jospeh: >>>> >>>> It is not quite ready to be done due to its' immaturity, however >>>> doing so will be the real test. >>>> >>>> One would look at an item like the "Data Model" and then in a >>>> reference architecture, would make a specific set of messages that >>>> get sent into and out of the service. For example, if the service >>>> had an abstract function to multiply two numbers and return the >>>> result, the data model is "two integers in, one integer out". >>>> >>>> I could make a set of schemas that constrain XML instances on the >>>> wire and express that data model in the XML syntax. >>>> >>>> This is one example of how we go from abstract Data Model to >>>> concrete Messages. Similar examples include going from abstract >>>> "policy" to concrete policies expressed using WS-Policy and >>>> WS-Policy Attachment (or similar mechanism). >>>> >>>> Everything that is in the RM ensures that the architects make >>>> consistent logical divisions in how they think about architecture. >>>> Does that explain it? >>>> >>>> Duane >>>> >>>> >>>> Chiusano Joseph wrote: >>>> >>>> >>>>> Thanks Duane - I think this would be great for the intro section. >>>>> >>>>> Can someone now relate this to our current Figure 2-1? How >>>> >>>> would an RA >>>> >>>>> be derived from that? This will help us understand better the >>>>> RM->RA roadmap that is required. >>>>> >>>>> Joe >>>>> >>>>> Joseph Chiusano >>>>> Booz Allen Hamilton >>>>> Visit us online@ http://www.boozallen.com >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Duane Nickull [mailto:dnickull@adobe.com] >>>>>> Sent: Tuesday, May 24, 2005 12:57 PM >>>>>> Cc: soa-rm@lists.oasis-open.org >>>>>> Subject: Re: [soa-rm] David Linthicum Says: "ESB versus >>>>>> Fabric.Stop It!" >>>>>> >>>>>> RA means Reference Architecture. As per the previous >>>>> >>>> emails on this >>>> >>>>>> subject, it is a generalized architecture. >>>>>> >>>>>> The relationship is that architects use a RM as a guiding >>>>> >>>> model when >>>> >>>>>> building a RA. >>>>>> >>>>>> For example, if you are architecting a house, an RM may explain >>>>>> the concepts of gravity, a 3D environment, walls, foundations, >>>>>> floors, roofs, ceilings etc. It is abstract however. There is >>>>>> nothing specific like a wall with measurements such as 8 feet high. >>>>> >>>> Note that >>>> >>>>>> the RM has only one each of these things - it does not have >>>>> >>>> 4, 16, 23 >>>> >>>>>> walls, just one as a concept. >>>>>> >>>>>> The architect may uses this model to create a specific >>>>>> architecture for a specific house (accounting for such things as >>>>> >>>> property, incline, >>>> >>>>>> climate etc) or an architect MAY elect to use it to build a more >>>>>> generalized reference architecture. >>>>>> The latter is often done by architects who design houses. When >>>>>> they sell a house, they must often re-architect the RA for >>>>>> specific implementation details such as incline of land, >>>>>> climate, facing the sun etc.. >>>>>> >>>>>> So why do we need a RM? Simple - we now have logical divisions >>>>>> amongst the components of a house and what they mean. That >>>>> >>>> way, when >>>> >>>>>> a company says " we are a flooring company..", that is >>>>>> meaningful since we all know what that means. The same applies >>>>>> to a roofing company. Without the basic consensus on the >>>>>> logical divisions, a roofing contractor may also try to include >>>>>> the ceiling and walls as part of his offerings. >>>>>> That would not work and not allow the general contractor to >>>>>> build a house very easily since there may not be consensus upon the >>>>> >>>> division >>>> >>>>>> of labor and components to build the house. >>>>>> >>>>>> Do you guys think an explanation of this nature may be good >>>>> >>>> to include >>>> >>>>>> in the introduction section? >>>>>> >>>>>> Duane >>>>>> >>>>>> Chiusano Joseph wrote: >>>>>> >>>>>> >>>>>> >>>>>>> What is an RA? What is the relationship between an RM and an >>>>>>> >>>>>>> >>>>>> RA? What >>>>>> >>>>>> >>>>>>> is the RM->RA path for SOA? >>>>>>> >>>>>>> Matt also submitted last week (I believe) that we may not >>>>>>> >>>>>>> >>>>>> even need an >>>>>> >>>>>> >>>>>>> RA. How should that change our notion of RM, if at all? >>>>>>> >>>>>>> Joe >>>>>>> >>>>>>> Joseph Chiusano >>>>>>> Booz Allen Hamilton >>>>>>> Visit us online@ http://www.boozallen.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > ------------------------------------------------------------------------ > ------------------ > Ken Laskey > MITRE Corporation, M/S H305 phone: 703-983-7934 > 7515 Colshire Drive fax: 703-983-1379 > McLean VA 22102-7508 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]