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. 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/resources/jsps - webui
• org.sophie2.server.webservice - ws
• org.sophie2.server.persistence - persistence
• FakeServerMain, server.bundles.config - server.

Facade

Currently, the facade interfaces - Facade, UserManager, GroupManager are located in org.sophie2.base.connectivity. They have 2 corresponding implementations - one for the server core, and one for the web services connector. 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 absolute ResourceRefs, which hold enough information for resource names, resource location, etc.
• getResource(String absoluteLocation) - will get a resource by a given absolute location.

There will be concrete implementations of these methods in both the client and the server.

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: getResourceList() will be implemented analogically to the login() method - the list of resourceRefs will be sent in XML format and read analogically. For the new references to be reconstructed we only need the absolute location. For getResource(), the client facade needs to download the persisted file and use the loader to open it. After that, it will be returned as a result.

Server

The BookService class does not make sense anymore (a Book is a Resource), but it could be useful for resource management. BookService will be renamed to ResourceService (its tests and methods, too). It also needs some changes:

• deleteBook can accept absolute location instead of a resource as an argument. It should also be renamed to deleteResource.
• getAllResources must return List of ResourceRefs instead of a list of Resources.
• The same applies for searchBook. It must also be renamed to searchResource.
• A getResource(absoluteLocation) method is needed. It must use the ResourceRef#getAbsoluteReference(String absoluteLocation) method in order to provide enough information for referencing resource on a server. This reference does not give us information about the EntityId of the reosurce, so for performance issues it would be best to use resource location as key in the fake persister (implemented in GROUP_BASE_SECURITY_R0).
• All the methods here must accept absoluteLocation as arguments, not entityIds.

The BookDao must also be refacored as ResourceDao (as well as methods and tests related to it). It should also have the getResource(String absoluteLocation) and getResourceList() methods.
The Web Services need also ResourceWebService. It will be a very-proto-revision and currently will persist a particular resource, making it available for download. Then, the file will be written as a response using output stream. Also, will need a persister for list properties to XML document to pass the list of ResourceRefs for getResourceList() method. This persister must be in some of the base classes - base.connectivity for example, in order to be used by both client and server facades.

• Server implementation of the Facade: just call the core methods and return their results. Tests seem trivial, since this facade has no logic for now.

• If there is time left, move all the *service logic to the corresponding *manager class. The main idea here is to have a simpler server core - it will only be a facade implementation. This is not a requirement of the analysis, so it is not obligatory for this revision. But it will ease the core structure and therefore the module decomposition.

Base tests for this task are:
ServerResourceManagerTest.java
ResourceServiceTest.java
Changeset: [3472]

Implementation

Module decomposition needed thorough refactoring of the servlets and jsp's, so some other things have been done:

• There is no more SophieBaseServlet, it's been replaced by the org.sophie2.server.webapp's extension point.
• One more module was created - org.sophie2.server.webapp: it starts the jetty server, registers the extensions provided by webui and webservices.
• org.sophie2.server just starts the needed modules, like in org.sophie2.author.
• Some jsp's are broken, but not deleted - they are moved in "broken jsps" directory and will be reimplemented in the task about webui. This is caused by the fakeResourceDao, which does not provide search methods, for example.
  

A new persister - from list of resource refs to org.w3c.Document was written. Its idea is to persist the result of getResourceList() in order to be sent to the client. The client also uses this persister to load the result. This way, we make an unified way of transporting data from server to client - looks like much better than XMLManagementService. So, for the next revision it would be a good idea (maybe) to remove this service.
Maven does not need anymore "-Djspcompile" in order to run the true configuration.
The server starts with loading a test book, so it waits about 5 seconds for persisters to be registered.

Changesets:

[3578], [3579], [3580], [3581], [3582], [3583], [3586], [3587], [3589], [3590], [3619], [3629], [3672], [3674], [3690], [3694], [3724], [3725], [3730], [3731], [3732]

Merged into the trunk in [3757].

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