On 01/07/06, Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > > > > > > > > Steve, > > In response to your last assertion: > > > > I tend to see architecture as the SOA bit, where you determine the > services to be delivered, their principles, drivers and capabilities. > These are the big picture elements, then either overall or for each of > the services you have to work out the best way to do it. > > > You can adopt an equally valid but different architectural approach -- the > REST approach, whenre you determine the resources that need to be delivered, > what their valid states should be, and when and how those state changes > should occur. These are also big picture elements. > > As I said before -- if you adopt a service-oriented perspective, then REST is > an implementation style. But if you adopt a resource-orient perspective, then > REST is your core architecture.
What confuses me though is how you model an enterprise or complex programme at the resource level without those resource level elements becoming services. So at the top level you have a "House" which contains "Rooms" which contain "Lightbulbs", in a Service world you will end up with the same elements as in the resource world. In both models you will also have the indirection challenge as you need to be able to alter the lightbulb state on a room level as well as individual bulb level. Simply put, beyond the technology approach (which isn't architecture) what is the difference between the lightbulb "service" and the lightbulb "rest"? To me they look identical. The SOA RM defines a service as something that provides access to capabilities, to me this view applies to what REST is trying to achieve at the implementation level too. > > Anne > > > > On 7/1/06, Steve Jones <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > On 01/07/06, Jan Algermissen <[EMAIL PROTECTED] > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Jun 30, 2006, at 11:59 PM, Steve Jones wrote: > > > > > > > REST, SOAP, EDA et al are not architectural styles > > > > > > > > > Maybe it is helpful to note that people from the REST camp use > > > "software architecture" and "software architectural style" as they > > > have been approached by Wolf & Perry[1] and after that by Roy > > > Fielding in his dissertation. This approach defines a software > > > architectural style to be a set of constraints on certain elements of > > > a software architecture. > > > > > > Yup... I just think we get caught up in the word architecture and > > don't like using the good old fashioned word of "design". > > > > > > > > > > AFAIK, "software architecture" is sometimes also used to mean > > > something like the technical infrastructure of a system (e.g. whether > > > you use J2EE or something else). Maybe this is some source of confusion? > > > > > > Anyhow, I'd encourage everyone to read the software architectural > > > discussion of Fielding's dissertation - it is an extremely sound > > > coverage and extension of what has bee laid out by Perry and Wolf. > > > Totally independent from the REST style (which is derived and defined > > > in the second part of the dissertation). > > > > > > ..... > > > > > > Steve, what is an "implementation style"? > > > > > > Cheers for the link, and for me an implementation style is pretty much > > what they define as software architecture, its about the specifics of > > the implementation, not about the overall vision and the direction of > > the system. Implementation style is one of those things that you > > decide in the design bits of the project when you are working out how > > to deliver the bugger. Architecture is about determining what the > > bugger is, its about the problem and understanding how to resolve and > > contain it, rather than about how to solve it. > > > > Trouble is that everything is now architecture and we don't like > > admitting to doing design. > > > > I tend to see architecture as the SOA bit, where you determine the > > services to be delivered, their principles, drivers and capabilities. > > These are the big picture elements, then either overall or for each of > > the services you have to work out the best way to do it. > > > > > > > > > > Jan > > > > > > [1] http://www.ece.utexas.edu/~perry/work/papers/swa-sen.pdf > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Check out the new improvements in Yahoo! Groups email. http://us.click.yahoo.com/6pRQfA/fOaOAA/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/
