XML Security in the Next Generation Optical
Disc Context
Gopakumar G. Nair1, Ajeesh Gopalakrishnan1, Sjouke Mauw1, and Erik Moll2
1 Eindhoven University of Technology (TU/e),
Eindhoven, The Netherlands
{G.gopakumar, A.gopalakrishnan, S.mauw}@tue.nl
2 Philips Applied Technologies,
Eindhoven, The Netherlands
Erik.moll@https://www.doczj.com/doc/766325347.html,
Abstract. The Extensible Markup Language (XML) is considered as the de
facto standard for information processing and exchange on the Internet and in
the enterprise services domain. It is widely regarded that XML has the potential
of being an interoperable standard for interactive applications in the next gen-
eration connected Consumer Electronic devices. A key industry concern in us-
ing XML in CE devices is that how basic security requirements pertaining to
the above said domain can be met. Notably, the standardization bodies of the
Internet domain such as W3C and OASIS have defined specifications for cryp-
tography-based security solutions using XML technology that is mainly aimed
for web applications. This paper investigates and presents various scenarios
where XML Security can be applied to markup based interactive applications in
the context of a next generation Consumer Electronic Optical Disc Player. We
conclude the paper by presenting a prototype establishing how these scenarios
could be realized in practice.
1 Introduction
Until recently, the diverse and well-established domains of Personal Computers (PC), Web (Internet), Consumer Electronics (CE) and Broadcast domains have had their own autonomous realms of existence. Each of these domains spawned their own char-acteristic and individualistic ways of managing and doing things, with examples as diverse as the application specification to the very notion of interactivity. However, lately there has been considerable interest among these domain communities to share and adopt inter-domain best practices and knowledge. As an illustration, the content creators could create applications for one domain, which could be seamlessly inte-grated or be transferred to other domains. Such integration could provide new usage models in the CE optical disc domains [2]. As a fleshed out example, the content crea-tors could author multi-domain interoperable applications which could be packaged in a disc and additional application extensions such as bonus materials, clips etc could be downloaded from a content server or a set top box in a home network, thus bor-rowing the ideas from Web and Broadcast domains. One of the possible candidates W. Jonker and M. Petkovi? (Eds.): SDM 2005, LNCS 3674, pp. 217–233, 2005.
? Springer-Verlag Berlin Heidelberg 2005
218 G.G. Nair et al.
for this cross-domain sharing is the XML and its related technologies, which entails the core theme of discourse in this paper.
XML is emerging as the de-facto standard for storing, managing, and communicat-ing information on the Internet [1]. In addition, XML is the basis for markup applica-tions and a wide range of XML based languages [7] for various web services. Several standardized interfaces, tools, techniques and their programming language bindings are available, both commercial and open source. This makes XML a serious con-tender for being considered as a standard for creating consumer interactive multime-dia systems, the market where disc based systems mainly belong. A well-known ex-ample of such a standard is DVB-HTML [8], an XML based interactive application specification for Multimedia Home Platform [8] which has been existing for several years. With such pervasive and proven applications and usage scenarios of XML in a myriad of domains, it is without doubt a pick while considering the specification for Interactive Applications in next generation optical discs. Certainly, in combination with a procedural language, such as Java such a standard would open up new possi-bilities in bringing interactivity to such devices.
Next generation optical disc formats such as Blu-ray disc (BD) [2], High Defini-tion (HD) DVD, and enhanced DVD (eDVD) [31] are reckoned as the natural succes-sors of DVD as a medium for storage, playback and distribution of digital media [2].
Fig. 1. End-to-End Usage Model (based on [1])
Figure 1 depicts the end-to-end usage model of the next generation optical discs based players in a consumer home. The movie companies distributes the High Defini-tion (HD) content via optical discs as medium or via HD broadcast and the optical disc player equipment at the consumer home can playback the content on HD Televi-sions. As a consequence, the consumers get High Definition (HD) video experience, the content providers (movie companies) get the opportunity to store and distribute high quality videos and games and the independent content creators and vendors have the opportunity to provide value-added media based services. Additionally, due to the wide availability and growth of broadband connections, new Internet based usage models to download applications from content servers are foreseen for such devices
XML Security in the Next Generation Optical Disc Context 219 due to the perceived characteristics of these devices to connect to Internet. In order to realize this, the next generation optical discs would need an interoperable interactive application specification with adequate considerations for security.
In the context of next generation optical disc players, careful consideration should go into the interactive application security issues while considering the usual issues of copy protection of audio and video content. In this case, the applications could also be copyrighted and could be subjected to malicious usage. To give an example, consider a malicious application loaded from an external server that could corrupt the local storage of the player. As another example, the user could try to create his/her own ap-plication, load to the system and try to access content where he has no access rights. The security mechanisms that could prevent such issues must be non-invasive to the users, should be capable of being applied easily by the content creators and be neces-sarily future proof. Additionally, the opted security mechanism should be flexible, in-teroperable, and widely supported with appropriate tools and libraries in order to be accepted by the manufacturers.
W3C [22] and OASIS [18], the major standardization bodies within the Internet domain, have been working on creating XML based security standards for web-based applications. We foresee that these standards can be applied with the XML based in-teractive applications for the next generation optical disc systems. In this paper we discuss which are these standards, what problems they can solve in a disc player con-text and how we can establish the end-to-end security. We also see whether these mechanisms are realizable in an embedded system context.
This paper first portrays a typical markup based Content Hierarchy depicting the Interactive Applications in the next generation optical discs. Further to that, we char-acterize the security profile of a connected player by applying analytical Threat Mod-eling and ascertaining the detailed security requirements for this paper from the Threat model, which will be used for the rest of the discussions. Various XML Secu-rity standards are presented with their proposed solutions for the above said security requirements. Additionally, an end-to-end security scenario is presented and a pro-posal of how all the security standards could be brought together to guarantee an end-to-end security solution is exposited. Finally, to substantiate the proposal, a prototype implementation is detailed on a next generation optical disc reference platform.
2 A Markup Based Content Hierarchy
Optical discs are intended to store digital content, the term, used to describe any kind of collection of functional work, artwork, or other creative content, copyrighted or otherwise distributed in an optical disc. In this section, we introduce the content hier-archy in the next generation optical discs; in particular, the markup based application hierarchy, which can be used for representing Interactive applications. The Interactive Application refers to a part of the overall content that can be executed by the optical disc player.
At the top of the content hierarchy (see Figure 2) is the Interactive Cluster, which is the generic representation of packaged content, including Video, Audio and markup Application. The Interactive Cluster contains several Tracks, which form chapters for Video/Audio Playlist [23] and optionally manifest (application). The playlists contain
220 G.G. Nair et al.
meta-information about the play items and refer to Clip Information, which ultimately links to the Mpeg-2 Transport Stream file [24]. It is the Application Manifest that represents the Interactive Application in the hierarchy and captures its essence.
Fig. 2. An XML based content hierarchy
The manifest file consists of two distinct parts, namely the Markup and the Code. The Markup part captures the static composition of the application, which includes layout, timing model. The Code part provides flexibility by adding programmability and dynamics to the overall interactive experience. In turn the markup part could con-tain “SubMarkups” helping the separation of various characteristics of the application. For e.g. the layout can be captured in one SubMarkup and the timing issues in an-other. On the same lines, the code part can contain none or more scripts. As long as the overall structure and representation is respected, these subtle choices are entirely up to the discretion of the content author.
The choice of the markup for next generation optical discs may be from the fol-lowing XML based languages, such as Synchronized Multimedia Integration Lan-guage (SMIL) [9], Scalable Vector Graphics (SVG) [26], Extended Hypertext Markup Language (XHTML) [27] and Extended Style Sheet Language (XSL) [28]. Additionally, ECMAScript [10] could be considered for the programmable part of the manifest.
XML Security in the Next Generation Optical Disc Context 221 3 Identifying Security in an Optical Disc Player Context
As pointed out in Section 1, next generation optical discs can be used to distribute HD video [3] content, along with interactive applications packaged in the disc and addi-tional resources may be downloadable from an external location. The disc players can represent a myriad of devices ranging from Consumer Electronics devices to PC drives and mobile systems such as portable game stations. To get a complete picture of security requirements in such varied usage contexts, a complete threat characteriza-tion, and analysis is necessary. As a result, a Threat Modeling approach based on STRIDE [15] has been applied in order to make a methodical analysis of the security threats for optical disc based systems– especially with regard to the accession of in-teractive applications.
3.1 Threat Modeling for Next Generation Optical Disc Player
The Threat Model [12] provides us with a comprehensive list of threats to the applica-tion security and the various mitigation strategies that can be applied. We intend not to present the full results from the model [12], since the model per se is out of scope of this paper. Nevertheless, using the model we select a subset of the requirements and investigate how XML security mechanisms could be used to mitigate certain risks. In particular, the requirements of Authentication, Application Integrity, Content Secrecy, and Access control management ([4]) were under scrutiny.
Some of interesting inferences resulting from the investigative study of the model [12] about threats and their widely adapted mitigation strategies [4] are presented be-low in the context of next generation optical disc and players.
?Authentication & Integrity: The markup applications or resources loaded from the disc need to be authenticated by the player in order to guarantee that only trusted applications are executed. Additionally, the applications or their parts or downloaded resources [3] may need to pass integrity checks [4] to detect (mali-cious) tampering before being used by the disc player.
?Encryption: Applying encryption techniques [4] can allow content authors to avoid wiretapping (man-in-the-van attack) and application sources/resources pro-tection. This is important in the context of markup and script applications because they are essentially verbose.
?Key Management:Key Management includes all the services pertaining to key handling, registration, revocation and updates of cryptographic public keys, which are used in authentication and encryption mechanisms. In particular, ap-propriate Key Management procedures [4] must be in place to circumvent the causes of illegal creation, exchange, repudiation, replacement, protection, stor-age, and usage of keys used in the scenarios of optical disc application authenti-cation and encryption.
?Access Control: The access control mechanisms [4] allow the next generation op-tical disc player to give access rights to the markup based on certain pre-determined policies. As a result, it can provide or restrict access to certain re-sources, as requested by the application author or under certain conditions.
222 G.G. Nair et al.
In the subsequent sections, we see various XML security standards and examine their usage in satisfying the requirements (identified in Section 3.1) in an optical disc usage context.
4 Overview of the Applicable XML Based Security Mechanisms
In this section, an overview of the standardized XML security mechanisms, proposed by W3C and OASIS, is presented.
The issues of Authentication and Integrity identified in Section 3.1 can be miti-gated by Digital Signatures, which can be used to verify the integrity of the Interac-tive Application or associated content assets. To this end, XML Digital Signature [5] proposes a specific syntax to represent a Digital Signature [4] over arbitrary digital content. Furthermore, the XML Digital Signature is in itself a well-formed XML document and carries all the information needed to process the signature, including the verification information. The XML Digital Signature specification also recom-mends a mechanism for signature creation and verification of XML based markup. It is useful for signing and verifying entire or portion of the markup, which may be of binary content and/or include multiple documents.
Another point identified for elaboration in Section 3.1 was the issue of encryption. This issue has been treated well by W3C, in particular with the standardization of the XML Encryption Syntax and Processing [6], which can be applied in the disc-player context to satisfy specific needs of application content protection and secrecy. XML Encryption can handle both XML and non-XML (e.g. binary) data, which makes it flexible to be used along with the interactive applications. A typical usage scenario foreseen in the above-mentioned systems is to encrypt markup applications residing in the disc along with the resources such as images and data. The player will decrypt the application and resources on execution of these markup applications. The content or referenced resources could be encrypted as well.
References [6] and [16] suggest that XML encryption can be done at various lev-els. The content could be encrypted and stored in parts or as a whole. This allows flexibility and better performance. A Player, for instance, can encrypt and store the high scores of a game in a local storage while keeping the general application markup unencrypted. When the game is being executed, the player needs to decrypt only the scores, which can be done in parallel to the execution of the markup.
Another advantage of XML encryption in ensuring confidentiality is that mecha-nisms such as Secure Sockets Layer (SSL)/Transport Layer Security (TLS) protocols only provide confidentiality while the information is in transit and not while it is stored at a server, but XML Encryption takes it one step further by maintaining the confidenti-ality of information, both while in transit as well as when stored. Notably, the secrecy is not dependent on the state or a particular session of the communicating parties.
The issue of Key Management could be dealt with using the XML Key Manage-ment Specification (XKMS) [33] from W3C. The XKMS helps manage the sharing of the public key realizing the possibility of signature verification and encrypting for re-cipients. The usage of XML based message formats for key management eliminates the need to support other specialized public key registration and management proto-cols for markup based interactive applications in the next generation optical discs.
XML Security in the Next Generation Optical Disc Context 223 In order to counter the Access control issue from Section 3.1, the XACML [19] Specification proposed by OASIS [18] provides access control mechanism for appli-cations, based on assertions. This may allow content creators to add policies to re-quest the disc player devices to provide certain rights to an application.
The mechanism defined by MHP [8] suggests the usage of XML based “permis-sion request” files. In this case, the content provider can add the permission request file along with the markup as an attachment. This will be interpreted by the platform and will provide access rights to the application (e.g. rights to use return channel or rights to dial to a particular server). Based on the adopted policy, the platform can al-low or reject the rights to the resources.
Having looked at the XML based security possibilities, we now broaden the dis-cussion with an overview of comparison of XML based security mechanisms with other potential content download security mechanisms like OMA DRM (Open Mo-bile Alliance - Digital Rights Management) [34]. Reference [37] provides an interest-ing comparison between OMA DCF (DRM Content Format) extensions (see [35] [36]) and XML based security mechanisms on overhead and performance for data broadcast in mobile networks. The reference [37] suggests that XML based security incurs 2.5 to 5.1 times more overhead as compared to OMA DCF and performance wise the text based XML takes a back seat when compared to binary-based OMA DCF. Nevertheless, our scenario test runs using the developed prototype (see Section 8) convinced us that in the context of a consumer electronic device like optical disc player, this performance reduction while using XML based security would be within the allowable performance requirements. Additionally, the indicated overhead would also not be a significant issue, owing to the fact that the broadband Internet bandwidth (used by next generation disc players) is not as much of a concern when compared to the mobile over-the-air bandwidth, which the reference [37] refers to.
Additionally, the DVD (Digital Versatile Disc) Content Scrambling System (CSS) used on DVDs to encrypt media data thereby restricting the decoding to only licensed DVD players is less likely to be extended to downloaded application security scenar-ios in the next generation optical disc in lieu of differences in the nature of content data and usage scenarios. Particularly, the CSS is meant for the protection of digital content and lacks flexibility and scalability when extended to interactive applications. Moreover, CSS has been tampered.
In Section 5, we see various ways in which the XML Digital Signature is applied to interactive applications. In Section 6, we see how XML encryption and decryption is applied. Even though Key Management as a requirement was highlighted earlier, an example of XKMS application in the context of interactive application in optical discs has been left out of the discourse in this paper. Section 7 describes the order of inte-gration of these two, along with additional mechanisms to provide order such that end-to-end security is ensured when applications are created and then later executed.
5 Applying XML Digital Signature in the End-to-End Usage
5.1 Global Scenario
Figure 3 examines the global scenario for usage of Digital Signature in the context of signing, transmission, and verification of Interactive Applications. In the previous
224 G.G. Nair et al.
sections, we introduced the notion of the player accessing the applications over the Internet in addition to accessing the applications on the pre-authored disc. Disc based applications are inherently trusted since they were authored into the disc by the con-tent providers - provided the disc is authenticated [29]. The real security issue [12] lies with the interactive applications downloaded over the Internet and the Sign-ing/Verification scenario identified in Figure 3 would facilitate in mitigation. Though the realization of the XML Digital Signature [5] in this section is addressed using ex-amples from the over the Internet downloaded Blu-ray applications, the Digital Signa-ture creation and verification can be extended to disc-resident disc-based Blu-ray ap-plications too.
Fig. 3. Global Signing/Verification Scenario in Bluray
As seen in Figure 3, both at the content creators end and at the application authors’ end, the applications can be digitally signed. When the player accesses any applica-tion from the Internet (e.g. Servers), it tries to authenticate the content by verifying the Digital Signature of the markup application. If the verification succeeds, the ap-plication is executed. In the case of signature verification failure, the application is barred from being executed. This implies that the player needs to have a Verifier component, which can carry out the signature (XML Signature) verification. Further-more, the flexibility with this approach lies in the fact that this signing/verification mechanism can be applied in a variety of ways and levels.
5.2 Identified Signing/Verification Levels for Applications
To account for and prove the application of XML Digital Signature mechanism in next generation optical disc format, we look at the various sub-scenarios where the XML Signing and Verification can be achieved in the context of the interactive Ap-plications as introduced in the “Content Hierarchy” section (see section 2). Even though these sub-scenarios can be extended with more detailed scenarios, here we only propose the general concept supported by examples here.
XML Security in the Next Generation Optical Disc Context 225 5.3 Signing/Verification at Interactive Cluster Level
We envision that the XML Digital Signature [5] can be applied at the level of Interac-tive Cluster (see Figure 2). Since the Interactive Cluster is Markup based, the XML Digital Signature can be used to sign/verify the Interactive Cluster in its entirety or can be used to sign/verify at Track (see Figure 2) Level. It is entirely up to the discre-tion of the Signer if (s)he wishes to sign the non-markup audio/video Content, which is nevertheless possible using XML Digital Signature. Since the main discourse is in-clined towards Interactive Application authentication, a realization of selective Sign-ing/Verification of application Track is hence commendable.
Fig. 4. Signing/Verification Scenarios in the Interactive Cluster Level
5.4 Signing/Verification at the Manifest Level
Taking the Signing and Verification one level deeper to the Manifest (see Figure 2) that forms part of the application Track, we notice that the control of authentication becomes much fine-grained or more granular. In this case, the choices available to the
Fig. 5. Signing/Verification Scenario at the–Manifest Level
226 G.G. Nair et al.
signer are quite large. (S)He can selectively sign only the Code or the Markup part (see Figure 2). Within the Code or Markup part itself, (s)he can choose to sign/verify only one of scripts or submarkups. The capability of the script to dynamically ma-nipulate the Interactive Application makes it much more suited for authentication us-ing XML Digital Signature[5]. Nevertheless, a maliciously tampered markup can be also detrimental to the Security of the Disc Player and the content.
From the above two example sub-scenarios we have seen that a number of Markup Items can qualify to be the target for XML Digital Signature. We refer to these as “Markup Targets”.
Fig. 6. Result of XML Signing on markup Targets
Figure 6 indicates the result of signing a Markup Target. The result of the signing process is the Signature Markup section that is demarcated in the figure by thick lines. This signature can be enveloped or enveloping [5] based on whether the markup target is parent or child to the “Signature”. The signature can also be detached [5] if the tar-get has no parent-child relationship to “Signature” element. The choice resides en-tirely with the content signer. The fact that XML based markups allows syntactic variations while remaining semantically equivalent and the nature of hash functions to be sensitive to syntax variations, calls for the application of canonicalization (XML-C14N)[32] to the signature to remove syntactic differences from semantically equiva-lent XML documents.
Reference [4] gives the concepts of Digital Signatures and the cryptographic algo-rithms which can be used for signatures. Reference [16] gives description of the markup tags for digital signature.
An additional concept used within the context of Digital Signature is the Certificate Handling [8], which uses a digital signature for public key [8] bindings.
5.5 Certificate Based Authentication
XML Digital Signature supports the insertion of digital certificates along with the signatures and provides syntax for the certificates present within the markups or re-
XML Security in the Next Generation Optical Disc Context 227
ferred to by the markups, which will be useful for the players to verify the authentic-ity of the keys. Reference [8] suggests a mechanism for the verification of certificates leading to a trusted root certificate within the player. It should be noted that the XML Digital Signature [5] could be used for such verification.
6 Applying XML Encryption to Markups
Having introduced the notion of XML based Encryption/ Decryption in the context of Interactive Applications in Section 4, we now take a look at how they can be applied in practice. As mentioned earlier, the XML Encryption could be used to encrypt both
Fig. 7.
Result of XML Encryption on Track Target
Fig. 8. Result of XML Encryption on Manifest Target
228 G.G. Nair et al.
XML markup based or non-XML based content. This brings us two different scenar-ios for encryption of Interactive Applications, namely, the Encryption of the Track Target and the Encryption of Manifest Target.
Figure 7 illustrates the result of signing non-markup content, i.e. a chapter’s au-dio/video track (see Figure 2) that is an Audio/Video Play list [23]. The result of en-cryption of non-markup content in this case is an “Encryption Data” [6], which is ei-ther created and embedded in the Interactive Cluster or jettisoned as a separate Markup.
However the scenario is different when markup content is encrypted. Figure 8 shows such a scenario where the manifest (see Figure 2) is encrypted.
In this case, the signing of manifest, an XML based markup, results in the Encryp-tion Data being embedded in the manifest itself. For more details on XML Encryption and various elements within the Encryption Data refer to [5].
7 Providing End to End Security
In this section we explore the possibility of integrating the previously identified secu-rity mechanisms in order to provide end-to-end security. In particular, we consider how the above-mentioned XML security mechanisms works together when a typical application is created, packaged or transmitted and later executed in a CE optical disc player.Figure 9 shows an example of how these mechanisms work together when an application is created, packaged and transmitted via Internet. Such an order can be used when applications are created and packaged in a disc and later launched by a player.
Fig. 9. Encryption and decryption process- end to end
XML Security in the Next Generation Optical Disc Context 229
To ensure the order between content encryption and signing, W3C specifies the Decryption Transform [21], which provides the signers with mechanisms specifying the order of signing and encryption. The resulting application contains sufficient in-formation in the form of additional markup that enables the player to identify how the application needs to be decrypted and verified. The content creators also can add XML based permission request file, which requests permissions from the player to al-low access to certain Player resources (e.g. access to graphics plane or writing to local storage). Furthermore, the XKMS [33] based Key Management could be used to con-vey key registrations and information requests to any “trusted source (trust server)” and to convey responses back from the server. Note that SSL/TLS mechanisms could be used for mutual authentication and secrecy between server and the player when applications are transmitted over the network.
8 Prototype
This section aims to substantiate the proposals mentioned in the previous sections with a prototype on a reference platform as a proof of concept. We chose Blu-ray as our optical disc format and aimed at prototyping the concepts mentioned above on a Blu-ray based optical disc platform.
For the choice of the markup target, we chose Application Manifest (see Figure
10), which represents the Interactive application. This choice is guided by the possi-bility to demonstrate the flexibility of the application of XML Digital Signature in a Blu-ray disc player.
8.1 Realizing the Reference Blu-Ray Interactive Application
The first and foremost need in the prototyping stage is to start with a reference Inter-active Application with Blu-ray as a target system, along with appropriate choice of
the markup target, the scripts and the sub-markups.
Fig. 10. Choices of Reference Blu-ray Markup Target, Script and SubMarkups
230 G.G. Nair et al.
For the prototype we choose to represent the script with ECMAScript [10], a scripting programming language created to capture the common core language ele-ments of both Javascript[11] and JScript[25]. For the timing and layout markup, we chose SMIL [9], a W3C [22] recommendation for describing multimedia presenta-tions based on XML. It defines timing markup, layout markup, animations, visual transitions, and media embedding, among other things.
8.2 XML Security Library Implementations
At the time of prototyping available XML Security Libraries were from Apache Secu-rity Project [13] and IBM Alphaworks [14]. We selected the Apache XML Security libraries since it provides flexible licensing options for prototyping. At the time of the prototyping, two XML security implementations were available in Java and C++ from Apache. Each of these library flavors stood out as potentials for our cause. Our choice of Java was guided by the need of quick prototyping and stability of the available Java based Libraries over C++ based libraries. Apache XML security uses Java Cryptogra-phy Extension (JCE) and this was included in the prototype, along with the bundled Sun cryptography provider [31].
8.3 Reference Platform
We chose Linux based Blu-ray platform and created a prototype as discussed in this section.
Figure 11 shows the layered view of the software architecture.
Fig. 11. Software Architecture for feasibility – Layered View
XML Security in the Next Generation Optical Disc Context 231 The Interactive Application Engine is the main component, which has access to the Interactive Cluster (see Figure 2) and is responsible for getting the application con-tents decrypted, if encrypted, and verified, if signed. In addition to the Verifier and Decryptor, a Signer and an Encryptor component were created to fulfill end-to-end requirements, which enabled the signing and encryption of Application Content.
The resulting prototype substantiated the pragmatic dimension of the proposal for using XML Security in the next generation optical discs. This prototype also demon-strated that XML based security and Interactive Application Engine (see Figure 11) can exist independent of the type the Disc format, be it Blu-ray disc [2], High Defini-tion-DVD and enhanced DVD (eDVD) [31]. In addition, one of the main highlights of the proposal was the overall development time of the prototype, which took no more than 4 man weeks to complete. This demonstrates the simplicity and flexibility in the case of implementation of the proposal.
9 Conclusions and Future Work
We have seen that XML security offers a standard and interoperable mechanism that can be used by content providers to accommodate necessary security requirements for next generation optical discs. The content authors may use the flexibility of partially signing or encrypting the applications. For player platforms, this flexibility translates into better performance. The standard looks mature and implementations are available in Java and C++. The prototype enabled us to conclude the feasibility of proposal in an embedded platform, although we did not derive any performance constraints. We conclude that the usage of XML Security as a mechanism for markup based interac-tive applications can alleviate the security concerns pertaining to application security for content providers and CE manufacturers.
In lieu of future work, to expand the scope of XML Security mechanisms we envi-sion that XRML [20], an XML based rights management language proposed by OASIS [18], to express digital rights for the usage of markup-based applications and resources, can be investigated for digital rights management in the next generation disc player context. Additionally, we intend to extend the current prototype with XML based Key Management [33].
Additionally, the current prototype could be extended to other underlying plat-forms, with respect to optical disc formats, Operating Systems and Hardware Plat-forms to account for the interoperability. Next, a scalable Interactive Application En-gine library could be developed enabling ease of deployment. Finally, a performance model with comprehensive performance study measurements could be done for iden-tifying and tuning the system resources needed for interpretation of the markup appli-cations, and the associated XML based security.
References
1.Tim Bray et al., Extensible Markup Language (XML) 1.0 (Third Edition), World Wide
Web Consortium (W3C) Recommendation. https://www.doczj.com/doc/766325347.html,/TR/REC-xml/
2.Blu-ray Disc Association (BDA), Blu-ray Disc –Application Specification, BD-J Baseline
Application Model Definition for BD-ROM – March 2005. https://www.doczj.com/doc/766325347.html,
232 G.G. Nair et al.
3.Blu-ray Disc Association (BDA), White Paper: Blu-ray Disc Format - General, August
2004. https://www.doczj.com/doc/766325347.html,
4.Bruce Schneier, Applied Cryptography, Wiley, Second Edition, 1995, ISBN: 0471117099.
5.Mark Bartel et al., XMLDigSig - XML-Signature Syntax and Processing, World Wide
Web Consortium (W3C) Recommendation 12 February 2002. https://www.doczj.com/doc/766325347.html,/TR/2002/ REC-xmldsig-core-20020212/
6.Takeshi Imamura et al., XML Encryption Syntax and Processing, World Wide Web Con-
sortium (W3C) Recommendation 10 December 2002. https://www.doczj.com/doc/766325347.html,/TR/2002/REC-xmlenc-core-20021210/
7.Uche Ogbuji, A survey of XML standards. https://www.doczj.com/doc/766325347.html,/developerworks/xml/
library/x-stand1.html
8.European Telecommunications Standards Institute (ETSI), Digital Video Broadcasting
(DVB), Multimedia Home Platform 1.2.1, ETSI TS 102 812 V1.2.1 (2003-06).
9.Jeff Ayars et al., Synchronized Multimedia Integration Language (SMIL 2.0), World Wide
Web Consortium (W3C) Recommendation, 07 January 2005. https://www.doczj.com/doc/766325347.html,/TR/2005/REC-SMIL2-20050107/
10.European Computing Manufacturing Association (ECMA), ECMAScript Language Specifi-
cation, Standard ECMA-262 ISO/IEC 16262, 3rd Edition - December 1999.
11.Mozilla, JavaScript 2.0 Specifications. https://www.doczj.com/doc/766325347.html,/js/language/js20/
12.G Gopakumar, A Gopalakrishnan, Threat Model based on STRIDE, OOTI Project Report
2005, TU/e.
13.Apache Security. https://www.doczj.com/doc/766325347.html,/security/
14.IBM Alphaworks, XML Security Suite. https://www.doczj.com/doc/766325347.html,/tech/xmlsecuritysuite
15.Frank Swiderski et al., Threat Modeling, Microsoft Press 2004 ISBN: 0-7536-1991-3
16.Blake Dournaee, XML Security, RSA Press, McGraw-Hill/Osborne 2002, ISBN: 0-07-
219399-9.
17.Balal Siddiqui, Exploring XML Security. https://www.doczj.com/doc/766325347.html,/developerworks/xml/library/
x-encrypt/
https://www.doczj.com/doc/766325347.html,anization for the Advancement of Structured Information Standards (OASIS).
https://www.doczj.com/doc/766325347.html,
19.Tim Moses et al., Extensible Access Control Markup Language Specification (XACML)
version 2.0, Organization for the Advancement of Structured Information Standards (OASIS) Committee draft 04, 6 Dec 2004. https://www.doczj.com/doc/766325347.html,/xacml/access_control-xacml-2_0-core-spec-cd-04.pdf
20.Simon Godik, Tim Moses et al., Xtensible Digital Rights Markup Language (XRML),
OASIS Standard, 18 February 2003. https://www.doczj.com/doc/766325347.html,/committees/xacml/repository/ 21.Decryption Transform for XML Signature, World Wide Web Consortium (W3C) Recom-
mendation, 10 December 2002. https://www.doczj.com/doc/766325347.html,/TR/xmlenc-decrypt
22.World Wide Web Consortium (W3C). https://www.doczj.com/doc/766325347.html,
23.Blu-ray Disc Association (BDA), Audio Visual Basic Specifications version 0.89 July
2004. https://www.doczj.com/doc/766325347.html,
24.ISO/IEC 13818-2 1996 Information technology, ISO/IEC 13818-2 1996 Information tech-
nology—Generic coding of moving pictures and associated audio information—Part 2: Video (MPEG-2 Video)
25.Microsoft Corporation, Jscript Language Reference 5.5, MSDN library.
26.Ola Andersson et al., Scalable Vector Graphics (SVG) 1.1 Specification, World Wide Web
Consortium (W3C),Recommendation 14 January 2003. https://www.doczj.com/doc/766325347.html,/TR/2003/REC-SVG11-20030114/
XML Security in the Next Generation Optical Disc Context 233 27.Steven Pemberton et al., XHTML1.0 The Extensible HyperText Markup Language (Sec-
ond Edition), World Wide Web Consortium (W3C)Recommendation revised 1 August 2002. https://www.doczj.com/doc/766325347.html,/TR/2002/REC-xhtml1-20020801
28.Sharon Adler et al., Extensible Stylesheet Language (XSL) Version 1.0, World Wide Web
Consortium (W3C) Recommendation, 15 October 2001.
29.Intel et al., Advanced Access Content System (AACS), Technical Draft, July 14 2004
https://www.doczj.com/doc/766325347.html,
30.DVD Forum, Enhanced DVD Specification version 0.9, DVD Forum news, Vol 19, Octo-
ber 2003, Office of the secretary, DVD Forum.
31.Sun Microsystems, JavaTM Cryptography Extension 1.2.2, API Specification & Refer-
ence. https://www.doczj.com/doc/766325347.html,/products/jce/
32.John Boyer, Canonical XML Version 1.0, World Wide Web Consortium (W3C) Recom-
mendation 15 March 2001. https://www.doczj.com/doc/766325347.html,/TR/2001/REC-xml-c14n-20010315
33.Phillip Hallam-Baker et al., XKMS – XML Key Management Specification, World Wide
Web Consortium (W3C) Recommendation 2 May 2005. https://www.doczj.com/doc/766325347.html,/TR/2005/PR-xkms2-20050502/
34.OMA DRM 2.0, OMA-DRM-DRM-V2_0-20040716-C
https://www.doczj.com/doc/766325347.html,
35. OMA DRM Content Format, OMA-DRM-DCF-v2_0-20040715-C,
https://www.doczj.com/doc/766325347.html,.
36.Nokia, S3-040781 Extensions to OMA DRM V2.0 DCF for MBMS Download
Protection,S3#35, Oct 2004, 3GPP.
37.Nokia, Overhead and Performance Comparison of OMA DRM V2.0 DCF and XML for
MBMS Download Protection, 3GPP TSG SA WG3 Security S3#36,
JAVA中常用类的常用方法 一、类 1、clone()方法 创建并返回此对象的一个副本。要进行“ 克隆” 的对象所属的类必须实现. Cloneable接口。 2、equals(Object obj)方法 功能：比较引用类型数据的等价性。 等价标准：引用类型比较引用，基本类型比较值。 存在特例：对File、String、Date及封装类等类型来说，是比较类型及对象的内 容而不考虑引用的是否为同一实例。 3、finalize()方法 当垃圾回收器确定不存在对该对象的更多引用时，由对象的垃圾回收器调用此方法。 4、hashCode()方法 返回该对象的哈希码值。 5、notify()方法 唤醒在此对象监视器上等待的单个线程。 6、notifyAll()方法 唤醒在此对象监视器上等待的所有线程。 7、toString()方法 返回该对象的字符串表示。在进行String与其它类型数据的连接操作时，自动调用toString()方法。可以根据需要重写toString()方法。 8、wait()方法 在其他线程调用此对象的 notify() 方法或 notifyAll() 方法前，导致当前线程等待。 二、字符串相关类 String类 charAt(int index) 返回指定索引处的 char 值。 compareTo(String anotherString) 按字典顺序比较两个字符串。 compareToIgnoreCase(String str) 按字典顺序比较两个字符串，不考虑大小写。 concat(String str) 将指定字符串连接到此字符串的结尾。 endsWith(String suffix) 测试此字符串是否以指定的后缀结束。 equals(Object anObject) 将此字符串与指定的对象比较。 equalsIgnoreCase(String anotherString) 将此 String 与另一个 String 比 较，不考虑大小写。 indexOf(int ch) 返回指定字符在此字符串中第一次出现处的索引。 indexOf(String str) 返回第一次出现的指定子字符串在此字符串中的索引。 lastIndexOf(int ch) 返回指定字符在此字符串中最后一次出现处的索引。 length() 返回此字符串的长度。 replace(char oldChar, char newChar)
JAVA屮常用类的常用方法 一．java?丨ang.Object 类 1、clone()方法 创建丼返M此对象的一个副木。要进行“克隆”的对象所属的类必须实现https://www.doczj.com/doc/766325347.html,ng. Cloneable 接口。 2、equals(Objectobj)方法 0 功能：比较引用类型数据的等价性。 0 等价标准.?引用类型比较引用，基木类型比较值。 0 存在特例.?对File、String、Date及封装类等类型来说，是比较类型及对象的内稃而+ 考虑引用的是否为同一实例。 3、finalize〇方法 当垃圾丨"丨收器确定>(、存在对该对象的更多引用时，由对象的垃圾丨"丨收器调用此方法。 4、hashCode〇方法返 回该对象的哈希码值。 5、notify〇方法 唤醒在此对象监视器上等待的中?个线祝。 6、notifyAII〇方法 唤醒在此对象监视器上等待的所有线程= 7、toString()方法 返W该对象的字符串表示。在进行String与其它类型数据的连接操作时，&动调用tostringo 方法。可以根据耑要重写toStringO方法。 8、wait()方法 在其他线程调用此对象的n〇tify()方法或notifyAIIO方法前，异致当前线程等待。 二、字符串相关类 I String 类 charAt(int index)返回指定索引处的char值。compareTo{String anotherString)按字
典顺序比较两个字符串。compareTolgnoreCase(Stringstr)按字典顺序比较两个字 符串，不考虑人小写。concat(String str)将指定字符串连接到此字符串的结尾。 endsWith(String suffix)测试此字符串是否以指定的〗?缀结束。equals{Object anObject)将此字符串与指定的对象比较。 equalslgnoreCase(String anotherString)将此String 与另一个String 比较，考虑人小'与’。indexOf(int ch)返H指定字符在此字符串屮第一次出现处的索引。 indexOf(String str)返回第一次出现的指定子字符串在此字符串屮的索引， lastlndexOf(intch)返回指定字符在此字符串中最后??次出现处的索引。 length()返|n丨此字符串的长度。 replace(char oldChar, char newChar) 返回一个新的字符串，它是通过用newChar替换此字符串中出现的所有oldChar得到的。 split(String regex)根据给定正则表达式的匹配拆分此字符串。startsWith{String prefix)测试此字符 串是否以指定的前缀开始。substring(int beginlndex) 返回一个新的字符串，它是此字符串的一个子字符串。该子字符串始于指定索引处的字符，一直到此字符串末尾。 substring(int beginlndex, int endlndex) 返回一个新字符串，它是此字符串的一个子字符串。该子字符串从指定的beginlndex 处开始，一直到索引endlndex-1处的字符。 t〇CharArray()将此字符串转换为一个新的字符数组。
JAVA中常用类的常用方法 一、https://www.doczj.com/doc/766325347.html,ng.Object类 1、clone()方法 创建并返回此对象的一个副本。要进行“克隆”的对象所属的类必须实现https://www.doczj.com/doc/766325347.html,ng. Cloneable接口。 2、equals(Object obj)方法 ?功能：比较引用类型数据的等价性。 ?等价标准：引用类型比较引用，基本类型比较值。 ?存在特例：对、Date及封装类等类型来说，是比较类型及对象的内容而不考虑引用的是否为同一实例。 3、finalize()方法 当垃圾回收器确定不存在对该对象的更多引用时，由对象的垃圾回收器调用此方法。 4、hashCode()方法返回该对象的哈希码值。 5、notify()方法唤醒在此对象监视器上等待的单个线程。 6、notifyAll()方法唤醒在此对象监视器上等待的所有线程。 7、toString()方法 返回该对象的字符串表示。在进行String与其它类型数据的连接操作时，自动调用toString()方法。可以根据需要重写toString()方法。 8、wait()方法 在其他线程调用此对象的notify() 方法或notifyAll() 方法前，导致当前线程等待。 二、字符串相关类 l String类 charAt(int index) 返回指定索引处的char 值。 compareTo(String anotherString) 按字典顺序比较两个字符串。 compareToIgnoreCase(String str) 按字典顺序比较两个字符串，不考虑大小写。 concat(String str) 将指定字符串连接到此字符串的结尾。 endsWith(String suffix) 测试此字符串是否以指定的后缀结束。 equals(Object anObject) 将此字符串与指定的对象比较。 equalsIgnoreCase(String anotherString) 将此String 与另一个String 比较，不考虑大小写。indexOf(int ch) 返回指定字符在此字符串中第一次出现处的索引。 indexOf(String str) 返回第一次出现的指定子字符串在此字符串中的索引。 lastIndexOf(int ch) 返回指定字符在此字符串中最后一次出现处的索引。 length() 返回此字符串的长度。 replace(char oldChar, char newChar) 返回一个新的字符串，它是通过用newChar 替换此字符串中出现的所有oldChar 得到的。split(String regex) 根据给定正则表达式的匹配拆分此字符串。 startsWith(String prefix) 测试此字符串是否以指定的前缀开始。 substring(int beginIndex) 返回一个新的字符串，它是此字符串的一个子字符串。该子字符串始于指定索引处的字符，一直到此字符串末尾。 substring(int beginIndex, int endIndex) 返回一个新字符串，它是此字符串的一个子字符串。该子字符串从指定的beginIndex 处开
Abstract class 抽象类:抽象类是不允许实例化的类，因此一般它需要被进行扩展继承。 Abstract method 抽象方法:抽象方法即不包含任何功能代码的方法。 Access modifier 访问控制修饰符:访问控制修饰符用来修饰Java中类、以及类的方法和变量的访问控制属性。 Anonymous class 匿名类:当你需要创建和使用一个类，而又不需要给出它的名字或者再次使用的使用，就可以利用匿名类。 Anonymous inner classes 匿名内部类:匿名内部类是没有类名的局部内部类。 API 应用程序接口:提供特定功能的一组相关的类和方法的集合。 Array 数组:存储一个或者多个相同数据类型的数据结构，使用下标来访问。在Java中作为对象处理。 Automatic variables 自动变量:也称为方法局部变量method local variables，即声明在方法体中的变量。 Base class 基类:即被扩展继承的类。HP0-538 Blocked state 阻塞状态:当一个线程等待资源的时候即处于阻塞状态。阻塞状态不使用处理器资源 Call stack 调用堆栈:调用堆栈是一个方法列表，按调用顺序保存所有在运行期被调用的方法。 Casting 类型转换 :即一个类型到另一个类型的转换，可以是基本数据类型的转换，也可以是对象类型的转换。 char 字符:容纳单字符的一种基本数据类型。 Child class 子类:见继承类Derived class Class 类:面向对象中的最基本、最重要的定义类型。350-018 Class members 类成员:定义在类一级的变量，包括实例变量和静态变量。 Class methods 类方法:类方法通常是指的静态方法，即不需要实例化类就可以直接访问使用的方法。 Class variable 类变量:见静态变量Static variable
(1)类的默认的无参构造函数[ ]。 A) 在任何情况下都存在 B) 仅当未定义无参构造函数时存在 C) 仅当未定义有参构造函数时存在 D) 仅当未定义任何构造函数时存在 (2) 类的默认的拷贝构造函数[ ]。 A) 在任何情况下都存在 B) 仅当未定义拷贝构造函数时存在 C) 仅当未定义有参构造函数时存在 D) 仅当未定义任何构造函数时存在 改错题：每题有一处错误，请在出错语句后用注释说明出错原因并提出更改意见(1)class Location { int X , Y ; protected: int SetZero(int zeroX, int zeroY); private: int length, height; public: void Location(int initX, int initY); int GetX( ); int GetY( ); }; （2）下面的程序有一处语法错误： #include
public static void main(String[] args) { String str1; str1 = "你好"; // 使用字符串常量构造一个字符串 String str2 = new String("你好"); // String类中重写了父类Object类的equals方法 // String类中的equals方法比较的是字符串的内容 // 使用String类中的equals方法时，建议将字符串常量写在前面 String str3 = null; System.out.println("你好".equals(str3));//正确写法 //System.out.println(str3.equals("你好"));//错误写法 // 使用equals方法 System.out.println(str1.equals(str2));//true System.out.println(str1 == str2);//false
// 使用char数组构造一个字符串 char [] ch1 = {'a', 'b', 'c'}; String str4 = new String(ch1); System.out.println("str4: " + str4); char [] ch2 = {'a', 'b', 'c', 'd', 'e', 'f'}; String str5 = new String(ch2, 2, 2); System.out.println("str5: " + str5); // 使用byte数组构造一个字符串 //byte [] by1 = {-50, 3, 100}; byte [] by1 = "测试".getBytes(); String str6 = new String(by1); System.out.println("str6: " + str6); // String类中的equals方法和等号String str7 = "西安网星"; String str8 = "西安网星"; System.out.println(str7.equals(str8));//true
java中的类修饰符、成员变量修饰符、方法修饰符。 类修饰符： public（访问控制符），将一个类声明为公共类，他可以被任何对象访问，一个程序的主类必须是公共类。 abstract，将一个类声明为抽象类，没有实现的方法，需要子类提供方法实现。 final，将一个类生命为最终（即非继承类），表示他不能被其他类继承。 friendly，默认的修饰符，只有在相同包中的对象才能使用这样的类。 成员变量修饰符： public（公共访问控制符），指定该变量为公共的，他可以被任何对象的方法访问。 private（私有访问控制符）指定该变量只允许自己的类的方法访问，其他任何类（包括子类）中的方法均不能访问。 protected （保护访问控制符）指定该变量可以别被自己的类和子类访问。在子类中可以覆盖此变量。 friendly ，在统一报中的类可以访问，其他包中的类不能访问。 final，最终修饰符，指定此变量的值不能变。 static（静态修饰符）指定变量被所有对象共享，即所有实例都可以使用该变量。
transient（过度修饰符）指定该变量是系统保留，暂无特别作用的临时性变量。 volatile（易失修饰符）指定该变量可以同时被几个线程控制和修改。 方法修饰符： public（公共控制符） private（私有控制符）指定此方法只能有自己类等方法访问，其他的类不能访问（包括子类） protected（保护访问控制符）指定该方法可以被它的类和子类进行访问。 final，指定该方法不能被重载。 static，指定不需要实例化就可以激活的一个方法。 synchronize，同步修饰符，在多个线程中，该修饰符用于在运行前，对他所属的方法加锁，以防止其他线程的访问，运行结束后解锁。 native，本地修饰符。指定此方法的方法体是用其他语言在程序外部编写的。
阅读java中的Object类 今天闲来无事，突然想看看java相关的类的源码。但是解压了src的压缩包。发现很多类都是写了千行的。看的头有点大。突然想起java的Object类应该简单。找到代码。果然很简单。毕竟提供的方法也少。但是发现里面很多什么native关键字。感觉有些奇怪。网络上一查。发现下面的说明。突然恍然大悟。 简单地讲，一个Native Method就是一个java调用非java代码的接口。一个Native Method是这样一个java的方法：该方法的实现由非java语言实现，比如C。这个特征并非java所特有，很多其它的编程语言都有这一机制，比如在C ＋＋中，你可以用extern "C"告知C＋＋编译器去调用一个C的函数。 "A native method is a Java method whose implementation is provided by non-java code." 在定义一个native method时，并不提供实现体（有些像定义一个java interface），因为其实现体是由非java语言在外面实现的。，下面给了一个示例： public class IHaveNatives { native public void Native1( int x ) ; native static public long Native2() ; native synchronized private float Native3( Object o ) ; native void Native4( int[] ary ) throws Exception ; } 这些方法的声明描述了一些非java代码在这些java代码里看起来像什么样子（view）. 标识符native可以与所有其它的java标识符连用，但是abstract除外。这是合理的，因为native暗示这些方法是有实现体的，只不过这些实现体是非java的，但是abstract却显然的指明这些方法无实现体。native与其它java 标识符连用时，其意义同非Native Method并无差别，比如native static表明这个方法可以在不产生类的实例时直接调用，这非常方便，比如当你想用一个
java常用类知识点总结 Java常用类 要求: 1、掌握String和StringBuffer的区别，可以熟练使用String和StringBuffer的各 种方法进行相关操作。 2、能够自己编写一个得到日期的操作类，并将日期进行格式化操作。 3、掌握比较器及其基本原理，并可以通过比较器进行对象数组的比较操作。 4、掌握对象克隆技术及其实现 5、能够灵活应用正则表达式对字符串的组成进行判断 6、掌握Math、Random、基本数据类型的包装类的使用 7、描述出Object System对垃圾收集的支持 8、使用NumberFormat、DecimalFormat、BigInteger、BigDecimal进行数字的操 作 String和StringBuffer String的内容一旦声明不可改变，如果要改变，改变的是String的引用地址，如果一个字符串要经常改变，必须使用StringBuffer。 在一个字符串内容需要频繁修改时，使用StringBuffer可以提升操作性能，因为StringBuffer内容可以改变，而String内容不可改变。StringBuffer支持的方法大部分与String类似。 StringBuffer常见用法: (1) 字符串的连接操作
String类可以通过“+“进行字符串的连接，而StringBuffer中却只能使用append方法进行字符串的连接，而且此方法返回一个StringBuffer类的实例，这样就可以采用代码链的形式一直调用append方法。 (2) 在任意位置处为StringBuffer添加内容 可以使用insert方法在指定位置上为StringBuffer添加内容 字符串的反转操作(较为常见的操作，使用reverse方法) (3) 替换指定范围的内容 replace方法可对指定范围的内容进行替换。在String中如果要替换，使用的是replaceAll (4) 字符串截取(使用subString方法从指定范围中截取内容) (5) 删除指定范围的字符串(使用delete方法删除指定范围内容) (6) 查找指定内容是否存在(indexOf查找指定内容，查找到返回内容的位置， 没查到返回-1) 问题:(1)String s = "Hello";s = s + " world!";这两行代码执行后，原始的String对象中的内容到底变了没有, 没有。因为String被设计成不可变(immutable)类，所以它的所有对象都是不可变对象。在这段代码中，s原先指向一个String对象，内容是 "Hello"，然后我们对s进行了+操作，那么s所指向的那个对象是否发生了改变呢,答案是没有。这时，s不指向原来那个对象了，而指向了另一个 String对象，内容为"Hello world!"，原来那个对象还存在于内存之中，只是s这个引用变量不再指向它了。通过上面的说明，我们很容易导出另一个结论，如果经常对字符串进行各种各样的修改， 或者说，不可预见的修改，那么使用String来代表字符串的话会引起很大的内存开销。因为 String对象建立之后不能再改变，所以对于每一个不同的字符
JA V A词汇大全 A Abstract Window Toolkit(AWT)抽象窗口工具集 一个用本地图形组件实现的图形接口。这些组件提供了大部分的本地组件。这个接口正逐步被Swing组件所替代，参见Swing Set. Abstract抽象的 一个Java语言中的关键字，用在类的声明中来指明一个类是不能被实例化的，但是可以被其它类继承。一个抽象类可以使用抽象方法，抽象方法不需要实现，但是需要在子类中被实现 abstract class抽象类 含有一个或多个抽象方法的类，不能被实例化。定义抽象类的目的是使其他类能够从它继承，并且通过实现抽象方法使这个类具体化 abstract method抽象方法 没有实现的方法 access control访问控制 控制用户或程序访问资源的权限，保证资源的一致性的方法 API应用程序接口 Application Programming Interface的缩写。指导应用程序开发人员访问类方法和类状态的说明 applet小应用程序
通常在Web浏览器中执行的一个Java组件，同样可以在其他的支持applet 模型的应用程序或设备中执行 Applet container applet容器 一个支持applet的容器 argument参数 在函数调用中使用的数据项。一个参数可以是常量、变量或表达式 array数组 相同类型的数据的集合，每一个数据项通过一个整数唯一标识 ASCII American Standard Code for Information Interchange的缩写。一个标准的7位字符编码，参见Unicode B Bean 一个可以重用的组件，可以通过组合Bean来创建应用程序 bean-managed persistence 当一个实体bean实例和资源管理器交换数据的时候，由实体bean实例来管理 bean-managed transaction Enterprise Bean定义事务的界限的时候 binary operator二值操作符
面向对象编程 本篇简单介绍面向对象的三个特性，这些特性会在后续中详细讲解。 1、面向对象的三个特性 （1）封装 面向对象的编程核心思想之一就是将数据和对数据的操作封装在一起，从实例中抽取共同性质形成一个概念。 （2）继承 继承体现了一种先进的编程模式，子类可以继承父类的属性和功能，即继承了父类所具有的数据和操作，同时子类还可以增加独有的数据和操作。比如，”猫“继承了“动物类…的属性和功能，但是它又有自己独特的属性和功能，猫可以”喵喵“的叫。 （3）多态 多态是面向对象编程的又一重要特征。多态有两种意义，一种是操作名称的多态，一种是与继承有关的多态，同一种操作被不同的类型对象调用产生不同的行为，比如猫和狗都有动物的叫功能，但是猫的叫声为”喵喵“，狗的叫声为”汪汪“，这就是多态。 2、Java类的声明 类是组成java程序的基本要素，在类里封装了一类对象的状态和方法。同时类也是规范对象的模板，可以创建对象。 类的定义格式： class 类名{ 类体的内容 } class是关键字，用来定义类。”class 类名“是类的声明部分，类名必须是合法的Java标识符。如： class Dog{ int i ; …… } 3、成员变量 （1）成员变量在使用时可以是任何一种数据类型类型（包括基本类型和引用类型）。（2）在定义成员变量时可以对其初始化，如果不对其初始化，java使用默认的对其初始化（详见下图）。 （3）成员变量的作用范围为整个类体。
4、方法 类体的内容有两个：成员变量和方法，其中，一部分方法称为构造方法，供类创建对象时使用，用来给出类所创建的对象初始状态。另一部分方法可分为实例方法和类方法。类所创建的对象可以调用这些方法形成一定的算法，体现对象具有的某种功能。 方法的定义：方法声明和方法体。其一般格式为： 方法声明部分{ 方法体内容 } 最基本的方法声明包括方法名和方法的返回类型，返回类型也称为方法的类型，如：int area（）{ ……} 该方法的名字为area，类型为int 方法返回的数据类型可以是任意java 数据类型，当方法不需要返回数据时，返回类型必须是void 。如：void Dog（）{……}。 5、方法重载 谈到方法不得不说方法的重载，方法重载是多态性的一种，所谓多态性，是指可以向功能传递不同的消息，以便让对象相应的消息来产生一定的行为。对象的功能是通过类中的方法来体现，那么功能的多态性就是方法的重载。 方法重载是指一个类中可以有多个方法具有相同的名字，但方法的参数必须不同，如果两个方法的名字相同，即使类型不同，也必须保证参数不同。另一种多态是与继承有关的多态，将在继承讨论。 方法的重载例如： [java]view plaincopyprint? 1class Fang{ 2double getArea(double x,int y){ 3return x*y; 4 } 5int getArea(int x,double y){ 6return (int)(x*y);
常用类 Object类 它是Java所有类的根类.所以Java的所有对象都拥有Object类的成员. 1．一般方法 boolean equals(Object obj) //本对象与obj对象相同，返回true String toString() //返回本对象的字符串表达形式，默认返回类名称和十六进制数的编码，即：getClass().getName+’@’+Integer.toHexString(hashCode()); 如果要显示自定义的对象，则需要覆盖这个方法。 protected void finalize() throws Throwable //对象销毁时被自动调用, native int hashCode() 返回对象的Hash码，Hash码是表示对象的唯一值，故Hash码相同的对象是同一对象。 2．控制线程的方法 final native void wait() //等待对象 final native void notify() //通知等待队列中的对象进入就绪队列 final native void notifyAll()//通知所有处于等待队列中的对象进入就绪队列 3．关于Object类的几点说明： 3.1. native <方法> 是指用C++语言编写的方法。 3.2.“==”运算符一般用于基本数据类型的比较，如果用于两个引用对象的比较，则 只有当两个引用变量引用同一个对象时，才返回true,否则返回false. String s1=new Strng(“java”); String s2=new Strng(“java”); System.out.pritnln(s1==s2); //显示false 但是，假如不使用new 关键字，创建String 型对象s3,s4,则它们引用的是同一个对象。 String s3=“java”; String s4=“java”;因为没有使用new 关键字，所以s4 引用既存的对象 System.out.pritnln(s3==s4); //显示true, 3.3. 比较对象内容时,使用equals()函数 Object 类的equals()定义 Public boolean equals(Object obj){ return (this==obj); } 由于String 类覆盖了继承自Object类的equals()方法,它比较的是引用对象的内容. 所以,没有覆盖equals()方法的类的对象使用该方法与另一对象进行比较时,永远返 回false; 只是因为此时进行比较调用的是Object的equals方法. 4. Object引用型变量 Object引用型变量可以用来引用所有的对对象. Object[] obs=new Object[3]; obs[0]=new Strng(“12345”);//将String对象赋给obs[0] obs[0]=new Boolean(true); obs[0]=new Integer(100); 5. toString()方法
Java中类的继承 1、方法重载 重载方法必须满足以下条件: ＃方法名相问. ＃方法的参数类型、个数、顺序至少有一项不相同。 ＃方法的返回类型可以不相同。 ＃方法的修饰符可以不相同. 方法覆盖 (1)子类方法的名称、参数签名和返回类型必须与父类方法的名称、参数签名和返回类型一致. (2)子类方法不能缩小父类方法的访问权限. (3)子类方法不能抛出比父类方法史多的异常， (4)方法覆盖只存在于子类和父类(包括直接父类和间接父类)之间.在同一个 类中方法只能被重载，不能被扭盖。 (5)父类的静态方法不能被子类覆盖为非静态方法。 (6)子类可以定义与父类的静态方法同名的静态方法，以便在子类中隐藏父类的静态方法.在编译时，子类定义的静态方法也必须满足与方法覆盖类似的约束。 (7)父类的非静态方法不能被了类覆盖为静态方法。 (8)父类的私有方法不能被子类覆盖。 (9)父类的抽象方法可以被子类通过两种途径覆盖:一是子类实现父类的抽象方法:二是子类重新声明父类的抽象方法。 (10)父类的非抽象方法可以被覆盖为抽象方法. 方法覆盖与方法重载的异同 方法覆盖和方法重载具有以下相同点: ＃都要求方法同名. ＃都可以用于抽象方法和非抽象方法之间. 方法筱盖和方法重载具有以下不同点: ＃.方法覆盖要求参数签名必须一致.而方法重载要求参数签名必须不一致.
＃.方法覆盖要求返回类型必须一致，而方法重载对此不做限制. ＃.方法覆盖只能用于子类覆盖父类的方法，方法重载用于同一个类的所有方d (包括从父类中继承而来的方法)。 ＃.方法覆盖对方法的访问权限和抛出的异常有特殊的要求，而方法重载在这力面没有任何限制。 ＃.父类的一个方法只能被子类覆盖一次，而一个方法在所在的类中可以被重载多次。 super关键字 super和this关键字都可以用来履盖Java语言的默认作用域.使被屏蔽的方法或变 盆变为可见。在以下场合会出现方法或变量被屏蔽的现象. .场合一:在一个方法内.当局部变量和类的成员变量同名，或者局部变量和父类的成员变量同名时，按照变量的作用域规则，只有局部变量在方法内可 见。 .场合二:当子类的某个方法覆盖了父类的一个方法。在子类的范围内，父类 的方法不可见. .场合三:当子类中定义了和父类同名的成员变量时，在子类的范围内，父类 的成员变量不可见。 在程序中，在以下情况下会使用super关键字: ＃在类的构造方法中，通过super语句调用这个类的父类的构造方法。 ＃在子类中访问父类的被屏蔽的方法和属性。 多态性 它是指当系统A访问系统B的服务时，系统B可以通过多种实现方式来提供服务， 而这一切对系统A是透明的. 多态的各种特性 (1)对于一个引用类型的变量，Java编译器按照它声明的类型来处理. (2)对于一个引用类型的变盆.运行时Java虚拟机按照它实际引用的对象来处理.例如以下代码虽然编译可以通过，但运行时会抛出ClassCastException运行时异常. Sub sub=new Sub();
java中的System类 System类是一个功能强大、非常有用的特殊类，它提供了标准输入输出、运行是的系统信息等重要工具。但不能创建System类的对象，它所有的属性和方法都是静态的，引用时应以System为前缀。 1 用System类获取标准输入输出 System类的属性有三个，分别是系统的标准输入，标准输出和标准错误输出。 public static PrintStream err; public static PrintStream in; public static PrintStream out; 通常标准输入指的是输入设备键盘，标准输出和标准错误输出指的是输出设备屏幕，如： char c=System.in.read();//由键盘读入一个字节的数据送给字符变量C System.out.println("Hello! Guys,");//由屏幕输出一个字符串。 2 用System类的方法获取系统信息，完成系统操作 System类提供用来与运行Java的系统进行交互操作的方法，利用这些方法可以获取解释器或硬件平台的系统参量信息，也可以直接向运行系统发出指令来完成系统操作。常用的System类方法如下： public static long currentTimeMillis();//获取1970年1月1日零时到当前系统时刻的微秒数。 public static void exit(int status);//在程序的用户线程执行完以前，强制Java虚拟机退出运行状态，并把状态信息status返回运动虚拟机的操作系统。 public static void gc();//gc方法代表无用内存回收器。
字符串操作：字符串的比较： boolean equals()比较此字符串与指定的对象。 Int compareTo() 比较源与（）的大小，两串大小相等返回0 加IgnoreCase()不考虑大小写boolean contains(CharSequence s) 当且仅当此字符串包含 char 值的指定序列时，才返回 true。 字符串的长度与组合： char charAt(int index)返回指定索引处的 char 值。 String concat(String str)将指定字符串联到此字符串的结尾。 int length() 返回此字符串的长度。 获取子串： String substring(int beginIndex) 返回一个从beginIndex到末尾的子串 String substring(int beginIndex, int endIndex) 返回一个从beginIndex到endIndex-1的字串 字符串的转换、替换和分隔： char[] toCharArray() 将此字符串转换为一个新的字符数组。 String toString() 返回此对象本身（它已经是一个字符串！）。 String toLowerCase() 变为全小写 String toUpperCase() 变为全大写 String trim() 返回字符串的副本，忽略前导空白和尾部空白。 String replace(char oldChar, char newChar) 用 newChar 替换此字符串中出现的所有 oldChar，返回新字符 String replaceAll(String regex, String replacement) 使用给定的 replacement 字符串替换此字符串匹配给定的正则表达式的每个子字符串。 String replaceFirst(String regex, String replacement) 使用给定的 replacement 字符串替换此字符串匹配给定的正则表达式的第一个子字符串。 String[] split(String regex) 在给定字符处拆分原字符串为若干字串。 找出相应字符或字串（找不到返回-1） int indexOf() 返回（？）填入的字符（串）在源中的第一个索引；（？,num）从num索引开始查找 int lastIndexOf()返回最后一次出现的指定值索引。 将字符和数值转化为字符串： Static String valueOf() 将（）填入的参数（任意、包括Obj）转化为字符串 StringBuilder类：构建： StringBuilder() 构建一个容量为16的空字符串生成器，（）填入数字构造指定大小，填入String 构造含有指定字符。 int capacity() 返回当前容量。 char charAt(int index) 指定索引处的 char 值。添改： StringBuilder append() 将特定内容由（）传入buffer StringBuilder insert(int offset,？) 将？变量插在此序列的offset 前 void setCharAt(int index, char ch) 改变索引处的字符为ch。 StringBuilder replace(int start, int end, String str) 替换从start至end-1处字符为str StringBuilder reverse() 反转字符序列。删除： StringBuilder delete(int start, int end) 移除从start索引到end-1索引的字符串。 StringBuilder deleteCharAt(int index) 移除此序列指定位置上的 char。查找： int indexOf(String str) 同String用法 int lastIndexOf()同String用法 int length() 返回长度（字符数）。返回值： int capacity() 返回当前容量。
类与类之间的关系对于理解面向对象具有很重要的作用，以前在面试的时候也经常被问到这个问题，在这里我就介绍一下。 类与类之间存在以下关系: (1)泛化(Generalization) (2)关联(Association) (3)依赖(Dependency) (4)聚合(Aggregation) UML图与应用代码例子: 1.泛化(Generalization) [泛化] 表示类与类之间的继承关系，接口与接口之间的继承关系，或类对接口的实现关系。一般化的关系是从子类指向父类的，与继承或实现的方法相反。 [具体表现] 父类父类实例＝new 子类() [UML图](图1.1) 图1.1Animal类与Tiger类,Dog类的泛化关系 [代码表现] 1.class Animal{} 2.class Tiger extends Animal{} 3.public class Test 4.{ 5. public void test() 6. { 7. Animal a=new Tiger(); 8. } 9.} 2.依赖(Dependency) [依赖] 对于两个相对独立的对象，当一个对象负责构造另一个对象的实例，或者依赖另一个对象的服务时，这两个对象之间主要体现为依赖关系。 [具体表现]
依赖关系表现在局部变量，方法的参数，以及对静态方法的调用 [现实例子] 比如说你要去拧螺丝，你是不是要借助(也就是依赖)螺丝刀(Screwdriver)来帮助你完成拧螺丝(screw)的工作 [UML表现](图1.2) 图1.2 Person类与Screwdriver类的依赖关系 [代码表现] 1.public class Person{ 2. /** 拧螺丝 */ 3. public void screw(Screwdriver screwdriver){ 4. screwdriver.screw(); 5. } 6.} 3.关联(Association) [关联] 对于两个相对独立的对象，当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时，这两个对象之间为关联关系。 [具体表现] 关联关系是使用实例变量来实现 [现实例子] 比如客户和订单，每个订单对应特定的客户，每个客户对应一些特定的订单；再例如公司和员工，每个公司对应一些特定的员工，每个员工对应一特定的公司 [UML图] (图1.3) 图1.3 公司和员工的关联关系 [代码表现] 1.public class Company{ 2. private Employee employee;
Java的类一些常识 “1、请解释Java语言的跨平台特性。 解析：虽然不知道什么是跨平台也可以使用Java语言进行编程，但是对于一个Java编程员来说，理解跨平台特性能够更深入掌握Java语言，所以企业中往往要求应聘者至少理解这个特性。 参考答案：Java的跨平台特性也被称为可移植性、平台无关性，或者一次编写处处运行。他的意思就是如果用Java语言编写一个应用，那么就可以在不同平台上运行，而不需要为不同平台单独运行开发。之所以能实现跨平台的特性。主要得益于Java虚拟机（JVM），JVM解释器在运行Java应用时根据当前平台进行解释，解释成符合当前平台规范的机器码，所以可以实现同样的应用在不同平台上都能运行。 “2、请列举JAVA语言的主要特点 解析：了解一门语言，往往从熟悉该语言的主要特点开始入手，所以企业也常常通过应聘者对JAVA语言特点的掌握程度而判断其语言基础是否扎实。 参考答案：JAVA语言有很多特点，主要包括：①跨平台性：一个应用可以不经过修改直接运行到不同的平台上。②面向对象：JAVA语言是一门面向对面的语言，可以使用对象的属性和行为，可以使用面向对象的思想进行分析设计，并实现整个应用。③解释执行JAVA应用时，JVM中的解释器将解释类文件，生成符合当前平台的字节码。④自动回收：JAVA 应用中的垃圾回收是自动进行的，JVM中的后台线程将监视内存中数据的使用，当内存中的数据不再被引用时，将被作为垃圾回收，而不需要程序员动手回收。 “3、请说明一个JAVA类中主要包含哪几个元素？并说明每种元素的作用。 解析：无论简单还是复杂的JAVA应用，都是由若干个类组成，所以类是JAVA应用的组成单位。了解一个类中包含的主要元素能够对类有一个清晰的认识。一个类中往往会有五种元素，即属性、方法、构造方法、块以及内部类、其实块和内部类比较少见。 参考答案：JAVA类中主要包含属性、方法、构造方法、块以及内部类。