ebSOA Submittal from BCM and BCM/EPR: Goals and RationaleWhy this submittal?The evolution of service-delivery technology and the growing complexity of services demand a service engineering discipline just as the growing complexity of information systems demanded an information engineering discipline. Competitive advantage is moving toward communities of service providers and service consumers who share a social experience and co-create value in experience networks. This dynamic marketplace has market participants entering and leaving the market continuously. This places a demand on architectures to support communication and collaboration in ad-hoc environments and create billable services in near real-time. The architecture must include social and technical infrastructures to support heterogeneous experiences and facilitate the co-construction of experiences and experience networks. Furthermore, the architecture must be “future proof” to support emerging technologies such as peer-to-peer computing, grid computing, and extreme mobility infrastructures for wearable computing.

This paper outlines the elements of an Adaptive Service Generation Conceptual Framework architecture which supports the above requirements. This paper is intended as either a tutorial or an application note to accompany or be integrated into the ebSOA best practices document which will accompany the normative standard document. The overarching goal of this paper is to focus on the core conceptual essentials of ebSOA and bridge the cognitive gap between the business domain experts and the IT infrastructure specialists. The Adaptive Service Generation Conceptual Framework supports real-time service generation in response to user requirements and real-time user customization. The framework functions as a service component factory to generate services from a set of available service components in a business service registry at or near real-time. The framework supports the interactive and adaptive qualities of the service relationship through service components enabled by environmental context and metadata stored in business service registries. A Service Component Architecture is developed which provides a layered view of componentized service delivery capabilities.

Finally, Semantic Infrastructure Services are developed to provide the metadata required to support the information and business architectures. The Semantic Infrastructure provides a service interface to a templating framework and content management system driven by a semantic registry. Adaptive Service Engineering methodologies utilize this interface to engineer composable service patterns for reuse and adaptation by the Adaptive Service Generation Conceptual Framework.

Goals?If I had the perfect ebSOA, how would I use it and how would I derive value from it and how would I communicate the management roles and tasks needed. This paper is intended as either a tutorial or an application note to accompany or be integrated into the ebSOA best practices document which will accompany the normative standard document. The overarching goal of this paper is to focus on the core conceptual essentials of ebSOA

1

2

3456789

101112131415161718192021222324252627282930313233343536373839404142434445

and bridge the cognitive gap between the business domain experts and the IT infrastructure specialists.

Give a roadmap for a possible application of ebSOA to focus the ebSOA TC discussions and submissions and provide a conceptual framework for integrating the various submissions with a primary focus on the business requirements and how the architectural elements and styles support those business requirements.

Rationale?Elicit overriding principles to facilitate communication and task goals of ebSOA TC.Principle 1:

Business User: I just want the information right now and right here to do my job.IT Professional: Semantic Granularity matches the Task GranularityArchitectural Support: Separation of Concerns throughout the Development

Lifecycle.

How does our ebSOA support this principle?e.g. How do we categorize semantics from weak to strong and where do we focus? How do we handle the level of concreteness and abstractness? Where do we as an ebSOA committee start in the following matrix and where do we migrate to???? Strong Semantics Self Organizing

Modal Logic ApplicationsFirst Order Logic      

Local Domain Theory Is disjoint subclass of    Description Logic with transitivity property    DAML+OIL, Owl    

UML Social ContractConceptula Model Is subclass of Establishment and

RDF/S MaintenanceXTM Business Services  

Extended ER      

ThesaurusHas narrow meaning than    

ER Business    Schema Foundation Services Source of Y axis:

Taxonomy Is subclassification of Figure 7.5, pg 157Relational Model     The Semantic Web

Weak Semantics    Daconta, Orbst, Smith

Very Concrete       Very Abstract

What should a reader of our document (Application Note?, Best Practice? or Tutorial?) learn?

1. Be able to create a “good” ebSOA specification (model?) that exhibitsa. Architectural Support for Automation

i. Partially executableii. Declarative precursor to MDA (Model Driven Architecture)

464748495051525354555657585960616263646566

67686970717273

b. Comprehensibilityi. Understandable semantics that are key to obtaining biz value

ii. Design Rationales are visible – often impossible to uncover the important business requirements and imperatives that shaped the model and specification and provide business value. This is often called implicit knowledge or domain knowledge.

c. Model or Specification is accessiblei. Understand the visual syntax

ii. Ability to drive the modeling tool to navigate the modeld. Collaboration Orientede. Traceable to Ontology, Dictionaries, Vocabularies

i. Automatablef. Specification supports Community of Interest

2. Have an appreciation of the difficult challenge of specifying the appropriate level of concrete abstraction. This translates into the wholeness of a specification and the architectural support for quality: When and who needs a template; and when and who needs a model. In other words, how many transformation steps from abstract to concrete does the framework for the specification require? Traceability of high level requirements to model artifacts relies on the fidelity of the modeling transformations and lacks essential feedback from the non-technical community. The model transformation fidelity requires semantic support linkages.

3. Semantic Support in the Architecture/Framework is the major determinant of adoption and technology transfer. How do we measure our success criteria for the following Innovation Drivers1 that increase the rate of adoption by the end customer and the team members:

a. Relative Advantage – the degree to which an innovation is perceived as better than the idea it supersedes. The degree to which an individual or organization perceives the innovation as advantageous because of economics, social prestige, convenience etc.

b. Compatibility – the degree to which an innovation is perceived as consistent with the existing values, past experience, and needs of potential adopters.

c. Complexity – the degree to which an innovation is perceived as difficult to use and understand. Innovation is slower if the adopter has to develop new skills and understandings.

d. Trialability – the degree to which an innovation may be experimented with on a limited basis. New ideas that can be tried on the installment plan will generally be adopted more quickly than innovations that are not divisible. Trialable represents less uncertainty to the individual who is considering it for adoption, as it is possible to learn by doing.

e. Observability – the degree to which the results of an innovation are visible to others. Visibility stimulates peer discussion of new ideas as peers of an adopter request innovation-evaluation information about it.

1 Rogers, Everett M., Diffusion of Innovations, 4th Edition, Free Press, 1995, pp. 15-17

7475767778798081828384858687888990919293949596979899

100101102103104105106107108109110111112113114115116117118

1

4.119120121

Table of ContentsebSOA Submittal from BCM and BCM/EPR: Goals and Rationale...................................1Introduction..........................................................................................................................8Adaptive Service Generation Conceptual Framework Business Drivers............................8Adaptive Service Generation Conceptual Framework Architecture Requirements............9

Social and Technical Infrastructures to Support Heterogeneous Experiences................9Rapid Resource Reconfiguration.....................................................................................9Access to Competence.....................................................................................................9Experience Quality Management..................................................................................10Business Lifecycle Activities Management...................................................................10

Adaptive Service Generation Basics.................................................................................11What is a “Service”........................................................................................................11What is a “Service Component”....................................................................................11Service Component Adaptation.....................................................................................12Service Collaboration....................................................................................................12

Adaptive Service Generation Conceptual Framework......................................................12<PasteFromMSDN>......................................................................................................13 Enterprise architecture—the systematic modeling of an organization's objectives, priorities, resources, and processes to achieve the self-awareness necessary for directed improvement..................................................................................................................13 Enterprise information integration—creating a set of organizational standards for the business entities—the complex "types" such as "customer," "employee," and "purchase order"—that are manipulated by your application portfolio.........................13 Process orientation—making the business process the focus of design for your enterprise architecture and information technology portfolio.......................................13 Business process orchestration—models that support agile business processes by making the sequencing of steps in the process as lightweight and adaptive as possible.

13 Event-driven architecture—a model in which business events, such as the arrival of parts on the shipping dock or the payment of an invoice, trigger a message to be sent to subscribing services to allow them to take appropriate action..................................13 Virtual enterprises—viewing business processes as value chains that extend across organizations, permitting each organization to focus on its core capabilities and to outsource noncore capabilities to external service providers....................................13 Aspect orientation—providing a means for the consistent handling of cross-cutting concerns, for example the monitoring of business activities, access control to services, and reliability of message delivery.................................................................13 Human workflow management—the orchestration of information workers and their interactions with business processes to achieve efficiency and responsiveness to customer needs...............................................................................................................13 Disintermediation—the automation of nonexceptional information exchanges across business boundaries, to eliminate the need for information workers to perform routine tasks such as data entry from written (fax, mail, e-mail) or verbal information exchange........................................................................................................................13

122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165

Agility—systems designed to be responsive to the specific context and content of a business request, as well as to broader changes to business requirements and business strategies........................................................................................................................13 Model-driven development—driving the solution development process from a higher-level—generally graphical—language that is more closely bound (compared with, say, Visual C#) to the business processes being automated.................................13</PasteFromMSDN>.....................................................................................................13Missing from the above Microsoft list are the following:.............................................13Federated Semantic Registries.......................................................................................13Domain Taxonomies......................................................................................................13Topic Maps....................................................................................................................13Vocabularies..................................................................................................................13Dictionaries....................................................................................................................13Legal Interaction Models (BPSS, CPA, CPP)...............................................................13Interface Rendering and User Interaction......................................................................14Agents............................................................................................................................14Business Services Architecture......................................................................................14

Shared Infrastructure Services...................................................................................14Shared Infrastructure Service Assembly & Deployment...........................................15Business Foundation Services...................................................................................17Business Services.......................................................................................................19

Semantic Infrastructure Services...................................................................................20Pragmatic Semantic Interoperability Support Mechanisms......................................20Template Lifecycle Management..............................................................................20Business Service Registries.......................................................................................21Deployment Automation for Choices and Adaptation..............................................21Content Management Systems..................................................................................23Enterprise Information Services................................................................................23

Adaptive Service Engineering Methodologies..............................................................23Engineering Pragmatic Semantic Interoperability.....................................................23Experience Network Focus........................................................................................24Template Focus..........................................................................................................24Exposed Context Everywhere....................................................................................24Design by Contract....................................................................................................25

Applying Adaptive Service Engineering Techniques....................................................25Determining Experience Network.............................................................................26

Collaboration Mechanisms............................................................................................26BCM Layered Methodology Mechanisms.....................................................................26Concept Layer using Draft ISO/IEC 15414:6-2002 Enterprise Specification Language.......................................................................................................................................27Business Layer...............................................................................................................28Extension Layer.............................................................................................................28Implementation Layer...................................................................................................28

Summarization of above into Conceptual Framework Views...........................................28Collaboration View........................................................................................................28Contractual View...........................................................................................................28

166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211

Execution View.............................................................................................................28Realizing Value from Adaptive Service Generation Conceptual Framework in Collaborative Commerce...................................................................................................28Acknowledgements:..........................................................................................................29

212213214215216

Introduction

Recent trends in technology and changes in the business environment for service delivery force a re-examination of our understanding of services and how we deliver services. Developments like web services and business trends such as service outsourcing make it possible to deliver services in new ways. This paper addresses the implications of these changes for service delivery and the speed with which new services can be developed and deployed though the use of new technologies. The evolution of service-delivery technology and the growing complexity of the service economy will demand a service engineering discipline just as the growing complexity of information systems demanded an information engineering discipline. This does not mean that all such services need to be automated. On the contrary, the concepts of service components and Service Component Architecture apply equally well to automated and human-delivered services.

This submittal outlines the elements of service engineering and the service customization aspects of the Adaptive Service Generation Conceptual Framework and addresses the following business issues:

IT infrastructure and service consolidation Satisfying customer support demands for increasingly complex products and

services. Reducing the time required for customized service generation and delivery Integrating human-delivered and machine-delivered services The Collaborative Commerce challenge of managing business functions that are

the joint effort of multiple business partners Maintaining private, shared, and public vocabularies, dictionaries and ontologies Benefits of Service Component Engineering

Adaptive Service Generation Conceptual Framework Business Drivers

Prahalad and Ramaswamy, in the Future of Competition2, postulate building an experience network infrastructure which enables managers to compete on experiences in experience networks. Customers build their own thematic communities (Experience Network) where they share their knowledge, support services, and peer group access to increase the collective expertise of the community by freely sharing best practices. This Experience Network is particularly important for highly informated and technology-enabled intelligent products where the customer service consumer and the company service provider co-discover and co-create new value for both. Competitive

2 Prahalad, C.K., Ramaswamy, Venkat, The Future of Competition: Co-Creating Unique Value with Customers, Pg. 97, Harvard Business School Press, 2004

217

218

219220221222223224225226227228229230231232233234235236237238239240241242243244245246

247

248

249250251252253254255256257

23

differentiation depends on the quality of the experience network that service providers and service consumers share and depends on the balance of local customization and cost efficiencies of standardization.

Adaptive Service Generation Conceptual Framework Architecture Requirements

Social and Technical Infrastructures to Support Heterogeneous ExperiencesInfrastructure must support heterogeneous co-creation experiences. Experience networks need smart control systems to move the market intelligence to the points of interaction and to manage the backbone of the network infrastructure. Both social and technical enablers must facilitate the co-construction of experiences and experience networks. Service consumer heterogeneity is supported by technical infrastructure for discovering and collecting attributes of the service consumer and the interactive behaviors that progressively change the capabilities of the service consumer. The framework provides the technical feedback mechanism for indicating the quality and effectiveness of changes in the service consumer. The social enablers include framework support for creating Service Consumer and Service Provider communities that overlap and share information, experiences, and knowledge. Social enablers provide Experience Network support services such as membership registration, identification, authentication and authorization. These core social enablers provide the basis for the Community to build trust networks, reputation chains and other Social Contract maintenance activities.

Rapid Resource ReconfigurationDelivering consistently high quality services and experiences requires the ability to quickly adjust to shifts in demand for service provider services. The critical ability of the experience network to scale up and down requires the capacity to reconfigure resources effectively and respond quickly. This marketplace dynamism requires automated service delivery mechanisms that generate services in a deployment framework. Dynamic service logistics depend on deployment automation which utilizes meta data about the service consumer to adapt services for the service consumer. Delivery of services has to emphasize the interactive and adaptive qualities of the service relationship in the context of an experience network. Componentization of the service delivery capability enables adaptation to changing requirements of service consumers and markets.

Access to CompetenceWho provides Ecosystem Provisioning Support????

Verify readiness for e-commerceSystem Operation and MaintenanceContent Provision for UsersSystem AdministrationSystem Configuration for SMEsSystem Integration for SMEs

258259260261

262

263

264265

266267268269270271272273274275276277278279

280

281282283284285286287288289290

291

292293294295296297298

e-Learning

Experience Quality ManagementAs service providers and service consumers interact in experience networks (Communities of Interest), value lies in the variety of experiences the experience network can accommodate as well as the quality of co-creation experiences. Managing the quality of co-creation experiences is Experience Quality Management (EQM) as opposed to Total Quality Management (TQM) which had a product and process focus. Traditional product-oriented TQM taught us to stamp out variation in a bid to control product quality. EQM on the other hand means embracing heterogeneity and variability with quality of execution. The Service Consumer demands a unique personalized experience while simultaneously demanding responsiveness, speed, reliability and cross-channel consistency. The experience network must be designed to accommodate variation in Service Consumer experiences while reducing variation in the quality of the supply processes that are activated to co-construct Service Provider and Service Consumer shared experiences. Service Consumer quality is highly dependent on consistent experiences in cross-channel access to products and services. Experience Quality is driven by the contextual interaction between individual Service Consumer and experience environments.

Business Lifecycle Activities ManagementThe activities of a business lifecycle – The declaration, maintenance and evolution of TRUST.Provision Enterprise for Role within the target marketplaceContract with PartnersProvision relationships with PartnersTransact with PartnersSettle transactions with PartnersResolve discrepancies with PartnersTerminate relationship with Partners Syndicate transactions through distribution Partners

The concerns associated with the activities of a business lifecycle areGovernance to control and direct the making and administration of

policy inAccreditation to recognize or vouch for as conforming with a standardProvisions the fact or state of being prepared beforehandAssurance the act or action to make safe as from risk Mediation the act of intervention between conflicting parties to

promote reconciliation, settlement, or compromiseSyndication the process of selling information for publication through a

number of independent distribution channels simultaneously

Reconciliation the process to make consistent or congruousRecourse the right to demand payment from the maker or endorser of

299

300

301302303304305306307308309310311312313314315316317

318

319320321322323324325326327328329330

a negotiable instrument

<This section needs major help and an owner. I just went to the dictionary while setting in traffic and pulled the following definitions into my voice recorder. These terms are not formal and orthogonal but they seem to capture the eCosystem aspects of the declaration, maintenance and evolution of trust and cooperation which is really the essence of business.>

Adaptive Service Generation Basics

What is a “Service”While process, defined as an activity with inputs and outputs, takes little account of external circumstances, for service, context is crucial. A service focuses on the service consumer rather than the business function. Whether provided by a human help desk operator or an automated system, a service provides something of value to a service consumer via an interactive course of action. The existence of the service consumer of the service is important in determining the behavior of the service provider.

Service properties: Mechanism for discovering attributes of its environment and the attributes of the

service consumer Interactive behaviors that progressively change the capabilities of the service

consumer Feedback mechanism for indicating the quality and effectiveness of those changes

in the service consumer Means for using the attributes of the service consumer to select appropriate

service delivery behaviors Means for adapting the mode of interaction with the service consumer to needs

(attributes) of the service consumer Means for communicating with and building on capabilities of other service

providers (collaboration) Access to skills and other knowledge resources that provide value to service

consumer.

What is a “Service Component”The decomposition of services into service components enables the business to identify service capabilities and support reusability of service capabilities that are delivered in different business contexts. The implementation of business service components depends on technical components that support service deployment. The initial modeling of services in terms of service components is performed independently of any particular technical implementation.

Adaptive Requirements of a Service Component Acquires custom information about the service consumer Selects service behaviors appropriate to service consumer

331332333334335336337

338

339

340341342343344345346347348349350351352353354355356357358359360361

362

363364365366367368369370371372

Adapts manner of interaction to service consumer profile Assesses change in service consumer capabilities Applies a skill-set and knowledge resource in delivering the service

Change in state of the service consumer becomes part of the customer profile and interaction history. Knowledge of service consumer preferences and behaviors in turn influences subsequent delivery of services. Service components adapt to the current needs of service consumers and the deployment environment. These adaptations are standardized for multiple service components but may adjust to factors that depend on where, when, how, and to whom the service is to be delivered.

Even though both software components and Service Components share the term service, the term has a different meaning for the two domains. In the software domain, service often takes on the meaning of a called procedure such as a CORBA service. In the service domain, service is an interactive process that changes the capabilities of the service recipient to do something of value. A Service Component is the componentized formal view of the interaction we call a business service. A web-service is simply a standard for software wrapping and identification. Web-services represent a software component technology which can be used to implement Service Components. The agile semantic interoperability focus of Adaptive Service Engineering refocuses architecture decisions away from applications and web services technology toward multi-participant collaborative business services that occur within experience networks.

Service Component AdaptationService components provide for service adaptation in two ways.

1. Collaboration Patterns2. Adapt to variation in service consumer needs

policy and profile as a service adaptation mechanism build the adaptation mechanism requirements for BCM Choice Point Linking and Switching here

Service CollaborationLike replication of business service components across business units, technical service components can be implemented within the reusable Adaptive Service Generation Conceptual Framework. See Shared Infrastructure Service Assembly & Execution layer of the Business Services Architecture.

Adaptive Service Generation Conceptual FrameworkThis section of the document will develop a conceptual and architectural framework consisting of

Business Services ArchitectureSemantic Infrastructure ServicesService Engineering Methodologies

373374375376377378379380381382383384385386387388389390391392393394

395

396397398399400401

402

403404405406

407

408409410411412

to address the following service orientation “concepts”. These concepts were cut and pasted from Microsoft MSDN3. <PasteFromMSDN>

Enterprise architecture—the systematic modeling of an organization's objectives, priorities, resources, and processes to achieve the self-awareness necessary for directed improvement.

Enterprise information integration—creating a set of organizational standards for the business entities—the complex "types" such as "customer," "employee," and "purchase order"—that are manipulated by your application portfolio.

Process orientation—making the business process the focus of design for your enterprise architecture and information technology portfolio.

Business process orchestration—models that support agile business processes by making the sequencing of steps in the process as lightweight and adaptive as possible.

Event-driven architecture—a model in which business events, such as the arrival of parts on the shipping dock or the payment of an invoice, trigger a message to be sent to subscribing services to allow them to take appropriate action.

Virtual enterprises—viewing business processes as value chains that extend across organizations, permitting each organization to focus on its core capabilities and to outsource noncore capabilities to external service providers.

Aspect orientation—providing a means for the consistent handling of cross-cutting concerns, for example the monitoring of business activities, access control to services, and reliability of message delivery.

Human workflow management—the orchestration of information workers and their interactions with business processes to achieve efficiency and responsiveness to customer needs.

Disintermediation—the automation of nonexceptional information exchanges across business boundaries, to eliminate the need for information workers to perform routine tasks such as data entry from written (fax, mail, e-mail) or verbal information exchange.

Agility—systems designed to be responsive to the specific context and content of a business request, as well as to broader changes to business requirements and business strategies.

Model-driven development—driving the solution development process from a higher-level—generally graphical—language that is more closely bound (compared with, say, Visual C#) to the business processes being automated.

</PasteFromMSDN>Missing from the above Microsoft list are the following:Federated Semantic RegistriesDomain TaxonomiesTopic MapsVocabulariesDictionariesLegal Interaction Models (BPSS, CPA, CPP)

3 Service Orientation and Its Role in Your Connected Systems Strategy. July 2004 http://msdn.microsoft.com/library/en-us/dnbda/html/SrOrientWP.asp?frame=true

413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456

45

Interface Rendering and User InteractionAgents

Business Services ArchitectureThe Business Services Architecture is layered into four layers or separations of concern. The four layers of conceptual abstraction are

Shared Infrastructure ServicesShared Infrastructure Service Assembly & Deployment Business Foundation ServicesBusiness Services

The first two layers are primarily infrastructure and technology oriented. The second two layers are primarily business and domain oriented. You can consider the two layers as a pair where one layer provides raw services and the related second layer provides service composition and deployment services on top of the raw services. For example, Business Services are “assembled” and deployed using Business Foundation Services. Graphically, the Adaptive Services Generation Conceptual Framework is abstractly bound at each abstraction layer by a contractual view which is influenced by the policies in effect in the eCosystem that the service provider and consumer operate.

Shared Infrastructure ServicesThe Shared Infrastructure Services Layer of the Adaptive Service Generation Conceptual Framework generalizes the network model to make it possible to employ or link to other technologies such as web services, GRID services, or peer-to-peer networks. This is achieved by adopting an abstract model based on actors and services and mapping the abstract model to a number of different implementation technologies.

457458

459

460461462463464465466467468469470471472473474

475

476

477478479480481482

Shared Infrastructure Service Assembly & Deployment4

This layer treats the Shared Infrastructure Services layer as a collection of Shared Services. For example, guaranteed messages could be implemented via ebXML ebMS or a stack of Web Services WS-* specifications. When infrastructure services are published to the eCosystem, traceability mappings are created for reconciliation and mediation by the Business Foundation Services layer. Traceability mappings include the form, function, and structure (Morphology) of the configured and enabled Shared Infrastructure Services. An Infrastructure Morphology with its own infrastructure contract semantics is used for infrastructure service discovery and provisioning. This layer provides a virtualization service to separate shared services from network, platform and language specific implementations. The abstract metadata of the Infrastructure Morphology is used by Model Driven Architecture (MDA) technologies such as Service Model Component Compiler technology to generate a “Collaboration Pattern” of deployment frameworks including Collaboration, Contractual, Execution and ebXML frameworks for a particular service consumer. The generated deployment frameworks are adapted for the eCosystem context model and the service consumer policy and profile.5 This layer manages the eCosystem ontologies for the infrastructure domains and their associated directories.

Actor Domains Collaboration Agent Directory Services

Service Domains Service Directory ServicesAgent Domains Agent Directory ServicesPlatform Domains Platform Directory Services

This layer supports ontology independence and supports dynamically-loaded, defined ontologies, policies, and profiles defined by an eCosystem collaborative architect. Once ontologies are loaded into a registry, the ebXML Federated Registry becomes the enabler for distributed and Federated governance. Conformance and interoperability at the Shared Infrastructure Services layer are now a function of shared information and collaboration semantics. A search into the EcoSystem Infrastructure Morphology Registry can be a constraint-based search for each service policy based on profile attributes. This search process might be considered as a matchmaking process, since the obtained results are bounded by user-defined constraints. Through registry enabled federation, infrastructure service providers can share their service repositories to provide infrastructure services.6 Provisioning automation enables both Infrastructure Services and Business Foundation Services. Portals can use provisioning automation to establish self service processing and if the marketplace grows, leverage incremental automation to migrate from people and paper based processes to interactive web based workflow processes with automated testing and automatic certification.

4 This layer is a conceptualization of the www.lauraproject.org project of a B2B Architecture Based on ebXML and Peer-to-Peer Technologies from Kingston University.5 Strengthen policy and profile as a service adaptation mechanism across this and all other layers 6 How does ebSOA envision testing, and certification services Self Provisioning and Self Certification BCM Templating mechanism at the BCM Implementation layer here. NO SELF REGISTRATION?

483

484485486487488489490491492493494495496497498499500

501502503504505506507508509510511512513514515516517

6789

10

Generic Open Source JXTA can be used to implement this layer and provide virtualization of Shared Infrastructure Services. JXTA is often used for a Mobile Middleware Distributed Execution Environment. JXTA generic services provided to this layer include

Environment Monitoring Event Notifications Service Discovery Configuration Management Trust and Privacy Support Mobile Data Management

In summary, this layer isolates the infrastructure services from the technology functions of platforms, network topologies (GRID, P2P, Agents, etc.) and middleware services. provides the foundations for automated self provisioning and certification through the use of an Infrastructure Morphology Registry. Conformance and interoperability are a function of shared ontologies, information models, and collaboration semantics. Common SLA Administration and SLA Governance services are provided to both the Infrastructure Services and the Business Foundation Services layers.

An implementation of this layer can be found in the www.lauraproject.org which conceptualized an architecture for Request-Based Virtual Organizations for sector-specific Service Level Agreements7.

Duane Nickull patterns hereBusiness Signals and Messaging Patterns

- Business Message Dispatch- Business Message Persistent Storage- Business Message Reception

o Validationo Security validationo Checking parameters against SLAo Internal Application binding to messaging serviceso Event notification via messaging API (Internal API)

- Business Eventso Monitor-able event linking to messaging and acknowledgements

SOA Payload and transaction metadata- Core Components approach- Data Element modelling- Context mechanism- Plurality mechanism- Data element reconciliation

7 This project created a BSN, Business Service Network, with Discovery Services at each of the four levels of the Adaptive Service Generation Conceptual Framework implemented through a Generic Discovery Service. Open Source JXTA generic infrastructure discovery services were used as an implementation model for the Shared Infrastructure Services Assembly and Deployment layer.

518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559

11121314

- Data element aggregation (Content Assembly)- Instance data constraints by metadata- Presentation and view of Business Message Payload

Business Foundation Services8

This layer of the architecture provides marketplace infrastructure services to the industry BUSINESS SERVICE NETWORKs (BSNs). Marketplace infrastructure services include

Collaboration Community Composition ProcessMaintenance of Social ContractCollaboration Support ServicesEcosystem Performance and Evolution Summarization Data

This layer is analogous to the Shared Infrastructure Services layer in the IT Infrastructure at the “bottom” of the conceptual framework. The Business Services layer could have been named Business Foundation Services Assembly & Deployment for framework consistency but Business Services is an accepted label, thus Business Services.

Collaboration Community Composition ProcessMarket Provisioning: negotiation, service matching

Partner SearchReputation Information Reference SearchSelection of PartnersCollaboration Contract ProposalModifications and Negotiations Formal Responsibilities ContractVoting on Community participation in Virtual Collaboration CommunityPlanning: Scheduling services that provide aggregation, procurement and

service matching functionsFormalize Virtual Collaboration Community (VCC)

Agreement to use advertised services are issued and agreed amongst community participants through formal contractsDefine VCC Formal Contracts

VCC ChoreographyVCC Choreography instantiate into Architecture and

Component specific orchestrations set boundary conditions for further task

negotiation Execution Environment

Orchestration DecisionsAllocation DecisionsInvocations

Maintenance of Social ContractIdentification of Maintenance Need

Social Interactions in VCC triggered by environmental monitoring activities or VCC member

8 The Concepts for this layer are based on analysis of Cross Flow, REACH and the LauraProject.

560561562563

564

565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603

15

Re-Choreography and/or Re-OrchestrationReplacement of Services

Search Directory Services for available ServiceIdentification of Potential CandidatesChoice of Candidate and Negotiation of Terms and ConditionsEstablishment and Amendment of ContractsGroup Acceptance

DissolutionTermination Conditions are triggered by VCC monitoring functionCompensation

Determination of Compensation Amounts and TimingPayment in Funds between Agents

Collaboration Support ServicesCollaboration Policies from Collaboration Profiles in Semantic Registry

Formation Conditions of Collaboration TeamDissolution Conditions of Collaboration TeamCompensation Terms for Collaboration InclusionCompensation Terms for Collaboration ExpulsionConsensus Mechanism

Voting, Veto, etc.Community Access from Community Manager

Edit Permissions; Delete Contacts via voting mechanism, Block Access

Collaboration Provision Role Assumption; Task AssumptionAdd Service ProviderAdd Service ConsumerVirtual Enterprise Creation – provide accessibility for enterprises to publish its own highly available services available to the experience network

Collaboration Profile Repository Searches of Community CategorizationsGeographical FocusReferrals & IncentivesAdd RatingAdd Contacts

Ecosystem Performance and Evolution Summarization Data Most Commonly used business channels, aggregators, syndicatorsNumber of Registered UsersNumber of Collaboration PeersQuality Assurance on Suppliers, Quality of Services in Collaborative Commerce PortalNumber of Collaboration CommunitiesNumber of Searches leading to business transactions

604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648

Business ServicesThese are the basic services an application service provider would provide to a marketplace.

Figure x.x: Adaptive Service Generation Conceptual Framework Stack Interactions

Business relationship based on a contract, providing a common view of the service, the monitoring and control points, and promises defined in the contract.

Service Activation, observing the progress of the service (allowing shadowing in the consumer) and providing the consumer with some control over the service provider behavior according to the contract at each of the Adaptive Service Generation Conceptual Framework Layers.

Business Life Cycle (Round Trip):

Business Goal: Virtual Enterprise through business process crossing organizational boundaries and enabled by:

Contract EstablishmentEnactment Infrastructure Creation and LinkingEnactment

I need someone to help me map the existing OASIS standards to this stack. BPSS resides in either the top of Shared Infrastructure Service Assembly & Deployment or the bottom of Business Foundation Services or both around the interfacial between them.

649

650651652

653654655656657658659660661662663664665666667668669670671672673674675

Semantic Infrastructure ServicesSemantic Infrastructure Services focus business analysts on precise communications amongst multiple experience networks with open declarative mechanisms that allow for mass customization of diverse vocabularies and models given the environmental context of the service providers and service consumers. The organizational memory of the eCosystem participants in experience networks is organized as a series of templates stored in the Semantic Registry and referenced by the Business Services Registry.Benefit statement here on value proposition for private, shared, and public information.

Pragmatic Semantic Interoperability Support MechanismsSemantic Infrastructure Services provide discovery and navigation of taxonomies, classifications and ontologies through template based mechanisms. The Adaptive Service Generation Conceptual Framework provides the following structures and support mechanism to generate Semantic Infrastructure Services

1. Taxonomy/Ontology, 2. Semantic Registry, 3. Workflow, and 4. Content management system.

The ontology is comprised of various facetted taxonomy views of the business with the capability of defining thesaurus (e.g. synonyms, alias) relationships that reside on a registry. The registry provides reference assistance and stores information about the supporting classifications and metadata artifacts in templates. Copy in Business First Idea here Workflow – this is the placeholder for Choreography vs. OrchestrationTop of the SOA Stack Choreography and Coordination

Business Process, Service FocusedExposed to a trading partnerUses Domain Expert Terminology

Lower in the SOA Stack Orchestration and CompositionComponent FocusedFlow of messages between components expressed as a meta languageUses IT Expert Terminology

Template Lifecycle Managementdirectly enables the model; provides coupling between the Templates and the deployment environment via distributed customization Choice Points to ensure that the linking and switching that occurs in the deployment environment matches the actual business requirements. choice point linking and switching as an adaptation mechanism for service component compositionCopy in Business First Idea here? Wait on the Business Centric Methodology TC Electronic PRocess (BCM EPR) Subcommitte to develop a position on Meta Models and Archetype Patterns9 and their 9 See Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML, Jim Arlow, Ila Neustadt, Addison Wesley 2004

676

677678679680681682683

684

685686687688689690691692693694695696697698699700701702703704705706707708

709

710711712713714715716717

1617

relationship to Templates and the resulting Template Lifecycle Management. I believe the BCM EPR eHealthcare requirements will drive this section in three months.

Business Service RegistriesDuane Nickull applicable patterns go here…4.2 Registry Discovery and Service Invocation

- 4.2.1 Basic Registry for Discovery- 4.2.2 Registry service patterns (Service Interface to Registry, API’s etc.)

o 4.2.2.1 Registry account set up(actors)o 4.2.2.2 Registration of Artifacts via Registry APIo 4.2.2.3 Management of Registry artifacts via APIo 4.2.2.4 Query for Artifacts via APIo 4.2.2.5 Registry Federation across multi-registry environmento 4.2.2.6 Assertions of associations by Registry Registered Userso 4.2.2.7 Linking and switching of Registry artifacts

- 4.2.3 Service Description Registration- 4.2.4 Service Security Assertion Registration- 4.2.5 Service Parameter Registration- 4.2.6 Service Supporting Artifact Registration- 4.2.7 Registry Interaction Patterns

Deployment Automation for Choices and AdaptationChoice Point Linking and Switching from OASIS BCM

The BCM utilizes a ‘contract’ to formalize the combination of workflow, processes, schema, maps, rules, etc. into BCM artifacts. The underlying principle is that each BCM layer solves the problem at that level, and only that level, based on a focused set of constraints. Information that is not available or relevant at that point is deliberately deferred up to the next layer – thereby simplifying the overall solution. This approach is also in alignment with Service Oriented Architecture (SOA) technologies built around Web services where service points deliver solutions to discreet requirements, and therefore often function like “help from above” from the user’s perspective.

The gathering of Choice Point parameters and control requirements

BCM Templates needed to generate decision points and variables across an identified pattern. For example, contract instantiation creates objects at runtime that interact as described by the contract;

http://www.amazon.com/exec/obidos/ASIN/032111230X/qid=1090990493/sr=ka-1/ref=pd_ka_1/103-6807037-6405420

718719720

721

722723724725726727728729730731732733734735736737738739

740

741742743744745746747748749750751752753754755756757758

1819

Figure xxx Template Contract Choices directed via Choice Point

Choice Points can be seen as providing enablers for agile information exchanges:

· Context criteria, where the scope of the context extends beyond the local decision point, and can also require persistence of decisions

· Determining context by refining criteria dynamically, and that may include undetermined start points

This is where the BCM differs significantly from current methodologies as it directly embraces and provides support for choice based on environmental context tie this to Service properties:

Mechanism for discovering attributes of its environment and the attributes of the service consumer

Interactive behaviors that progressively change the capabilities of the service consumer

Feedback mechanism for indicating the quality and effectiveness of those changes in the service consumer

Means for using the attributes of the service consumer to select appropriate service delivery behaviors

Means for adapting the mode of interaction with the service consumer to needs (attributes) of the service consumer

Means for communicating with and building on capabilities of other service providers (collaboration)

Access to skills and other knowledge resources that provide value to service consumer.

759

760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790

Content Management SystemsNasty hard question: When is Context considered Content??? This is a major interaction with Choreography and InteractionebXML Registry Version 3 Capabilities with respect to content

Arbitrary Content (Content Repository)Content Specific ValidationContent Specific CatalogingVersion ControlPre-defined taxonomiesOntology SupportUser-defined AssociationsSimple Event NotificationContent Based Event NotificationExtensible Information Model (Metadata is extensible)

Enterprise Information Services???

Adaptive Service Engineering Methodologies Adaptive Service Engineering captures and configures the metadata that populates Semantic and Business Registries with reusable and composable service patterns for use in the service composition factory of the Adaptive Service Generation Conceptual Framework. Adaptive Service Engineering focuses the metadata aspects of software engineering, business process engineering, and ontological engineering on sustainable and agile interoperability mechanisms in the Adaptive Service Generation Conceptual Framework.

The agile semantic interoperability focus of Adaptive Service Engineering refocuses architecture decisions away from applications and web-services technology toward multi-participant collaborative business services that occur within experience networks.

Link to agents and infrastructure morphology example of supporting the degree of syndication and aggregation here if time

Engineering Pragmatic Semantic Interoperability Captured rationale and documented constraints are necessary to make

transformations from data to information Templates are used with the various layers of the methodology to collect metadata

and business rationale; apply form to this information to establish context; and further constrain it using human capital and experience to produce useful knowledge

Templates simplify data collection , properly classify the resulting information, and reveal underlying patterns within the information.

Extend ontological alignment beyond the contractual layer Creation of a comprehensive information architecture

791

792793794795796797798799800801802803804

805

806

807

808809810811812813814815816817818819820821822

823

824825826827828829830831832833

Experience Network FocusExperience Networks (Communities of Experience) are the focus for managing of eCosystem artifacts and governance. This includes the linking of business goals to concepts, and exact business requirements, through mappings and generating physical implementations via the Adaptive Service Generation Conceptual Framework.  The Experience Network collaboration partners are then able to reuse their own declarative community semantics in loosely-coupled machine readable mechanisms such as ontologies, classifications, industry vocabularies, and patterns within their normal business processes with precise context when business opportunities arise. 

Template Focus Adaptive Service Engineering (ASE) is a philosophy of making business objectives, agreements, semantics, and rules of the organization preeminent in system and partnership development. ASE uses classifications, ontologies, and patterns to clarify and align the business context.

Exposed Context EverywhereDynamic environmental context is the fundamental driver behind all information exchanges. Business context is one aspect of the service consumer’s environmental context which is used by service consumers to change the capabilities of the recipient. Interactive behaviors progressively change the behavior of the service recipient. ASE simplifies the transformation of eCosystem data into context-specific information collected in templates. Transactions contain only data unless the context is known as well, and then it becomes information. ASE focuses on the need to provide visibility, accessibility, and understandability using open declarative mechanisms that allow for mass customization of diverse vocabularies and models within heterogeneous experience networks.

The OASIS CAM (Content Assembly Mechanism) specification illustrates one way of engineering for context as the foundation of the eCosystem’s transactions. It provides a mechanism to retroactively apply context to existing transactions. CAM templates also enable registry components to direct the semantics across the transactions from a single declarative mechanism through its use of content references linked to registry aliases. There are many context types that need to be managed. As summary is provided here:

Experience Network determination Business agreement context Business agreement roles Classification of artifacts context Process selection context Process tracking context Transaction context Exception handling context Decisions context

834

835

836837838839840841842843

844

845846847848

849

850851852853854855856857858859860861862863864865866867868869870871872873874875876

Rules context

By enabling the exposing and control of these context parameters through declarative mechanisms in the ASE Templates, this enables agile semantic interoperability.

Design by Contract

Applying Adaptive Service Engineering TechniquesThis section discusses key implementation techniques and a realistic but simple example. Use Domain Specification Language from

Determining Experience NetworkIn building interoperable agile information systems, one of the first needs is to select common formats for the information. To achieve consensus the participants can either seek out existing formats or develop their own. In either case, it is important to determine the Experience Network into which the information domain falls and authoritative sources within that domain. While this is often overlooked in local

877878879880

881

882

883

884

885886887

888

889890891892893

application system development, where the focus is totally on internal information, as soon as any external interaction occurs it becomes apparent that those internal systems need to conform to external requirements and that authoritative sources for those are needed. Plan immediately to understand the Experience Network and the internal and external information requirements for all the participants in the Experience Network. This forces a community orientation of the information.Once the broad Experience Network has been established, the next classification is within the Experience Network itself, and development of ontologies and classifications to promote re-use by enabling the purpose and function of artifacts to be clearly determined. Again this is often overlooked and artifacts are poorly organized, or placed within too broad a grouping.

By identifying the task of Experience Network facilitation the BCM helps focus business attention on the need to improve Experience Network alignment. By providing templates to address these needs the BCM allows individual enterprises to effect change and improve within the Experience Networks. Technology such as federated registries and shared directory services are the other metrics in improving discovery and re-use of coherent standards. The next section considers in more detail collaboration mechanisms between enterprises within a Experience Network.

Collaboration MechanismsOnce the Experience Network metrics are determined, two things are needed to more effectively interact with enterprise partners within a Experience Network; (1) BCM Templates to formulize the information configurations consistently, and (2) methods of interacting with and distributing those in a shared environment. Figure x.TBD.x shows the technology aspects of this.

BCM Layered Methodology MechanismsConcept LayerBusiness LayerExtension LayerImplementation Layer

Concept Layer using Draft ISO/IEC 15414:6-2002 Enterprise Specification Language

894895896897898899900901902903904905906907908909910911912913

914

915916917918919920

921

922923924925926

927928

929

Enterprise Specification ConceptField of ApplicationSystemScope

Community ConceptsCommunityEnterprise ObjectObjectiveContract of the Community

Behaviour ConceptsActionBehaviourRoleProcess and StepInterface Role

Policy ConceptsRule

930931932933934935936937938939940941942943944945946947948949950

PolicyAuthorizationObligationPermissionProhibitionViolation

Accountability ConceptsPartyCommitmentDeclarationDelegationAuthorityAgentPrincipalEvaluationPrescription

Business Layer

Extension Layer

Implementation Layer

Summarization of above into Conceptual Framework Views

Collaboration View

Contractual View

Execution View

Realizing Value from Adaptive Service Generation Conceptual Framework in Collaborative CommerceWalk through of the various components described above with interactions that generate business value and satisfy Adaptive Service Generation Conceptual Framework Business Drivers from beginning of this paper.

951952953954955956957958959960961962963964965966967968

969

970

971

972

973

974

975

976

977

978

979

980981982983

Acknowledgements:

The following people from the OASIS Business Centric Methodology TC made contributions to this specification:

Dan PattynNeil WassermanDavid RR Webber

984

985986987988989990991