wiki:GROUP_APP_SERVER_RESOURCE_ACCESS_R0

Version 12 (modified by kyli, 16 years ago) (diff)

--

Error: Macro BackLinksMenu(None) failed
compressed data is corrupt

Error: Macro TicketQuery(summary=GROUP_APP_SERVER_RESOURCE_ACCESS_R0, format=table, col=summary|owner|status|type|component|priority|effort|importance, rows=description|analysis_owners|analysis_reviewers|analysis_score|design_owners|design_reviewers|design_score|implementation_owners|implementation_reviewers|implementation_score|test_owners|test_reviewers|test_score|) failed
current transaction is aborted, commands ignored until end of transaction block

Analysis

Overview

This group of tasks is about accessing resources on the server from the client application.
Sophie2 Author (and probably Reader) should provide a palette that lists the resources on a given server and allows actions to be taken on them. The exact list of actions is not yet well defined - for sure, it must be able to open them. Resource listing will be available only if a connection to a server is established and selected.
The server, on the other hand, should provide a facade and web services for resource access. At this iteration, a prototype of this will be created, allowing users to remotely open a book that resides on the Sophie 2 Server.

Task requirements

  • Decompose the server in appropriate modules with well-defined functionality (and do the refactoring needed):
    • Server persistence at this iteration is not a requirement. It can be fake (dumping everything to memory) for ease of implementation.
    • The Sophie2 Server should use the base resource model of Sophie2 (that includes book, users and groups at this iteration).
    • S2S should be accessible only through the facade.
    • The modules should be well structured, with clear communication between each other.
    • It would be good to create a draft diagram of the modules decomposition.
  • Revise the currently implemented app_connectivity part (ability to establish a session), if it is not currently working, make it work with the new server model. It will be needed for resource listing.
  • Add resource access support for the server (it currently only provides access to user and group managers):
    • Implement both the server-side and the client-side of the facade. This way the client will be able to connect to the server and access resources there.
  • Create a palette for listing server resources and make it work synchronously with the existing Connections palette (i.e. display the resources of the server we are connected to):
    • It should be in the Servers tab in the left flap.
    • At this iteration it should list all the resources on the server (users, groups, books). No resource list filtering is required.
    • It should support opening a book on a double-click (other actions will be implemented at a next iteration).

Task result

  • Source code:
    • New Server module structure.
    • Ability to open a book from the server.

Implementation idea

Web Services

Since changes serialization is not implemented yet, it is not possible to send changes from the server to the client. For this revision, it would be best to use the current persistence and send a copy of the book in persisted format to the client. The client on its turn will download the book and open it. This will be good for demonstration of the working web services, as well as client connectivity. It will also show that the server really works with the base modules and with the client resources.

S2S Decomposition

Here is a brief idea for a module decomposition, discussed 2 months ago:

  • There will be a server.persistence module which will eventually maintain a database with some records. It will grant access only to the S2S core. (Actually, there is currently such module).
  • There will be a server.core module, which uses the persistence one and adds some business logic to it - sessions, resource access, etc. It will also hold a server facade, which will expose the core functions. The functions themselves will not be accessible by anyone except the facade.
  • There will be modules for S2S UI, S2S Web Services and eventually S2S Direct connect. They will communicate with the core facade and will eventually be extensible.
  • The client will have modules which connect to the web services / direct connect and provide the facade API to Sophie2. Currently, there is one such module - server.web_services, which is used only by base.connecticity.

GROUP_BASE_SECURITY_R0
S2S_WS_CONNECTOR_R0

How to demo

  • Start Sophie2 Server and Author.
  • Connect to a server from the Left Flap -> Servers Tab -> Connections palette.
  • Double-click on a book from the list below.
  • Show the new module structure.
  • Run the test and briefly describe the changes made.

Design

Component diagram for server decomposition: source:branches/private/kyli/sophie2-platform/modules/org.sophie2.server/doc/

Implementation

Describe and link the implementation results here (from the wiki or the repository).

Testing

Place the testing results here.

Comments