- From: Shi, Xuan <xshi@GEO.WVU.edu>
- Date: Thu, 16 Mar 2006 12:18:39 -0500
- To: "'Kunal Verma '" <verma@cs.uga.edu>, "'public-sws-ig@w3.org '" <public-sws-ig@w3.org>
- Cc: "Shi, Xuan" <xshi@GEO.WVU.edu>
Kunal, Thanks very much for your kind information. I know it may be a long story to describe the whole process about OSRR but I'd like to explain it and why it is much easier and simpler for use. First, let's see WSDL/SOAP. WSDL is the product of Object Oriented Programming thus it contains the abstract interfaces that we designed in the program. When we deploy the service, computers on the requester side will automatically generate SOAP message through the process of serialization. When computers on the provider side receives the SOAP message, it will deserialize the SOAP message into proprietary programming language to process the request, and then send the response back to the request via the serialzation/deserialization process. Given the following examples as you know, http://www.arcwebservices.com/services/v2006/AddressFinder.wsdl http://arcweb.esri.com/services/v2/AddressFinder.wsdl those complex types are just the corresponding parts in OOP. I have detailed explanation on how to derive the x,y coordinates from OOP in the article http://www-128.ibm.com/developerworks/library/ws-semantic/ once you get a LocationInfo object in OOP and complexType in WSDL. However, OSRR gets rid of ALL such kind of complexType in the service request and response document. So your comments is not correct as I do not capture the same information within a WSDL document, but rather, only those information relevant to the service request and response. In this case, when you tell me your address, I will send you back the longitude and latitude of your address as well as the information about the datum of the survey to locate your address. However, in WSDL or OOP, before you get the longitude and latitude of your address, you may wish to check if it is true that you at least have to go through more than a dozen varied types or complexTypes in WSDL or corresponding objects in OOP once you invoke the service and get back a locationInfo object in version 2 or GeocodeInfo object in version 2006. For now, can you see the value of OSRR? In OSRR, I just have one function interface for ALL operations that can be identified in WSDL. As you see, I use the same service (WSDL) URL and the same function interface to invoke different functions and services (geocoding or data conversion). How I process the request is based on the request XML document sent to me. As for geocoding service, you just need to type such a request document and you will get the answer explicitly without worrying about how to deal with more than a dozen types and complexTypes in WSDL and further the same corresponding objects in OOP-actually you do not need to write a single code. By WSDL approach, you have to figure out the relationship among those complex types, operations, etc. and you have to write a program to consume the service. In OSRR, you can ignore everything but just "compose" a service request document and invoke the service in either SOAP or REST approach. So if you agree that OSRR is more easier, simpler, understandable to ALL users, then you can see the value of it. One key issue here is that, I just focus on the messages within SOAP that are relevant to the *meaning* of the service. I ONLY pick up such relevant message as the base to compose a request and response document. Finally, I can get rid of WSDL/SOAP and send such message directly over HTTP-that's the core for OSRR. Best wishes, Xuan -----Original Message----- From: Kunal Verma To: public-sws-ig@w3.org Cc: xshi@GEO.WVU.edu Sent: 3/16/06 11:26 AM Subject: Re: Semantics of WSDL vs. semantics of service Xuan, I read your paper and saw the WSDL files posted in your message. I was not able to understand your point with respect to semantics or ease of use. Others have already replied about your notion of semantics, so this message pertains to your claim that your approach is easier to use. See comments inline. > <<GeocodingConversionServiceDescription.xml>> > Carine, Bijan, colleagues, > > I read those recent messages under this thread, and want to reply to all of > them in this email. I hope we can discuss relevant issues rationally. > > Fact 1: many service providers provide the same kind of service in different > ways. Address geocoding is a typical example. All service providers share > the same service semantics: if the requester sends an address to provider, > then provider will return latitude and longitude of the input address back > to requester. > > Fact 2: requesters don't care about how provider process their request but > just want to get an answer. > > Fact 3: different service providers can create the same service in different > ways, either by SOAP/WSDL or REST, with different business logics. For > example, ESRI, geocoder.us, google maps, etc. > > Based on such facts, can we draw conclusion that service semantics are > neutral and independent from the service development framework and process? > > By targeting at the address geocoding Web services which can be identified > in the WSDL documents listed below, > > http://www.arcwebservices.com/services/v2006/AddressFinder.wsdl > http://arcweb.esri.com/services/v2/AddressFinder.wsdl > > I wonder if Bijan can tell us which elements in these WSDL documents are > worthy to have semantic annotations or pointers (internal or external) and > which ones are not? Supposed, as Bijan said, we can create a rich service > description document with detailed content about the service, then why do we > need to associate such rich semantic description document with WSDL? We can > invoke the service directly over HTTP based on such rich service > description. > > It seems Bijan does not believe that I can use the same service request to > invoke either a SOAP/WSDL service or a REST service. Please forgive me if I > need to repeat something that had been repeated before. > > Also Carine has a concern in her reply message > http://lists.w3.org/Archives/Public/public-sws-ig/2006Mar/0048.html > > All such concerns were covered in the paper "Rebuilding the Semantic Web > Service Architecture" in which the so-called OSRR approach was originally > proposed, discussed and demonstrated. This paper can be accessed at: > http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-140/paper1 .pdf > > The five building blocks can answer all Carine's questions. Attached is a > service description document for demonstration and discussion. In this > document, it contains two different service domains, one is geocoding > service, the other is data conversion service. If you read the five building > blocks for each service, then you can understand how to deploy the service > since everything is self-describing. It seems to me that you capture exactly the same information in your service description as a WSDL file. You can probably write code or XSLT even mappings to convert to WSDL to your format. It is not clear to me what the value of doing that, since it is almost the same information. Since, WSDL is flexible to support mutiple binding, you lose a lot of information in your service desription. You can look see WSDL bindings, which includes HTTP binding at: http://www.w3.org/TR/wsdl20-bindings/ As an exercise, you can create a sercie description for the your wsdl. http://www.arcwebservices.com/services/v2006/AddressFinder.wsdl Please make sure that you create it for all the operations and keep the complex types as they are, not take a snippet of the data. Then compare them and try to see if a non programmer can understand that easier than WSDL. > I also designed a Web interface for demonstration, especially for Bijan so > that Bijan can believe OSRR is not just an assertion. The Web interface can > be accessed for now at: > > http://157.182.136.76/xshi/disst/discovery/Webform3.aspx > > In this example, for ALL SOAP-based Web services, they just have ONE > standardized interface: > > Function getService(String request):String response > > For REST service, I developed a HTTP server which is waiting for a POST > message as service request. > > Both service (WSDL) URL and server URL can be identified in the attached > document. > > To deploy the service, you have to compose an XML document as service > request. First, write the following line in any text editor: > > <?xml version="1.0" encoding="utf-8"?> > > Then, copy and cut the whole section of <ServiceRequest> section within the > <RequestTemplate> of a specific service and function described in the > document, and then paste it into your text editor under the line you just > typed, then now it should be: > > <?xml version="1.0" encoding="utf-8"?> > <ServiceRequest> > <Service Name="Geocoding"> > <Function Name="Geocoding"> > <InputVariables> > <Address> > <Street></Street> > <City></City> > <State></State> > <ZipCode></ZipCode> > </Address> > </InputVariables> > </Function> > </Service> > </ServiceRequest> If a Web service always had to interact with a person, one could always generate a form from the WSDL, which would be easier than the XML based template. > The last thing you have to do is assign the value of the input variables, > i.e. the information to compose your address (street, city, state, zip) > > This is the service composition process, easy, simple, understandable, > right? People don't need to write a single code. This is not service composition. All you are doing is invoking a service. > Once you compose a service request, put it within the "Request" text box on > the Web interface. > > If you want to use SOAP/WSDL Web service, then copy the service (WSDL) URL > into the text box for WSDL URL. Or, if you want to use REST Web service, > then copy the server URL into the text box for REST URL. Then click the > "Send Request" button, you can get the result which should exactly follow > the format specified in the <ResponseTemplate> section of the description > document. > > If anyone want to try the data conversion function and service, just follow > the same steps as mentioned above. You can use exactly the same service > interface and URL to invoke another kind of service. > > Since SOAP/WSDL service in this case just has ONE function interface, it is > so easy to create a dynamic service invocation. > > SOAP/WSDL are only for programmers. How many programmers are there in the > world that can consume such kind of services? However, for programmers, > don't you think it's so easy for them to process such an XML document? Most > importantly, since the service semantics keep the same when the interfaces > keep changing as demonstrated by the three versions of ESRI's services, for > service requesters, the programmers do NOT need to change anything if they > just process such an XML document of semantic service request, which can be > used by all three versions of the same service with different interfaces. See point about creating a complete service description for a complex WSDL above. > OSRR is for all users. As demonstrated, people do not need to know any kind > of programming languages. They just need a text editor to compose an XML > document for service request. The composition process is almost just a > cut-copy-paste process. They do not need to know any details about service > aggregation or mediation processon the server side (my paper published by > IBM already demonstrated that ALL kind of composite services can be > transformed into an atomic one). In OSRR, there is no process, just one > service request and one service response. Actually, if I don't tell you, how > do you know which geocoding server and which server for data conversion I > wrapped in my applications-they are not in my machine? > > By now I hope Bijan can believe such an assertion that the same service > request can be used to invoke either SOAP or REST service. If further you > want me to demonstrate how the same service request can be used to invoke > the same service offered be different service providers with different > business logics, I'd be happy to do that. > > At last, my question then is, since the same service and function can be > deployed by REST service, why do we need the serialization/deserialization > process, which means, WSDL can be deprecated, although many people are not > happy to see such a conclusion. > > As for service semantics, we need more standards and agreements on > describing the meaning of the service. If we can describe it, then we can > invoke it directly over HTTP without SOAP/WSDL. It is not an assertion, but > now a demonstrated fact. > Best wishes, > > Xuan > -- Kunal Verma, LSDIS Lab, Dept. of Computer Science, University of Georgia. URI: http://lsdis.cs.uga.edu/~kunal Cell: 706 254 3330
Received on Thursday, 16 March 2006 17:19:12 UTC