Re: Compositions Types:Static and Dynamic

Xuan,

I have already solved the problem when the service is a front end of a 
database.  It is now possible to query any database regardless of its 
schema.  I have a demo system ready. 

As for services, I have also solved the problem when the target service 
is not process oriented (as in partner interface process described by 
RosettaNet).  I am working on a demo system right now.  I am very close 
to solve the problem when the service is process oriented.   
Unfortunately I am filing patents, so I cannot disclose more.  Please 
wait until that process is complete, then I can disclose more.

Right now the only thing I can say is that the current OWL-S and 
semantic annotation is not enough.  As we all know, if just given a 
WSDL, no human programmer can really use the web service without 
mistakes.  Just think how much information is contained in an API 
document or a programmer's guide contains and how much knowledge a 
programmer need to have before he/she can start to read those documents, 
you can appreciate how much knowledge must be built into the 
program-programmer in order to make it work.  Also it is not necessary 
to have the same standard API for all Web Services.  It is the PROBLEM 
Semantic Web should solve.  And I have solved most of it.


Cheers,
William Wu
Semansoft Corporation


Shi, Xuan wrote:
> William,
>
> Thanks for your comments and advice. I agree with you to some degree as
> "Dynamic" means composition and invocation is programed by
> program-programmer. However, program by program-programmer is predefined by
> human programmer, as the machines has little intelligence to know and do
> something in any unknown situation, such as any exception undefined in SW
> logic referential scope.
>
> Given the example of those four address geocoding Web services as I sent to
> 'public-ws-semann@w3.org':
>
> http://www.arcwebservices.com/services/v2006/AddressFinder.wsdl 
> http://arcweb.esri.com/services/v2/AddressFinder.wsdl 
> http://rpc.geocoder.us/dist/eg/clients/GeoCoder.wsdl 
> http://157.182.136.76/xshi/disst/geocodingservice/geocodingconversion.asmx?W
> SDL
>
> supposed we know that we need such Web services for certain tasks in a
> composite process involving multiple Web services, and we already can
> identify these 4 available Web services through composition process. Then
> how can invoke any of them?
>
> In case one service does not function correctly then machine has to switch
> to another one. In this case, since all APIs and WSDLs for such same kind of
> Web services are different, machine has to do everything differently to
> figure out how to invoke the same service with a different interface. If
> unfortunately only the 4th service can work correctly for some reason, then
> you can imagine how long people or machine has to wait until an answer comes
> out through such kind of dynamic matchmaking, composition, and invocation
> process.
>
> In my previous suggestion to develop semantic Web services through OSRR
> approach by sharing service semantics, all Web services have one
> standardized API. Since everything has been predefined in one service
> description XML document, program by program-programmer is not that hard
> since to compose a service request, it is such a simple process as
> copy-cut-paste then machine can do such work easily (one of my papers is
> accepted by an IEEE journal and will be published).
>
> Whenever any service does not work correctly, machine just need to send the
> same request to another service provider without changing anything. Dynamic
> invocation is easy and simple since the ONLY input and output are a 'String'
> data type containing the message exchanged between requester and provider.
> We can easily build dynamic invocation in different ways by SOAP/WSDL,
> HTTP/POST, or even CORBA and DCOM.
>
> Regarding semantic annotation for WSDL, please use the above four WSs to
> test such an approach. The result may be a mixure of semantics of both
> service and interface. It may be a way to describe the semantics of service
> interface, but not good for service semantics. However, such an approach can
> be a new burden for dynamic invocation as mentioned above.
>
> Below is a message I got from someone who has been keeping an eye on the
> debates we have had in W3C-SWS-IG. I hope it could be helpful to all of us
> for consideration. In W3C-SWS-IG, someone said before that I am an outsider
> from this community. Then you know the meaning of "insider" in the following
> message. This guy seems to be an insider as you see he or she digged much
> deeper than what I did. 
>
> Again, thank you very much for your kind attention and advice to such
> discussion. Maybe you can tell us something about how do you think the
> algorithm related issues for SW and SWS.
>
> Best wishes, 
>
> Xuan 
>
> ************************************************************************* 
>
> ... ...
>
> The deeper I get into this field, the more skeptical I feel towards 
> current roadmap for so called Semantic Web. As we have seen in 
> Deductive Database, Object-Oriented Database, Neural Network, Expert 
> System, just mention a few among many 
> looks-nice-at-the-beginning-but-failed-finally research, scaleability 
> has killed so many other beautiful ideas. Do you believe an ExpTime or 
> even NExpTime algorithm will be accepted by any computer network or 
> database researcher? That's what OWL can offer us at best - not to 
> mention other practical difficulties in communication, modularity, 
> privacy and ontology mapping. To my opinion, only O(log) or linear 
> algorithm can survive on the Web, which is only possible for very week 
> ontologies, such as RSS, Trees and DAGs. I would say, the working SW 
> in practice in the near future can hardly be more complex than that. 
>
> Well, nobody who is an "insider" should say that - only to be a 
> funding killer. And you know from your experience what some people 
> will react for such a skepticism from non-insiders. 
>
> Recently people are moving on to OWL1.1 with even stronger 
> expressivity. I believe it is further wrong on an already misleading 
> direction. And you know, some rule language proposals may even lead to 
> undecidability. 
>
> ... ...
>
> ************************************************************************* 
>
>
> -----Original Message-----
> From: William Wu
> To: Shi, Xuan
> Cc: 'Daniela CLARO '; 'public-sws-ig@w3.org '
> Sent: 4/27/06 9:29 AM
> Subject: Re: Compositions Types:Static and Dynamic
>
>
> Daniela and Xuan,
>
> For semantic web, I would give a somewhat different definition about 
> "dynamic" vs "static" than conventional  definition.  "Dynamic" means 
> composition and invocation is programed by program-programmer.  "Static"
>
> means it is programed by human programmer.  The more dynamic it is, the 
> more a human programmer needs to make his/her program closer to a 
> program-programmer.  "Dynamic" composition/invocation in conventional 
> technology like Java, CORBA, ActiveX, or Web Services are very limited.
>
> The goal of semantic web is to create an order-of-magnitude more 
> flexible program-programmer.  Semantic annotation is to assist them to 
> write programs  to use a particular service just as API specification 
> and programmer's guide to assist human programmer.
>
> Even though, we are still far away from creating program-programmer 
> close to human programmer.  The research in semantic web has 
> dramatically improved the capability of program-programmers.  To do 
> this, it requires a paradigm shift from conventional object-oriented 
> model to semantic-oriented model.  It requires a different kind of 
> programming language, a different kind of data store, a different kind 
> of API, and most of all, a different kind of API specification.
>
>
> William Wu
> Semansoft Corporation
>
> Shi, Xuan wrote:
>   
>> Daniela,
>>
>> Thanks very much for your kind advice and discuss. To my opinion,
>>     
> dynamic
>   
>> composition may be a part of the service discovery and matchmaking
>>     
> process.
>   
>> Semantic information is useful in such situation. Dynamic invocation,
>> however, may have to deal with programming issue.
>>
>> So when we know the composite process of a service chain, how can you
>> dynamically invoke each of the services described in your composition
>> document? Given the example that you know the WSDL URLs and IOPEs for
>>     
> both
>   
>> Microsoft's TerraService and ESRI's address geocoding services, you
>>     
> know you
>   
>> have to first use the "address" information to invoke geocoding
>>     
> service to
>   
>> retrieve lat/lon values, which will then be used to invoke
>>     
> TerraService's
>   
>> function to retrieve the image you want. How can you invoke the
>>     
> service
>   
>> through composition? 
>>
>> I know even it's a difficulty and complex process to create/deploy a
>>     
> static
>   
>> java Web service, but did not try dynamic invocation in java. However,
>>     
> I do
>   
>> know how to dynamic invoke a WS in .NET in the proposed OSRR approach
>>     
> which
>   
>> is much much better and convenient than the traditional WSDL-based
>>     
> dynamic
>   
>> invocation-a difficulty for such task.
>>
>> Best wishes,
>>
>> Xuan
>>
>>
>> -----Original Message-----
>> From: Daniela CLARO
>> To: public-sws-ig@w3.org
>> Sent: 4/26/06 4:11 AM
>> Subject: RE: Compositions Types:Static and Dynamic
>>
>>
>> Hi Xuan, 
>>   
>>
>>   
>>     
>>> One more question is about the relationship between dynamic 
>>> service composition and dynamic service invocation. If the 
>>> purpose of dynamic service composition is for dynamic service 
>>> invocation, given the example of retrieving an aerial photo 
>>> from Microsoft's Terraservice, how such dynamic composition 
>>> will enable the dynamic invocation? 
>>>     
>>>       
>> For me, one think is dynamic composition, i.e. when your goal is to
>> construct a stair(ws1) and for this you need to supply the
>> concrete(ws2). However the ws2 (supply concrete) you do not know yet.
>> Thus the dynamic composition is responsible to put the ws2 in your
>> composition to achieve the goal 'create a stair'. On the other hand,
>> dynamic invocation, we can have already done dynamic composition, and
>>     
> at
>   
>> the moment you will execute these services w1 and w2, the w2 is
>>     
> offline.
>   
>> Thus you should find another service, with the same functionalities to
>> replace the ws2. 
>>
>> Thus we can have dynamic compositions and dynamic invocations or both!
>> This is my point of view :o)! And most of the papers in planning, as I
>> could observe, treats dynamic invocation. Actually I do not know if
>>     
> they
>   
>> treat dynamic composition also, do they? 
>>
>>
>>   
>>     
>>> In this case, the known 
>>> WSDL documents can be identified, thus you know the IOPEs for 
>>> this task. 
>>>     
>>>       
>> Yes... 
>>   
>>     
>>> I never tried the dynamic invocation in Java, but in .NET, I 
>>> know it's a difficulty to build dynamic invocation in the 
>>> traditional WSDL approach.
>>>     
>>>       
>> I think dynamic invocation as people are doing, as I have read in some
>> papers is using planning and semantic web, because how you will find
>> other services, with the same functionalities (and probably others
>> non-functional criteria as QoS) without semantics, it will be more
>> difficult. Thus many approaches are using planning with semantics. The
>> paper Template-based Composition of Semantic Web Services E. Sirin, B.
>> Parsia, J. Hendler used a planner based on Java, the Jshop. 
>>
>> I created a planning algorithm using a rule-based engine, called JESS.
>> It not efficient as a planner with relaxed restrictions as a HTN, but
>>     
> we
>   
>> should start by something! JESS is completely integrated with Java.
>> JSHOP I do not know, but the authors can say something about it! I
>> created a dynamic composition and not a dynamic invocation. In my
>> invocation I consider that everything works fine!
>>
>> Hope that helps,
>> Daniela
>>
>>
>>   
>>     
>
>
>
>

Received on Friday, 28 April 2006 02:59:56 UTC