Mapping SOA Artefacts onto an Enterprise Reference Architecture Framework

Ovidiu Noran

Griffith University Australia, School of ICT, O.Noran@griffith.edu.au

Abstract: Currently, there is still no common agreement on the Service Oriented Architecture (SOA) definition, or the types and meaning of the artefacts involved in the creation and maintenance of an SOA. Furthermore, the SOA image shift from an infrastructure solution to a business-wide change project may have pro-moted a perception that SOA is a parallel initiative, a competitor and perhaps a successor of Enterprise Architecture (EA). This paper attempts to map several typ-ical SOA artefacts onto an enterprise reference framework commonly used in EA. This is done in order to show that the EA framework can express and structure most of the SOA artefacts and therefore, a framework for SOA could in fact be de-rived from an EA framework with the ensuing SOA-EA integration benefits.

1. Introduction

Although several definitions for Service Oriented Architecture (SOA) exist, the prevalent view appears to be that SOA is in essence an architectural style promot-ing the concepts of service (packaged business functions with all necessary infor-mation) and service consumer as a basis to structure the functionality of an entire business. Although the SOA concept originates in the modular, object-oriented and component-based software development paradigms, the lack of adequate sup-porting and realisation infrastructure have hindered its early adoption [1]. Accord-ing to the Gartner Group, after the typical wave of vendor hype and unrealistic ex-pectations, SOA appears to be now finally heading towards the plateau of productivity [2]. Even though standardisation attempts are underway, currently there is still no common agreement on a rigorous SOA definition, or the types and meaning of the artefacts that should be involved in the creation and maintenance of an SOA [3]. Furthermore, the realisation that building an SOA involves signifi-cant costs and changes to the entire business has contributed to SOA being seen in some circles as a separate approach, a competitor and (aided by vendor hype) per-haps a potential successor of Enterprise Architecture (EA). This paper attempts to advocate the benefits of using a reference framework in finding common, agreed-upon meanings and actual coverage of the various arte-facts involved in an SOA effort. More importantly however, it attempts to show that SOA is potentially a style and component of EA rather than an alternative.

Copyright. Citation Information: Noran, O. (2009). Mapping SOA Artefacts onto an Enterprise Reference Architecture Framework. In G.A. Papadopoulos, et al. (Eds.), Information System Devel-opment: Towards a Service Provision Society (Proceedings of the 17th International Conference on Information Systems Development (ISD 2008)), Springer Verlag, New York, pp. 197-205

2 Ovidiu Noran

These aims are pursued by mapping several typical artefacts described in SOA lit-erature against a reference Architecture Framework (AF), obtained by combining a number of mainstream Enterprise AFs and validated against several others. Note that a comprehensive mapping of all SOA artefacts currently identified is beyond the scope and space available for this paper; the aim is to prove the concept and promote constructive debate. In addition, the scope of this paper is limited to ‘top-down’ SOA.

EM

GERAGeneralisedReference

Architecture

EEMEnterprise

Engineering Methodology

EML

Enterprise Modelling Language

EETEnterprise

Engineering Tool

Enterprise Model

EOSEnterprise

Operational System

PEMPartial Enterprise

Model

GEMC

Generic Enterprise Modelling Concept

EMO

Enterprise MOdule

supports

used in

utilised in

implemented in

used to implement

used to build

define meaning of

OASIS Reference

model

Open Group SOA

Ontologies

MSOAM, OASIS SAB

SOAModels

SOA Trusted Components

SOA-PG Reference

Model

SOA-PG Reference

ArchitectureBPEL, BPMN...

SOATools

CBDI Metamodel

Linthicum metamodel

GERAM Boundary

Executable Services

OASIS Reference

Architecture

Fig. 1. Sample mapping of SOA artefacts on GERAM [4] (dashed outline boxes show possible and / or generic SOA elements)

2. The Reference Framework

The need to establish a framework early in an SOA project appears to be generally accepted [5-7]. The assumption made in this paper is that if SOA-specific artefacts can be mapped onto an enterprise reference AF in a meaningful way, then the re-quired ‘SOA framework’ could in fact be specialised from that enterprise refer-ence AF, thus facilitating synergy and integration of SOA and EA.

The reference framework proposed is described in Annex C of ISO15704:2000/ Amd1:2005 and it is called the Generalised Enterprise Reference Architecture and Methodology, or GERAM [4] (see Fig. 1). ISO15704:2000 sets requirements for reference architectures and methodologies (without prescribing any specific arte-facts) and GERAM is provided as an example of a generalised enterprise AF that satisfies these requirements. As such, GERAM can be used to assess particular

Mapping of SOA Artefacts onto an Enterprise Reference Framework 3

AFs, or to establish selections of AF components to be used in a specific EA pro-ject since often, one single AF does not have all the elements required. Several mainstream AFs have been mapped against GERAM [8-10] and a ‘Structured Re-pository’ (knowledge base-like) of mainstream AF elements is being built using GERAM as a decomposition and structuring tool [11]. GERAM is one of the most complete reference AFs; in addition, as part of ISO15704:2000, it is regularly re-viewed so as to harmonize it with other standardisation efforts, such as ISO/IEC 42010:2007 [12].

The Generalised Enterprise Reference Architecture (GERA) component of GERAM contains the multi-dimensional modelling framework (MF) and other es-sential concepts such as life history and enterprise entity. The GERA MF (see Fig. 2) contains a multitude of aspects that may be required in modelling an EA project / product, in the context of the project / product’s life cycle. The GERA MF also features the genericity dimension, which allows representing the metamodels and ontological theories underlying languages used to build partial and particular models. Thus, the GERA MF contains placeholders for models describing the components shown in the GERAM structure depicted in Fig. 1. Full descriptions of GERAM, GERA and GERA MF are beyond the scope of and space available for this paper. The keen reader can find all the details in [4].

Management and Control

Product or Customer Service

HumanMachine

ResourceOrganisation

InformationFunction

GenericPartialParticular

HardwareSoftware

Life Cycle Phases

Views

Instantiation

Design

Arch. design

Detailed design

Identification

Concept

Implementation

Operation

Decommission

Requirements

Fig. 2. GERA MF [4]

4 Ovidiu Noran

3. Mapping Typical SOA Artefacts on the Reference Framework

The following section attempts to map several SOA artefacts currently offered by vendors and / or described in SOA literature deemed of interest to the scope of this paper. The selection does not imply endorsement of any specific artefacts.

3.1 SOA Ontologies

The SOA Working Group (WG) of The Open Group aims to provide ontologies for SOA so as to promote “common understanding of SOA in order to facilitate alignment between the business and information technology communities” [13]. In GERAM, ontological theories are a kind of generic enterprise model, describing the most general aspects of enterprise-related concepts and defining the semantics of the modelling languages used. The Open Group Ontology document currently contains definitions for contract, visibility, registry etc. Due to its structure and contents it does abide by the GERAM definition and it maps onto the Generic Concepts area of GERAM (see Fig. 1) and the Generic area of GERA MF (de-tailed mapping not shown due to space limitations)

3.2 SOA Metamodels

In GERAM, a metamodel describes the properties and relationships of concepts used in the modelling effort, as well as some basic constraints, such as cardinality [4]. Thus, an SOA metamodel should unambiguously define relationships between SOA components, elicit rules for building relevant models and define terminology in a consistent and unambiguous manner.

Linthicum [14] proposes an artefact called an SOA metamodel. However, ac-cording to the definitions above, the artefact is rather a high-level reference model since it describes an SOA model at the architectural level life cycle phase (see the mapping in Fig. 1).

Another metamodel proposition is offered by Everware-CBDI [15]. This arte-fact appears to fulfil the requirements of a metamodel by GERAM (although ad-mittedly it lacks some SOA principles such as loose coupling, autonomy, media-tion, etc) and thus can be mapped on the generic concepts area of GERAM. In addition, the various artefacts depicted in the metamodel can be mapped onto the aspects present at the generic level of the GERA MF.

Mapping of SOA Artefacts onto an Enterprise Reference Framework 5

3.3 SOA Reference Models and Reference Architectures

Many vendors and consultants (IBM, BEA, Oracle, WebMethods, etc) offer what they call ‘reference models’ (RMs) and ‘reference architectures’ (RAs). In GERAM, RMs are seen as blueprints describing features common to specific types of enterprises, while RAs are RMs created at the Architectural Design level.

The OASIS RM [16] in its current version is closer to a meta-model than to an RM from the GERAM perspective since it does not appear to express a blueprint for SOA implementation. OASIS RAs and patterns do however match the GERAM RA definition since they are RMs for particular SOA systems expressed at the Architectural Design level. The OASIS Concrete Architecture is in EA the Architectural Design level model of a particular SOA system – and thus maps on the Particular level within the GERA MF, at the Architectural Design life cycle phase.

The RA described in the Practitioner’s Guide (PG) authored by Durvasula et al. [17] specifies the structure and the functionality of model components and thus appears to be a proper RM at the Architectural level, i.e. a RA within the GERA MF. The proposed mappings of the two artefacts are shown in Fig. 1 and Fig. 3

F

SOA Project Partial Level

DD

MSOAMAD

R

I

Bell’s Fwk(FIRO)

O

F

SOA Project Partial Level

DD

AD

R

I

OASISSAB

OASIS RA

SOA-PG RA

SOA Team

(FO)

CEA3

Fwk(FIR)

RO

I

Fig. 3. Sample mappings of MF and methodologies (left) and human aspect of SOA projects (right) on simplified GERA MF (aspects / levels irrelevant to specific mapping omitted)

3.4 SOA Modelling / Documentation Framework

An MF according to ISO15704:2000 is a structure that holds models describing all necessary aspects of enterprises and/or EA projects during their entire life.

The EA Documentation Framework (DF) is described by Bernard [6] as one of the main components of any EA endeavour. Similarly, in the SOA domain McGovern [5] emphasizes the importance of having a framework guiding the

6 Ovidiu Noran

SOA initiative. It appears that the general meaning given to a DF is in fact that of MF. Knippel [18] describes the SOA DF as a new product, however he suggests investigating whether the SOA and EA frameworks could have common areas and even be merged. This supports the SOA-EA integration proposition of this paper.

The SOA MF described by Bell [19] provides conceptual, analysis and logical life cycle phases that can map onto the Requirements, Architectural and Detailed Design phases of GERA; however, the MF appears to lack several other aspects. For example, the human aspect and the management / service distinction are not explicitly represented. Therefore, if such aspects are deemed necessary for the SOA project at hand, elements of other frameworks may need to be employed.

HM

RO

IF

SOA Project Partial Level

DD

SOAVision

AD

R

I

Governance(Mgmt side)

C

MCS

C

D

Op

I

DD

AD

R

Id

MCS

‘ESB = Specification’

‘ESB = Architecture’

‘ESB = Middleware’

‘ESB = Web Services’

‘ESB = Policies’QoS, SLA…

Possible ESB meanings along its

life cycle

SOA-PG Life Cycle

IBM Life Cycle

HM

RO

IF

SOA Project Partial Level

DD

SOAVision

AD

R

I

Governance(Mgmt side)

C

MCS

C

D

Op

I

DD

AD

R

Id

MCS

‘ESB = Specification’

‘ESB = Architecture’

‘ESB = Middleware’

‘ESB = Web Services’

‘ESB = Policies’QoS, SLA…

Possible ESB meanings along its

life cycle

SOA-PG Life Cycle

IBM Life Cycle

Fig. 4. Life cycle models, Reference Architectures and Enterprise Service Bus mappings on sim-plified GERA MF (aspects irrelevant to specific mapping omitted)

As another example, the EA3 framework described by Bernard [6] as expressed in its graphical form (which may not completely reflect the written content) appears to map on the Partial Level, at Concept and Architectural Design levels (life cycle phases), and cover Function, Information and Resource aspects (see Fig. 3, left).

3.5 SOA Life Cycle and Service Lifecycle

The SOA PG [17] describes a set of life cycle phases for SOA projects. On map-ping onto GERA, a possible interpretation is that the Requirements life cycle phase has been omitted from the model, and so have the phases beyond Detailed

Mapping of SOA Artefacts onto an Enterprise Reference Framework 7

Design (see Fig. 4, right). This may be due to the intended scope of the SOA PG; however, when managing an SOA project, the practitioner should be aware of the issue and if necessary seek to complement or replace this life cycle model with one that provides all necessary phases.

Another life cycle model is proposed by IBM [20, 21]. Again, it appears that some life cycle phases are not covered – notably concept and requirements. It is interesting to note that this model distinguishes between the management and ser-vice / production aspects of the SOA project; this subdivision exists in the GERA MF and the mapping reflects this situation (see Fig. 4, right). It should be noted that the IBM model also distinguishes between the SOA project lifecycle and the service lifecycle. The distinction between a project and the prod-uct(s) of the project figures prominently in EA best practice and is also reflected in GERAM – which allows for the representation of the business, project, product and any other relevant EA artefacts’ life cycles as illustrated in Fig. 5.

SP

AS

Legend:

BPMES: Business Mgmt. and Exec Service

AS: Application Service

IS: Infrastructure Service

HQ: Headquarters

BU: Business Unit

SP: SOA Project-------------------------------

M: Management CS: Customer Service Id: Identification C: ConceptR: RequirementsAD: Architectural DesignDD: Detailed DesignI: ImplementationOp: OperationD: Decommissioning

DOp

IDD

ADRCId

MCS

BU HQ

ISBPMES

BU

Fig. 5. Relation project / product / services (based on [22])

The figure presents (using a simplified GERA MF modelling formalism) a possi-ble SOA initiative scenario, where the headquarters (HQ) of a business sets up an SOA project but also sets the mission and high-level requirements for the services required. Subsequently, the SOA Project starts operating and with assistance from all business units creates the rest of the deliverables required for the business, ap-

8 Ovidiu Noran

plication and infrastructure services. Once the services are operational, they per-form their primary function, i.e. to support the Business units’ operation. In EA, such representations have proven to be effective in achieving a common under-standing of the AS-IS and TO-BE states of the business. Figure 4 shows how an EA-specific representation can be used to describe an SOA-specific scenario.

3.6 SOA Vision

Articulating a coherent and easy to communicate vision is identified by Knippel [18] as paramount to any successful SOA initiative and it is no different in any EA project. The vision maps onto the Concept development life cycle activity of GERA, where the stakeholders decide if and how to satisfy the need(s) present in the Identification life cycle phase.

3.7 SOA Governance

In the mainstream literature it is often argued that an SOA initiative would not succeed without a proper cross-departmental governance approach. Governance should be present at all SOA project life cycle phases and a governance model should also make clear which business units influences which area of the SOA project, the authority of the SOA /EA team, how services will affect the business units, etc. Thus, SOA Governance maps onto the management part of the GERA MF and should cover all relevant aspects and life cycle phases of the SOA project, similar to the area occupied by the SOA team; however, it must include the non-human area of the management side as well. Depending on the specific details of the SOA project, various extents of the project’s life cycle phases may be man-aged by the business headquarters (HQ) as shown in Fig. 5. Representing the loca-tion and extent of governance on the GERA framework allows HQ and the SOA team to unambiguously represent their position / authority and to specify govern-ance deliverables needed in each area for each life cycle phase of the SOA project.

3.8 The SOA Team

The SOA team is in GERA terms the human aspect of the SOA project processes. We subscribe to Knippel’s [18] view that a dedicated SOA team can be detri-mental if an EA team exists and has (or can acquire) the necessary SOA skills. The SOA/ EA team must also have sufficient authority and management support.

Mapping of SOA Artefacts onto an Enterprise Reference Framework 9

Such aspects can be detailed in the Functional and Organisational aspect (Fig. 3, right).

3.9 SOA Methodologies

In GERAM terms, EA methodologies (called Enterprise Engineering Methodolo-gies - EEMs) aim to assist in the (re)engineering and in the management of on-going change within a business. Typically, models of an AS-IS (present) state and one or several TO-BE (desired future) state(s) are created, with the methodology providing a set of process descriptions required to reach the chosen TO-BE from the AS-IS. An important issue in EA is achieving a common stakeholder under-standing of the AS-IS and potential TO-BE states. Similarly, in an SOA adoption / on-going project, understanding the AS-IS is paramount e.g. in order to determine what might constitute a service and what services may be needed in the TO-BE state.

Many EA methodology models (such as proposed by Spewak [23]) include guidelines reflecting principles that cut across business units, e.g. cultural change and politics. Such principles applied to SOA, e.g. promoting a culture of sharing and reuse and obtaining enterprise-wide support are at the heart of a successful outcome.

Noran [24] describes a set of steps that can be used to produce a methodology for a specific EA project (a ‘meta-methodology’) involving several businesses. This concept can be readily applied to an SOA project if the participating busi-nesses are replaced with units of the same or other business, business HQ, etc and the end products are deemed to be the SOA project and its deliverables / artefacts.

Sample dedicated SOA methodologies are the OASIS SOA Adoption Blue-prints (SAB) [25] and Erl’s Mainstream SOA Methodology (MSOAM) [26]. These methodologies are in GERA terms reference models of processes and as such they map onto the functional aspect at the Partial Level of GERA (see Fig. 3, left) at the Requirements and Architectural and Detailed Design life cycle phases. Further mapping details are available however have not been shown here due to space limitations.

3.10 SOA Quality of Service and Quality Control

Quality of Service (QoS) is an essential aspect in SOA acceptance. QoS monitor-ing can be partially automated; however, underlying requirements must be speci-fied e.g. in Service Level Agreements (SLAs) that would map onto the Functional aspects at the Requirements life cycle phase in the GERA MF. Quality control as-pects such as version control, reuse policies, service document rules, security

10 Ovidiu Noran

models and policies, test procedures etc, are also typically expressed in specifica-tion documents. Depending on the detail level, they could be mapped onto the Functional aspect of the Concept, Requirements and/or Architectural life cycle phases in the GERA MF (Fig. 4, left).

3.11 Enterprise Service Bus and Policies

The current definition of an Enterprise Service Bus (ESB) according to various sources (vendors, practitioners, academics etc) appears to be inconsistent: service integration architecture, integration middleware product, web services-capable in-frastructure and others.

It may be that in fact all these views are correct and that they are simply ex-pressing the same concept materialised at different life cycle phases of the ESB. Thus, using a life cycle–enabled perspective (such as provided by a ‘type 2’ archi-tecture described in the GERAM specification), the ESB policies can reside in the Concept area; the ESB as architecture can be an RM in the Architectural Design life cycle phase; and ESB as middleware and possibly part of the infrastructure could then reside in the Detailed Design life cycle phases. Therefore, various stakeholders can describe the ESB differently depending on the life cycle phase context (see Fig. 4, right).

4 Conclusions and Further Work

In this paper, we have argued that the use of an enterprise reference AF is suitable and beneficial in the effort to assess and select suitable artefacts for specific SOA initiatives. The mappings shown are by no means comprehensive, nor are they an attempt to criticise valuable work in the SOA domain, but rather aim to exemplify how a common reference can help business management and the EA/SOA team work out areas that can be covered by the various artefacts on offer and also point out potential gaps and overlaps. Making sense of the myriad of SOA artefacts cre-ated by interest groups, academics, vendors etc appears to be a crucial early step when attempting to gather support for an imminent SOA initiative.

The chosen Generalised Enterprise AF was able to represent the SOA entities artefacts identified (detailed mappings may make the object of further publication due to space restrictions). A lot more mapping work needs to be accomplished; however, this early result appears to support the idea that an SOA framework could be derived from an EA reference framework. This course of action would promote SOA-EA integration rather than rivalry and be highly beneficial to the organisation. Thus, EA can help an SOA initiative get off the ground by more ac-curately identifying and predicting required business and supporting services, and

Mapping of SOA Artefacts onto an Enterprise Reference Framework 11

then sustain it by a cross-departmental approach. EA can also help achieve a cul-tural change promoting reuse – e.g. by a system of values that rewards business units who share services that become frequently reused.

References

1. Schönherr, M., Connecting EAI-Domains via SOA - Central vs. Distributed Approaches to Establish Flexible Architectures, in Knowledge Sharing in the Integrated Enterprise: Interop-erability Strategies for the Enterprise Architect, P. Bernus, M. Fox, and J.B.M. Goossenaerts, Editors. 2004, Kluwer Academic Publishers: Toronto / Canada. pp. 111-113.

2. Fenn, J., A. Linden, and D. Cearley. Hype Cycle for Emerging Technologies, 2005Gartner Group. Retrieved June 5, 2008 from http://www.gartner.com/teleconferences/attributes/attr_ 129930_ 115.pdf

3. Erickson, J. and K. Siau, Web Services, Service Oriented Computing and Service Oriented Architecture: Separating Hype from Reality. Journal of Database management, 2008. 19(3): pp. 42-54.

4. ISO/IEC, Annex C: GERAM, in ISO/IS 15704:2000/Amd1:2005: Industrial automation sys-tems - Requirements for enterprise-reference architectures and methodologies. 2005.

5. McGovern, J., Service Oriented Architecture, in A Practical Guide to Enterprise Architecture, J. McGovern, et al., Editors. 2003, Prentice Hall PTR: Upper Saddle River, NJ. pp. 63-89.

6. Bernard, S.A., An Introduction To Enterprise Architecture. 2005, Bloomington, IN: Autho-rHouse.

7. Sprott, D. and L. Wilkes, Enterprise Framework for SOA. Component based Development and Integration Journal, 2005.

8. Noran, O., An Analysis of the Zachman Framework for Enterprise Architecture from the GERAM perspective. IFAC Annual Reviews in Control, 2003. Special Edition on Enterprise Integration and Networking(27): pp. 163-183.

9. Noran, O., An Analytical Mapping of the C4ISR Architecture Framework onto ISO15704 Annex A (GERAM). Computers in Industry, 2005. 56(5): pp. 407-427.

10. Saha, P., A Synergistic Assessment of the Federal Enterprise Architecture Framework against GERAM (ISO15704:2000 Annex A), in Enterprise Systems Architecture in Practice, P. Saha, Editor. 2007, IDEA Group: Hershey, USA. pp. 1-17.

11. Noran, O., Discovering and modelling Enterprise Engineering Project Processes, in Enter-prise Systems Architecture in Practice, P. Saha, Editor. 2007, IDEA Group: Hershey, USA.

12. ISO/IEC, ISO/IEC 42010:2007: Recommended Practice for Architecture Description of Software-Intensive Systems. 2007.

13. SOA WG. Open SOA Ontology The Open Group,. Retrieved June 23, 2008 from http://www.opengroup.org/projects/soa-ontology/uploads/40/12153/soa-ont-06.pdf

14. Linthicum, D.S. SOA Meta-model, (PDF). Linthicum Group. Retrieved June 12, 2008 from http://www.linthicumgroup.com/paperspresentations.html

15. CBDI. CBDI-SAE™ Meta Model for SOA Version 2 Retrieved from http://www.cbdiforum.com/public/meta_model_v2.php

16. OASIS SOA Reference Model TC. OASIS Reference Model for Service Oriented Architec-ture V 1.0OASIS Group. Retrieved June 20, 2008 from http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf

17. Durvasula, S., et al. SOA Practitioner's Guide. BEA Systems, Inc. Retrieved 2008 from http://dev2dev.bea.com/pub/a/2006/09/soa-practitioners-guide.html

18. Knippel, R., Service Oriented Enterprise Architecture (Doctoral Thesis), in IT. 2005, IT-University of Copenhagen: Copenhagen. pp. 125.

12 Ovidiu Noran

19. Bell, M., Introduction to Service-Oriented Modeling, in Service-Oriented Modeling (SOA): Service Analysis, Design, and Architecture. 2008, Wiley & Sons.

20. IBM. SOA Governance and LifeCycle Management Retrieved April 12, 2008 from http://download.boulder.ibm.com/ibmdl/pub/software/au/solutions/businessflexibility/soahighway/pdf/SOA_Gov_SLM_Brochure.pdf

21. IBM. The Role of SOA Quality Management in SOA Service Lifecycle Management, (PDF Document). Retrieved March 10, 2008 from http://www.ibm.com/developeworks/rational/ library/mar07/mcbride/

22. Bernus, P. How To Implement SOA For The Whole Of Business. in Service Oriented Archi-tecture 2008 - Implementing And Measuring SOA Projects To Drive Business Value. 2008. Syndey: IQPC.

23. Spewak, S.H., Enterprise Architecture Planning: Developing a Blueprint for Data, Applica-tions, and Technology. 1993: Wiley.

24. Noran, O., Refining a meta-methodology for collaborative networked organisations: a case study. Int. J. Networking and Virtual Organisations, 2006. 3(4): pp. 359-377.

25. OASIS SOA Adoption TC. SOA Adoption Blueprint - 'Generico'. OASIS Group. Retrieved June 20, 2008 from http://www.oasis-open.org/committees/download.php/17616/06-04-00002.000.doc

26. Erl, T., Appendix B: Process Descriptions, in SOA: Principles of Service Design. 2007, Pren-tice Hall PTR.