Z++ tell/hear and Web Services
Mathematics evolves through simplification of complexity. Higher-level concepts abstract away a great deal of complexity. Otherwise, our fundamental tool would be limited to arithmetic and basic geometry. In the same vain, software engineering will make a jump in solving problems only when a programming language brings about simplification by hiding complexity through automation of higher-level abstractions.
In Robotic Communication we illustrated an application of tell/hear with regard to Concurrent Communicating Processes. The tell/hear abstraction is orthogonal to the rest of Z++ expressiveness, and therefore it monotonically increases Z++ expressiveness. In this note we will illustrate another application of tell/hear for solving the problem of Web Services.
Z++ is generally described as a greatly enhanced superset of C++. Indeed, Z++ corrects C++ defects and extends its subset in many directions. However, Z++ abstractions for a variety of software solutions can never become part of C++. These abstractions, one of which we will illustrate here, require technological solutions which are beyond what a language can do on its own. For Z++ this underlying technology is Z47 Processor.
Without reviewing the boring history of Web Services, let us just state what was envisaged by that terminology. A client is looking for a particular service. The method of describing this service is a service indicator and a list of types of objects that may be sent along for service. The client may only need an acknowledgement of completion of service, or it may receive some data as part of the acknowledgement.
Let us look at a scenario. A user has registered with a service provider for hotel reservations, plane tickets, etc. Using his handheld device, the user fills out a request for a particular type of hotel, pricing and dates. The application adds user’s authentication to the request and sends it to the server. At this time user is able to use his device for other purposes.
A few minutes later user receives a popup on his device informing him of the availability of the service. For simplicity, we avoid the case that the server may have suggested alternatives, and that user may change some data and resend the request. Once the user accepts the offer, the server will confirm the service, charge the user’s account and send back a confirmation. The application will also record the confirmation for future use. In this scenario, the contact-server may also need to contact other servers as a client for finding the right hotel and pricing for its client. This process is also part of Web Services.
Thinking about a solution for the above scenario, we see that most of the cost of development will be in the area of communication and testing of data transmission. After all, a GUI and some file processing is not a major challenge and can be tested quite easily. So, how does Z++ reduce the complexity of developing this type of software?
The Z++ tell/hear signaling provides a simple and natural form of telling a server about a request and later hearing about it. Obviously, the simplicity hides a great deal of complexity. The linguistic design is quite effective in assisting the compiler to trap many coding errors. Furthermore, regardless of the complexity of data, there is no visible code in a Z++ application regarding data transmission, communication, synchronization or anything else for that matter. Basically, the server side of code focuses on the services, and the client code deals with providing its user with a simple GUI.
Z++ approach is as follows. The provider of a service simply registers the service as a hears(…) specification. This is a simple line of code similar to throws specification. On the client side, a client simply tells what it needs in a line that resembles a function call. Z47 Processor undertakes the entire complexity of executing the protocol. The protocol asks the server whether it is capable of providing the service prior to sending the actual data to it. The server checks the request against its registered hears(…) specifications. All of this is transparent to Z++ code. That simply means there is no code to write beyond expressing your intent, and therefore nothing to test or maintain, either.
New services can be added without having to change the code already written in any subtle way. Basically, one adds a new hears(…) specification, and the related code for serving an incoming request. No other part of the code needs updating.
On the other hand, the notion of Web Services is independent of expressiveness of C++ language. That means, one needs to line up library API using the facilities of the operating system on which a client or server will be running. But then a C++ compiler would not able to trap errors relevant to the notion of Web Services. Relatively speaking, such a C++ program will be large, complex and look like assembly language.
In Robotic Communication we illustrated an application of tell/hear with regard to Concurrent Communicating Processes. The tell/hear abstraction is orthogonal to the rest of Z++ expressiveness, and therefore it monotonically increases Z++ expressiveness. In this note we will illustrate another application of tell/hear for solving the problem of Web Services.
Z++ is generally described as a greatly enhanced superset of C++. Indeed, Z++ corrects C++ defects and extends its subset in many directions. However, Z++ abstractions for a variety of software solutions can never become part of C++. These abstractions, one of which we will illustrate here, require technological solutions which are beyond what a language can do on its own. For Z++ this underlying technology is Z47 Processor.
Without reviewing the boring history of Web Services, let us just state what was envisaged by that terminology. A client is looking for a particular service. The method of describing this service is a service indicator and a list of types of objects that may be sent along for service. The client may only need an acknowledgement of completion of service, or it may receive some data as part of the acknowledgement.
Let us look at a scenario. A user has registered with a service provider for hotel reservations, plane tickets, etc. Using his handheld device, the user fills out a request for a particular type of hotel, pricing and dates. The application adds user’s authentication to the request and sends it to the server. At this time user is able to use his device for other purposes.
A few minutes later user receives a popup on his device informing him of the availability of the service. For simplicity, we avoid the case that the server may have suggested alternatives, and that user may change some data and resend the request. Once the user accepts the offer, the server will confirm the service, charge the user’s account and send back a confirmation. The application will also record the confirmation for future use. In this scenario, the contact-server may also need to contact other servers as a client for finding the right hotel and pricing for its client. This process is also part of Web Services.
Thinking about a solution for the above scenario, we see that most of the cost of development will be in the area of communication and testing of data transmission. After all, a GUI and some file processing is not a major challenge and can be tested quite easily. So, how does Z++ reduce the complexity of developing this type of software?
The Z++ tell/hear signaling provides a simple and natural form of telling a server about a request and later hearing about it. Obviously, the simplicity hides a great deal of complexity. The linguistic design is quite effective in assisting the compiler to trap many coding errors. Furthermore, regardless of the complexity of data, there is no visible code in a Z++ application regarding data transmission, communication, synchronization or anything else for that matter. Basically, the server side of code focuses on the services, and the client code deals with providing its user with a simple GUI.
Z++ approach is as follows. The provider of a service simply registers the service as a hears(…) specification. This is a simple line of code similar to throws specification. On the client side, a client simply tells what it needs in a line that resembles a function call. Z47 Processor undertakes the entire complexity of executing the protocol. The protocol asks the server whether it is capable of providing the service prior to sending the actual data to it. The server checks the request against its registered hears(…) specifications. All of this is transparent to Z++ code. That simply means there is no code to write beyond expressing your intent, and therefore nothing to test or maintain, either.
New services can be added without having to change the code already written in any subtle way. Basically, one adds a new hears(…) specification, and the related code for serving an incoming request. No other part of the code needs updating.
On the other hand, the notion of Web Services is independent of expressiveness of C++ language. That means, one needs to line up library API using the facilities of the operating system on which a client or server will be running. But then a C++ compiler would not able to trap errors relevant to the notion of Web Services. Relatively speaking, such a C++ program will be large, complex and look like assembly language.
Labels: Tell/Hear, Tell/Hear Signaling, Web Services, Z++, Z47
posted by Dr.Z. at 4:17 PM
0 Comments:
Post a Comment
<< Back to Blogger Start Page >>