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, but the user visible part will contain:

• Retrieve resource list - the list should not contain users, groups and other administrative resources. This should depend on user privilegies.
• Filter the list - filtering should allow filtering books, image frames, etc.
• Retrieve preview of a resource (not part of this task)
• Retrieve meta of a resource (not part of this task)
• Edit resources - depends on user permissions
• Delete resources - depends on user permissions
• 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.

Related

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

Module Decomposition

This is the component diagram for the server decomposition:

Currently there is a clear separation of the classes into packages, which will ease the module decomposition:

• org.sophie2.server.service - core
• org.sophie2.server.facade - core
• org.sophie2.server.webapp - webui
• org.sophie2.server/src/main/resourcesjsps - webui
• org.sophie2.server.webservice - ws
• org.sophie2.server.persistence - persistence.

Facade

For server resource access, the facade needs to implement an additional method - getResourceManager() that will return an instance of the ResourceManager class. This is a new class that will be created and will support basic manipulation of resources. It should have the following methods (at this iteration):

• getResourceList(). It will return list of all book resources on the server (without users and groups). Actually returns ResourceRefs, which hold enough information for resource names, resource IDs on the server, etc.
• getResource(String entityId) - will get a resource by a given entityId.

There will be concrete implementations of these methods in both the client and the server.
UserManager and GroupManager can be combined as SecurityManager, since we do not need such division.

Client

Currently the client successfully establishes a session to the server using the Connections palette in the Servers tab of the left flap. The username and password used are hardcoded at the current stage and will be left this way at this iteration.

A class ServerResourcesPalette will be created in org.sophie2.main.func.servers. It will track the currently selected element in ConnectionsPalette (using the findNearestElement method) and if there is a connection established, it will use it to obtain a list of server resources. The only action it will support at this iteration is double-click on a book item. This will get and open the selected book, using the current app logic.

• Client implementation of Facade .

Server

• Server implementation of the facade

Implementation

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

Testing

^{Place the testing results here.}

Comments

• Implement the resource list filtering at the next iteration of this task or of APP_SERVER_RESOURCE_BROWSER_FILTER_R0? (512) --boyan@2009-06-09
• Provide a dialog for entering a username and password for connection to the server at the next iteration of this task or at some of the connectivity tasks. --boyan@2009-06-11