2014 - next generation soa - a real-world guide tomodern service-oriented computing

7/26/2019 2014 - Next Generation SOA - A Real-World Guide ToModern Service-Oriented Computing

1/298


2/298


3/298


4/298


5/298


6/298


7/298


8/298


9/298


10/298


11/298


12/298


13/298


14/298


15/298


16/298


17/298


18/298


19/298


20/298


21/298


22/298


23/298


24/298


25/298


26/298


27/298


28/298


29/298


30/298


31/298


32/298


33/298


34/298


35/298


36/298


37/298


38/298


39/298


40/298


41/298


42/298


43/298


44/298


45/298


46/298


47/298


48/298


49/298


50/298


51/298


52/298


53/298


54/298


55/298


56/298


57/298


58/298


59/298


60/298


61/298


62/298


63/298


64/298


65/298


66/298


67/298


68/298


69/298


70/298


71/298


72/298


73/298


74/298


75/298


76/298


77/298


78/298


79/298


80/298


81/298


82/298


83/298


84/298


85/298


86/298


87/298


88/298


89/298


90/298


91/298


92/298


93/298


94/298


95/298


96/298


97/298


98/298


99/298


100/298


101/298


102/298


103/298


104/298


105/298


106/298


107/298


108/298


109/298


110/298


111/298


112/298


113/298


114/298


115/298


116/298


117/298


118/298


119/298


120/298


121/298


122/298


123/298


124/298


125/298


126/298


127/298


128/298


129/298


130/298


131/298


132/298


133/298


134/298


135/298


136/298


137/298


138/298


139/298


140/298


141/298


142/298


143/298


144/298


145/298


146/298


147/298


148/298


149/298


150/298


151/298


152/298


153/298


154/298


155/298


156/298


157/298


158/298


159/298


160/298


161/298


162/298


163/298


164/298


165/298


166/298


167/298


168/298


169/298


170/298


171/298


172/298


173/298


174/298


175/298


176/298


177/298


178/298


179/298


180/298


181/298


182/298


183/298


184/298


185/298


186/298


187/298


188/298


189/298


190/298


191/298


192/298


193/298


194/298


195/298


196/298


197/298


198/298


199/298


200/298


201/298


202/298


203/298


204/298


205/298


206/298


207/298


208/298


209/298


210/298


211/298


212/298

211

Each role has specific deliverables and plays a particular set of functions ineach phase in the SOA project lifecycle.

Summary of Key Points

! Each SOA project progresses through a variety of stages

! A number of roles are necessary to effectively implement SOA governance

8.3 SOA Governance Fundamentals

The primary business goal of SOA governance is to ensure that an SOAinitiative achieves its targeted business outcome. This is achieved by

establishing an SOA governance system, which acts as a meta-decision systemthat an organization puts in place to control and constrain decision-makingresponsibilities related to the adoption and application of service-orientation.The foundation of an SOA governance system resides within an SOAGovernance Program Office (SPGO) responsible for creating andadministering an SOA governance program.

There are several ways in which the SPGO may be established in anorganization.

! Centralized Enterprise SGPO # a single governance body that oversees SOAgovernance on behalf of the entire IT enterprise.

! Centralized Domain SGPO # a single governance body that subjects alldomain service inventories on to a common SOA governance system.

! Federated Domain SGPOs # in this model, a central overarching SGPOexists in addition to individual SGPOs, each responsible for a separate domain

service inventory.

! Independent Domain SGPOs # in absence of a central overarching SGPO,each domain service inventory has its own SGPO, which has full governanceauthority and jurisdiction over that domain.

The SGPO exists to create and maintain an SOA governance program. Thetask of realizing it can be divided into three basic steps:

1. Assessing the Enterprise (or Domain) , which is focused on:


213/298

212

! Current Governance Practices and Management Styles

! SOA Initiative Maturity

! Current Organizational Model

! Current and Planned Balance of On-Premise and Cloud-based ITResources

2. Planning and Building the SOA Governance Program # primaryelements include:

! SOA Governance Precepts (i.e. rules, policies and standards)

! SOA Governance Processes

! SOA Governance Roles

! SOA Governance Tools! SOA Governance Roadmap

3. Running the SOA Governance Program that includes the followingsteps:

! Collect the right metrics and have the right people use them

! Provide transparency and foster collaboration

! Ensure consistency and reliability

! Ensure compliance and establish incentives! Provide education and communication

These elements establish a solid foundation for a successful SOA governanceprogram.


! The SOA Governance Program Office should be established to administer the

SOA governance program

! The SGPO can be organized in a variety of ways

8.4 Governing SOA Projects

As discussed earlier, SOA projects typically go through a number of stages.The SOA Governance Program Office establishes entry and exit criteria foreach stage. An effective approach to achieving this is to ensure that the quality

and completeness of outputs from each individual lifecycle stage are reviewedand approved before proceeding to the next stage. To achieve this, a number


214/298

213

of review processes based on criteria established by related precepts areestablished.

Each SOA project stage comes with a distinct set of precepts, processes, and

roles associated with it. There are some that are common across most, if notall the stages.

! Precepts

! Service Profile Standards # services within a given serviceinventory need to be consistently documented

! Service Information Precepts # service information primarilyrepresents business-centric data to which clear meaning and contexthas been assigned

! Service Policy Precepts # information describing operationalelements of a service

! Logical Domain Precepts # rules and guidelines for services basedon different types of service models

! Security Control Precepts # services unique security requirementsand concerns

! SOA Governance Technology Standards # SOA governancetechnology products are standardized for the regulation of services within a service inventory boundary

! Metrics

! Cost Metrics # metrics describing costs associated with SOAinvestments and ongoing work

! Standards-related Precept Metrics # metrics derived from theresults of corresponding review processes

! Threshold Metrics # hard limitations on the design-time orruntime usage or management of a service

! Vitality Metrics # measure of a service s on-going behavior

We will not discuss detailed governance mechanisms applied in each SOAproject phase, as this is covered in great detail in a separate book.



215/298

214

! SOA governance projects are governed through a variety of precepts andprocesses

8.5 Service Information and Policy Governance

Service information governance is the practice of identifying and evolvinggovernance controls that ensure the provision of timely and accurateinformation. There is a distinct difference between data, information, andknowledge. SOA governance can help ensure that services provide clearunderstating of data and its meaning and that service consumers can trust thisinformation without requiring knowledge of its origins.

Policies represent information related to service s non-functional

requirements, security, and other limitations. They can be described in humanor computer readable formats. Many service management platforms caninterpret and enforce such policies at runtime.

A number of precepts are required to position and regulate serviceinformation and policy content.

! Enterprise Business Dictionary/Domain Business Dictionary # an officialreference for definitions of information terms and concepts that are core to

the organization s business. There may be an Enterprise Business Dictionaryand a Domain Business Dictionary established.

! Service Metadata Standards # data about a service focused on establishingits functional meaning and context. This typically includes technology,functional, programming logic, and quality of service information.

! Enterprise Ontology/Domain Ontology # the information at the basis ofontology that originates from or relates to information in the businessdictionary as well as service metadata. Typical concern is with ensuring thatthe ontology is current and in alignment with business dictionary and servicemetadata content.

! Business Policy Standards # a set of standards related to how business isconducted. The expectation is that any policy (human or machine-readable)used within a given service inventory be standardized in terms of technology,tooling, and vocabulary.


216/298

215

! Operational Policy Standards # rules and guidelines that establishconstraints and requirements for how services operate and interoperate atruntime. Policies that are in use are expected to be standardized within theservice inventory boundary.

! Policy Centralization # policy definition needs to be centralized when itneeds to be shared by multiple service contracts.

There is a number of governance processes that support the application of theprecepts described above. They provide controls for maintaining the qualityand alignment of service information and related policies.

! Data Quality Review # ensures data correctness.

! Communications Quality Review # addresses the communications quality ofdata.

! Information Alignment Audit # ensures that the meaning is kept consistentthroughout the scope in which content is utilized.

! Policy Conflict Audit # resolves policy domain overlaps.

To attain the most effective service-oriented platform, an organization shouldattempt to establish a comprehensive set of enterprise business models. Toachieve this, the following steps should be undertaken.

! Establish a Service Information Governance Council # chartered withproviding governance over information standards and is comprised ofmembers or department representatives from all affected lines of business.

! Assign Business Information Custodians # support creation andmaintenance of business dictionary and ontology.

! Assign Value to Business Information # assign individual terms and business entities a value ranking indicating its relative importance to theorganization.

! Relate Service Information Governance to Master Data Management # ensure that if MDM is in use within an IT enterprise that is adopting SOA, it

should be related to and incorporated with service information and policygovernance precepts and processes.


217/298

216

Once all the precepts, processes, and governance mechanisms are established,service information and policies can be effectively governed across the entireSOA project lifecycle.


! Service policies and information are governed through a variety of preceptsand processes

8.6 SOA Governance Vitality

Once deployed and in use, services and supporting technologies become livingassets. The SOA governance program must therefore provide a means by

which these assets are routinely reviewed, kept current and accurate and,most importantly, relevant to business needs. To address this evolutionaryaspect, the SOA governance program needs to make the notion of vitality partof the SOA governance system being employed.

To accomplish this, the SOA program must implement a series of vitalitytriggers as a mechanism of notification and reaction. They representpre-determined events and conditions that execute pre-determined activitiesas part of a vitality process. There are five common types of vitality triggers:

! Strategic Adjustments # changes to the organization s business direction or vision; IT changes pertaining to technology and resources.

! Industry Shifts # changes in business law, governmental policy, or eveneconomic or political factors; technology shifts that occur within proprietary vendor platforms and product lines, as well as industry technology standardscommunities.

! Metrics # metrics related to performance of various parts of an SOAecosystem; metrics exposing lack of compliance with industry or ITregulations.

! Organizational Shifts # organizational events that affect the IT enterprise,deliberately or inadvertently.

! Periodic # pre-defined vitality activities that are carried out at scheduled

intervals; review of assets using a pre-defined timescale.


218/298

217

A set of processes should exist to ensure SOA asset vitality is being addressed.They are comprised of a series of activities that are carried out in response tocertain vitality concerns or requirements. They ensure execution of different vitality activities, which include:

! Identify Activity # centers on capturing relevant information surroundingthe trigger and the circumstances of its execution.

! Assess Activity # encompasses tasks that focus on determining the effect ofcarrying out a refresh, prior to moving on to the actual Refresh activity.

! Refresh Activity # governs the actual actions performed in response to thepreviously identified vitality concern.

! Approve Activity # SOA Program Governance Office review that can resultin the acceptance or rejection of the refresh plan.

! Communicate Activity # the communication of the planned refresh to theaffected stakeholders, project teams, and others involved with the targetedasset.

Together, the vitality triggers and activities that are kicked off in responseensure that the SOA program remains current and viable. SOA program vitality is the final element that underlines and supports all the previouslydefined SOA governance mechanisms.


! SOA governance program must implement a series of vitality triggers todetermine qualifying events

! In response to a trigger, a series of activities can be executed

8.7 Next Generation SOA Governance

As discussed in previous chapters, evolution of the service-oriented computingintroduced a number of new technology elements, practices, and patterns.These had direct impact on the state of SOA governance. It had to adapt to therapidly changing service-oriented computing space. As a result, new SOA

governance practices and mechanisms had to be introduced.


219/298

218

The extensions to the existing SOA governance attributes are rooted in thefoundation described throughout this chapter. Instead of establishingradically new approaches, they aim to coexist with and extend current SOAgovernance program implementations. However, the shifts in theservice-oriented computing space necessitated expansion of the SOAgovernance domain and scope.

Each next generation architecture element creates a need for related set ofgovernance mechanisms and practices. The subsequent sections discussspecific precepts and processes that are introduced in each stage of an SOAproject.

Business Process Management

BPM has a profound impact on SOA. When applied correctly, it cansignificantly enhance the value SOA already offers. Therefore, SOAgovernance mechanisms should concentrate on maximizing the alignment between the two disciplines but do so intelligently and for the right reasons.Table 9.1 discusses how this can be accomplished in each SOA project stage.


220/298

219


221/298

220

SOA governance mechanisms related to Business Process Management.


222/298

221

The BPM approaches, tools, and technologies offer significant synergies withSOA and its established precepts and processes. While this close relationshipshould be exploited to its full potential, it will undoubtedly become evenstronger, as the technology evolves and maturity increases on both sides.

Business Rules Engines

Business Rules Engines bring a new dimension to service-orientation. Theyprovide capability to externalize business rules that services need to execute aspart of their logic. The rules may be maintained by external parties outside ofthe organization that owns and manages the service. The changes to the rulesimplemented through a rules engine need to be synchronized with the serviceinterface and other business logic the service may execute. The service itselfmay be reduced to just a call to a rules engine.

The variety of rule engine technologies that exists today demands a careful setof guidelines to be crafted in order to determine which platform is the mostappropriate to use in which situation. SOA governance mechanisms need to beput in place to help guide rule service design and development in the mosteffective way. Table 9.2 specifies which existing precepts and processes needto be expanded to accommodate Business Rule Engine technology and

whether new ones need to established or not.


223/298

222

SOA governance mechanisms related to Business Rules Engines.


224/298

223

The business rule engine technology is becoming more pervasive andlightweight. The evolutionary path of this platform points to significantsynergies with ESB and BPM technologies. The precepts and processesoutlined above may not be necessary in the future if rule engines become fullyintegrated into the rest of SOA platform.

Event Driven Architecture

Event Driven Architecture represents a shift from typical service-orientedapproaches. In its simplistic form, it can be viewed as asynchronous SOA. Inits most complex representation, other technologies such as ESB, BPM, business rules engines, and complex event processing platforms may be partof the whole picture.

Event driven services and their consumers need to be governed from asomewhat different perspective than their typical counterparts. Specificprovisions related to the complex and asynchronous nature of EDA should beadded to the SOA governance mechanisms. Table 9.3 discusses them in detail.


225/298

224


226/298

225

SOA governance mechanisms related to Event Driven Architecture.

As everything else, Event Driven Architecture continues to evolve. ESBs arestarting to provide support for events and complex event processing. Vendorsare introducing event processing platforms. Registries are building in support


227/298


228/298

227

The Business Architecture governance body is typically comprised of businessand IT executives. Ideally, an Enterprise Architecture or SOA governancefunction should be represented on the committee.

Similar executive steering committees may already exist in the organization. Ifthat is the case, the business architecture governance function can beundertaken by one of them. Alternatively, the SGPO can add this function toits charter but representatives from the business community should be addedin order to align SOA and business strategies.

Case Study Example

Once RYLC established its SOA program, the chief architect realized that itlacked structured governance. A number of services were created andcontinued to evolve with little oversight. The developers and architects working on SOA projects complained that there was little guidance availableto them and they lacked proper documentation. The funding for services being constructed was also unclear. Many projects complained that they

were unfairly taxed by being the first ones implementing services slated to be reused by others later. Project managers were unclear on whatmethodologies needed to be followed to create a service, what deliverables were necessary, and how changes to existing services had to be introducedand implemented.

In response to these concerns, the chief architect decided to institute anSOA Governance program. He presented the case to the CIO to attain initialfunding and begin planning the SOA Governance program. As part of the

need for SOA Governance, he described RYLC as a Service


229/298

228

Aggressive organization and outlined the risks associated with this type ofapproach to SOA.

At the outset, a central SOA Governance Program Office (SPGO) wasestablished, as shown inFigure 8.3.

Figure 8.3. RYLC established a central SGPO responsible for itsenterprise service inventory.

The SGPO was chartered with establishing all the SOA governance precepts

and processes, setting up a standard funding model, and continuallyrevitalizing the program. The CIO decided to let the chief architect chair theSGPO and include representatives from each IT department as well as theenterprise architects responsible for various domains including data,security, infrastructure, and common assets.

The SGPO decided to establish a central platform funding approach to helpRYLC better manage its SOA platform investment and demand. It alsorecommended establishing a hybrid funding model for service delivery work.

The SGPO felt that a combination of these models would provide the bestplatform for RYLC to streamline its SOA program.


230/298

229

Next, SGPO tackled the SOA project lifecycle. It defined a comprehensiveset of precepts and processes along with the corresponding roles for eachstage in the lifecycle. Additionally, a set of operational metrics were definedto measure how well each precept and process was performing.

To alleviate the issue of service discoverability and lack of centralizeddocumentation storage, SGPO recommended adopting one of the existingRegistry and Repository tools. A separate team was chartered withexploring the existing product landscape and making a recommendation. Itdeveloped a comprehensive roadmap describing what the SOA Governanceautomation goal state looked like and what capabilities had to be present.Based on this roadmap, the team evaluated a number of commercial andopen source products. The final recommendation was to purchase aRegistry / Repository platform from the same vendor that supplied thecompany s ESB in order to leverage synergies and built-in integrations between the two products. However, the proposed implementationapproach took a number of deliberate steps prior to fully implementing allthe features and introducing an end-to-end SOA Governance automation.These steps included:

1. Building out Registry / Repository infrastructure and installingsoftware

2. Establishing a metadata model that fully describes all servicemetadata

3. Registering all existing services

4. Allowing other groups to start registering their own services andrequest access to existing services

5. Fully integrating Registry / Repository with ESB

6. Automating all established processes throughout each SOA projectlifecycle stage

Since RYLC wanted to leverage SOA as a strategic tool to gain competitiveadvantage and become more agile, the CIO proposed to extend the SOAGovernance to the business. He proposed that an executive steeringcommittee responsible for aligning business and IT goals be created. RYLCCEO, who was already impressed with the results achieved through the SOAprogram, concurred and sanctioned establishing this new body. The new ITSteering Committee included the CIO, chief architect, and all businessdivision heads, COO, and CFO. The CEO specifically chartered the group to


231/298

230

work closely with the SGPO in aligning business strategies with SOA andmeasuring results.


! Existing SOA governance precepts and processes need to be extended inresponse to technology and architecture evolution

! Business Architecture should be closely aligned with SOA and SOAgovernance


232/298

231

SOA Industry Standards

1. Executive Summary

This chapter is intended to serve as a guide to help readers differentiate andselect appropriate SOA standards based on their specific needs. Thespecifications introduced and positioned here include:

o The OASIS Reference Architecture for SOA Foundationo The OMG Service Oriented Architecture Modeling Language (SoaML)

Specificationo The Open Group SOA Ontologyo The Open Group SOA Governance Frameworko The Open Group Service Integration Maturity Model (OSIMM)

These specifications are discussed in detail and contrasted with each other.

2. What are Architectural Standards?

System architecture is a formal description of a system, or a detailed plan ofthe system at component level to guide its implementation. Architecturerepresents the structure of components, their interrelationships, and the

principles and guidelines governing their design and evolution over time. Italso ensures a common understanding of what exists now or will be built inthe future. Architecture helps us compose complex solutions from simpler building blocks. Architectural standards [1] are needed to address customerarchitecture and deployment considerations. They are directed towards ITarchitects and oriented towards consistency rather than interoperability.Infrastructure standards are normative, product-driven, conformance-centricand interoperability-focused.

Figure 1. The landscape of architecture standards


233/298


234/298


235/298


236/298

235

participants representing over 600 organizations and individual members in100 countries.

The OASIS SOA Reference Model Technical Committee is responsible

for developing a common SOA reference model (RM) and SOA architecture(RA). The reference model defines a set of SOA-related entities andrelationships, intended to provide a common understanding and language forSOA concepts, while the associated reference architecture comprises of

o Business via Service view which lays the foundation forconducting business in the context of Service Oriented Architecture

o Realizing Services view which addresses the requirements forconstructing a Service Oriented Architecture

o Owning Service Oriented Architecture view which focuses onthe governance and management of SOA-based systems.

OASIS has several member sections that focus on specific technical areasincluding:

o The Open Composite Services Architecture (CSA) MemberSection # advances open standards intended to simplify SOAapplication development

o The Semantic Execution Environment (SEE) TechnicalCommittee # proposes a semantic Web Services platform to addressthe problems of interoperability between data and behavior acrossdiverse organizations

o The SOA for Telecom Technical Committee (SOA-TEL TC) # plans to identify gaps in standards coverage for using ServiceOriented Architecture (SOA) techniques in a telecom environment

o The SOA End-to-End Resource Planning Technical

Committee (SOA EERRP TC) # focuses on the supply chain, withparticular reference to business quality of service, SLA managementand supplier credentials.

OMG

The Object Management Group membership includes hundreds oforganizations, with half being software end-users in over two dozen verticalmarkets, and the other half representing virtually every large organization in

the computer industry and many smaller ones. OMG is responsible for theUnified Modeling Language $ (UML ( ) and Model Driven Architecture (


237/298


238/298

237

While the potential benefits of SOA are clear, the standards picture still looksless so. Forrester Research has counted around 115 standards floating aroundin the SOA space in its most recent study on that topic. It also has found that just confirming which vendors support which standards is virtually impossible,mainly because of missing compliance tests. Since many of these standardsare not yet fully mature, the main challenge is to find an architecturalframework to help maintain integrity and integration while standardscontinue to evolve.

Technical experts and architects have to navigate their adoption of standardscarefully until they mature and become widely accepted. Standards such as

SOAP and WSDL have already been well-adopted and others like WS-Securityare being increasingly accepted. Popular standards include SOAP, WSDL, WS-I Basic Profile, UDDI, WS-Security, WS-BPEL, BPMN, WSRP, XMLSchema, XSLT, XPath, XQuery, XML Signature and XML Encryption.

There are many new terms emerging in the SOA space due to the arrival ofdifferent players including IT service and solution organizations, consultingcompanies, standards consortiums, academic institutions, governments,customers, etc. This rapid expansion creates an urgent need for universal sets


239/298


240/298


241/298

240

models. Vendors and various BPM platforms support one or both of theselanguages.

Additionally, there may be a variety of Domain Specific Languages (DSL)

defined for a variety of domains. Some of these DSLs are incorporated intostandards, while others remain on their own. DSLs, as any other modelinglanguages, help people working within the domain standardize the syntax,notation, and semantic of the information being presented by each model.

Concrete/Solution / Physical Architectures # A concrete architecture isa physical instantiation of a reference architecture achieved by substitution ofthe general, logical, and abstract elements of the template with concrete orphysical realizations of vendor products and instances of technical products,standards, protocols, and design/architectural decisions. Industries caninstantiate concrete architectures for their usage context. Concrete/solutionarchitectures are used directly to drive project implementations.

While we already briefly discussed SoaML, the next section is dedicated tocovering it in detail.

4. Service Oriented Architecture Modelling Language (SoaML) [2]

For many years, UML (unified modeling language) has been the key tool for visually specifying, modeling, representing and communicatingobject-oriented software design. With the continued adoption ofservice-orientation for enterprise engineering, there was a need for UML to beextended to accommodate the unique principles and patterns of the serviceparadigm. To address this need, OMG created the SoaML specification.SoaML defines a UML profile and a metamodel that extends UML to supporta range of modeling requirements for SOA. The key requirements include the

specification of a system of services, individual service interfaces and serviceimplementations.

The SoaML metamodel extends the UML metamodel to support servicemodeling. This extension is intended to support different service modelingscenarios, such as single service description, service-oriented architecturemodeling, or service contract definition. SoaML has been designed to support both the IT and business perspectives of SOA. A UML profile customizes UMLfor a specific domain or purpose by using extension mechanisms such as


242/298


243/298


244/298

243

The simple interface based approach uses a UML interface to specify aone-way service interaction. This focuses attention on a one-way interactionprovided by a participant on a port represented as a UML interface. Theparticipant receives operations on this port and may provide results to thecaller. This approach can be used with &anonymous ' callers and theparticipant makes no assumptions about the caller or the choreography of theservice.

The service contract based approach extends a UML collaboration tospecify a binary or n-ary service interaction. This defines service specificationsthat describe the roles each participant plays in the service (such as providerand consumer) and the interfaces they implement to play that role. These

interfaces are the types of ports on the participant, which obligates theparticipant to be able to play that role in the service contract. The servicecontract based approach extends a UML collaboration to model the structuralpart of the service interaction. The approach can be used to specify services in which there is a contractual obligation, i.e. an agreement, between two ormore parties. This is the case where you have an interaction pattern thatinvolves an exchange of messages specifying (simple) interfaces on both sides.

The service interface based approach extends a UML class to specify a

binary or n-ary service interaction. This is quite similar to the service contract based approach in that it also focuses on binary and n-ary service interactions,requiring that a set of related (simple) interfaces is specified as one servicespecification. Whereas the service contract based approach prescribes usingUML collaboration, the service interface based approach focuses on UMLcomponents and allows the interconnection between these componentsthrough ports. In order to connect components through ports, the ports mustspecify both required and provided interfaces. The service interface based

approach introduces the concept of a service interface and a conjugateservice interface to type the ports on the provider and consumer siderespectively.

Both the service contract and service interface based approaches entail thespecification of simple interfaces, typically one for each of the rolesparticipating in the service interaction. Thus, a service contract or a serviceinterface can be seen as an extension of the simple interface based approach.

An Illustration - The Dealer Network Architecture example from the SoaMLspecification is explained here. The services architecture for this example is


245/298


246/298


247/298

246

It should be noted that some of the language constructs defined in SoaML fiton both the business and IT level. In particular, this applies to participantsthat are used to define the service providers and consumers in a system. At the business level, the participants typically represent business organization unitsor roles, whereas on the IT level the participants typically represent ITsystems or software components. When a participant acts as a provider, itcontains service ports, and when a participant acts as a consumer, it containsrequest ports.

SoaML is agnostic to the choice of modeling formalisms to define behavior.The specification states that any UML behavioral constructs can be used todescribe behavior, e.g. service choreographies, and other formalisms, e.g. EPC

(event processing chain), business process modeling notation (BPMN), UML,BPEL (business process execution language), etc. The SoaML specificationprimarily describes the structure of the service architecture.

SoaML goals are:

o Intuitive and complete support for modeling services in UMLo Support for bi-directional asynchronous services between multiple

parties

o Support for Services Architectures where parties provide and usemultiple services

o Support for services defined to contain other serviceso Easy ability to map to a business process specification or become a part

of ito Compatibility with UML, BPDM and BPMN for business process

modelingo Direct mapping to web serviceso Top-down, bottom up or meet-in-the-middle modelingo Design by contract or dynamic adaptation of serviceso Ability to specify and relate service capability with its contracto No changes to UML notation

The SoaML modeling language was designed to generate services directlyfrom models. It provides a baseline modeling language for specification of anyservices within a service oriented environment, including cloud-based services.The SoaML language specifies some twenty main extensions to UML that

provide key language constructs for specifying the structure of services.


248/298


249/298


250/298


251/298


252/298


253/298


254/298

253

availability, reliability, manageability, scalability, latency, governance, andintegration capabilities. The underlying requirements that determine thecapabilities SOA supports are determined by:

o A set of service requirements that includes business (functional) andnon-functional requirements of a service

o Service requirements result in the documented capability that a serviceneeds to deliver or is expected to deliver

o The provider view of a service requirement is the business andtechnical capability that a service needs to deliver given the context of allof its consumers

o The consumer view of a service requirement is the business and

technical capability that the service is expected to deliver in the context ofthat consumer alone.

A service requirement may be addressed through a combination of layers,each of which has a specific responsibility. This is typically defined in the SOAReference Architecture. Services themselves have a contract element andfunctional element. The contract defines what the service does for consumers, while the functional element defines how the service is implemented. Theservice contract is integrated with the underlying functional element through

a binding component that hides the physical implementation of the servicefrom its consumers, thereby allowing the physical implementation to bechanges without breaking the service contract.

This model addresses ability to service enable legacy assets, new assets,services composed from other services or infrastructure services. For eachlayer, there is a specific mechanism by which the service requirementsinfluence that layer. The identification of service requirements and themapping of those requirements to each of the layers in the SOA Reference Architecture is a key element for implementing SOA in an enterprise.

Figure 8. Nine Layers of the SOA Reference Architecture


255/298


256/298


257/298


258/298


259/298

258

compelling IT related reason behind the use of such services, they are notgenerally tied back to a business process and, as such, do not warrant arigorous analysis required for business services.

In addition to being an important template for defining an SOA solution at alogical level, the SOA Reference Architecture is also a useful tool in the designof vendor neutral SOA solutions. This is because it enables the objectiveidentification of SOA infrastructure requirements. The SOA Reference Architecture provides a well-factored decomposition of the SOA problemspace, which allows architects to focus on those parts of an SOA solution thatare important in the context of the problem they are solving and to map therequired capabilities onto vendor product capability rather than trying to

reverse engineer an SOA solution architecture from the capability of aparticular vendor s products. This set of requirements can be used to betterleverage various capabilities provided by a mix of different vendors that mayoffer the same architectural building blocks. Using the same SOA Reference Architecture we can deliver SOA business services based on the samedeployment framework.

Layer 4: Business Process Layer

In a service-oriented world, business capabilities are realized by businessprocesses or collections of business processes. These business processesinclude service orchestrations and compositions, as well as the ability to insert&human intervention ' and support long-living transactions. In particular,compositions and choreographies of services exposed in Layer 3 are defined inthis layer.

The evolution of service composition into flows, or choreographies of services bundled into a flow act together to establish an application. These applications

support specific use cases and business processes. Visual flow compositiontools can be used to design application flows. Figure 10 shows how a BusinessProcess &P ' can be implemented using Services A, B, C and D from ServicesLayer. Process P contains the logic to sequence and orchestrate serviceinvocation and execution. The services that are aggregated as a businessprocess can be an individual service or a composite service.

Figure 10. Process composed from a variety of services


260/298


261/298

260

From the bottom-up perspective, after we have created a set of assets, we would like to leverage them in a meaningful business context to satisfycustomer requirements. The flexibility and extensibility of service compositionguided by business requirements and composition rules enable businessprocess to address different types of customer pain points by reusing serviceassets.

From the interaction perspective, the business process layer communicates with the consumer layer (a.k.a. presentation layer) to gather inputs from anddisplay results to various actors (e.g. end-user, decision makers, systemadministrator, etc.) through Web portals or business-to-business (B2B)interfaces. Most of the control flow messages and data flow messages of the

business process may be routed and transformed through the integration layer.The structures of the messages are most often defined by the data architecturelayer. The KPIs for each task or process could be defined in QoS and businessperformance layer. The design of service aggregations is guided by theGovernance layer. Of course, all the services should be represented anddescribed by the Services Layer in the SOA Reference Architecture.

From the technical perspective, dynamic and automatic business processcomposition poses critical challenges to researchers and practitioners in the

field of Web services. Business processes are driven by business requirementsthat typically tend to be informal, subjective, and difficult to quantify.Therefore, it is critical to properly formulate the descriptive and subjectiverequirements into quantifiable, objective, and machine-readable formats inorder to enable automatic business process composition and execution. Inaddition, the current web service specifications generally lack ability to definecomprehensive relationships among business entities, business services, andoperations. These relationships may be important to optimize business

process composition and execution. How to clearly specify searchrequirements to discover the most appropriate Web services candidatesremains a challenge.

Lastly, a typical business process generally requires multiple web services tocollaborate in order to address its needs. Therefore, each service not onlyneeds to satisfy individual requirements, but also needs to coexist with otherservices in order to fit within the overall composed business process. Thissuggests that the entire business process needs to be optimized prior toexecution.


262/298


263/298


264/298

263

An ESB provides a location-independent mechanism for integration. Theintegration that occurs here is primarily the integration of the &functional ' layers in the SOA Reference Architecture (layers 2 through 4). For example,this is where the binding (late or otherwise) of services occurs for process

execution. This allows a service to be exposed consistently across multiplecustomer-facing channels such as Web, IVR, XML client, mobile, etc. Thetransformation of response to HTML (for Web), Voice XML (for IVR), XMLString, wireless mark-up language can be done via XSLT or other built-intransformation functionality supported by the ESB platform.

The integration layer provides a level of indirection between the consumer offunctionality and its provider. A service consumer interacts with the serviceprovider via the Integration Layer. Hence, each service interface is only

exposed via the integration layer (e.g. ESB), never directly. Consumers andproviders are decoupled, and this decoupling allows seamless integration ofdisparate systems into new solutions.

Business Rules and Integration Layer

As widely known, business rules are a cross-cutting architectural concern.They need to be consistently applied across the multiple layers in SOA or overtime. The integration layer provides a common business rules capability that

can be used by the ESB and the other layers in the SOA Reference Architecture.


265/298

264

The integration layer also incorporates the support for runtime service virtualization using registry. Service virtualization abstracts (decouples) thelocation of services for consumers. Services are exposed and can be discoveredthrough a registry, but the exact location is hidden to support versioning,change of service locality and administration, without impacting theconsumer.

Layer 7: Quality of Service (QoS) Layer

SOA contains inherent characteristics that exacerbate existing QoS concernsin computer systems. They include increased virtualization / loose coupling, widespread use of XML, composition of federated services, heterogeneouscomputing infrastructures, decentralized SLAs, need to aggregate IT QoSmetrics to produce business metrics, etc. These characteristics createcomplications for QoS that require attention within any SOA solution. TheQoS layer provides the service solution lifecycle processes with the capabilitiesrequired to ensure that the defined policies and non-functional requirementsare addressed.

The QoS layer deals with issues like monitoring and capture of service andsolution metrics from an operational perspective as well as signaling

non-compliance with non-functional requirements related to the salientservice qualities and policies associated with each SOA layer. Service metricsare captured and connected with individual services to allow serviceconsumers to evaluate service performance, creating an increased level oftrust. This layer serves as an observer of the other layers and can create events when a non-compliance condition is detected or (preferably) when anon-compliance condition is anticipated. The QOS layer makes non-functionalrequirements related issues the primary feature/concern and establishes afocal point for dealing with them in any given solution. It provides the meansof ensuring that each service meets its requirements in the followingcategories:

o reliabilityo availabilityo manageabilityo scalabilityo security


266/298

265

Finally, the QoS layer enhances the business value of SOA by enablingorganizations to monitor business processes related to or supporting sharedservices. In particular, SOA security, a significant issue with typical serviceimplementations due to their potential perimeter-less nature as opposed totraditional, web-based, & within the firewall ' , perimeter based security is acapability realized by the QoS layer.

Layer 8: Information Architecture Layer

This layer includes information architecture, business intelligence, andmeta-data considerations. It ensures the inclusion of key considerationspertaining to data and information architectures that can also be used as the basis for the creation of business intelligence through data marts and data warehouses. This includes meta-data content that is stored in this layer. Forindustry-specific SOA solutions, this layer captures all the commoncross-industry and industry-specific data structures, XML-based meta-dataarchitectures (e.g. XML schema), and business protocols of exchanging business data. Some discovery, data mining, and analytical modeling of dataare also covered in this layer. These common structures may be standardizedfor the industry or an organization.

Layer 9: Governance LayerSOA Governance ensures that the services and SOA solutions within anorganization adhere to the defined policies, guidelines and standards. SOAgovernance activities need to conform to Corporate, IT & EA governanceprinciples & standards. The Governance layer will be adapted to match andsupport the target SOA maturity level of the organization.

The governance layer includes SOA governance (governance of processes for

policy definition and enforcement) as well as Service governance (servicelifecycle). This covers the entire lifecycle of the services and SOA solutions(from design to runtime and retirement) as well as portfolio management of both the services and SOA solutions managing all aspects of services and SOAsolutions (e.g. SLA, capacity and performance, security and monitoring). Thislayer can be applied to all the other layers in the SOA Reference Architecture.From the quality of service and performance metrics perspective, it is wellconnected with the QoS layer. From a service lifecycle and design timeperspective, it is connected with the Service layer. From an SOA solutionlifecycle perspective, it is connected with the Business Process layer. The goal


267/298

266

of the SOA Governance layer is to ensure consistency of the Service andSolution portfolio and lifecycles processes. In this layer, the extensible andflexible SOA governance framework will ensure that all aspects of SOA aremanaged and governed. This includes:

o Service lifecycleo SOA standards, precepts, and practiceso SOA methodologyo Governance processes and mechanismso Service Level Agreements based on QoS and KPIso Capacity and Performance management policieso Security enablement

The information in this layer that is collected and made available consists of:

o Guidelines for SOA Governanceo Guidelines for Service and SOA Solution lifecycle and portfolio

managemento Best practiceso Policies (e.g. security)o Standardso Service and SOA solution roadmapso Compliance, Dispensation and Communication documentation

The SOA Reference Architecture is a crucial component for constructingcompetent service-oriented IT systems, as it can be applicable to any domainand technology. Due to highly abstract and generic nature, any kind ofpreferences can be imposed on the Reference Architecture.

6. SOA Ontology

The purpose of this technical standard is to contribute to the Open Groupmission of Borderless Information Flow by developing and fostering commonunderstanding of SOA in order to improve alignment between the businessand information technology communities and to facilitate SOA adoption. Itdoes this in two specific ways:

o It defines the concepts, terminology and semantics of SOA in both business and technical terms in order to create a foundation for further work in domain-specific areas, enable communications between business


268/298

267

and technical people, and enhance the understanding of SOA concepts inthe business and technical communities

o It provides a means to state problems and opportunitiesunambiguously so as to promote mutual understanding. In the long termscenario, it potentially contributes to model-driven SOA implementation.

The SOA ontology is designed to be used by:

a) Business people, to give them a deeper understanding of SOA conceptsand how they are used in the enterprise

b) Architects, as metadata for architectural artifacts

c) Architecture methodologists, as a component of SOA meta-models

d) System and software designers, for guidance in terminology andstructure

The SOA ontology is best represented using the Web Ontology Language(OWL) defined by the World-Wide Web Consortium (W3C). OWL has threeincreasingly expressive sub-languages: OWL-Lite, OWL-DL, and OWL-Full.This ontology uses OWL-DL, the sub-language that provides the greatestexpressiveness possible while retaining computational completeness anddecidability. The SOA ontology contains classes and properties corresponding

to the core concepts of SOA. The formal OWL definitions are supplemented bynatural language descriptions of the concepts with graphic illustrations of therelations between them and with examples of their use. For purposes ofexposition, the ontology also includes UML diagrams that graphicallyillustrate its classes and properties. The natural language and OWL definitionscontained in this specification constitute the authoritative definition of theontology, and the diagrams are for explanatory purposes only.

The Core Concepts of SOA Ontology

The terms system and element are two core concepts of the SOA ontology.Both are concepts that are often used by practitioners, including the notionthat systems have elements and that systems can be hierarchically combined(systems of systems). What differs from domain to domain is the specificnature of systems and elements. For instance, an electrical system has verydifferent kinds of elements than an SOA system. Relationships betweensystems and elements are represented using the following constructs:

o uses and usedBy


269/298

268

o represents and representedBy

Element Class

Elements may use other elements in various ways. An element uses anotherelement if it interacts with it in some fashion. For example, an element simplyis a member of (used by) some system class or an element interacts with

(using) another element (such as a service) in an ad-hoc fashion or even a


270/298


271/298

270

A system is an organized collection of other artifacts, specifically instancesof Element , each such instance having the used by relationship to thesystem. The concept of system is captured by the System OWL class, which isillustrated in Figure 13.

Figure 13. System class representation

In the context of the SOA ontology we consider in detail only functionalsystems that belong to the SOA domain. Note that a fully described instanceof System should have by its nature (as a collection) a uses relationship to atleast one instance of Element .

Since System is a subclass of Element , all systems have a boundary and areopaque to an external observer (black box view). This excludes structures thathave no defined boundary from the System class. From theservice-orientation perspective, this is not especially relevant, since mosttypical SOA systems can be described from an outside (consumer) perspective.

Furthermore, having System as a subclass of Element allows us to naturallyexpress the notion of systems of systems # the lower-level systems are simplyelements used by the higher-level system.

At the same time, along with supporting an external viewpoint (black box view,see above), all systems must also support an internal viewpoint (white box view) expressing how they are organized as a collection. As an example, from aservice perspective, these viewpoints would typically correspond to a servicespecification view versus a service realization view (similar to the way thatSoaML defines services as having both a black box (specification) part and a white box (realization) part).

It is important to realize that even though systems using elements express animportant aspect of the uses property, it is not necessary to &invent ' a system just to express that some element uses another. In fact, even for systems wemay need to be able to express that they can use elements outside their own boundary # though this in many cases will be expressed not at the system level,

but rather by an element of the system using that external Element instance.


272/298


273/298

272

express the concept of architectural abstraction. We find the need forarchitectural abstraction in various places such as a role representing thepeople playing that role, an organizational unit representing the people withinit (subtly different from that same organizational unit using the people withinit, as the represents relationship indicates the organizational unit as asubstitute interaction point), an architectural building block representing anunderlying construct (for instance, important to enterprise architects wantingto explicitly distinguish between constructs and building blocks) and anEnterprise Service Bus (ESB) representing the services that are accessiblethrough it (for instance, relevant when explicitly modeling operationalinteraction and dependencies). The concept of such an explicitly changing viewpoint, or level of abstraction, is captured by

the represents and representedBy properties illustrated in Figure 13.

Figure 14. Represents and representedBy properties

It is important to understand the exact nature of the distinction between usingan element (E1) and using another element (E2) that represents E1. If E1

changes, then anyone using E1 directly would experience a change, butsomeone using E2 would not experience any change. When applying thearchitectural abstraction via the represents property there are threedifferent architectural choices that can be made:

a) An element represents another element in a very literal way, simply byhiding the existence of that element and any changes to it. There will be aone-to-one relationship between the instance of Element and the(different) instance of Element that it represents. A simple real-world


274/298


275/298


276/298


277/298

276

integration with one or more packaged applications, application renovationand development, and systems integration. This roadmap helps to determinethe scope, focus, and incremental steps for different parts of the organizationin order to transform them towards a higher level of service-orientation andservice integration, with justifications in terms of anticipated business benefits.

OSIMM provides a framework for surfacing insights and identifying ITimprovements in terms of component development, service integration, SOA,and IT governance. OSIMM focuses on increasing levels of flexibility in sevenaspects of an organization or enterprise # business, organization andgovernance, methods and processes, application portfolio, architectu

2014 - next generation soa - a real-world guide tomodern service-oriented computing

Documents