RE: Compositions Types:Static and Dynamic

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 Thursday, 27 April 2006 15:31:50 UTC