Radovan
On 9/19/06,
Steve Jones <[EMAIL PROTECTED]> wrote:
On 19/09/06, Nick Gall <[EMAIL PROTECTED]> wrote:
>
>
> "...I've yet to see a single paper that explains how you model a
>
> business in terms of REST and a single paper that doesn't talk about
> the implementation details. When I see how people explain how to
> model the business of (for example) Vendor Managed Inventory in a
> "REST" way that actually makes sense from a business sense then I'll
> agree its architectural."
>
>
> I agree that REST designs too often get into implementation details too soon. On the other hand, I've yet to see a single paper that explains how you model a business in terms of SOA that isn't so sketchy and vague that it's next to useless as a model.
Ahh that is because you haven't read mine :) ( http://www.oasis-open.org/committees/download.php/15071/A%20methodology%20for%20Service%20Architectures%201%202%204%20-%20OASIS%20Contribution.pdf#search=%22OASIS%20Service%20architecture%20methodology%20pdf%22). Critisisms gladly received.
>
> If I had to choose between being too implementation detailed in my design vs. being too sketchy and vague, I'd always choose the former. I was prompted to post this reply by the recent BusinessWeek article on Apple's key designer Jonathan Ive. Here is a quote from the article:
>
But that is like choosing between two bad options, I'd be with you in that case, I loathe and detest "architectures" which purport to represent the business but have lots of "maybe" and "to be confirmed" statements in it. But the odds are you are going to have problems if its a choice between those two.
>
[snip the apple bit which is interesting...]
>
>
> A REST design that translates a business service into a set of URIs, XML formats, and HTTP operations is really like designing an iPod down to such details. But don't be fooled, such a REST design reveals NOTHING about the real IMPLEMENTATION of the service. Perhaps someday we'll have a more abstract, but still simple, way to work out REST designs. Until then, I see no harm in working in the medium of the Web to realize a business service design. It's the only medium that has transcended so many of traditional architectural tradeoffs: it is at once easy enough for non-programmers to express themselves and at the same time robust enough to be the basis for a global information space.
[SJ]I'm not convinced on either of those things yet around REST, trying to work out how REST would work using some of the industry standard schemas (like IATA) is a bit of a challenge. I'm not arguing that implementation design isn't a very very valuable thing (it is) or that technical ability doesn't matter (it does) but that the focus should be on defining what the service IS before you start getting into XML, HTTP and URIs, which are just focused on those services which will be accessible in that manner.
I completely agree that this is a fine way however to realise a business service design, but not I'd argue to define the actual business service itself and the business service architecture. My point is that SOA should focus on the architecture and business challenge, while REST, WS et al should be focusing on the design challenge. But no-one likes saying they do Service Oriented Design of IT, but I say SOD IT and be proud[/SJ]
> Any SOA that does not embrace the Web and is not immersed in the architecture of the web is doomed to failure.And here I have to disagree. I've done business service architectures on backend systems using legacy technologies, and they delivered what the business wanted. Believing that the web is a technology silver bullet, given its been around for quite a while, is a tad optimistic IMO, and also implies that SOA can't be applied to backend or human parts of the system, which it certainly can.>
> -- Nick
>
>
>
>
> On 9/15/06, Steve Jones <[EMAIL PROTECTED] > wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> > On 14/09/06, Nick Gall <[EMAIL PROTECTED] > wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> > > "REST/SOAP/CORBA/Flying Monkeys are all about implementation"
> > >
> > >
> > > Rubbish. This is where is the misunderstanding so often occurs. REST is no more a technology or an implementation than SOA is. Don't be fooled by some who equate REST with the random use of HTTP and XML. REST, like SOA, is an architectural style. Roy Fielding makes that quite clear in his thesis and his recent podcast with Jon Udel. If you don't agree, then I'd love to hear your reasons for thinking that REST is about implementation or technology.
> >
> >
> > Because I've yet to see a single paper that explains how you model a
> > business in terms of REST and a single paper that doesn't talk about
> > the implementation details. When I see how people explain how to
> > model the business of (for example) Vendor Managed Inventory in a
> > "REST" way that actually makes sense from a business sense then I'll
> > agree its architectural.
> >
> > NB. SOAP and WS aren't architectural styles either IMO.
> >
> > >
> > > Once people understand that REST is simply an additional set of ARCHITECTURAL constraints beyond those required by SOA, then they begin to see where REST ensures more flexibility than SOA sub-styles that impose different constraints.
> > >
> > >
> > > "I've seen lots of examples, some using WS and some in Plain
> > > old Java, some even using services from ERPs and mainframes that
> > > deliver this sort of flexibility"
> > >
> > >
> > > Perhaps they were using REST constraints and they didn't even know it. <grin> The REST architectural style can be realized on lots of technologies other than Web technologies.
> >
> >
> > No I wasn't.
> >
> >
> > >
> > > -- Nick
> > >
> > >
> > >
> > >
> > > On 9/14/06, Steve Jones < [EMAIL PROTECTED]> wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I have to say the statement
> > > >
> > > >
> > > > "in practice it is the only sub-style that has ever come close to
> > > > delivering on the promise of SOA: design for the changes in the
> > > > business services and processes."
> > > >
> > > >
> > > > Rubbish. I've seen lots of examples, some using WS and some in Plain
> > > > old Java, some even using services from ERPs and mainframes that
> > > > deliver this sort of flexibility, precisely because they don't view
> > > > SOA as being about a technical implementation style.
> > > >
> > > > I'd argue that we won't deliver any value out of these things until we
> > > > stop obsessing about technology details and start thinking about the
> > > > BUSINESS side of it first. REST isn't a silver bullet, its not even
> > > > close to a silver bullet.
> > > >
> > > > The real shame here, IMO, is that there are thousands of companies
> > > > already using WS successfully and delivering real value and
> > > > flexibility to their companies and partners, but they don't have a big
> > > > ra-ra crowd or a cool brand so we don't hear much about them. They
> > > > also tend not to shout about it too much as actually its pretty damned
> > > > simple.
> > > >
> > > > If SOA is about technology then lets go home, the only way to deliver
> > > > business flexibility is to model the business, THAT is where SOA comes
> > > > in. REST/SOAP/CORBA/Flying Monkeys are all about implementation, and
> > > > its that obsession with implementation that continues to ensure that
> > > > IT fails to deliver flexibile BUSINESS solutions.
> > > >
> > > >
> > > > On 14/09/06, Nick Gall < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "design for the changes in the business services and processes, not a design for current business requirements"
> > > > >
> > > > >
> > > > > Strongly agree that this should be the primary design goal for SOA.
> > > > >
> > > > >
> > > > > "Web Services and 'Web-style' are only optional communication models in SOA"
> > > > >
> > > > >
> > > > > Strongly disagree. This is one of the biggest and most pervasive misconceptions about the the WWW. The WWW was, is, and should be understood as an "application architecture", not a communication model. That's what TBL said from the beginning, and what Roy Fielding said in his PhD, and what RESTafarians have been saying since then, and what Tim Bray just said. Most SOAPers either don't understand this or consciously ignore it and misuse the WWW (specifically HTTP) as only a communication model.
> > > > >
> > > > > A recently published spec by Microsoft puts it quite clearly (see quote below). While in theory Web-style (which I call WOA--Web-Oriented Architecture) is only one possible architectural sub-style of SOA (sub-style in the same way that dutch colonial architecture is a sub-style of colonial architecture; it imposes additional constraints), in practice it is the only sub-style that has ever come close to delivering on the promise of SOA: design for the changes in the business services and processes. If any architectural style has shown an ability to enable new and changed business services and processes, it's the web architectural style. Client-Server didn't come close, MOM didn't come close, Distributed Objects (CORBA and DCOM) didn't come close, and WS-* (which overlays the web, but violates several WOA constraints) doesn't look like it's going to get as close as we hoped; unless it starts to adopt the Web/REST application architecture (WSAP is a step in the right direction).
> > > > >
> > > > > -- Nick
> > > > >
> > > > > WSAP Quote:
> > > > >
> > > > >
> > > > > The Web and REST
> > > > >
> > > > > The term "REST" was originated by Roy Fielding. It abstracts, and to a degree, formalizes the Web architecture. REST builds on the notion introduced by Tim Berners-Lee that a URI refers to a resource and all interactions with that resource happens by exchanging state. One can exemplify a resource as a person and a picture of that person as a particular representation. Representations can change over time and be expressed in a variety of data formats. For example, a representation of a person can be rendered as a picture, a textural description, an audio clip, etc. The only way to interact with resources is through the exchange of state representations. The separation of state and behavior of a resource is a key component in achieving loose coupling between communicating components.
> > > > >
> > > > > While many people think of REST as unique to HTTP, this is not the case. The principles of REST (and Web architecture in general) can be implemented in any number of ways but today HTTP is the only protocol that effectively allows one to think in terms of REST: It supports URIs and provide shared semantics for how to interact with resources.
> > > > > SOAP and REST: Apples and Oranges
> > > > >
> > > > > The SOAP protocol is at the core of the Web Services model. While SOAP started out as a way of serializing C# and Java style objects, it had by the time SOAP/1.0 was published evolved into a lightweight, semi-structured message structure focused on extensibility.
> > > > >
> > > > > Because SOAP is a protocol, it is often contrasted to HTTP and REST, but that is a misunderstanding. The focus of SOAP is to provide a distributed, structured extensibility model, whereas the purpose of REST is to provide an application model.
> > > > >
> > > > > The SOAP extensibility model is based on a set of rules for processing a SOAP message that enables a sender to indicate what a receiver must do in order to properly process that message. The extensibility model provided by SOAP is a direct superset of what HTTP provides and evolved from observing the many ways HTTP is being used.
> > > > >
> > > > > The main difference between HTTP and SOAP is that SOAP doesn't define an application model like HTTP and this is where we get back to REST. Because SOAP does not care about how it is being used, it can support any number of application models ranging from RPC to loosely coupled applications and indeed REST style applications.
> > > > >
> > > > >
> > > > >
> > > > > On 9/13/06, Michael Poulin < [EMAIL PROTECTED]> wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > There are too many topics in one message. Probably, this deserves several discussions.
> > > > > >
> > > > > > I believe, Web Services and "Web-style" are only optional communication models in SOA while the latter is an application architecture, which implements business services and business processes. While I defined business services and business processes in another message, let me outline that SOA IMPLEMENTS, not supports a few functions, of the business services and processes. The major differentiator of this implementation is design for the changes in the business services and processes, not a design for current business requirements.
> > > > > >
> > > > > > As you an see, I do not have "paragraphs and paragraphs prose". However, it is not for a programmer to understand, it is for an Architect to understand and split into simple tasks for the programmers. SOA is not about IT infrastructure and development governance, it is about business model finally implemented in IT.
> > > > > >
> > > > > > - Michael Poulin
> > > > > >
> > > > > >
> > > > > >
> > > > > > Gervas Douglas < gervas.douglas@ gmail.com> wrote:
> > > > > >
> > > > > >
> > > > > > <<What's your view of services oriented architecture, SOA?
> > > > > > Tim Bray:
> > > > > >
> > > > > > The term SOA, I don't really like to use it any more. It has, I think,
> > > > > > become damaged, weakened by over hype, over use, over promise, under
> > > > > > deliver. I can't explain what the difference is between SOA and Web
> > > > > > services and I'm not sure I've met anybody who actually can without
> > > > > > going into paragraphs and paragraphs prose. I want an explanation
> > > > > > that's meaningful in terms a programmer can understand, so a
> > > > > > programmer can go and build one of these things. So I'm actually
> > > > > > becoming actively unfriendly to the use of the term SOA. So I'm happy
> > > > > > to be quoted as saying that emperor has no clothes. If you are
> > > > > > confused about what SOA really means, it's because the world is.
> > > > > >
> > > > > > What needs to be done to make sense of it?
> > > > > > Bray: I think we really do need some new terminology. One term that
> > > > > > I've seen used a bit is "Web-style," software that is in the
> > > > > > Web-style. The Web has lots of lessons to teach. If you look at the
> > > > > > Web there are no APIs. All there are is messages. If you look at the
> > > > > > message exchange patterns, there's only one. I send you a message, you
> > > > > > send me a message, our conversation is over. It imposes some
> > > > > > difficulties, but it allows for fantastic scaling behavior. So I think
> > > > > > Web-style is a flag I would like to see more people start to wave
> > > > > > because I think it really means something.
> > > > > >
> > > > > > What about Web services?
> > > > > > Bray: The importance of Web services is being underestimated. It's
> > > > > > becoming plainly obvious that none of Java and .NET and LAMP [Linux
> > > > > > Apache, MySQL, PHP] are going to wipe each other out. We're going to
> > > > > > have all these things with us for the long haul. And yet, we need them
> > > > > > to interoperate with each other. Enterprises need these things to work
> > > > > > together. And I'm sorry they just have different APIs. That just the
> > > > > > way it is. So if we're going to get them to work together it's going
> > > > > > to be something along the lines of Web services that's going to make
> > > > > > that happen.
> > > > > >
> > > > > > Now, having said that. A lot of us are not sure that WS-* is the
> > > > > > future. It seems unreasonably big, unreasonably complex and few of the
> > > > > > core low-level elements of the stack seem ugly and awkward and
> > > > > > difficult. We observe that people are putting out lightweight
> > > > > > distributed applications using good old XML and HTTP and getting them
> > > > > > done in days and they work great. Other people are trying to bring
> > > > > > WS-* things online and spending a lot more and apparently not getting
> > > > > > as much.
> > > > > >
> > > > > > I don't think, we at Sun, are willing to place an unqualified bet on
> > > > > > WS-* as the future, which means there's a lot of interesting work that
> > > > > > needs to be done. Because whereas the ultra-lightweight, I've seen it
> > > > > > called POX for Plain Old XML or the architectural style called REST
> > > > > > [Representational State Transfer], this kind of stuff apparently works
> > > > > > great. It's being deployed by Amazon, by Google, by lots of people. On
> > > > > > the other hand there's not much developer tooling. So I think it's
> > > > > > fair to say that's a need that hasn't been met well enough by the
> > > > > > vendors. I think Sun, and our competitors too, should be doing a
> > > > > > better job of addressing it.
> > > > > >
> > > > > > Are there just too many XML and Web services standards?
> > > > > > Bray: It's clearly true that there are too many of them. I also have
> > > > > > an issue with the process. If you look at many of the successful
> > > > > > standards, they tend to be distillations of technology that already
> > > > > > existed. XML was a distillation of a previous technology called SGML.
> > > > > > Java was created a dozen years ago applying the lessons that had been
> > > > > > learned from many other object oriented languages. We had a lot of
> > > > > > experience with object oriented languages and Java distilled those
> > > > > > lessons. When you go and look at situations where people try to invent
> > > > > > a whole new technology and standardize it at the same time, it's, to
> > > > > > be charitable, a high-risk undertaking.>>
> > > > > >
> > > > > > You can read this in full at:
> > > > > >
> > > > > > < http://searchwebservices.techtarget.com/qna/0,289202,sid26_gci1189019,00.html?track=NL-110&ad=564807&asrc=EM_NLN_535422&uid=5532089 >
> > > > > >
> > > > > > Gervas
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ________________________________
> > > > Get your email and more, right on the new Yahoo.com
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > > > --
> > > >
> > > > > Nick Gall
> > > > > Phone: +1.781.608.5871
> > > > > AOL IM: Nicholas Gall
> > > > > Yahoo IM: nick_gall_1117
> > > > > MSN IM: (same as email)
> > > > > Google Talk: (same as email)
> > > > > Email: nick.gall AT-SIGN gmail DOT com
> > > > > Weblog: http://ironick.typepad.com/ironick/
> > > > > Furl: http://www.furl.net/members/ngall
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> > > --
> > >
> > > Nick Gall
> > > Phone: +1.781.608.5871
> > > AOL IM: Nicholas Gall
> > > Yahoo IM: nick_gall_1117
> > > MSN IM: (same as email)
> > > Google Talk: (same as email)
> > > Email: nick.gall AT-SIGN gmail DOT com
> > > Weblog: http://ironick.typepad.com/ironick/
> > > Furl: http://www.furl.net/members/ngall
> > >
> > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
> --
>
> Nick Gall
> Phone: +1.781.608.5871
> AOL IM: Nicholas Gall
> Yahoo IM: nick_gall_1117
> MSN IM: (same as email)
> Google Talk: (same as email)
> Email: nick.gall AT-SIGN gmail DOT com
> Weblog: http://ironick.typepad.com/ironick/
> Furl: http://www.furl.net/members/ngall
>
>
>
--
Radovan Janecek
http://radovanjanecek.net/blog __._,_.___![]()
SPONSORED LINKS
Computer software program Computer software spy Computer job Database software Discount computer software
Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
__,_._,___
Reply via email to
