It is always good to have a small message. But in mobile computing, it is absolutely required because of the narrow bandwidth connection. * Wireless Connection vs. Wired Connection (Bandwidth) * Problems created by encoding/decoding (Increased message size and A text conversion) * HTTP: the most popular transport protocol in mobile Web Service
X.694, a specification that defines a mapping from XSD to ASN.1, is an important building block for Fast because XSD is used in WSDL to define the structure of messages. Consequently, the XML schema referenced in a WSDL document can be considered an abstract schema, with an equivalent ASN.1 description, whose instances can be encoded using XML or an ASN.1 encoding. In the latter case it is possible to use an efficient binary encoding such as Packed Encoding Rules (PER), also known as X.691 [ 15 ]. Figure 2 depicts this process. Stub and Tie is for WSDL DEFINE XML INFOSET WHAT DOES (PER) – Octet mean
Significance of the research: Investigating what are the obstacles of mobile Web Service / Grid Computing Investigating those obstacles in detail to find resolutions or bypasses
This is a Practical problem practical problem: problem you experience or you observe in the "reality" and which manifests itself as a cost in time, satisfaction, money, etc... It is important to motivate why the problem is important enough to be worth the research. The practical problem is associated with a topic, which is the area in which the research will be done. state of the art analysis: once a practical problem is identified, a state of the art analysis is done to identify and evaluate all the existing solutions to the practical problem. The state of the art analysis includes a literature analysis (i.e. review of the published research results) and a best practice analysis (i.e. review of the current industrial practice). At this point, either the practical problem is solved (still be worth to write a technical report on the results) or none of the existing solutions are satisfactory and you can carry the research. research problem: practical problem reformulated by the researcher in a way which states how the current state of the art presents an incomplete or flawed understanding. research solution: solution to the research problem, which could be applied to solve the practical problem. Usually, an hypothesis is stated and is then validated by using some methods. It is important to show how the research solution contributes to solve the practical problem. Note that hypothesis which have been proven invalid might also be published.
Streams help performance using WS-Context saving of replicated data And by amortizing negotiation Streams help HTTP
If you have a single message that has different structure and type, it should be exchanged in another stream. Phrase two WS nodes exchange a stream of messages Is FUNNY as always true – nothing to do with application domain In Sensor Grid example, no “mobile clients” Add a mobile example such as PDA web access to Grid job
DOM (Document Object Model) SAX (Simple API for XML) “ Use a data description file as a sample instance of messages in the stream” is an assumption we made and it could be the limitation of the current implementation. Maybe should be earlier as you use Infoset without definition earlier
Using the description language file dynamically generated filter which converts representations. Note that current version of the HHFR prototype has only a binary format filter Current implementation handles header hasn’t implemented A picture of filters and handlers and body processor showing different possible orders Could be good
Like the video application case, there are many undocumented specifications. Customized choice of transport Axis2 Axiom data model is SOAP Infoset compatible. What is 2 nd channel? Isn’t first bullet Transport and second bullet message representation? If so clearly label two issues
Not only save redundant/unchanging art, but also save negotiation information. General goal is to reduce the size of message. In mobile environment, the message size is tend to be small and latency is high. Stress that any WS enabled database could be used and in fact our WS-Context Built on Javaspaces which is a natural model with a SQL database “just” to store OGSA-DAI would also be possible
Could mention WS-Policy here specifying default strategy
Context size is 847bytes and the entire SOAP message size is 1.58KB
HTTP is not a mandatory transport protocol, though it is the most popular protocol in mobile computing.
Don’t understand Measured through HHFR to show bandwidth gain from using a Context-store
In the result of the scalability test, it should be stated that the time for processing result is not optimized and there is lots of possible improvement room in Axis. Axis2 should perform better. You should separate twsctx taxis ttrans measurements from discussion of N You haven’t even explained that N maximum supported by one server So measure fully a server Then pose question as to allowed N
In one second, there is N/T stream starts N/Tstream ends. Thus 2N/Tstream + N/Tstream access per second.
Results and claim Design and implement HHFR architecture which overcomes/bypasses obstacles.
![Outline ,[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],[object Object],Sangyoon Oh](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)