connections to the 'outside world'

[Josmas Flores]

Hi guys, I need to check a couple of facts with you regarding
connections to external webservices.

Thinking out loud here but I hope it makes sense, if anyone can help!
After reviewing this thread
(https://groups.google.com/group/openwonderland/browse_thread/thread/156addc08d2ee643/c04197b5a6d776d1?hl=en&lnk=gst&q=darkstar+service)
I want to check the following two scenarios.

Scenario 1:
Say that I don't want to share anything with any other users (no
server interaction), I just want to retrieve a certain amount of
information from a webservice and show it in a Swing App that only I
can see. Can I create the external connection directly from the
client? or, in other words, am I restricted due to transactions or
threading, etc.?
I will probably be using the client's credentials so as the thread
reads, this is probably the best way to stablish the connection.

If I wanted at some stage to share info with other users, I would go
on and use the server support to do so (MOs, messages, and so on).

My understanding was that if the connection takes too long (imagine
that you are downloading a document), it would get squashed by
Darkstar, and that the only way to avoid this was by writing a
Darkstar service to be used in the client. Is this correct?

Scenario 2: If the server is the one connecting in order to make some
info available to everyone in-world, then a darkstar service is the
only way to go (unless you download to client and from client send to
server, but you depend on a client being logged in for the thing to
work!).

So, in summary:
1: connecting from the client I don't have to worry about timing?
2: connecting in behalf of the server, I need to write a darkstar service.

cheers,
Jos

[Morris Ford]

Breaking your request into three (semi)independent parts, ie, a mechanism to display info, a method to retrieve the info and a method to move the data to other clients. The displayer of the info could be a scripted swing app or a java swing app client. I think I would choose a scripted swing app, probably javascript because of the ease of writing swing apps in javascript,  to make the other two parts easier.

The retriever of the info, depending on the source of the info, could be a variety of different script languages. I might choose php here because I have done a bit of retrieving and parsing of web service data in php using curl. I would then use an inter-cell event (ICE message) to pass the data to the displayer. Like

MyClass.postMessageEvent(theData, 456);

and to post the data across the server to the other clients the command would be

MyClass.postMessageEventToServer(theData, 456);

and that would take care of getting the data across to any other client that is connected.

There are of course some details but not too many.

Morris

[Josmas Flores]

Hey Morris, thanks for the tip. I had thought of the servlet in the
scripting module, but this is actually more of a documentation effort.
I want to start a new page in the community wiki about services so if
anyone can validate the scenarios, that would be a lot of help!

cheers,
José

[Jonathan Kaplan]

Jos,

This is generally correct.

In Scenario 1, you are using normal Java calls on the client, so there are no restrictions in terms of threading or networking. Darkstar is not involved in the client at all, so there are no timeouts and no relevance of Darkstar services. Basically the client can fetch data in whatever manner it sees fit, and share some or all of that with other clients via the server.

An example of Scenario 1 would be a flickr viewer. The user enters a query, and their client then sends that as a photo query to flickr. Flickr returns a set of photo URLs to the client. The client then sends messages to the server to create a bunch of image viewer cells for the photos, which are visibile to everyone because the image cells include the URL of the photos.

In Scenario 2, the actual work is performed on the server, by way of a Darkstar service. This is subject to all the restrictions of Darkstar programming, including threading and transactions. The advantage of this scenario is that the querying is only done once, and everyone sees the same results.

An example of Scenario 2 would be access to a relational database. Since individual clients can't connect to the database directly, the server connects to the database and relays results to clients.

There is also a Scenario 3, which is kind of a hybrid of 1 and 2. In this case, you have a separate process that talks to the external service and then sends messages to the Darkstar server. It has the benefits of both scenarios: you can use any library without worrying about threading or transactions, but because there is single, permanent process, it can supply data for everyone in the world via a single connection. The only downside is that you have to manage the separate process. This is how, for example, the Shared Application Server works.  You could imagine plugging into XMPP chat servers this way as well.

[Josmas Flores]

Thanks Jon, that makes it 'almost' all very clear... the only thing is
that if from the client you can use any Java you want... why can you
not access a DB if you program the access on the client side?

cheers,
José

[Jonathan Kaplan]

Technically, there is no reason your database couldn't be accessible to every client. Realistically, databases are usually tightly controlled behind firewalls, with limited usernames and passwords for access. So rather than making your database available outside the firewall, giving every client credentials to log in, and requiring an extra network connection, it is usually better to have the server access the database and feed the results to clients.

Alternatively, a custom client (Scenario 3) could run behind the firewall and access the database as needed. That way you wouldn't have to write a Darkstar service, but you could still access the database in a controlled manner.

I've always referred to Scenario 3 as a "custom client" or "standalone client". Reading this discussion is making me think that "bridge" might be a better term -- the custom client in this case is a bridge between the database and Darkstar.

[Josmas Flores]

Thanks again Jon, I understand what you say about access an all that,
but I just needed a clear 'technical' picture in my head so that I can
write it up.

Bridge makes a lot more sense than custom or standalone, no doubt!

cheers,
José

[Josmas Flores]

Link to the document in the community wiki:
http://faithhold.dyndns.org:8080/JSPWiki/Wiki.jsp?page=Communicating%20with%20external%20services

Thanks for your help guys!
José

On Feb 2, 8:27 pm, Josmas Flores <josmasflo...@gmail.com> wrote:
> Thanks again Jon, I understand what you say about access an all that,
> but I just needed a clear 'technical' picture in my head so that I can
> write it up.
>
> Bridge makes a lot more sense than custom or standalone, no doubt!
>
> cheers,
> José
>

> On 2 February 2011 19:56, Jonathan Kaplan <jonathan...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Technically, there is no reason your database couldn't be accessible to
> > every client. Realistically, databases are usually tightly controlled behind
> > firewalls, with limited usernames and passwords for access. So rather than
> > making your database available outside the firewall, giving every client
> > credentials to log in, and requiring an extra network connection, it is
> > usually better to have the server access the database and feed the results
> > to clients.
> > Alternatively, a custom client (Scenario 3) could run behind the firewall
> > and access the database as needed. That way you wouldn't have to write a
> > Darkstar service, but you could still access the database in a controlled
> > manner.
> > I've always referred to Scenario 3 as a "custom client" or "standalone
> > client". Reading this discussion is making me think that "bridge" might be a
> > better term -- the custom client in this case is a bridge between the
> > database and Darkstar.

> > On Wed, Feb 2, 2011 at 11:45 AM, Josmas Flores <josmasflo...@gmail.com>

> > wrote:
>
> >> Thanks Jon, that makes it 'almost' all very clear... the only thing is
> >> that if from the client you can use any Java you want... why can you
> >> not access a DB if you program the access on the client side?
>
> >> cheers,
> >> José
>

> >> > On Wed, Feb 2, 2011 at 8:16 AM, Josmas Flores <josmasflo...@gmail.com>

> >> > wrote:
>
> >> >> Hi guys, I need to check a couple of facts with you regarding
> >> >> connections to external webservices.
>
> >> >> Thinking out loud here but I hope it makes sense, if anyone can help!
> >> >> After reviewing this thread
>

> >> >> (https://groups.google.com/group/openwonderland/browse_thread/thread/1...)