My Wishlist for Delphi Compiler

Today I was discussing at work about the problems we are facing with Delphi as an IDE, Language, Development tool. One of the problems I see with Delphi relates to the way it handles Abstract methods. This forced to think what I would like to have in Delphi Compiler.

1. Enable me have annotations in the classes instead of keywords to override methods.
2. There should be a way to declare a class abstract like in Java. The user program should not be able to instantiate the abstract classes.
3. A class with minimum one abstract methods should be forced to declare as abstract.
4. Like DotNet we should be able to make a Class / method final. So that nobody can extend it and in-turn override the behavior of the method.
5. There should be some way to warn user that an overridden method has empty implementation. May be an optimizer feature but this will be really helpful.

There are few more features (related to IDE) which would be nice to have:

1. Keyboard shortcut to see all the open files in one popup etc like eclipse.
2. Keyboard shortcut to go to method or class declaration. Just like F3 key in eclipse.
3. A Javadoc kind of feature where the user can attach some sort of documentation with the method and that can be picked up by the Code-Insight. So that we know what this method is doing. The current mouse hover does not give sufficient details as we cannot write documentation for the method to be picked up by any other class.
4. Also a scrapbook kind of feature in Delphi IDE will be cool to have where we can write couple of lines of code and then just test it. Something similar to what WSAD has in it. This will save time to test few lines of code we want to try in our code.
   

I am not sure if any of the reader has a contact with Delphi Team but it would be desirable to have these features in Delphi which one time was my favorite language which Borland team managed to destroy over a period of time.

Disclaimer: This post has nothing to do with the Semantic Database or Semantic Web Services as such.

Until Next Time...:)

Problems With Web Services

In previous posts I'd been talking about why Web Services are not for Web and how Semantic Web Services promise to solve the problem etc etc. While I was reading about WS and listing down what are the problems we have with the technology, I came up with a list of issues which needs to be addressed any technology which claims to be superior to Web Services.

Web Services are one of the best means to share applications in today's world. It frees one from worries of Applications, Infrastructure, Platform, Language, Upgradation etc. But while they are great for ordinary use. They do have few issues which need to be resolved to enable them serve their purpose.

1. Web Services today have problems like Automated Discovery, Choreography and Composition. Not to mention the security aspect this is not even thought about.
2. Currently web services use the infrastructure provided by the World Wide Web (WWW) but they do not actually operate on web. The World Wide Web is built on the top of the Infrastructure provided by Internet. Web Services operated on Internet infrastructure but do not work on the core principles of World-Wide-Web.
3. Web services also lack the capability of asynchronous communication or callback functionality.
4. Web services are very rigid in terms of messaging syntax. They have a fixed format for input and output messages.
5. There is no way to determine at execution time as which web services to pick up and which one serves the purpose. As web services do not work on Semantic structure (meaning) and they work on Syntactic structure. What this means is, they are very much discovered early or have a static binding. There is no dynamic discovery in Web Services
   
6. Web services also lack the capability of asynchronous communication or callback functionality.
7. Due to the Black-Box nature of Web-Services we often don’t know what is happening inside. By looking at a Web Service Description we can get information about the input parameters (message format) and Output Result (output message format) but we do not get any information about how it is doing what it is doing. In a nutshell the transparency is not there at all.
8. While using Web Services we assume that the output we are getting as result is correct. Since we don’t know (rather most of the time we don’t care) about the internals we cannot really verify the steps (logics) used to derive the final result from the input parameters passed to it. So verifiability is another concern we have in regards to Web Services. That affects the reliability on the Web Services as well.

I guess I'd been very negative about Web Services here. But then it is a great way to take our existing system functionality to a next level. Next post on will start touching on what is required to have a Semantic Web Services.

Until Next Time... :)

Introducing Semantic Web Services

In last few posts I was concentrating mostly on Web Services and what they are not. Last night I was reading and Article Approximate Reasoning and Semantic Web Services and there I happen to read about what it takes to create a Semantic Web Services. According to one of many definitions the Web Services can be described as systems with a number of features:

1. They are identified by a Uniform Resource Identifiers (URI)
2. Their public interfaces and bindings are defined and described using XML;
3. Their definitions can be discovered by other software systems;
4. Other systems may interact with the Web Services in a manner prescribed by their definitions using XML-based messages conveyed by Internet protocols.

The proposed definition of the new concept Semantic Web Services has few changes and enhancements when compared with the definition of the Web Services. Semantic Web Services are system that:

1. Are identified by a URI.
2. Whose public interfaces, bindings, some behaviour and various other features are defined and described using Semantic Web language. The Semantic Web Language here refers to OWL, DAML-S etc.
   
3. Their definitions and other descriptions can be discovered by other systems.
4. Other systems may then reason about and interact with the semantic web services in a manner guided by their definitions using xml-based messages conveyed by internet protocols.

In the light of those definitions, it can he stated that the biggest advantage of the Semantic Web Services is their flexibility. The interacting system do not have to know everything about each other before they start interaction. They "learn" about their specifics and behaviour at the time they interact. The concept of Ontology and its application to represent information ahout data and services give such capabilities. Each service in the fiamework of the Semantic Web Services is represented by:

1. Profile ontology, called ServiceProfile, is a description of a service.
2. Model ontology, ServiceModel, is a description of a process itself and its composition.
3. Grounding ontology, called just Grounding, describes mapping of service elements to WDSL messages.

This is the first of the many posts yet to come related to Semantic Web Services. Keep watching this space for more on this topic in days / weeks / months to come.

Until Next Time...:)

Global E-Business

There was a time when Business used to take place in person. ie people used to discuss among themselves and finalize the deal. While this was the best way for doing the business, it had few drawbacks as well. It was time consuming and one was limited by the time and resources available.

The times have changed and we moved to E-Business now. The transaction which used to take place over phone or in person started to happen on internet. While this enabled us to do transaction with any other business located in any part of the world, it introduced quite a few complexity in the whole process. But this is not what the main theme of this post is.

The Vision of E-Commerce
The original vision of E-Commerce was to enable anybody to do trade and negotiate with anybody else. But is that really possible in current scenario? Lets see what it takes to have such a system in this world:

1. A Machine Interpretable format or A system must be in place which can deal with numerous and heterogeneous data formats and numerous and heterogeneous Business Logics. A Strong decoupling is required for various applications/components which realizes the E-Commerce application.
2. Some sort of semantics is needed in this heterogeneous environment which will allow mediation at the conceptual level. i.e. a Strong mediation service is required which allows a system to communicate with another system. Here we are talking about machines to communicate with each other without human intervention.

Is Current Technology Sufficient?
In todays world we have Technologies like Multi-Tier and Distributed computing, Web Services, Web based shopping carts etc. These tools and technologies help people to do business over web. We call this E-Commerce. But they are nowhere close to realizing the vision of E-Commerce. These technologies while they work great with known systems, they fail to mediate between two different systems. Also the systems today are not able to handle the hetrogenity in terms of data and business logic.

Web Services as a technology has made lots of promises to the businesses worldwide. It had what it takes to become the most acceptable solution for E-Commerce. But since its advent it failed to realize the vision. I will discuss about this in one of my future post. In my previous post about Are Web Services Really Web Services, I had pointed out what is missing in today's Web Services.

What is the Solution?
Semantic Web as a technology has lots of promises to the world. Semantic web promises to make the content of world-wide-web Machine Readable and Machine Processable. Semantic Web involves Ontologies which is one of the most abused term (from its original meaning). Researchers around the world are working day and night to make the web contents machine readable and machine processable by developing Ontologies. At the same time Web Services community also worked on to improve the Web Services Standards. But so far not much of work is been done to combine the best of two and come up with a powerful solution.

Semantic Web Service is one such solution which promises to enable E-Commerce in its original form and realize the vision of E-Business.

In my upcoming posts I will discuss about Semantic Web Services in detail. Starting from conceptual level to the more detailed level architecture and implementation.

Until Next Time.... :)

Are Web Services really Web Services?

In my previous post regarding Web Services I mentioned why besides their name Web Services have nothing to do with the Web. In this post we will discuss them in detail as why it makes me and everybody else who researches Web Services to come to this conclusion. While Web Services as a technology is been great for ordinary users there are several disadvantages which becomes obvious when the researchers look at it.

Current Web Services Technology
Current Web service technology is based on tightly coupled message exchange. The sender and receiver has to be online during the whole communication period. It will fail if one of them is offline. This situation is similar to the situation faced by scientist community in the pre-Web age, where one had to send an e-mail message to a scientific colleague, asking for a specific paper or piece of information. With the introduction of web it became simpler. In the current Web as an infrastructure for humans, this pattern of communication has widely been replaced by persistent publication and asynchronous retrieval. We no longer request the biggest share of information in lengthy, synchronous communication cycles with the originators, but fetch it from persistent sources, e.g. the scientist’s personal Web page. We don't have to be online all the time to ensure that whoever wants our page can get it. We can just publish the article on a web page and let others download it from there. We argue that this has significantly contributed to the success and scalability of the Web, since it freed the sender from the need to handle individual requests, and it made resources identifiable and thus referable.

Imagine what will happen if Web was not there today. In such a situation one will have to handle individual requests from all your scholarly colleagues who visit your Web site. You might soon become the main bottleneck for the dissemination of your own ideas. The shift from information dissemination based on message exchange not only made the Web scale tremendously, it has also sped up the dissemination process.

On the contrary when we compare Web services with this important principle of the Web it becomes very obvious that Web services are not following the core idea of the Web. It is true that Web services use the Internet infrastructure as the transport medium. However, that is more or less all they have in common with the Web. The idea of publishing data and accessing it asynchronously is lacking. Web services failed to work in asynchronous mode. Instead of publishing the information based on a global and persistent URI, Web services establish (1) stateful conversations based on the (2) hidden content of messages.

The negative effect of such distributed applications that communicate via message exchange is that they require a strong coupling in terms of reference and time. This means that traditional Web services require that the sender and receiver of data:

1. maintain a connection at the very same time, that they
2. agree on the data format, and
3. know each other and share a common representation.

Therefore, the communication has to be directed to a particular service and is synchronous as long as neither party implements asynchronous communication (and jointly agree on the specific way this mechanism is implemented).

The two major criticisms around Web services today are about the improper usage of URIs and the violation of the stateless architecture of the Web. It is one of the basic design principles of the Web and REST architecture to not provide stateful protocols and resources.

In real-world(where we live in) this means that when sending and/or receiving SOAP messages, the content of the information is hidden in the body and not addressed as an explicit Web resource with its own URI. Therefore, most Web functionality dealing with caching or security checks is disabled, since using it would require parsing and understanding all possible XML schemas that can be used to write a SOAP message. Thus, when a stateful conversation is required, this should be explicitly modelled by different URIs. Moreover, referring to the content transmitted via an explicit URI in an HTTP-request would allow the content of a message to be treated like any other Web resource.

Summary:
In this post we discussed how Web-Services failed to realize the Web part of its name. What is missing ie stateless architecture and using URIs to refer to the resources. In next post we will discuss what is Semantic Web Services and how they are better than the Traditional (syntactic) Web Services.

Until Next Time....:)

Web Services are NOT for Web

Yes this is right Web Services are NOT at all for Web. Last few days/weeks I spent reading through different journals, conference papers and articles to understand what Web Services are all about. At the end when I was writing down my concluding notes on what I read and what I understood. I came up with the conclusion that Web Services miss the Web part and are better of called as Internet Services.

Internet and Web
The first question that comes to anybody's mind is that are they two different thing? I mean Web and Internet aren't they same thing? To a novice reader there is no difference between Web and Internet. Web today is the major means of publishing and accessing information. Starting as a closed network to exchange emails and share files for scientific reasons, today it has become a global media used for information dissemination and information access within little over a decade.

Internet is the infrastructure and the TCP/IP stack we are talking here. It is the backbone of the World-Wide-Web. It handles all the communication and the data transfer. Web is just an application of the Internet. There are other applications like File Transfer, Voice and Data transfer etc. All of them use the infrastructure provided by Internet.

Where is the missing?
Web Services technologies today are far from being in a state where the automated and seamless integration is possibility. There are known problems in the Web Services arena and researchers around the world are working on to overcome those problems.

Web services are mainly based on transient message exchange and not on persistent publication of data. As a matter of fact, Web services are far from using the Web as means for information publication and access. Instead of following the ’persistently publish and read’ paradigm of the Web, traditional Web services using WSDL and SOAP establish a tightly coupled communication cycle, most frequently using a synchronous HTTP transaction to transmit data. URIs, which are meant as unique and persistent identifiers for resources are used only for the identification of the participant, whereas the information exchanged is hidden in the SOAP message.

In next posting I will discuss how the Web Services as a Technology do not fit the specifications of the web. There will also mention why apart from name Web is not there in Web Services at all.

Until Next Time ...:)