Results 1 to 4 of 4
  1. #1

    Usecase of MetadataAdapters

    from what i've seen, MetadataAdapters are used for receiving messages (sent by client's sendMessage) and managing the new session for a new subscription (acess, bandwidth,..)

    in my app, there can be a client A that will subscribe to "foo" and "bar", then another client B subscribing to "quux", the subscribe event is caught in the DataAdapter that will later send data to either "foo", "bar" or "quux"
    all "quux" updates are sent to only its subscribers, B for example

    So in this case with just pushing, DataAdapter does it all, I don't need to set up and launch a MetadataAdapter right? or I miss something

    i can pass more settings in the subscription name "foo|param1|param2" then unsubscribe and subscribe to "foo|param1|param3" if the client changes a parameter, ugly but it's ok no?

    thanks
    Last edited by darch; March 22nd, 2013 at 12:39 PM.

  2. #2
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    543
    Hi darch,

    Each Adapter Set defined for an instance of Lightstreamer must necessarily have a Metadata Adapter defined in the adapters.xml.

    We provide inside the ls-generic-adapters.jar a fake metadata, LiteralBasedProvider, which performs the basic functionality, such as the getItmes, which are always called from the server. You can see for example the HelloWorld demo and the adapters.xml configuration file proposed in this tutorial.

    However, in realistic production scenarios, we recommend to implement a custom Metadata to implement authentication and security policies as well as the management of the ItemGroup and FieldSchema.

    Please note that you can also implement a remote DataAdapter but a MetadataAdapter inprocess in Java with a minimal set of features implemented.

    Hope that Helps.

  3. #3
    thanks, i'm more using the dotnet remoted architecture
    so the basic metadataAdapter:
    Code:
      <metadata_provider>
        <adapter_class>com.lightstreamer.adapters.metadata.LiteralBasedProvider</adapter_class>
      </metadata_provider>
    is not recommended in production?

    probably the fact that cross domain is enabled, then the sendMessage() without password or such is unsecure.
    but in my case, i will not send messages from javascript, they will be processed via other ajax-php script that checks user's authenticated session, it's less complicated than doing twice this job (sessions in apache-php already there, + sessions in lightstreamer metadata).
    do you think, using the basic metadataadapter is ok in my case?
    Last edited by darch; March 22nd, 2013 at 12:44 PM.

  4. #4
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    543
    Please note, as suggested in section 4.1 of this document, that it is not necessary to repeat the authentication process twice; if the actual authentication is handled by other ajax-php script, I suppose that some sort of session_id is sent back to your Client. When the Web Client creates the Lightstreamer session, instead of sending again the full credentials (usually involving a password) to Lightstreamer Server, it sends just the session_id (or the username and the session_id). The Metadata Adapter is passed this information and validates the session_id against the Web/Application Server that generated it (or a database or whatever back-end system).

    Anyway, the use of LiteralBasedProvider metadata, at least not subclassed, is not reccomended in every production environment.

 

 

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 11:41 AM.