Ash, See comments in line ...
On 6/3/07, ash galal <[EMAIL PROTECTED]> wrote: > > Anil > B2C interactions do not need to have preplanned message schemas. For example, > a browser can pull down and display any HTML or XML page, and a human > consumer can understand it. > By contrast, in B2B interaction, the consuming application must understand > the data received from the provider application by understanding it at > development time, or being able to machine-read it at runtime. > > This is why B2B interactions require the exchange of metadata (for example, > using XSD with either system and, in the case of WS-*, also using WSDL for > service definition). REST does not preclude the exchange of metadata (e.g., XSDs, WSDLs, WADLs, WS-CDLs, etc). > Secondly, B2C processes can be ad hoc because a user can make the navigation > decisions at runtime by manually clicking through a sequence of URIs visibly > displayed on the screen. > Users rely on a Web page's human-readable contextual information (serving as > metadata) to understand a resident URI's value in further executing on the ad > hoc process. > By contrast, B2B processes are preplanned by building flow-logic options into > the application or a rule-driven orchestration service (for example, using > BPEL). Metadata must be preplanned or machine readable to execute the > preplanned process. REST uses hypermedia as the engine of state -- a resource representation should reference related resources via URIs. But this model does not presume that it requires human-readable contextual information to interpret the URIs. Assuming that you have metadata about the representation (e.g., a schema), then you know where to find the URIs that reference the related resources.I don't see a reason why you couldn't orchestrate RESTful services. (BPEL might be problematic, because BPEL presupposes SOAP/WSDL, but that's an inappropriate limitation of BPEL, which should make you question whether it's appropriate to invest in BPEL.) > WS-* is meant to implement repeatable processes, where a single entry from a > human user can trigger a complex sequence of many different services linked > together and running to completion without requiring the user to interpret > intermediate data results or specify what steps to take next. > By contrast, B2C implements a flat model of navigation where links to > additional resources/service providers are not automatically perused, but > rather are sent back to the user for a manual decision on where to go next. You're talking about web applications, not RESTful services. REST has no such limitations. I've been talking about applying the REST architectural style (i.e., its constraints) to service development. > For unstructured B2C activities — such as those typically found in read-only > searches of large, often-changing infobases — this B2C (WOA) style of > navigation is well-suited. However, the standard WOA approach does not work > well for executing long-running, complex, structured B2B transactions where > multiple machine processing mediators ensure proper process execution across > organizational boundaries and disparate physical environments. This includes > transactions that require close control and state management (for example, > updating financial data where integrity must be maintained). To operate under > these requirements, WOA must be extended to add the capabilities that are > inherent in WS-*. I don't think it's appropriate to equate WOA and REST. WOA applications are designed to be viewed via a browser. I don't think the same is true of RESTful apps (although it's a good idea to provide a little XHTML wrapping for your resources.) > In addition to QoS that is needed by much business, B2C (WOA, or REST) is > limited in such requirements. (Supply chain management system is an example) I see no reason why you can't enforce QoS properties with REST. (Bare in mind that REST != POX/HTTP) > > Thank you > Ash Galal > > > Anil John <[EMAIL PROTECTED]> wrote: > > > > Ash, > > Could you clarify the aspects of a B2B interaction that make it different > from a B2C or a interaction that happens within an Enteprise etc. > > Regards, > > - Anil > > > ________________________________ > From: [email protected] [mailto:[EMAIL > PROTECTED] On Behalf Of ash galal > Sent: Friday, June 01, 2007 2:36 PM > To: [email protected] > Subject: Re: [service-orientated-architecture] Anne on REST (Time for Spring > WS v. REST Campaign to Open) > > > > > This is a great comment. > My question: Does REST fits in all kinds of interactions, specifically B2B > interaction? > If the answer is "Yes" then please point us to an example of such > implementations. > What I found out that most of REST implementation is just POX/HTTP and > violate the REST principles. (Amzon is an example) > If the answer is "No" then such articles about REST might imply to the reader > that REST fits all kind of interactions. Which, in my opinion, it does not > fit B2B. > Thank you > Ash Galal > Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > Let me reiterate. REST is about the way you design/implement a > capability (i.e., a service). If you abide by the REST constraints, > your service will exhibit a number of desirable characteristics, such > as simplicity, scalability, performance, reliability, evolvability, > maintainability, visibility, and portability. If you expose your > RESTful resources using pervasive protocols, such as HTTP, then they > are also extremely accessible. > > Note that all of these desirable characteristics support > non-functional requirements. Business people don't necessarily care > about non-functional requirements, but they still provide value to the > business. > > I also want to point out the REST does not preclude the use of SOAP. > You lose some of the power of the deployed HTTP infrastructure is you > use SOAP headers rather than HTTP headers to convey infrastructure > information, but nonetheless, SOAP over HTTP can be RESTful. (The > debate between REST and WS-* is like comparing apples and oranges.) > > Anne > > On 6/1/07, Steve Jones wrote: > > Out of interest what is the view around Security, Reliability and the > > other important "enterprise" qualities that don't current exist in the > > REST world? > > > > I completely agree that vendors will be starting to have "REST" > > tooling in their IDEs (this year I'd say) , mainly because it isn't > > hard and adds yet another "tick" into the boxes and keeps certain > > sections of the developer community happy. My question though is to > > what are the actual BUSINESS benefits of doing REST v WS (i.e. in > > having two tracks) and I've yet to see a single article looking at > > whether REST (or WS) actually progress us towards business goals. > > > > Its really not suprising that the vendors want to do this as what is > > the difficulty for them? None whatsoever, and indeed its gives them > > the opportunity to resell the old stuff with a slightly different > > interface. How does this progress us towards the business goals? Not > > at all as it is just a revision at the current level of operation, in > > fact its BELOW that current level as it doesn't include the security, > > reliability and addressing elements that WS-* has already addressed. > > > > In my simple world we are still arguing about the moving parts of IT > > and not really progressing the business agenda. > > > > On 01/06/07, Anne Thomas Manes wrote: > > > You know, it's interesting. Pete Lacey, the most vocal pro-REST > > > advocate on my team thought that my presentation was much too > > > conservative, and I made it sound like REST was much too challenging > > > for most organizations to tackle at this point. (True assessment.) He > > > wants me to advise our clients to immediately desist from using WS-* > > > except when requirements specifically call for it. (Not gonna happen > > > anytime soon.) But what was reported in the press and has been bandied > > > about in the blogosphere is that I predicted that REST would trounce > > > WS-*. (False assessment.) > > > > > > What I did predict is that major vendors would start to deliver within > > > the next 2-3 years frameworks in their tools and platforms that > > > assisted developers in creating RESTful services, and at that point > > > REST would become more palatable for the "early adopter" enterprise > > > developer. It will take about 5 years for REST to cross the chasm and > > > be adopted by the "early majority". But that doesn't mean that I'm > > > predicting the imminent demise of WS-*. I agree with Todd that there's > > > room for both noun-oriented systems and verb-oriented systems. > > > > > > I disagree that REST resources can't be "services", though. From my > > > perspective, SOA encompasses many different types of services, > > > including method-oriented, resource-oriented, event-driven, > > > workflow-driven, and goal-driven services. Just as I rejected the > > > whole concept of "SOA 2.0" being a new combination of SOA and EDA, I > > > also reject the idea that ROA is somehow incompatible with SOA. (No > > > doubt now someone is going to start promoting "SOA 3.0" as the evolved > > > SOA that includes SOA + EDA + ROA. Please NO! The original concepts of > > > SOA have always encompassed all types of services.) > > > > > > REST can be service oriented. A RESTful resource still exposes an > > > interface, but the interface is uniform. REST adds constraints to SOA, > > > and in the process imparts a number of desirable properties to the > > > services that conform to the constraints. REST is an architectural > > > style for implementing services. SOA is at a much higher level -- the > > > fact that you're exposing functionality as services in the first > > > place. > > > > > > Today WS-* hits a sweet spot in enterprise application development, > > > but that's primarily because the vendors provide tools and frameworks > > > that enable web service development. For REST to "win" in the > > > enterprise, the vendors need to provide comparable frameworks that > > > enable RESTful development. That will probably require some different > > > modeling tools that help designers model their resources (rather than > > > their methods). > > > > > > And of course I might be blowing smoke here. Anyone that spends the > > > time to figure out AOP usually comes away thinking that this is > > > awesome stuff, and they don't understand why it hasn't swept the > > > development world. But it hasn't, and it probably never will. The same > > > may be true of REST. Anyone that spends the time to really understand > > > this architectural style usually becomes a convert. But it's possible > > > that the learning curve is just too steep, and the vendors won't be > > > able to supply frameworks that effectively guide developers into > > > designing RESTful systems. But it seems clear that they're going to > > > try. > > > > > > From my perspective non-RESTful POX over HTTP is a poor substitute for > > > SOAP. If you're not going to do REST, then it's better to stick with > > > SOAP. > > > > > > In response to Stuart's remark: > > > > > > > > WHY, for example, I may want to have a URI > > > > > for everything interesting instead of just embedding an arbitrary > > > > > context-specific identifier in my XML document. > > > > > > To be RESTful, the XML document would include the URI of the resource > > > of interest. By naming the resource and using hypermedia to reference > > > it, you get the benefits of the Web. (Hypermedia as the engine of > > > state.) It's an incredibly powerful feature. > > > > > > Anne > > > > > > On 5/31/07, Todd Biske wrote: > > > > I certainly agree that SOA needs to be a balance between producer and > > > > consumer interests. Unless you're a monopoly, or at least an 800- > > > > pound gorilla, success with a producer-focused view will be difficult. > > > > > > > > I can also see your point that the REST debate offers interesting > > > > lessons on being consumer-oriented, however, I think that's more a > > > > statement on the potential complexity of WS-* than it is about the > > > > potential benefits of REST. I suspect that the alternate approach in > > > > those situations are more likely to be POX/HTTP than REST. As Anne > > > > points out in her Burton Group APS blog, having every single resource > > > > available as a unique URI is something that people are still getting > > > > their arms around. While each resource is accessed via a uniform > > > > interface, navigating the interactions across those resources in code > > > > could get very complicated. This is where it becomes ROA, not SOA. > > > > If the developers try to stick with an SOA approach, there's a risk > > > > that it all just gets buried in POST operations which then begins to > > > > look at lot like how WS-* works, minus WSDL and everything that goes > > > > into SOAP headers. > > > > > > > > Like many others on the group, I think there are places for both REST > > > > and WS-*. WS-* certainly has a sweet spot in many of the enterprise > > > > integration problems, and you can argue that REST has the most > > > > potential on the Web. Because the Web is a bit more associated with > > > > loose, mashup type approaches that aren't as prominent in the > > > > enterprise, it has a lot more to prove to gain adoption in the > > > > enterprise. That will happen, it's just a matter of how long. It > > > > won't be done at the detriment of WS-*, however, but rather as > > > > complimentary to WS-*. There will be pockets where WS-* is being > > > > used today where REST may be more appropriate, others where REST > > > > enables new solutions that didn't previously exist (probably in the > > > > presentation space), and then others where WS-* will thrive and you > > > > won't see any REST. For example, I'm pretty sure that Anne and > > > > others have mentioned management technologies as a potential fit for > > > > REST, and I agree with her. When you see that one of the WS-* specs > > > > in the management space is WS-Resource, it would seem to make sense > > > > that this could be a good fit for REST. :) > > > > > > > > -tb > > > > > > > > > > > > On May 31, 2007, at 11:21 AM, Stuart Charlton wrote: > > > > > > > > > I find if people look at SOA as a producer-focused view, i.e. "I have > > > > > these capabilities to offer in the granularity that is convenient for > > > > > me & aligned to my business", then certainly it's very different from > > > > > REST. > > > > > > > > > > Some alternatively view SOA as a twin-track analysis (a balance > > > > > between > > > > > producer and consumer interests), which an approach that some analysts > > > > > like CBDI promote. This approaches values synergy and serendipity > > > > > across producers & consumers over alignment. There, I think REST > > > > > offers many interesting lessons on the extent that one can > > > > > "consumer-orient" one's services: the impact of global naming, > > > > > interface generality, etc. > > > > > > > > > > As for the POX/HTTP v. REST confusion, I tend to look at the tools as > > > > > the culprit. There aren't really good agent-programming environments > > > > > that concretely highlight WHY, for example, I may want to have a URI > > > > > for everything interesting instead of just embedding an arbitrary > > > > > context-specific identifier in my XML document. > > > > > > > > > > Cheers > > > > > Stu > > > > > > > > > > > > > > > --- Todd Biske wrote: > > > > > > > > > >> One point that Anne made which still doesn't get a lot of press is > > > > >> the difference between Resource Oriented Architecture and Service > > > > >> Oriented Architecture. In a companion article, it was called out > > > > >> that REST is about the nouns, where SOA is about the verbs. This is > > > > >> > > > > >> part that I think needs some honest debate. Is a resource oriented > > > > >> view of the world going to be better than a service oriented view? > > > > >> > > > > >> Many people keep associating REST with SOA, but I think that's an > > > > >> inaccurate portrayal. The people I've spoken with have been doing > > > > >> POX over HTTP, which is not REST, and I'd argue that there are some > > > > >> very big differences. > > > > >> > > > > >> -tb > > > > >> > > > > >> On May 30, 2007, at 1:34 PM, ash galal wrote: > > > > >> > > > > >>> This is a very good article, but the problem with REST in the > > > > >>> machine-to-machine interactions. Till now, I did not see anything > > > > >>> about such interactions in any REST articles, seminars, or books. > > > > >>> REST is very good concept for B2C but I couldn't find any > > > > >>> justifications for B2B. > > > > >>> If someone have such justifications or examples about B2B in REST, > > > > >> > > > > >>> please publish it here. > > > > >>> Thank you > > > > >>> Ashraf Galal > > > > >>> > > > > >>> > > > > >>> > > > > >>> Gervas Douglas wrote: > > > > >>> I have a vague feeling that the subject of REST has arisen before > > > > >> in > > > > >>> this Group..... > > > > >>> > > > > >>> <> > > >>> architecture (SOA) projects, you probably are not doing > > > > >>> representational state transfer (REST) now, but within the next > > > > >> five > > > > >>> years you probably will be. > > > > >>> > > > > >>> That is how Burton Group Inc. analysts answered their own > > > > >> rhetorical > > > > >>> question – REST: Is it the next big thing? – with a resounding yes > > > > >> at > > > > >>> a Web conference on Tuesday. Repeating the mantra "The Web is REST. > > > > >>> REST is the Web," Anne Thomas Manes, vice president and research > > > > >>> director at Burton, said the only thing new about REST is that it > > > > >> is > > > > >>> starting to catch on with SOA tool vendors and the open source > > > > >>> community as well as architects and developers. > > > > >>> > > > > >>> "REST is not new because REST is in fact the Web," she said. "The > > > > >> Web > > > > >>> has been around for 15 years, but very few people have used it for > > > > >>> service-oriented systems. Mostly REST is being used for visual > > > > >>> applications, browser-based applications." > > > > >>> > > > > >>> That is about to change. Looking to the future, Manes listed time > > > > >>> frames Burton predicts for REST adoption now and in the next three, > > > > >>> five and 10 years. > > > > >>> > > > > >>> "Today, it is only innovators that are really working with REST," > > > > >> she > > > > >>> said. "In three years, we should see the early adopters start to > > > > >> play > > > > >>> with REST. It will probably be five years before it is adopted by > > > > >> the > > > > >>> early majority. We anticipate that the late majority will probably > > > > >> not > > > > >>> pick up REST for at least another 10 years." > > > > >>> > > > > >>> What will drive REST adoption eventually is that it brings > > > > >> structure > > > > >>> in the form of "constraints" to the sometimes chaotic world of Web > > > > >>> services, which includes those pesky rogue services, according to > > > > >>> Burton. This will provide a level of maturity for SOA development. > > > > >>> > > > > >>> Peter Lacey, senior consultant at Burton, played devil's advocate > > > > >> on > > > > >>> the Web conference, arguing the current state of Web services > > > > >>> standards are inadequate and hamper SOA development, which needs > > > > >> the > > > > >>> constraints REST development will bring. Manes did not agree that > > > > >> the > > > > >>> state of Web services standards is hopeless, but she did advocate > > > > >> the > > > > >>> transition to REST for SOA. > > > > >>> > > > > >>> So what does this mean to IT departments in general, and enterprise > > > > >>> architects and developers in particular? Manes said where they end > > > > >> up > > > > >>> on the adoption curve depends on the skills of the architects and > > > > >>> developers and their willingness to think outside the box of > > > > >>> object-oriented programming. > > > > >>> > > > > >>> She explained that the basic concept of REST, which starts with > > > > >>> sending out GET commands sent via HTTP to URIs to retrieve data is > > > > >>> simple enough. But she noted that even long-time REST advocates > > > > >> admit > > > > >>> having trouble thinking of applications in terms of REST. > > > > >>> > > > > >>> Borrowing a verb from Robert A. Heinlein's fictional Martian > > > > >> language > > > > >>> in the 1961 novel "Stranger in a Strange Land," she said, "The > > > > >> basic > > > > >>> concepts are easy, but truly groking REST takes time." > > > > >>> > > > > >>> To illustrate the difference between an object-oriented approach > > > > >> and > > > > >>> REST, she used the example of writing a program to turn a > > > > >> building's > > > > >>> lights on and off, keeping in mind that in REST the power is in > > > > >>> sending a command to a URI. > > > > >>> > > > > >>> "A REST application to turn on and off the lights in your building > > > > >>> will require you to design a URI for every light bulb and then you > > > > >>> send it on/off messages," she explained. "It's not like I have a > > > > >>> single service that manages all my light bulbs. It's a very > > > > >> different > > > > >>> approach to designing a system. And it's going to be really hard > > > > >> for > > > > >>> developers to get their hands around it." > > > > >>> > > > > >>> Frameworks and tools for designing and building such REST > > > > >> applications > > > > >>> are coming from major vendors, especially IBM and Microsoft, which > > > > >> are > > > > >>> making major investments in the technology, she said. It is also > > > > >>> coming from the open source community. The new version 2.0 of Ruby > > > > >> on > > > > >>> Rails "will make it easier to do REST Web services," Manes said. A > > > > >>> major vendor commitment was confirmed this past week by Gerry > > > > >> Cuomo, > > > > >>> IBM Fellow and WebSphere CTO, who said in an interview at IBM's > > > > >> Impact > > > > >>> 2007 conference in Orlando, that Big Blue also sees REST as the > > > > >> next > > > > >>> big thing. > > > > >>> > > > > >>> However, the problem for early adopters is that most of the tools > > > > >>> developers will use for future REST development are still on the > > > > >>> drawing boards, and current tooling is not ready for REST, Manes > > > > >> said. > > > > >>> "Web services toolkits that say they do REST don't always [do it as > > > > >>> advertised]," she said. "They do POX (plain old XML)." > > > > >>> > > > > >>> But architects and developers will not have long to wait before > > > > >> REST > > > > >>> is "baked into frameworks," she said. "You're going to see some > > > > >> very > > > > >>> interesting frameworks come down the line in the not too distant > > > > >>> future," she predicted. > > > > >>> > > > > >>> In the next three years, an IT organization's willingness to be > > > > >>> patient with early versions of REST tools and to make the mind-leap > > > > >>> from object-oriented programming will determine where they land on > > > > >> the > > > > >>> adoption curve, Manes said. > > > > >>> > > > > >>> "The first thing you have to figure out is whether or not you're > > > > >> ready > > > > >>> for REST," she told her audience. "What's your developer skill set? > > > > >>> Are they going to be comfortable working with XML? Are they going > > > > >> to > > > > >>> be comfortable working with raw HTTP? Are they comfortable working > > > > >>> with open source projects, experimental frameworks or incubation > > > > >>> projects? Are they open to letting go of their object-oriented > > > > >>> mindset? Are they willing to relinquish the productivity frameworks > > > > >>> that are inherent in the current vendor tooling and start working > > > > >> in a > > > > >>> more raw framework environment?" > > > > >>> > > > > >>> Any architect or IT manager answering yes to all of the above is a > > > > >>> REST innovator in Manes book. > > > > >>> > > > > >>> "If you're ready for REST I suggest you jump on board right away > > > > >> and > > > > >>> get ahead of the curve," she said. "You'll have to train your > > > > >>> developers in REST principles. You'll probably want to adopt one of > > > > >>> the new frameworks or help build one yourself to help your > > > > >> developers > > > > >>> implement RESTful applications. You definitely need to provide > > > > >>> guidance to your people. What you want to do is work to the point > > > > >>> where REST becomes the default for all your distributed > > > > >> applications." > > > > >>> > > > > >>> Those who are not ready to take the leap into REST need not be too > > > > >>> concerned, she said, stressing that the advent of REST as the > > > > >>> programming model for SOA is a matter of "when, not if.". > > > > >>> > > > > >>> "If you're not ready for REST, if your organization is not ready to > > > > >>> jump into the innovator stage that's okay," she reassured her > > > > >>> audience. "You're not going to get hurt. It's perfectly reasonable > > > > >> to > > > > >>> wait two to three years for the frameworks to mature to the point > > > > >>> where they are actually going to help you with this process. For > > > > >> the > > > > >>> time being, you probably should continue to use SOAP and WS-* to > > > > >> build > > > > >>> your distributed services." > > > > >> > > > > > === message truncated === > > > > > > > > > > > > > > > > > > > > > > > > > ______________________________________________________________________ > > > > > ______________ > > > > > Fussy? Opinionated? Impossible to please? Perfect. Join Yahoo!'s > > > > > user panel and lay it on us. http://surveylink.yahoo.com/gmrs/ > > === message truncated === > > > > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> 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/
