From CyberGIS

Jump to: navigation, search


The context of service in service computing

  • In English dictionaries, service means “work done for others”, or “contribution to the welfare of others”, or “work done for somebody”. If a work is not done for others, it is a “self-service” but cannot be called a “service”.
  • In service computing, the consumer of a service is a computer agent or program, not human being. For example, a .NET service can be consumed by a Java program, or vice versa.
  • A functional module is not a service if such a module can only process its own data, while no other computer agents or programs can utilize this module to process other datasets.
    • WFS and WCS are typical examples of data service, not software as such 'service' has no capability to process/serve the data hosted by the others.
  • A Web application is not a Web service if the consumer is human being. Charles Petrie @ Stanford University [founding Editor-in-Chief of IEEE Internet Computing] indicated in 2009 – “To clarify, I am not talking about Web-based services. You can easily order a book from Amazon using your browser. That’s not a Web service.” [Source: IEEE Internet Computing, Nov/Dec Issue 2009]
    • A tool or application on a Web browser is not a service in the context of service oriented computing, if the consumer is human being, or if no other computer programs in other platforms can use such a tool.
  • REST can be a service if it can be consumed by other computer agents or programs on other platforms.

The context of service discovery

  • In the old tale of the Emperor’s New Clothes, it is well-known how beautiful those clothes were, though people just could not see any cloth.
  • If we change the word “clothes” to “services”, it could be a modern tale if “services” could not be found.
  • Ian Foster commented in Science (“Service-Oriented Science,” 6 May 2005) that “[Web] services have little value if others cannot discover, access, and make sense of them”, which means, service discovery seems to be at the first order for others to deploy useful services.
  • Michael Brodie stated (2007) “How will services discover the right services that meet specific requirements in such an environment? We’re far from that scale at the moment.” [Source: IEEE Intelligent Systems. Sep/Oct Issue 2007] If we’re far from discovering the right services at the moment, how can the others consume services?
  • W3C proposed three approaches for service discovery, namely, service registry, index, or Peer-to-Peer (P2P). [Source: W3C. 2004. Web Services Architecture.]
    • P2P is impossible because under the existing Web service technology, a service only has an interface definition specified in WSDL while messages can be exchanged through the SOAP protocol. There is no mechanism for a “service” to query its neighbors in search of a suitable Web service.
    • The index approach is not feasible either and encounters varied challenges and problems, including the fact that the service description has little semantics. [Source: Al-Masri, E. and Q. H. Mahmoud. 2008. Discovering Web Services in Search Engine. IEEE Internet Computing. May/June 2008]
    • When the Universal Description, Discovery and Integration (UDDI) Business Registry (UBR) was closed in early 2006 (Microsoft, 2006), the service registry approach essentially declared failure.
  • Web service architecture (WSA), or service oriented architecture (SOA), has three components including service provider, service requester, and service registry. Service registry and discovery should be the key in WSA/SOA.
  • Although service discovery is the key and starting point in service computation, service discovery, however, is independent from service invocation and integration.

The context of service computing in SI2 project

  • The key words for SI2 are “software”, “infrastructure”, and “Innovation”.
  • Data service and integration are not the focus of SI2 project for software research.
  • UDDI and BPEL were either obsolete or old technologies with little contribution to innovation.
  • Software integration through javascript seems not meaningful and reasonable in software engineering.
  • Cyberinfrastructure is characterized by the massively parallel computing environment empowered by modern multi-core and many-core.
  • Service oriented software development and integration based on single threading solution seems not meaningful over the Cyberinfrastructure.
  • Research at the infrastructure level, not interface level, could be the source of sustained innovation for software development and integration.

The context of OGC services

  • OGC standards and specifications are about the interface definitions of OGC Web services (OWS).
  • Except Web Processing Service (WPS), most OGC services are about serving data and maps, which may not have much relationship to SI2 focusing on software engineering research.
  • WPS was finalized in 2007. Developing WPS-based services seems only to prove its validity without innovation.
  • WPS has been constrained by the scalability and performance issues due to the inability at the infrastructure level since the servers cannot handle large data, particularly when lots of users send requests concurrently. In this case, the servers have neither sufficient computing power, nor sufficient memory, to complete the jobs.
  • The limitation of WPS in real world practice was evidenced by a variety of OGC testbeds and confirmed by OGC.