Mark Baker wrote: > David, > > On Mon, Sep 26, 2005 at 08:22:28AM -0600, David Forslund wrote: > > > > > 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'm not sure what you mean by "register" and "capabilities", but a > service provider would publish that form - perhaps embedded within > some other XML content - at some URI. Then the client can either be > handed that URI by the server during a part of the application that > preceded the query step (if any), or by some third party (e.g. search > engine). The client could also be hard-coded with that URI, but that's > a less interesting case, of course.
I mean for some sort of standard this form or "interface" should be published so it can be used again and so that one can understand what it does and what the terms mean. The individual server could provide this but then every server may be different, so the client has to "learn" the capabilities of each server which may choose to use a different form or terminology. I really think I'm getting at the issue not of a single user using an interface but two computer systems that want to talk together to create a service which may be an aggregate of the two (true distributed computing). If the forms and terminology vary from server to server, then this is difficult to accomplish without doing something for each server/client relationship. If they use the same forms and terminology (through some standards effort), then they can rely on the "service" without having learn each one individually. > > >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. > > Sorry, I didn't understand that. The server has to understand how to deal with the particular request. Since it is just a URI, it could get any old type of message, which may have nothing to do with its capabilities. The server must do its own "filtering" and rejection. This is something that distributed computing environments normally take care of transparently. Perhpas this helps. > > > > >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. > > There's no ambiguity, because the service only does this *one thing*. > If the client didn't want a SoundsLikeName query done, it shouldn't have > submitted data to that service. If the client thought that "SoundsLikeName" query mean "BuySomeApples" because they didn't understand English, then you would have a problem. I think you are assuming that a server always gives the client an "interface" it can understand and that the client understands what the server means by that. This is the ambiguity that is normally handled in some of the standards. For example, ebXML has mechanisms for expressing things and people in a domain (such as healthcare) may control the terminology so the requests make sense. This what I refer to as a "contract". > > It's just document-in, document-out. If you need to add new > functionality, say a different kind of search that also takes a last > name as input, you need a new service with a new URI. These really aren't documents except in the most general sense. A response can be thought of as a message, for example with some context. How is the end user supposed to interpret the response? What are the semantics and terms being used? Who defines the semantics and terms? If only the server, then the user has little chance of understanding them. For example, if I make a request and expect html in response and you give me something other than well-formed html (according to a standard), then I won't know what to do with the data. Html is just a simple example of the problem since it doesn't deal with semantic meaning, only presentation, which the client may care less about. If it is in XML, who controls the semantic meaning of the returned data (in a DTD or Schema)? If you give me your own person schema, I still may not know what to do with the data. This mixture of the concepts of human-readable XML that you might know what to do with and a computer receiving some XML and trying to figure out what it means creates semantic ambiguity as to what a service is "supposed" to do. > > > > >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. > > It's a scalability problem for XForms, yes. But it's not an issue with > the forms approach in general. RDF Forms doesn't suffer from it, for > example. Perhaps. I can't tell. If there are embedded URI's in the forms, they aren't very portable. > > > > > 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. > > You misunderstand, because I agree with you. I'm saying interface > constraints are *required* for Internet scale systems. I guess I do not understand you. You seem to want a "single" interface when the examples are the exact opposite of this (DNS, LDAP, Email. IM, Web all have different "interfaces", but still support loose coupling). > > Implicitly, I'm also saying that SOA rejects interface constraints ... > although those promoting "document oriented" SOA are unknowingly > adopting them (for services, not for clients). Why do you say "SOA rejects interface constraints"? Says who? I don't see how it can and be a service at all. I view services are things that can be "plugged" together to accomplish a larger task. Without an interface defining the semantics of the interaction by whatever means, I don't see how one can have a SOA. I may have a broader view of a SOA than you do, since the concept has been around for decades and people have been building Internet scale apps long before the web became popular (again: DNS, LDAP, Email, IM ...) > > > > 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". > > REST includes a constraint called "hypermedia as the engine of > application state" which (assuming its adopted), in practice requires > that any architecture supporting non-trivial applications include a > forms language. This is a help, as this will take the role of "interfaces" in other approaches. > > FWIW, I personally try and avoid calling forms languages "description > languages", because it describes different things than, say, WSDL or > IDL describes. They may be different, but they must be equivalent, otherwise one can have distributed systems working together. My view of WSDL is that it is an abomination as it mixes all kinds of issues in a single descriptor. IDL is ok, but also has many well known drawbacks associated mostly with its requirement to map to almost any language. But it does allow one to express the proper constraints between a server and its clients and is fully discoverable. With the standardization of IDL in certain domains, it becomes possible to build heterogeneous services which are far more than the sum of the parts. For example, federated systems can be built in this way. Thanks for the discussion, 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/
