[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!"
Additionally: I am involved in the US federal government's Data
Reference Model (DRM) efforts. We are planning to produce an XML
representation ("profile") of the DRM as well as a semantic technologies
representation (e.g. OWL). Both of these representations (profiles)
would align to the core RM.
Is this the same idea?
Kind Regards,
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
> -----Original Message-----
> From: Duane Nickull [mailto:dnickull@adobe.com]
> Sent: Wednesday, May 25, 2005 9:34 PM
> Cc: SOA-RM
> 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]