Using Semantic WebServices allows the creation of machine readable descriptions of theservice capability and interface, allowing the dynamic discovery andexecution of services.13.3.. In
Trang 1Services are software components with a well-defined interface that isimplementation-independent A key aspect of an SOA is the separation
of the service interface from its implementation (Mahmoud, 2005) Thebenefits from adopting an SOA approach include:
Services are self-contained
Services are loosely coupled
Services can be dynamically discovered
Composite services can be built from aggregates of other services.SOA uses the find-bind-execute model as shown in Figure 13.1 Serviceproviders first register their service in a registry This registry is thenused by consumers to find services that match certain criteria If theregistry has such a service, it provides the consumer with a contract andinformation on accessing the service
The greater agility afforded by an SOA will also allow organisations torespond to the needs of the market more quickly and in ways that aremore attractive to the customer The SOA is particularly applicable to theTelecommunications market where customer and operational supportcosts are high and customer satisfaction is a key differentiator
However, there is evidence to suggest that companies with complexinternal organisations and supply chains will find that large scale SOAsare not achievable without semantic descriptions of service componentsthat can aid service discovery and integration For example, Brodie(2003), Chief Scientist at Verizon Communications stated that:
‘There is a growing consensus that Web Services alone will not besufficient to develop valuable and sophisticated Web processes due thedegree of heterogeneity, autonomy, and distribution of the Web Beforethe huge promise of Web Services become industry strength, a lot ofwork is needed, and semantics holds a key’
Registry
Contract
Bind & Invoke
Figure 13.1 The SOA find-bind-execute model
Trang 2It is apparent that Web Services alone are not enough to implement anSOA and enable the advantages that this architecture can bring (such asdynamic discovery and execution of services) Using Semantic WebServices allows the creation of machine readable descriptions of theservice capability and interface, allowing the dynamic discovery andexecution of services.
13.3 A SEMANTIC SERVICE-ORIENTATED ARCHITECTURE
This section will explain the benefits of semantically described webservices in the context of an SOA In order to do this, the limitations ofcurrent web services are first considered
Web Services are generally described using XML-based standardsnamely WSDL (which allows one to describe a Web Service in terms ofwhat it does and what its inputs and outputs are), UDDI (which is acentralised registry allowing one to discover Web Services) and SOAP(which is a protocol allowing one to execute services) In addition tothese low-level standards, work is in progress to create standards thatallow services to be combined into a workflow, for example WS-BPEL(Web Services — Business Process Execution Language) (IBM, 2005) andalso to define permissible message exchange patterns and contents, forexample ebXML (Eisenberg, 2001) However, none of these standardsprovide a means to describe a Web Service in terms of explicit semantics.For a given service you might want to describe:
What kind of service it is;
What inputs it requires;
What outputs it provides;
What needs to be true for the service to execute (pre-conditions);
What becomes true once the service has executed (post-conditions);
What effect the service has on the state of the world (and/or the data itconsumes and provides)
The first of these requirements is partly addressed by UDDI in that
a category and human readable description can be assigned to aweb service in a registry to aid discovery This provides only limitedsupport for automated discovery since a computer will not understand1the description or what the category means The second and third of theserequirements are partly addressed by WSDL in that XML tags can beattributed to inputs and outputs A computer can easily match these but
1 Strictly, the computer never actually understands even when semantics are provided It is merely provided with the means to relate a piece of information to a machine readable ontology which in turn allows it to determine relationships with other pieces of information and given these perform reasoning to deduce new information Thus the provision of semantic descriptions makes data much more amenable to machine processing.
Trang 3again has no notion of their meaning or relationship to other pieces ofdata Fundamentally, most of the hard work is left to the human user whomust interpret the descriptions provided to the best of his or her abilities.Services can be described semantically by relating them to ontologies.Ontologies provide a shared view of a domain that can be interpreted bymachines Thus ontologies can describe kinds of services, the data theyconsume and provide, the processes that services are part of and, equallyimportantly, the relationships between all of the above.
The explicit relationship between services and ontologies is the keyelement for Semantic Web Services It is envisaged that this will enable:
Improved service discovery: Semantic Web search technology allows users
to search on ontological concepts rather than by keywords A simplekeyword search only finds where a particular term occurs, and does notgive details about its context or relationship to other information.Ontological searches utilise the structured way that information ismodelled to allow more powerful searches, such as the ability toquery attributes or relationships between concepts This will allowusers (and indeed computers) to find the most appropriate servicesmore quickly or narrow down their search via more expressive queries
if required
Re-use of service interfaces in different products/settings: Services that aredescribed semantically can more easily be discovered, understood andapplied thus reducing the need to create new services that serve thesame purpose This could also be used in a strategy to reducecomplexity, that is remove services/interfaces that exactly repeat thefunction of other services but are described slightly differently
Simpler change management: Changes to models and services areinevitable over time The key thing is to reduce the knock-on effect
of change or at least manage it A semantic approach will significantlyreduce the overhead and simplify the process For example, when aproposed change is made to a data element, those services or interfacesthat employ that data in some way can be dynamically discovered andappropriate action could be taken, for example to contact the owner ofthe service with details of the proposed change
A browseable, searchable knowledge base for developers (and others): Intandem with the example given above for simpler change manage-ment, semantically described services and ontologies enable a knowl-edge base to be constructed This allows developers and solutionproviders to perform queries relating to the data and processes theyare concerned with, for example to determine the origin or destination
of a piece of data
Semi-automatic service composition: Given a high level goal which wewish a service or set of services to achieve, expressed in terms of anontology, it is possible to carry out decomposition into componentparts and then match these components with appropriate services The
Trang 4level of automation possible is a matter for ongoing research Initialpractical results are likely to provide users with a set of candidateservices that might satisfy their needs They are then left to decidebetween these services and oversee the composition required in order
to satisfy the goal
Mediation between the data and process requirements of component services:Often there is need for two or more services to interact eventhough their communication requirements are semantically the samebut syntactically different (they may require different messageexchange patterns or different data formats) In this case it should bepossible to automatically construct a translation between message dataelements that allows the services to communicate This is an example
of a process known as mediation, which is discussed in more detail inthe next section It relies upon the mappings of messages and dataelements to an ontology allowing semantic equivalence to be inferred
Enterprise Information Integration: As the name suggests, the SemanticWeb builds upon existing Web technology This can afford universal(or at least enterprise-wide) access to semantic descriptions of services(or information) One advantage is the ability to construct complexqueries which can be executed over a variety of heterogeneoussystems For example, suppose there is a requirement to determinethe number of customers within a particular postcode who spendmore than £100 per quarter If that information is held within onedatabase and the person asking has access to it and knows how toquery it then an answer could readily be obtained Of course thesituation is more complex if multiple databases hold the answer andaccess and a query interface have to be determined The humansinvolved have some work to do in locating the data and processing it
in the required way A semantic approach, however, allows a singlequery to be made via a unifying ontology
13.4 SEMANTIC MEDIATION
The role of mediation in supporting an SOA has already been noted.Mediation is generally achieved through the use of mediators, that iscomponents which enable heterogeneous systems to interact In a prac-tical sense, mediators have generally been realised as pieces of programcode that perform point-to-point, low-level translations Although suchmediators satisfy the short-term goal in that they allow two systems totalk to each other, they suffer from maintainability and scalabilityproblems In general, it is not likely to be feasible to automate theirapplication in a dynamic environment because of their close couplingwith the implementation
Semantic Mediation enables a more dynamic approach through the use
of ontologies, which provide consensual and formal conceptualisation of
Trang 5a given domain ‘Mediators can be used to convert from a sourceimplementation interface to that of a target implementation Modellingthe processes and data in the source and target interfaces using ontolo-gies, enables the definition of relationships between semantically equiva-lent concepts The mediator can use these relationships to dynamicallymap between the source and target’.
Mediation can be classified as acting on both data and process Thefollowing two sections describe this in more detail
13.4.1 Data Mediation
Data mediation is required when the semantic content of a piece of data
or message provided by one system and required by another is the same,but their syntactic representations are different This may be due todiffering naming or formatting conventions employed by the partnersystems In order to overcome these mismatches, a mapping tool can beapplied at design time These can be used to map source elements totarget elements, often on a one-to-one basis Where more complexmappings are required such as many-to-one mappings or mappingsthat are dependent upon content, a rule language may be necessary todescribe them Once a data mediator has been developed its functionalityshould be described (e.g the source and target that it mediates between)
so that interested parties (be they humans or computers) can inspect itand use if necessary
13.4.2 Process Mediation
Process mediation is required when the semantic content of a process isshared by two parties but the messages or message exchange patterns ofthe parties required to achieve that process differ The process mediatormust ensure that the message exchange required by each party isadhered to As a result the mediator may need to, for example, createnew messages that appear to come from the source party and send these
to the target The content of such created messages would have beenobtained from the source by the mediator either by explicitly asking for it
or by retaining it until required by the target
13.5 STANDARDS AND ONTOLOGIES IN
Trang 6telecommunications network One such approach is the New GenerationOperations Systems and Software (NGOSS) initiative from the TeleMan-agement Forum (TeleManagement Forum, 2005a) NGOSS is an inte-grated framework of industry agreed specifications and guidelines whichinclude a shared information and data model for systems analysis anddesign, and a process framework for business process analysis NGOSS isintended to allow easier integration of the Operational Support Systems(OSS) software used to provision, bill and manage network-basedproducts and services.
Part of the work of NGOSS is to produce standards for NextGeneration Networks (NGNs) Currently telecommunications compa-nies have many different networks for different services (e.g.PSTN, Leased Line) that require managing and maintaining individu-ally This requires hundreds or even thousands of different bespokesystem for each network to enable billing, maintenance, troublereporting etc Telco’s are moving towards a consolidated IP-based core
to their networks, where many network services can be provided overone core network This should lead to substantial cost savingsand greatly improve flexibility and efficiency in providing networkservices
NGOSS has identified that the use of SOA will be important inmanaging the NGNs as the benefits offered by SOAs fit well into thedynamic and highly flexible architecture that NGNs offer The criticalfeatures of an SOA are captured in the NGOSS principles:
Shared Information Data Model: NGOSS components implement and use
a defined part of the Shared Information/Data Model (SID) agement Forum, 2005b)
(Teleman- Common Communications Vehicle: Reliable distributed communicationsinfrastructure, for example software bus integrating NGOSS compo-nents and workflow
External Process Control: Separation of End-to-End Business ProcessWorkflow from NGOSS Component functionality
Business Aware NGOSS Components: Component services/functionalityare defined by NGOSS Contracts
The work of the TeleManagement Forum in developing a framework forNext Generation OSS can be seen as ontology building in that NGOSSprovides a level of shared understanding for a particular domain ofinterest NGOSS (TeleManagement Forum, 2005a) is available as a toolkit
of industry-agreed specifications and guidelines that cover key businessand technical areas including Business Process Automation and SystemsAnalysis and Design The former is delivered in the enhanced TelecomOperations Map (eTOMTM) (TeleManagement Forum, 2005c) and thelatter is delivered in the SID The eTOM provides a framework thatallows processes to be assigned to it It describes all the enterprise
Trang 7processes required by a service provider The SID provides a commonvocabulary allowing these processes to communicate It identifies theentities involved in OSS and the relationships between them The SID cantherefore be used to identify and describe the data that is consumed andproduced by the processes.
The eTOM can be decomposed to lower level process categories, forexample ‘Customer Relationship Management’ is decomposed into anumber of categories, one of which is ‘Problem Handling’ This is thendecomposed further into categories such as ‘Track and Manage Problem’
It is to these lower level categories that business specific processes can bemapped eTOM uses hierarchical decomposition to structure the busi-ness processes Process elements are formalised by means of a name, adescription, inputs/outputs and a set of known process linkages (i.e.,links to other relevant categories)
The eTOM supports two different perspectives on the grouping of thedetailed process elements:
Horizontal process groupings, in which process elements describefunctionality that spans horizontally across an enterprise’s internalorganisations (e.g., market, product, customer and service manage-ment etc.)
Vertical process groupings, in which process elements are groupedwithin End-To-End processes (e.g., fulfilment, assurance etc.) accom-plished by the Service Provider enterprise
The eTOM Business Process Framework is defined as generically aspossible, so that it is independent of organization, technology andservice
13.5.2 SID
The SID is much more complex than the eTOM in both its aims and form
It provides a data model for a number of domains described by acollection of concepts known as Aggregate Business Entities These usethe eTOM as a focus to determine the appropriate information to bemodelled The SID models entities and the relationships between them.For example a ‘customer’ is defined as a subclass of ‘role’ It contains
Trang 8attributes such as ‘id’ and ‘name’ It is linked to other entities such as
‘CustomerAccount’ with an association ‘customerPossesses’
13.5.3 Adding Semantics
Although the TMF NGOSS is one of the more prominent initiatives instandardising data and process models for telecommunications, there arealso other attempts from different groups in the industry such as ITU-T(2005), 3GPP (2005) and IPNM (2005) It is Important for NGN to bebased on standardised data models but it is unlikely that one particularmodel will be mature enough to implement in the next 2–3 years (thetimeframe for deploying the first generation of NGN)
Ontologies provide a solution due their flexibility in modelling and theability to easily mediate between ontologies representing different datamodels This allows a single conceptual view over several data models
In the classical approach, data models represented in a format such asXML would not easily allow mappings to be defined between them, orallow remodelling and adjustment as the standards develop over time.For the first step in adding semantics to the NGOSS it was decided toconcentrate only on the SID and eTOM as these most closely fit therequirements for building a Semantic SOA prototype based aroundcommon OSS assurance tasks Given that ontologies are a conceptualisa-tion of a domain and the Web Services Modelling Ontology (WSMO,2005) is a specific form of ontology intended to represent services, theircapabilities and data requirements; it is natural to represent the SID andeTOM in WSMO as domain ontologies for data and process Ontologiesare the key element of WSMO since the other three elements (WebServices, goals and mediators) all refer to them Representing SID andeTOM ontologically will enable service components in the SOA to bedescribed as Web Services using WSMO, with descriptions that refer tothe domain ontologies Similarly WSMO goals for web service discoverycan be expressed in the same terms Mediators will make use of thedomain ontologies to, for example, enable mappings between the differ-ent message formats of two communicating services The use of WSMO
in this context creates an explicit link between a capability described in amodel and the actual service component that will provide it Subsection13.6.3.1 gives more information on how the SID and eTOM were used asdomain ontologies in the case study prototype
Trang 9longer-term vision is that Web Services will compete and collaborate over theInternet and that businesses will trade with partners and with consumersbased upon highly dynamic commercial arrangements (Muschamp,2004) Prior to this vision being realised, SOAs can already be usedwhere trading partner agreements already exist and this is the focus ofour case study.
Traditionally, vertically integrated telecommunications companiessuch as BT have provided end-to-end services to customers using theirown retail operations and their own hardware Over recent years, thesecompanies have worked hard to improve customer service and reducecosts through greater process efficiency and effectiveness These effortshave been enhanced with the introduction of integrated OperationalSupport Systems (OSS) These can provide customers with end-to-endvisibility of service delivery and assurance The challenge in the newenvironment is to maintain these levels of efficiency and customerservice even though the service is being delivered by multiple partiesand organisations who inevitably have their own systems that cannot bedirectly integrated with those of others (Evans, 2002) BT Wholesale’sB2B Gateway is provided to Service Providers2to allow them to integratetheir OSS with those of BT Without such a system the service providerwould either need to manually coordinate with BT via a BT contactcentre or operate a system separate to its own OSS that communicatedwith BT’s—thus requiring information to be entered twice
The B2B Gateway exposes an interface which is a combination oftransport technologies such as SOAP, security protocols such as SSL, andmessaging middleware such as ebXML, and linked to the behaviour ofback-end systems Messages formats are expressed using XML Schema(XSD) (The World Wide Web Consortium, 2000) which has the advantage
of availability of tools and the increased possibility of integrating withnewer transport standards such as Web Services
Currently the process involved in granting access for a new serviceprovider on the Gateway is lengthy and complex It commences with acommunication phase where partners assess their technical suitability,receive documentation and consider the level of fit with their existingOSS A development phase follows, during which support is provided by
BT During the testing phase, the partner is given access to a testenvironment provided by BT where they can test the validity of theirmessages and their transport and security mechanisms Firewalls,proxies etc must be configured by both parties to ensure that commu-nication can occur Once the testing phase is complete and documentedthe partner can move to a pilot phase where terms must first be agreedregarding volumes, frequency and support arrangements before access is
2 A service provider in this context is the organisation which has the relationship with the end customer.
Trang 10given to the live system Transactions are monitored during the pilotphase to ensure validity.
The Gateway currently exposes a number of interfaces concerned withservice fulfilment and assurance These are generally concerned withregulated services such as broadband access The interfaces allow ServiceProviders to order and cease broadband lines on behalf of their custo-mers, manage faults (i.e raise faults, request, confirm and cancel repairappointments and receive fault status notifications) and carry out diag-nostics (i.e., request tests and handle the response to these)
The process can take several months from start to finish Any approachthat can reduce development time, improve the quality of developmentthrough enhanced understanding, and as a result avoid significantproblems during the testing and pilot phases will naturally save BTand its partners significant time and money The remainder of thissection will examine how, by using Semantic Web Services, these goalscan be achieved for one particular function, that of Broadband Diagnos-tics
in a collaboration The Broadband Diagnostics interface has only twotransactions These are ‘RequestTest’ and ‘NotifyOfTestCompleted’
‘RequestTest’ is a ‘RequestResponse’ transaction which means that aresponse to the test request is expected This response indicates whetherthe test has been accepted or rejected It may be rejected if, for example,the Service Provider is requesting a test on a circuit which it does notown The ‘NotifyOfTestCompleted’ is a ‘Notification’ transaction This is
a single message that is sent following the completion of an accepted testdescribing the results of the test
13.6.2 The B2B Gateway Architecture
The B2B Gateway, in common with most B2B interfaces has threeseparate elements The two internal systems of the respective organisa-tions that need to communicate and the interface that they will use to do
Trang 11this This usually involves both systems translating their internal cation view of data and process into the interface view of the problem.Depending upon who produces the interface definition, the amount oftranslation involved can be either very small or almost impossible toachieve without development effort.
appli-The Gateway architecture can be represented as shown in Figure 13.2.The Service Provider’s OSS is able to generate a call to request a test Inorder to pass this on to the B2B Gateway, it must first be adapted toenable it to be understood The adaptation process has two key elements.First, the test call must be represented as a business message that will
be understood by the gateway as valid, given the current state of thetransaction That is, it must be represented as a TestRequest messagewhich is the initial interaction of the ‘RequestTest’ transaction Second,the business message must be wrapped within the protocol envelope,that is ebXML messaging A message received by the B2B Gateway mustalso be adapted before it can be processed by the BT Wholesale OSS Thisadaptation is effectively the reverse of the previous one
Generating the adapter between OSS calls and valid B2B Gatewaymessages is one of the key challenges of the integration process The WebServices Modelling Ontology aims to significantly simplify this integra-tion process The next section describes a prototype using WSMO to
BT Wholesale
Test Interface B2B Gateway
ebXML
Adapter
ebXML
SP OSS Call
Trang 12model the broadband interface, allowing ontological representations ofthe data being exchanged to enable semantic mediation.
13.6.3 Semantic B2B Integration Prototype
This section describes the prototype system—The B2B Integration form—developed to allow mediation to occur between theService Provider trading partner and the B2B Gateway The prototype
Plat-is based upon the execution environment of the Web ServicesModelling Ontology—WSMX (WSMX, 2005) The components of thisarchitecture include Process Mediation (the task of resolving hetero-geneity problems in communicating processes) and Choreography (thetask of semantically describing the expected message-exchange pat-terns), which is required by process mediation Adaptor componentshave been added to allow low level messages to be represented inWSML (Web Services Modelling Language), the language associatedwith WSMO and which can be interpreted by WSMX In this specific usecase, multiple Service Providers are interfacing with one WholesaleProvider (BT)
semanti-to convert semanti-to and from popular messaging formats such as ebXML, UBL[Oasis] etc No intelligence is required in this adaptation step and theresult is an ad hoc messaging ontology that models the elements of themessages in WSML Following the adaptation, the elements can then bereferenced against a domain ontology, in this case using the industrystandard specification Shared Information/Data Model of the TeleMan-agement Forum (TeleManagement Forum, 2005c) These references pro-vide context to the data and allow their semantic meaning to be inferred.For example the SID defines two concepts Party and PartyRole Theconcept Party is used to explicitly define an organisation or individualand PartyRole allows an organisation/individual to take on a parti-cular role during a business transaction On the B2B Gateway theseconcepts fit nicely, as there are a number of organisations that use theGateway (such as BT and other third party providers) and take ondifferent roles depending on the operation being undertaken If a thirdparty provider wishes to carry out a testRequest operation, then theConcept Party is used to describe their organisation, and PartyRole isused to define their role in this transaction as ‘Conductor’ Similarly BTs
Trang 13partyRole in this operation is ‘Perfomer’ as they are performing theactual test.
The final design-time task for BT is to semantically describe themessage-exchange pattern that it expects As explained previously, this
is known as choreography The choreography relates the semantic content
of the messages to a semantic description of the process This can be used
by a process mediator to reason about how to mediate to a targetchoreography The design-time tasks for BT are illustrated in Figure 13.3.From the perspective of the Trading Partner, the design-time activitiesinclude applying an appropriate adaptor to their message descriptions,defining its own semantic choreography description and defining a datamediator between its data representation and that of BTs This final step
is perhaps the most important and labour intensive However the openarchitecture should allow discovery and reuse of mediators if theyalready exist The end result of this mediation step is that the ad hocmessaging ontology of the Trading Partner is mapped to the domainontology enabling semantic equivalence A data mediator is producedthat is stored and applied at run-time The mediator acts as a declarativetransform that can be dynamically discovered and applied in other(perhaps closely related) scenarios As such, it should be stored in such
a way that other parties can later discover it
The choreography of the Trading Partner can be compared with thechoreography of BT by the Process Mediation system which can reasonwhether it is possible to mediate and if so, automatically generate aprocess mediator This reasoning step can be carried out at design-time ifthe two parties are known at this stage (as is the case here) or at run-time
if one of the parties discovers the other in a dynamic run-time scenario asdescribed in Section 13.1 This latter case is only feasible if data mediation
BTWholesale B2B G/W
WSMX Adapter
ebXML Messages conforming to BT XSD & BPSS
WSML Messages conforming to
Ad hoc WSML
Message Ontology
Message Ontology
Trang 14has already occurred or a suitable data mediator can be discovered(Figure 13.4).
13.6.3.2 Run-Time
The sequence of events at runtime are:
1 The trading partner OSS generates a message in its native format, forexample XML and forwards this to the Integration Platform
2 The Integration Platform applies the appropriate adaptor to convertthe message to WSML
3 A description of the appropriate target interface is retrieved from thedata store of the platform This can either be predetermined at design-time or discovered at run-time in a more flexible scenario
4 The choreography engine identifies suitable process and data tors for the message exchange
media-5 If it is appropriate to send an outgoing message to the target system atthis stage, the choreography engine applies the data mediator togenerate a message that the target will understand
6 The outgoing message is adapted to the native format of the targetinterface In this case, the target interface is that of the B2B Platform,which is ebXML
7 The outgoing message is forwarded to the intended destination
Of this sequence, steps 2–6 are platform-dependent in that they arecarried out by the WSMX architecture However, it is worth pointing out
already exist!
Message Ontology
Domain Ontology
Chor.
Ontology
BT – Side already exists
Message Ontology WSMX
DataMediationGUI
WSMO Mediators
ProcessMediation
Figure 13.4 Trading partner design-time tasks
Trang 15that the key benefit is obtained by the explicit relation that is madebetween the low-level messages and the domain ontology Any platformable to interpret this relationship would be able to apply mediation,thereby transforming the data and process to that required by the target.
13.6.4 Prototype Implementation
The prototype has been implemented using WSMX components to formthe B2B Integration platform Web-based GUIs, backed by appropriateWeb Services, simulate the OSS of the ISP and BT Wholesale The webservices observe the behaviour of the working systems in that actualmessage formats and exchange patterns have been utilised The follow-ing describes the RequestTest process that has been implemented for theAssurance Integration scenario A screenshot from a trading partner GUI
is shown in Figure 13.5
Figure 13.5 Screenshot from prototype UI