© 2006 - 2007 ieee standards association ieee service-oriented architecture (soa) standards ieee...

© 2006 - 2007 IEEE Standards Association

IEEE Service-Oriented Architecture (SOA) Standards

IEEE SOA Standards Updates

Liang-Jie (LJ) Zhang, Ph.D. Chair of Technical Committee on Services Computing, IEEE CSResearch Staff Member, SOA Services Research, IBM ResearchJuly 9, 2007

2


http://www.soa-standards.org

Services Computing

Community Overview

3



Services Computing Landscape

Service-Oriented Architecture (SOA)

BusinessConsulting

Services Orchestration

EnterpriseModeling

ServicesManagement

ServicesDiscovery

SolutionCreation

Services Optimization

Business process standards (OASIS)

Web Servicesstandards (W3C)

Internetstandards (IETF)

Internet (WWW) & NetworkingSoftware

Engineering

Database

Serv

ices

Com

putin

g

Parallel & Distributed System

Communication

ServicesDelivery

Multimedia

E-Commerce

ServicesMarketing

Management

Finance

Manufacturing

ApplicationDomains

...

GridComputing

UML & XMLHTTP

4



Proposed Structure of the Computing Curricula Series (Computing Discipline for Services Innovation)

SC 2007

Services ComputingCurriculum

Volume

Note: Blue pieces added by LJ Zhang

*Source: Computing Curricula 2005, The Overview Report, ACM and IEEE Computer Society

5



Body of Knowledge (BoK) Promoting Services Computing

An advanced single-sign-on capability has been integrated in this new RSS portal. Only the registered members of the IEEE Services Computing Community can access the IEEE Body

of Knowledge on Services Computing Portal.

RSS List

User System

BoK Web 2.0

Portal

ServicesComputing.tv

6



Service-Oriented Architecture (SOA)

Standards Update

7



SOA Standardization in the Industry(We have so many Web services standards. No SOA standards today.)

OASIS– SOA Reference Model (It is just an

annotation of Services.) – OASIS SOA Reference Architecture

Open Group– Open Group SOA Reference Architecture

Initiative (just formed in June 2007) OMG

– BPM Models on SOA (Rational)– UPMS – Organization Design

IEEE Standards Association – SOA Solution Reference Architecture (Started in June 2006)– It has published thousands papers on SOA in the past 5 years!

WHAT’S THE META DATA

MODEL FOR SOA?(of course, it is NOT the

triangular model!)

8



About IEEE Standards Association

The Institute of Electrical and Electronics Engineers Standards Association (IEEE-SA) is the leading developer of global industry standards in a broad-range of industries, including:– Power and Energy, Biomedical and Healthcare – Information Technology, Telecommunications– Transportation, Nanotechnology– Information Assurance

For over a century, the IEEE-SA has offered an established standards development program that features balance, openness, due process, and consensus.

9



IEEE Standards Association SOA Working Group

IEEE Standards Association formed SOA Working Group to define industry standards around SOA in June 2006.

Working Group Name: SOA and Web Services – with a short name of SOA

Standards Committee– SOA Working group is under the IEEE Computer Society/Software & Systems

Engineering Standards Committee (C/S2ESC) chaired by Paul R. Croll

10



One Year Late …

11



The IEEE SOA Standardization Efforts

Draft: IEEE SOA Solution Reference Architecture (SOA-SRA)

Work in Progress in the technical community: SOA Relationship Modeling Language (SOA-RML) SOA Services Discovery Language (federated discovery) (SOA-SDL)

Discussed Ideas at the 2007 IEEE Symposium on SOA Standards at SERVICES 2007:

SOA Services Composition Protocols (SOA-SCP) SOA Requirements Model (SOA-RM) SOA Adaptive Services Invocation Model (SOA-ASIM) SOA Services Ecosystem Exchange Protocols (SOA-SEEP) SOA Services Integration Protocol (SOA-SIP) SOA Service-Oriented Enterprise Project Management Model (SOA-

EPM) SOA Proactive Event Services Model (SOA-PESM) SOA for Manufacturing Execution System (SOA4MES)

12



IEEE P1723™ Standard for SOA Solution Reference Architecture

Scope:– This standard develops a standard protocol for creating service-oriented

solution architecture. This protocol is independent of the underlying implementation, platforms, and products used to realize the service-oriented architecture (SOA)-based solutions. This protocol is usable in all classes of solution scenarios. This standard is limited to design and modeling of service-oriented solution architecture and does not include design or modeling of service-oriented implementation and supporting infrastructures.

Purpose of Proposed Standard:– There is currently no defined, independent standard for designing and

modeling service-oriented solutions based on service-oriented architecture (SOA). Each vendor builds some design into the underlying programming language or business process flows. Without an independent, openly defined protocol, applications and other solutions cannot automatically determine the type of solution being communicated and integrated. This protocol provides a minimum implementation subset that allows automatic identification and configuration of service-oriented solutions and vendor extensibility, which will provide for growth and product differentiation.

13



IEEE P1723™ Standard for SOA Solution Reference Architecture (cont.)

Need for this project– There are significant challenges in creating an SOA solution. For example, from a

technical perspective, an architect has to answer the question such as “How do we produce an SOA solution using a well-defined notation?” or, “How can an SOA solution be organized as an architectural framework with inter-connected architectures and transformation capabilities? How can an SOA solution be designed in a manner that maximizes asset reuse? How can automated tools take the guess work out of architecture validation and artifact generation?”

– In order to address these issues, this standard presents an SOA Solution Reference Architecture that includes a reference architecture and construction protocols for designing and modeling an SOA-based solution. It provides a high-level abstraction of an SOA factored into layers, each addressing specific value propositions within SOA. Underlying this layered architecture is a meta-model consisting of layers, architectural building blocks (ABB), relations between ABBs and between layers, interaction patterns, options and architectural decisions. These will guide the architect in the creation of the architecture. An architectural building block represents a basic element of a reusable functionality that can be realized by one or more components or products. Examples include: a service definition, or a messaging mediation.

Stakeholders:– This standard may be used by almost every industry as long as they are moving to

SOA for creating flexible, extensible, and configurable solutions.

14



Contents of the IEEE P1723™ Standard for SOA Solution Reference Architecture

Overview Diagram of the SOA Solution Reference Architecture

MetaData Model Component Relationship

Diagrams Component Interaction

Diagrams Enterprise View of SOA

Solution Reference Architecture

Servicesatomic and composite

Operational Systems

Service Components

Consumers

Business ProcessComposition; choreography; business state machines

Service

Pro

vider

Service

Co

nsu

mer

Inte

gratio

n (E

nte

rprise

Se

rvice B

us)

Qo

S L

ayer (S

ecu

rity, M

an

ag

emen

t & M

on

itorin

g In

frastru

cture S

erv

ices

)

Da

ta Arch

itectu

re (m

eta-d

ata) &

Bu

sines

s Inte

lligen

ce

Go

vern

an

ce

Channel B2B

PackagedApplication

CustomApplication

OOApplication

S3: A Service-Oriented Reference ArchitectureFrom IEEE IT Professional Magazine, June 2007, http://www.computer.org/portal/cms_docs_itpro/itpro/homepage/2007/may_june/f3010.pdf

S3: A Service-Oriented Reference ArchitectureFrom IEEE IT Professional Magazine, June 2007, http://www.computer.org/portal/cms_docs_itpro/itpro/homepage/2007/may_june/f3010.pdf

15



SOA Solution Stack – Meta Model

16



The Meta-model of SOA Solution Stack (cont.)

Layers: – It is an abstraction of the nine layers of S3, which

contains a set of components such as ABBs, architectural decisions, interactions among ABBs and interactions among layers.

Options– options focus on solution-level patterns or principles

that an SOA solution architect should consider and make decisions upfront.

Architectural Decisions– It is one type of options specific for architectural

designs of an SOA solution. Normative Guidance

– It is one type of options specific for scenario-specific normative guidance.

Method Activities– It is a collection of steps that involve ABBs to form a

process to populate components in a layer. ABBs

– A set of Architectural Building Blocks (ABBs) reside in a layer that contains attributes, dependencies and constraints as well as relationships with other ABBs in the same layer or different layers.

Interaction Patterns– It is an abstraction of the various relationships

among ABBs (patterns and diagrams) within and across layers.

KPIs– It is a set of key performance indictor constraints

that involve in ABBs and put concerns on making architectural decisions

NFRs– It is a set of non-functional requirement constraints

that involve in ABBs and put concerns on making architectural decisions.

Enabling Technology– It is a technical realization of ABBs in a specific layer

by selecting which technology or product. Exposed Business Services

– Exposed business services (a.k.a. externalized business solution elements) refer to entities that expose business processes or composite business applications as business services that can be reused as service assets.

External Service Connectors– External service connectors refer to adaptors (e.g.,

transformers) for exploiting external services for business connections and business integrations.

Data Models– It models data contents associated with ABBs

including data exchange between layers and external services.

Functional Requirements– It models the functional requirements that one layer

or ABB must fulfill.

17



IEEE P1723 Draft Trial Standard for SOA Reference Architecture

18



SOA Services Discovery Language (SOA-SDL)

Draft Trial-Use Standard for SOA Services Discovery Language

Prepared by the SOA Working Group of the IEEE Computer Society/Software & Systems Engineering Standards Committee (C/S2ESC)

19



SOA-SDL: Scope

This standard develops a standard protocol for discovering business services in an SOA environment. This protocol is independent of underlying implementations, platforms and products used to realize the services-oriented architecture (SOA)-base solutions. This protocol does not deal with the publishing mechanism of business services. It works with both UDDI-based and WSIL-based services registries. With proper implementation supports, it can work with unstructured business services in which the owner of business services just posts web services in web sites where related parties have access. This protocol does not deal with the steps after business services discovery. These steps may include service composition, service invocation, service monitoring, service payment and service management.

20



SOA-SDL: Purpose of the Proposed Standard

The proposed standard defines a language called SOA-SDL (Service-Oriented Architecture, Services Discovery Language, or SDL for short in this specification).

SOA-SDL defines the desired input and expected output for the business services discovery system.

As expected, the design and implementation of the discovery system is not the main concern of this standard.

However, this standard includes requirements and recommendations for how this type of system should be implemented.

21



SOA-SDL: Need for this project

The idea behind SOA is simple: delivering business values to customers by leveraging open standards-based business services.

One of the key challenges is how to find the most appropriate business services. If the very best business services are not discovered, how an enterprise is able to deliver the best business value to customers?

This standard directly addresses this key challenge. It guides SOA solution architects in finding the best business services for their needs.

22



SOA-SDL: Stakeholders

This standard is applicable to SOA solution architects, designers of business services discovery systems, developers of business services discovery systems, owners of business services, IT managers and executives.

23



SOA-SDL: Abstract

This standard is the result of active research and development work starting from 2001. The public availability of UDDI is a milestone in the SOA community. However, people have concerns about the centralized architecture of UDDI for many years. WSIL was proposed to address the problems encountered in the implementation and usage of UDDI repositories. WSIL is a lightweight and decentralized approach to defining and linking web services. UDDI and WSIL are not the only ways to publish and store web services. It is possible to simply post web services on web sites or create a proprietary database for web sites and open up its interface.

In this specification, a language called SOA Services Discovery Language (SOA-SDL) is proposed to find available business services. This language includes two parts: desired input and expected output. The desired input allows users to specify search criteria such as service names and related key/value pairs. In addition, it is possible to specify aggregation logic and ranking criteria. The supported aggregation operators are OR and AND. The supported ranking criteria are Relevance and Newest First. Please note that in this specification, three words are used interchangeably: discovery, search and find.

24



Services Discovery

25



SOA-SDL Overview

SOA-SDL

Search Source

Aggregation Logic

Ranking Criteria

Extension Links NFR

KPI

ServiceName

Description

URL4WSDL

Others . . . .

Input Output

Ownership

Basic Information

Query

26



Example SOA-SDL

<?xml version="1.0" encoding="UTF-8"?><ServicesDiscovery xsi:noNamespaceSchemaLocation="SOA-

SDL.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<DateTimeOfCreation>2007-12-17T09:30:47.0Z</DateTimeOfCreation>

<ContactInfo> <AuthorName>John Smith</AuthorName> <Phone>914-784-7169</Phone> <Email>[email protected]</Email> <Address>String</Address> </ContactInfo> <Source>

<PublicUDDI>http://servicescomputing.org/service1/uddi</PublicUDDI>

<PublicUDDI>http://servicescomputing.org/service2/uddi</PublicUDDI>

<PrivateUDDI>http://w3.xyz.com/service1/uddi</PrivateUDDI>

<PrivateUDDI>http://w3.xyz.com/service2/uddi</PrivateUDDI>

<CustomRegistry>http://w3.acme.com/CustomRegistry1</CustomRegistry>

<AllTheWeb>false</AllTheWeb> </Source> <Query>

<QueryID>ID_1</QueryID>

<ServiceProviderName>Worldwide</ServiceProviderName>

<ServiceName>Shipping</ServiceName> <ServiceNameContains>transport</ServiceNameContains> <KeyValuePair> <Key>ServiceArea</Key> <Value>Northeast</Value> </KeyValuePair>

<ExtensionLink>http://www.acme.com/nfr/ShippingServicesNFR.xml</ExtensionLink>

</Query> <Query> <QueryID>ID_2</QueryID> <ServiceProviderName></ServiceProviderName> <ServiceName>transport</ServiceName> <KeyValuePair> <Key>TransportationMode</Key> <Value>Air</Value> </KeyValuePair>

<ExtensionLink>http://www.acme.com/nfr/ShippingServicesKPI.xml</ExtensionLink>

</Query> <AggregationLogic>ID_1 OR ID_2</AggregationLogic> <RankingCriteria>NewestFirst</RankingCriteria></ServicesDiscovery>

27



Value Added Services Around IEEE SOA Standards

28



Tooling for Supporting IEEE SOA-SRA

Model SOA Solutions In a Systematic way based on IEEE SOA Solution Reference Architecture

29



Summary

Lots of people are talking about SOA in an Ad-hoc way …

Need systematic way of standardizing SOA not only at infrastructure level (e.g. Web Services), but also at solution and services level

SOA Standards Are Coming …

© 2006 - 2007 ieee standards association ieee service-oriented architecture (soa) standards ieee...

Documents