The reason I believe it is appropriate to compare MVC and SOA is that there needs to be architectural guidance on how to identify services, their contracts, and their interactions, just as we once asked ourselves these questions inside object oriented systems. MVC or PAC were layering patterns that dealt with the evolutionary lifecycle differences betwen shared data, shared process, and presentation, and thus likely have parallels worthy of consideration within SOA. They were patterns that helped to "future-proof" object-oriented applications from changes in view, or in data, or in process.
MVC's benefit is firstly to highlight the lifecycle benefits of separating data, view, and control. Secondly, it is to recgonize that objects, and thus services, fulfill different responsibilities and thus their interfaces exhibit an inherent bias, depending on the responsibility they fulfill. There are some services that are oriented towards a consumer (a view or presentation), some are oriented towards a subject area (a model or abstraction), and some are oriented towards a set of business process-specific requirements (a controller).
To elaborate: a business process is one input into identifying services, but it cannot be the only input. Business processes do not, for example, provide clear guidance on many questions of service or contract granularity -- where should the boundary go? What does a contractual boundary imply and why do I need one?
For example, if the service is "activity oriented", in that it represents a contract for an activity within a business process, then the boundary becomes easier to recognize, as it is based around an activity that can quantiatively demonstrate economic value-add.
However, if the service is "resource oriented", that is, it encapsulates policy that must be enforced among several business processes (such as a "Customer" service), business processes do not help matters. Such services likely benefit the most from uniformity of interface.
Furthermore, business processes often are accessed through a variety of channels, including contact centres, retail outlets, web sites, IVR, mobile devices, etc. Should the biases and contortions required to support those channels be an intrinsic part of a busienss process, or disinct from it? This is the question of how "presentation" services fit into an SOA.
Cheers
Stu
From: Gautham Kasinath <[EMAIL PROTECTED]>
To: [email protected]
Sent: Sunday, July 16, 2006 6:05:33 AM
Subject: [service-orientated-architecture] Re: Differences between SOA and MVC?
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 service-orientated- architecture@ yahoogroups. com, Stuart
Charlton <stuartcharlton@ ...> 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 <rschmelzer@ ...>
> To: service-orientated- architecture@ yahoogroups. com
> Sent: Thursday, July 13, 2006 8:38:37 AM
> Subject: [service-orientated -architecture] Differences between SOA
and MVC?
>
>
> Model-View-Controll er (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.
>
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
