Mark Baker wrote: > On Wed, Sep 21, 2005 at 05:22:02PM -0600, David Forslund wrote: > > How do you specify what this integration is in REST, so that it can be > > reused over and over again > > without having to have your code. > > My request is to do something like the equivalent of a workflow service > > using REST. Use any > > of the WfMC specifications in WS or IDL. Map them to to a > specification > > that can be automatically > > run in REST. I may be dense, but if I can take a machine > specification > > and generate the relevant > > code to run, then I could compare the various approaches better. I > > don't see how interoperability > > is supported without something like this. > > REST uses hyperlinks to drive an application. You're not "dense" if > you don't see that, of course, but I don't think any amount of > explanation on my part (past the basics, which I've described) will > help drive that point across nearly as well as just trying it out for > yourself. > > > > A client using that form could construct a URI; > > > > > > http://example.org/iuuiuiuiuiu?name="forslund"; > > > > > > .. and GET on that would give you your answer. > > > > This seem to be great, but where did this come from? What is the > > standard for doing this that everyone > > would know ahead of time? > > The above was inspired by my work on RDF Forms (linked to by Jan), > but one could use XForms - a W3C Rec - instead, ala; > > <xforms:model> > <xforms:instance> > <SoundsLikeNameQuery xmlns=""> > <name/> > </SoundsLikeNameQuery> > </xforms:instance> > <xforms:submission action="http://example.com/iuuiuiuiuiu"; > method="get"/> > </xforms:model>
Where would one "register" this interface and "discover" it and its "capabilities". I would think an interface would be independent of the URI to the resource, so shouldn't there be some abstraction for specifying the action location? This also doesn't address what happens on the server side, particularly if people use some other scheme to access this URI. Obviously it must have code to reject erroneous requests. It is this code that I don't have to worry about as the middleware normally shields a recipient from requests that don't make sense or are unauthorized. > > >The approach we have used has been around for > > 10 years and is quite stable. > > Who would own the term: "SoundsLikeNameQuery" above? What you have is > > seems to be exactly > > what is required to make a RPC-like call in http/REST. > > It's not RPC, it's a "service type", the difference being that the > former modifies the contract, while the latter does not. Note that the > semantics of the RESTful HTTP message are always "GET" not > "SoundsLikeNameQuery", as "SoundsLikeNameQuery" isn't even part of the > message. What do you mean by the "contract" in this context. I'm, of course, dealing with service type systems. If "SoundsLikeNameQuery" isn't part of the message, how is the server to know what methodology to invoke? "SoundsLikeNameQuery" would be an important part of what the server needs to know in order to process the request. Suppose it can't do a "SoundsLikeNameQuery" and doesn't know that the client is asking for this? What if the client is asking for a different type of query and it responds with a "SoundsLike" response. This seems like semantic ambiguity or confusion to me. > > Who "owns" that term would be either the service provider, or some > standards setting organization. > > >What about when > > the data that needs > > to be sent is in binary? I guess I convert it to ascii with base64, > but > > this all seems overly complex > > compared to using standard method calls remotely. > > That's either a transfer coding, in which case out of scope for a > forms language (the transfer protocol can negotiate it), or it's a new > media type. > > >In addition, in your > > above example there is a specific path (URI) present > > which keeps this from being a nice abstraction of the service that is > > being requested. There must be some other > > way to write what you have above because it would take hand editing > > everytime I deployed the service to a different location. > > Relative URIs should help with that, e.g; > > <xforms:submission action="iuuiuiuiuiu" method="get"/> > > (though the ability to use relative URIs in XForms is governed by > the language which encapsulates the form) This seems like a real limitation and potential lack of interoperability. > > > > > Certainly a registered API is one way to do this. Other > > > > ways must be substantially equivalent to this and save nothing > in terms > > > > of implementation or deployment, since code > > > > equivalent to the API must be embedded in the server. > > > > > > Respectfully, I don't think that's a very useful way to look at the > > > difference. If you looked at it in architectural terms, you'd be > > > able to evaluate the architectural properties lost and gained from the > > > adoption or rejection of known constraints, and evaluate the resulting > > > properties for suitability of deployment in the target environment > > > (e.g. the Internet). An typical Web services approach, for example, > > > rejects API constraints, and therefore sacrifices - compared to an > > > equivalent Web based approach - significant simplicity, > scalability, and > > > reliability. > > > > I may not be following your point here. We have deployed non-web > > applications on the internet for almost 10 years > > without any problems. Interoperability has worked well. The > > middleware deals with most of the issues you indicate > > without my having to deal with it other than make my application do > what > > it has contracted to do. If you have some > > people writing client code (in whatever language, Java, XML, HTML, ...) > > it is architecturally very helpful to have an > > interface to code to so that a server and client can work correctly > even > > though they are developed independently by different > > people and organizations. > > I'm not saying that one can't build a solution over the Internet without > interface constraints. I'm just saying that it won't scale to > Internet-scale as systems like the Web, email, instant messaging, etc.. > have. If you don't need your system to scale like that, great. But > then I thought the SOA vision was supposed to be about loosely coupled, > ad-hoc, inter-business application integration over the Internet, which > seems very Internet-scale to me. Back to an old point, but DNS and LDAP are certainly internet scale and involve interface constraints. I see nothing to prevent scaling to Internet-scale with interface constraints. The question is what is the interface constraint one is going to follow. Email also has a lot of interface constraints. Only certain types of requests/responses are understood by email. Same for IM. The question isn't, is there an interface constraint, just what is it and who agrees to it. > > >This is true regardless of what transport > > mechanisms are being used. The WSDL spec attempts > > to do this but not in a very portable or interoperable manner. > > Something equivalent to WSDL is needed in REST, I submit. Your > > above form example seems to me to be this equivalent. > > Yes, XForms is such a "RESTful description language". In fact, I've > made a late-breaking-news submission to XML 2005 on that exact subject. > I haven't heard if it's accepted yet, but I expect it might pique > MikeC's interest. 8-) Great. Without some kind of "description language" that is discoverable, I believe that Internet scaling would be difficult even with "REST". This is because to talk to each server may require a different "interface". This becomes a nightmare to manage. This is no problem if either you are providing all the client/server code (XML, HTML, etc), or if you "own" the entire application space. But for people who have never communicated to work together they need to be able to discover and understand the semantics of the interaction. This either requires an interface or a "virtual interface" which passes the equivalent of interface semantics through the communication layer. This is how I see it anyway, Dave > > Cheers, > > Mark. > -- > Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca > Coactus; Web-inspired integration strategies http://www.coactus.com > > > ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/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/
