The application layer uses the services (DRM and context) to offer own solutions.
These solutions are mostly:
• Content oriented: offering, manipulating, integrating, etc. content from one or more content and License Services.
• Statistics oriented: offering, integrating, etc. statistics from one or more Accounting Services.
We work out an example for each solution type.
5.8.1 Content oriented
Suppose someone wants to create a specialized shop where you can buy everything about a particular subject, e.g. Lord of the rings. The entrepreneur does not want to host content itself, but instead redirects customers to publishers offering the requested content. The dealer asks money for the usage of his integration service, while the publisher is paid for content and licenses.
This can be achieved by the usage of the broker pattern. A custom content integration service is plugged-in as service. This service (see figure23on page 53) supports an N:1 topology that separate read-only distribution rules and interme-diary results. It allows a single interaction from a customer to be distributed to multiple Content Services concurrently.
The solution is divided into a number of logical components:
• The customer represents one or more customers that are interested in inter-acting with Content Services of other publishers.
• The Entrepreneur Service supports message routing, decomposition and re-composition, message enhancement and transformation. Rules for doing this are stored read-only (R/O). This service also uses a work-in-progress data store (WIP) to retain the intermediate results from responses coming back from target applications until all the necessary responses are received.
• The Content Services represents Content Services in multiple partner orga-nizations.
Obtaining content from the entrepreneur succeeds in several steps. First, a cus-tomer contacts the Entrepreneur Service (possibly after authenticating) by query-ing for content. Secondly, the Entrepreneur Service concurrently queries several Content Services of multiple publishers. Thirdly, the Entrepreneur Service waits for answers. What happens next, depends on the business model. For instance, the entrepreneur can resell content or redirect the customer to the right publisher.
If the entrepreneur resells content, its service obtains7 content and a redis-tribution license from the publisher who offered the cheapest book. The service repackages the content and gives it to the customer with a corresponding license.
If the entrepreneur redirects the customer, its service combines the search re-sults and presents them to the customer. The customer selects one, and finally is redirected8 to the publisher who offers the selected content.
5.8.2 Statistics oriented
Suppose someone wants to offer statistics about content produced by some pro-ducer, published by more than one publishers. Therefore, he can use a slightly variation of the above solution:
• Replace customer by producer.
• Replace Content Service by Accounting Service.
6 Evaluation and related work
This section highlights the main advantages of having a detailed architecture, i.e.
dealing with quality requirements. It first defines the main quality attributes that are relevant for DRM systems. Secondly, it describes how the proposed architec-ture supports each of these attributes in form of quality scenarios. The section closes with discussing main conclusions we can draw from this evaluation.
6.1 Evaluation criteria and quality attributes
This section applies an architecture evaluation by usage of quality attributes on recent technologies such as DMP and AXMEDIS.
7The Publisher can offer him a subscription based billing model.
8The entrepreneur can authenticate the customer before redirection.
A quality attribute is a property of a work product (or software architecture) by which stakeholders can judge its quality. These properties, like for instance interoperability, modifiability, or extendability may have significant impact on the architecture of a system [2]. As such, quality attributes are generally accepted to be crucial attention points during the early phases of system development, i.e.
analysis and architecture design.
It should be clear that many quality attributes must be supported when build-ing and deploybuild-ing DRM systems or content distribution applications: interop-erability, modifiability, extendability, usability, testability, availability, security, performance, scalability, etc.
Since many interpretations of these attributes exist, we provide a definition for a selection of them and motivate why it is an important concern for DRM systems:
• Interoperability. The ability of two or more (sub)systems to cooperate at runtime. Interoperability of DRM service components is highly important given the complexity and extensiveness of DRM functionality, as well as the rapidly evolving field, which imply that multiple variants of the same service will co-exist and should be able to co-operate.
• Accountability. The ease to add accounting and consumer tracking aspects to the system. Since business and payment models will likely be personal-ized, and since license abusers should be identifiable, tracking of consumer activities is a crucial concern.
• Modifiability. The ease with which a software system can accommodate changes to its software. License and payment models will involve various publisher specific policies, which implies that the publishing system’s behav-ior must be modifiable to accommodate varying policies.
• Extendability. The ease to add new features to the system. Since the domain of software security and DRM is highly dynamic, DRM systems must embrace change and be open to extend their functionality with new or improved security technologies.
• Usability for developers. Programming support and ease of use for devel-opers of the system. In order to prevent security holes in DRM software, it is highly important to guide developers and force them as much as possible in a well-defined software architecture.
• Testability. The ease with which software can be made to demonstrate its faults. Testability is crucial for every publicly accessible system, especially if authentication, authorization, and accountability is at stake, as is the case with DRM.
• Availability. Availability can be measured as the time that the system is up and running correctly, the time between failures, and the time needed to resume operation after a failure. Business systems should be ’constantly’
online, which is highly challenging in a rapidly evolving field which implies frequent (security) updates.
• Performance. Performance can be measured as the number of transactions per second (throughput). Performance is important for a DRM system, because consumers do not want to wait longer to consume protected content than to consume unprotected content.
• Reusability. Reusability is the degree to which a software module or other work product can be used in more than one computing program or software system. This quality attribute is important for almost every software system, including DRM systems, because it saves a lot of development time, aids interoperability and reliability.
QualityattributeArchitecturalstyleAdvantage/Disadvantage Interoperabilityservicecomponents,brokerreusableservicecomponents,messageconversion, clearlydefinedinterfaces Accountabilitybroker,componentgroups(+)brokerallowstransparentmessageinterception Modifiabilitybroker,servicecomponentsbehaviordescribedinpluggablepolicies Extendabilitybroker,servicecomponentssecuritycomponentsregisteredatbroker Usabilityfordevelopersservicecomponents,overallarchitecture(+)hotspotstoinsertservicecomponents, layeredsecuritylayer Testabilitycomponentgroups(+)hierarchicalviewsallowsincrementaltestapproach Availabilitybroker(-)singlepointoffailure Performancebroker(-) Reusabilitycomponents(+) Table5:Overviewofmainqualityattributes,thearchitecturalstylesthatsupportthem,andthebenefitstheyoffer.
Quality attribute Proposed Architecture DMP Axmedis
Table 6: Comparison between the proposed architecture and the DMP architecture related to their support for quality attributes.