Stu, Thanks a bunch for elaborating on the difference. It provided me a lot of clarity.
However, IMO, it is not quite fair to compare SOA and MVC. Eric Newcomer et.al. in their book "Understanding SOA with Web Services" on page 13, explain what SOA is. According to them, SOA is a style of design that guides business process life cycle. As I understand it, SOA is a means of *future-proofing* business processes and their collaboration from the changes in the computing environment. Having said that, MVC, I agree is a design pattern. While SOA is an architectural mind-set, MVC is closer to a low level design. And hence, I maintain that the two cannot be compared. Correct me if I am wrong. In fact, this leads to a related question: What are the motivations for SOA? - see my other post on the list. Cheers G --- In [email protected], Stuart Charlton <[EMAIL PROTECTED]> wrote: > > Ron, > > I think there are some parallels, since SOA has been derived, to some degree, from object-oriented abstraction principles. > > MVC is such an overloaded term that it's sometimes hard to know what some are referring to. There's a related pattern from vol1. of "Pattern Oriented Software Architecture" called Presentation-Abstraction-Control (PAC) that is more aligned to what people today think of as MVC in a web framework, vs. the original Smalltalk MVC framework (controllers were really more like event generators than a tie between model & view), or even how modern frameworks like Java's Swing implemented MVC. But anyway, I'll focus on how it's used with web frameworks today (Struts, RoR, etc) as a comparison to SOA. > > I think MVC does relate to the notion of "layering" in a services-oriented business reference architecture. I think this is somewhat different from what you would call a "metamodel". A business RA would describe the categories of services, and how they're connected (or not) to one another. Such a notion recognizes that there is no "one sized fits all" service, there are varying levels of interface granularity and responsibility. > > Similarly, MVC noted that not all objects are the same, and encapsulation shouldn't be taken to extremes. Views and models should be (relatively) loosely coupled. User-observable state transition also should be loosely coupled. > > In an SOA, a similar principle applies when defining a business reference architecture. A seapartion betwen model & view is clear -- it's easier to consume context-independent shared data than it is to "screen scrape it" because it's too focused on aparticular application. Thus, one separates "business" services , oriented around a subject-area or resource (described by a canonical XSD + WSDL, for example) from a "presentation" service that has a more uniform interface for a class of consumer (RSS, WSRP, XHTML, etc.). > > But with services it's a bit more complicated than just having a set of "model" services. Some "model" services are oriented towards a producer's internals (the "web services = MOM or RPC with angle brackets" style of servcies), which aren't easily reusable due to overlapping, messy/dirty data, and lack of shared semantics. They do, however, have tactical value in that they expose data on the network with a standard transfer protocol and/or standards for security, reliability, etc. > > As for "controller", that's an interesting one. In web frameworks, it tends to be a way of encapsulating "screen flow" state transitions. In an SOA it could be a shared business process service (regardless of how implemented), or a choreography description, or even a hypermedia document that specifies forms and/or links in a REST-style SOA. > > Cheers > Stu > > > > ----- Original Message ---- > From: Ron Schmelzer <[EMAIL PROTECTED]> > To: [email protected] > Sent: Thursday, July 13, 2006 8:38:37 AM > Subject: [service-orientated-architecture] Differences between SOA and MVC? > > > Model-View-Controller (MVC), on the other hand, IS a software architecture (or software design pattern as defined in the Wikipedia). Many of the ideas of MVC very closely parallel the ideas of SOA, especially the notion of the SOA metamodel, which separates Service design into three aspects: the business model, Service model, and Implementation models. The MVC approach separates application design into the Model (domain-specific representation), View (rendering of model for interaction), and Controller (event and action handling between View and Model). Likewise, MVC is also what you do and not what you buy and can be implemented using a variety of technologies including Java, Ruby on Rails, and others. > > I would like to know what the folks on this list think about the relationship between MVC and SOA. Is one an aspect of the other? What aspects of loose coupling are present in MVC that are not present in SOA... or vice-versa? > > We have our own (strong) opinions on this matter and probably will publish an opinion piece in response in an upcoming ZapFlash, but it would be good to understand what sort of diversity of thought there is on this topic. It might be that we all agree on the role of MVC as separated from SOA, but then again, the amount of disagreement on what we thought were fairly basic ideas continues to surprise me. > ------------------------ Yahoo! Groups Sponsor --------------------~--> Great things are happening at Yahoo! Groups. See the new email design. http://us.click.yahoo.com/TISQkA/hOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
