Loading ...
Sorry, an error occurred while loading the content.

JSDL (Javascript Service Definition Language)

Expand Messages
  • Mert Sakarya
    Lately I ve been coding with Javascript and JSON a lot. I am using XHConn.js (downloadable from http://xkr.us/code/javascript/XHConn/) as XmlHttpRequest object
    Message 1 of 5 , May 23 1:37 AM
    • 0 Attachment
      Lately I've been coding with Javascript and JSON a lot. I'am using
      XHConn.js (downloadable from http://xkr.us/code/javascript/XHConn/)
      as XmlHttpRequest object which is quite small and efficient.

      I've noticed that it might be a good practice to move or copy the
      business/application layer to the client side (basically some HTML
      file). I've modified XHConn (XmlHttpRequest) a little, to use client-
      side caching, work both synchronously and asynchronously and return
      JSON objects only (currently it is using eval function for
      performance). The thing, I like about using "eval" is, you can
      create function properties.

      Assume that you have a service that works just like a web service,
      but this one talks only JSON and works on Web pages over HTTP
      (narrowed down the platform). JSON objects are results of our
      WebMethods which are callable through XmlHttpRequests. If we can
      group these methods in a service in a logical way, we
      get "Javascript Services". So we need something like WSDL to combine
      these methods. They should contain the definitions of the methods
      (the body of the method is a XmlHttpRequest to the server),
      parameter validation and some very light error checking (eg. if a
      parameter can be null or the max length of parameter etc.). I call
      this concept JSDL (Javascript Service Definition Language). The good
      thing is, JSDL is itself written with Javascript and actually can be
      a JSON object (if we are allowed to add functions to JSON standard).
      In Javascript Services we can define functions like below;

      function GetCustomer(custId) {
      if(!custId) throw "CUSTID null";
      return (new XHConn()).connect("URL", "GET", "Parameters", null);
      }

      or async version;

      function GetCustomerAsync(custId, asyncCallback) {
      if(!custId) throw "CUSTID null";
      (new XHConn()).connect("URL", "GET", "Parameters", asyncCallback);
      }

      Now assume that we combine these method definitions in a JSON Object;

      Service.jsdl file
      ------------------------------------------------------------------
      {
      "GetCustomer" : function(custId) {
      if(!custId) throw "CUSTID null";
      return (new XHConn()).connect("URL", "GET", "Parameters", null);
      }

      "GetCustomerAsync" : function(custId, asyncCallback) {
      if(!custId) throw "CUSTID null";
      (new XHConn()).connect("URL", "GET", "Parameters",
      asyncCallback);
      }
      }

      As long as "Service.jsdl" file is a JSON object, it can be
      downloaded with XmlHttpRequest and be named as a service.

      //Synchronous version;
      try {
      var service = (new XHConn()).connect("Service.jsdl", "GET", "",
      null);
      var customer = service.GetCustomer("CustId");
      } catch(e) {
      alert(e);
      }

      //Asynchronous version;
      try
      {
      //probably we need to load the service synchronously
      var service = (new XHConn()).connect("Service.jsdl", "GET", "", );
      var customer;
      service.GetCustomerAsync("CustId",
      function(jsonObj) {
      customer = jsonObj;
      }
      );
      }
      catch(e)
      {
      alert(e);
      }

      All you need is to figure out a way to generate JSDL files on the
      server-side just like WSDL files are generated may be something
      like, attribute based programming on .Net.

      I've got a working copy of this idea in a zip file, but i think
      attachments are not allowed here. Wait till I can upload it to the
      internet or I can gladly mail it individually.

      I've created a server-side solution for this(Javascript Sevices and
      JSDL), but it is another long story (may be I'll post it on some
      other mail) and covers a lot of other issues (eg. using MSMQ, RSS
      generation, Logging, Caching etc). JSDL is only a small part of it.
      It is called MS.Services and can be downloded from gotdotnet.com.

      Best regards,
      Mert Sakarya
    • Martin Cooper
      You might want to look at the Dojo toolkit. It already has a JSDL implementation that it uses along with its JsonService class for JSON-based remote calls. --
      Message 2 of 5 , May 23 9:14 AM
      • 0 Attachment
        You might want to look at the Dojo toolkit. It already has a JSDL
        implementation that it uses along with its JsonService class for JSON-based
        remote calls.

        --
        Martin Cooper


        On 5/23/06, Mert Sakarya <mertsakarya@...> wrote:
        >
        > Lately I've been coding with Javascript and JSON a lot. I'am using
        > XHConn.js (downloadable from http://xkr.us/code/javascript/XHConn/)
        > as XmlHttpRequest object which is quite small and efficient.
        >
        > I've noticed that it might be a good practice to move or copy the
        > business/application layer to the client side (basically some HTML
        > file). I've modified XHConn (XmlHttpRequest) a little, to use client-
        > side caching, work both synchronously and asynchronously and return
        > JSON objects only (currently it is using eval function for
        > performance). The thing, I like about using "eval" is, you can
        > create function properties.
        >
        > Assume that you have a service that works just like a web service,
        > but this one talks only JSON and works on Web pages over HTTP
        > (narrowed down the platform). JSON objects are results of our
        > WebMethods which are callable through XmlHttpRequests. If we can
        > group these methods in a service in a logical way, we
        > get "Javascript Services". So we need something like WSDL to combine
        > these methods. They should contain the definitions of the methods
        > (the body of the method is a XmlHttpRequest to the server),
        > parameter validation and some very light error checking (eg. if a
        > parameter can be null or the max length of parameter etc.). I call
        > this concept JSDL (Javascript Service Definition Language). The good
        > thing is, JSDL is itself written with Javascript and actually can be
        > a JSON object (if we are allowed to add functions to JSON standard).
        > In Javascript Services we can define functions like below;
        >
        > function GetCustomer(custId) {
        > if(!custId) throw "CUSTID null";
        > return (new XHConn()).connect("URL", "GET", "Parameters", null);
        > }
        >
        > or async version;
        >
        > function GetCustomerAsync(custId, asyncCallback) {
        > if(!custId) throw "CUSTID null";
        > (new XHConn()).connect("URL", "GET", "Parameters", asyncCallback);
        > }
        >
        > Now assume that we combine these method definitions in a JSON Object;
        >
        > Service.jsdl file
        > ------------------------------------------------------------------
        > {
        > "GetCustomer" : function(custId) {
        > if(!custId) throw "CUSTID null";
        > return (new XHConn()).connect("URL", "GET", "Parameters", null);
        > }
        >
        > "GetCustomerAsync" : function(custId, asyncCallback) {
        > if(!custId) throw "CUSTID null";
        > (new XHConn()).connect("URL", "GET", "Parameters",
        > asyncCallback);
        > }
        > }
        >
        > As long as "Service.jsdl" file is a JSON object, it can be
        > downloaded with XmlHttpRequest and be named as a service.
        >
        > //Synchronous version;
        > try {
        > var service = (new XHConn()).connect("Service.jsdl", "GET", "",
        > null);
        > var customer = service.GetCustomer("CustId");
        > } catch(e) {
        > alert(e);
        > }
        >
        > //Asynchronous version;
        > try
        > {
        > //probably we need to load the service synchronously
        > var service = (new XHConn()).connect("Service.jsdl", "GET", "", );
        > var customer;
        > service.GetCustomerAsync("CustId",
        > function(jsonObj) {
        > customer = jsonObj;
        > }
        > );
        > }
        > catch(e)
        > {
        > alert(e);
        > }
        >
        > All you need is to figure out a way to generate JSDL files on the
        > server-side just like WSDL files are generated may be something
        > like, attribute based programming on .Net.
        >
        > I've got a working copy of this idea in a zip file, but i think
        > attachments are not allowed here. Wait till I can upload it to the
        > internet or I can gladly mail it individually.
        >
        > I've created a server-side solution for this(Javascript Sevices and
        > JSDL), but it is another long story (may be I'll post it on some
        > other mail) and covers a lot of other issues (eg. using MSMQ, RSS
        > generation, Logging, Caching etc). JSDL is only a small part of it.
        > It is called MS.Services and can be downloded from gotdotnet.com.
        >
        > Best regards,
        > Mert Sakarya
        >
        >
        >
        >
        >
        >
        >
        >
        > Yahoo! Groups Links
        >
        >
        >
        >
        >
        >
        >


        [Non-text portions of this message have been removed]
      • Atif Aziz
        Mert, it seems to me that what you are proposing here is rather a JavaScript service proxy than a description language. A description language would be just
        Message 3 of 5 , May 24 12:36 AM
        • 0 Attachment
          Mert, it seems to me that what you are proposing here is rather a
          JavaScript service proxy than a description language. A description
          language would be just that, a description to be interpreted by a
          receiving party (without implementation details embedded as JS
          functions).

          As Martin already pointed out, someone over at Dojo has come up with SMD
          [1], but I think it's rather too simple and experimental right now. I
          added SMD support to Jayrock [2] some time back if you want to check it
          out. As for something like JSDL that you're proposing, you might want to
          check out how Jayrock does something similar already via dynamic proxy
          generation for the client. For a live demo, try this on your
          terminal/console:

          wget -O - http://www.raboof.com/Projects/Jayrock/Demo.ashx?proxy

          I've also worked towards an implementation-independent proxy that allows
          a service exposed via Jayrock to be called over any channel and
          client-side AJAX toolkit (be that YUI connection, Dojo, Atlas or your
          own home-grown stuff). You can get a crack at this by appending v=2 to
          the query component of the URL, as in:

          http://www.raboof.com/Projects/Jayrock/Demo.ashx?proxy&v=2

          The difference you'll see with the latter is that the proxy never makes
          the call or bears any implementation details about XmlHttpRequest. It
          simply prepares a call object that can be serialized and shipped over
          some arbitrary channel implementation.

          Finally, I'm working on the JSON-RPC 1.1 specification where one of the
          goals is to come up with a standard description language. If you're
          interested, hop over to http://groups.yahoo.com/group/json-rpc/ and see
          threads related to the 1.1 working draft (subject line is usually
          prefixed with "1.1WD"). You're feedback on what what's coming up in 1.1
          and how would be appreciated.

          - Atif

          [1] http://dojo.jot.com/SMD
          [2] http://blog.dojotoolkit.org/2006/03/11/jayrock-implements-smd
          [3]
          http://developer.berlios.de/feature/index.php?func=detailfeature&feature
          _id=1890&group_id=4638
          [3] http://www.raboof.com/Projects/Jayrock/Demo.ashx?proxy

          -----Original Message-----
          From: json@yahoogroups.com [mailto:json@yahoogroups.com] On Behalf Of
          Mert Sakarya
          Sent: Tuesday, May 23, 2006 10:38 AM
          To: json@yahoogroups.com
          Subject: [json] JSDL (Javascript Service Definition Language)

          Lately I've been coding with Javascript and JSON a lot. I'am using
          XHConn.js (downloadable from http://xkr.us/code/javascript/XHConn/)
          as XmlHttpRequest object which is quite small and efficient.

          I've noticed that it might be a good practice to move or copy the
          business/application layer to the client side (basically some HTML
          file). I've modified XHConn (XmlHttpRequest) a little, to use client-
          side caching, work both synchronously and asynchronously and return
          JSON objects only (currently it is using eval function for
          performance). The thing, I like about using "eval" is, you can
          create function properties.

          Assume that you have a service that works just like a web service,
          but this one talks only JSON and works on Web pages over HTTP
          (narrowed down the platform). JSON objects are results of our
          WebMethods which are callable through XmlHttpRequests. If we can
          group these methods in a service in a logical way, we
          get "Javascript Services". So we need something like WSDL to combine
          these methods. They should contain the definitions of the methods
          (the body of the method is a XmlHttpRequest to the server),
          parameter validation and some very light error checking (eg. if a
          parameter can be null or the max length of parameter etc.). I call
          this concept JSDL (Javascript Service Definition Language). The good
          thing is, JSDL is itself written with Javascript and actually can be
          a JSON object (if we are allowed to add functions to JSON standard).
          In Javascript Services we can define functions like below;

          function GetCustomer(custId) {
          if(!custId) throw "CUSTID null";
          return (new XHConn()).connect("URL", "GET", "Parameters", null);
          }

          or async version;

          function GetCustomerAsync(custId, asyncCallback) {
          if(!custId) throw "CUSTID null";
          (new XHConn()).connect("URL", "GET", "Parameters", asyncCallback);
          }

          Now assume that we combine these method definitions in a JSON Object;

          Service.jsdl file
          ------------------------------------------------------------------
          {
          "GetCustomer" : function(custId) {
          if(!custId) throw "CUSTID null";
          return (new XHConn()).connect("URL", "GET", "Parameters", null);
          }

          "GetCustomerAsync" : function(custId, asyncCallback) {
          if(!custId) throw "CUSTID null";
          (new XHConn()).connect("URL", "GET", "Parameters",
          asyncCallback);
          }
          }

          As long as "Service.jsdl" file is a JSON object, it can be
          downloaded with XmlHttpRequest and be named as a service.

          //Synchronous version;
          try {
          var service = (new XHConn()).connect("Service.jsdl", "GET", "",
          null);
          var customer = service.GetCustomer("CustId");
          } catch(e) {
          alert(e);
          }

          //Asynchronous version;
          try
          {
          //probably we need to load the service synchronously
          var service = (new XHConn()).connect("Service.jsdl", "GET", "", );
          var customer;
          service.GetCustomerAsync("CustId",
          function(jsonObj) {
          customer = jsonObj;
          }
          );
          }
          catch(e)
          {
          alert(e);
          }

          All you need is to figure out a way to generate JSDL files on the
          server-side just like WSDL files are generated may be something
          like, attribute based programming on .Net.

          I've got a working copy of this idea in a zip file, but i think
          attachments are not allowed here. Wait till I can upload it to the
          internet or I can gladly mail it individually.

          I've created a server-side solution for this(Javascript Sevices and
          JSDL), but it is another long story (may be I'll post it on some
          other mail) and covers a lot of other issues (eg. using MSMQ, RSS
          generation, Logging, Caching etc). JSDL is only a small part of it.
          It is called MS.Services and can be downloded from gotdotnet.com.

          Best regards,
          Mert Sakarya








          Yahoo! Groups Links
        • Mert Sakarya
          I ve finally had the time to check DOJO and JSDL and examining it since Friday.I think I ll be able to use my server-side application (JSDL definition) with
          Message 4 of 5 , Jun 4, 2006
          • 0 Attachment
            I've finally had the time to check DOJO and JSDL and examining it since Friday.I think I'll be able to use my server-side application (JSDL definition) with DOJO.

            It's good to know the people are thinking the same way, all over the world. I thought, that this was something that I've found, but hey, someone has already thought about it, and coded it on the web, while I was eating pizza ;). Even the extension was the same. So I think I'll use DOJO as my client-side library, instead of creating one from scratch.

            I know this is not the place to talk about it, but has anyone been using DOJO on real-time web project in this group? How does it perform? Any recommendations?

            Mert Sakarya


            To: json@yahoogroups.comFrom: mfncooper@...: Tue, 23 May 2006 09:14:10 -0700Subject: Re: [json] JSDL (Javascript Service Definition Language)You might want to look at the Dojo toolkit. It already has a JSDLimplementation that it uses along with its JsonService class for JSON-basedremote calls.--Martin CooperOn 5/23/06, Mert Sakarya <mertsakarya@...> wrote:>> Lately I've been coding with Javascript and JSON a lot. I'am using> XHConn.js (downloadable from http://xkr.us/code/javascript/XHConn/)> as XmlHttpRequest object which is quite small and efficient.>> I've noticed that it might be a good practice to move or copy the> business/application layer to the client side (basically some HTML> file). I've modified XHConn (XmlHttpRequest) a little, to use client-> side caching, work both synchronously and asynchronously and return> JSON objects only (currently it is using eval function for> performance). The thing, I like about using "eval" is, you can> create function properties.>> Assume that you have a service that works just like a web service,> but this one talks only JSON and works on Web pages over HTTP> (narrowed down the platform). JSON objects are results of our> WebMethods which are callable through XmlHttpRequests. If we can> group these methods in a service in a logical way, we> get "Javascript Services". So we need something like WSDL to combine> these methods. They should contain the definitions of the methods> (the body of the method is a XmlHttpRequest to the server),> parameter validation and some very light error checking (eg. if a> parameter can be null or the max length of parameter etc.). I call> this concept JSDL (Javascript Service Definition Language). The good> thing is, JSDL is itself written with Javascript and actually can be> a JSON object (if we are allowed to add functions to JSON standard).> In Javascript Services we can define functions like below;>> function GetCustomer(custId) {> if(!custId) throw "CUSTID null";> return (new XHConn()).connect("URL", "GET", "Parameters", null);> }>> or async version;>> function GetCustomerAsync(custId, asyncCallback) {> if(!custId) throw "CUSTID null";> (new XHConn()).connect("URL", "GET", "Parameters", asyncCallback);> }>> Now assume that we combine these method definitions in a JSON Object;>> Service.jsdl file> ------------------------------------------------------------------> {> "GetCustomer" : function(custId) {> if(!custId) throw "CUSTID null";> return (new XHConn()).connect("URL", "GET", "Parameters", null);> }>> "GetCustomerAsync" : function(custId, asyncCallback) {> if(!custId) throw "CUSTID null";> (new XHConn()).connect("URL", "GET", "Parameters",> asyncCallback);> }> }>> As long as "Service.jsdl" file is a JSON object, it can be> downloaded with XmlHttpRequest and be named as a service.>> //Synchronous version;> try {> var service = (new XHConn()).connect("Service.jsdl", "GET", "",> null);> var customer = service.GetCustomer("CustId");> } catch(e) {> alert(e);> }>> //Asynchronous version;> try> {> //probably we need to load the service synchronously> var service = (new XHConn()).connect("Service.jsdl", "GET", "", );> var customer;> service.GetCustomerAsync("CustId",> function(jsonObj) {> customer = jsonObj;> }> );> }> catch(e)> {> alert(e);> }>> All you need is to figure out a way to generate JSDL files on the> server-side just like WSDL files are generated may be something> like, attribute based programming on .Net.>> I've got a working copy of this idea in a zip file, but i think> attachments are not allowed here. Wait till I can upload it to the> internet or I can gladly mail it individually.>> I've created a server-side solution for this(Javascript Sevices and> JSDL), but it is another long story (may be I'll post it on some> other mail) and covers a lot of other issues (eg. using MSMQ, RSS> generation, Logging, Caching etc). JSDL is only a small part of it.> It is called MS.Services and can be downloded from gotdotnet.com.>> Best regards,> Mert Sakarya>>>>>>>>> Yahoo! Groups Links>>>>>>>[Non-text portions of this message have been removed]
            SPONSORED LINKS



            Programming languages
            Format
            Computer security

            Computer training
            Large format
            Cover letter formats


            YAHOO! GROUPS LINKS

            Visit your group "json" on the web.
            To unsubscribe from this group, send an email to: json-unsubscribe@yahoogroups.com
            Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



            _________________________________________________________________
            It�s the future of Hotmail: Try Windows Live Mail beta
            http://www2.imagine-msn.com/minisites/mail/Default.aspx?locale=en-us

            [Non-text portions of this message have been removed]
          • Martin Cooper
            ... You re right, this is not the place to talk about Dojo. You should check out the Dojo mailing lists, and the archives of those lists. There are many, many
            Message 5 of 5 , Jun 6, 2006
            • 0 Attachment
              On 6/4/06, Mert Sakarya <mertsakarya@...> wrote:
              >
              > I've finally had the time to check DOJO and JSDL and examining it since
              > Friday.I think I'll be able to use my server-side application (JSDL
              > definition) with DOJO.
              >
              > It's good to know the people are thinking the same way, all over the
              > world. I thought, that this was something that I've found, but hey, someone
              > has already thought about it, and coded it on the web, while I was eating
              > pizza ;). Even the extension was the same. So I think I'll use DOJO as my
              > client-side library, instead of creating one from scratch.
              >
              > I know this is not the place to talk about it, but has anyone been using
              > DOJO on real-time web project in this group? How does it perform? Any
              > recommendations?


              You're right, this is not the place to talk about Dojo. You should check out
              the Dojo mailing lists, and the archives of those lists. There are many,
              many hundreds of Dojo users on the list, so you will get lots of feedback if
              you ask the right questions.

              That said, as for "real-time", it somewhat depends on how you define that
              term. Do you mean highly interactive applications, or do you specifically
              mean Comet applications? Two commercial examples that might be of interest
              to you are http://www.jotlive.com/ and http://www.renkoo.com/. Both are
              built on Dojo.

              At my company, we are using Dojo in current product development, but not for
              real-time purposes (since we don't have any real-time requirements at this
              time). You'd have a hard time persuading me to use anything else.

              --
              Martin Cooper


              Mert Sakarya
              >


              [Non-text portions of this message have been removed]
            Your message has been successfully submitted and would be delivered to recipients shortly.