ebSOA Submittal from BCM and BCM/EPR: Goals and Rationale
Upcoming SlideShare
Loading in...5
×
 

ebSOA Submittal from BCM and BCM/EPR: Goals and Rationale

on

  • 579 views

 

Statistics

Views

Total Views
579
Views on SlideShare
579
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

ebSOA Submittal from BCM and BCM/EPR: Goals and Rationale ebSOA Submittal from BCM and BCM/EPR: Goals and Rationale Document Transcript

  • 1ebSOA Submittal from BCM and BCM/EPR: Goals and 2Rationale 3Why this submittal? 4The evolution of service-delivery technology and the growing complexity of services 5demand a service engineering discipline just as the growing complexity of information 6systems demanded an information engineering discipline. Competitive advantage is 7moving toward communities of service providers and service consumers who share a 8social experience and co-create value in experience networks. This dynamic marketplace 9has market participants entering and leaving the market continuously. This places a 10demand on architectures to support communication and collaboration in ad-hoc 11environments and create billable services in near real-time. The architecture must 12include social and technical infrastructures to support heterogeneous experiences and 13facilitate the co-construction of experiences and experience networks. Furthermore, the 14architecture must be “future proof” to support emerging technologies such as peer-to-peer 15computing, grid computing, and extreme mobility infrastructures for wearable 16computing. 17 18 This paper outlines the elements of an Adaptive Service Generation Conceptual 19Framework architecture which supports the above requirements. This paper is intended as 20either a tutorial or an application note to accompany or be integrated into the ebSOA best 21practices document which will accompany the normative standard document. The 22overarching goal of this paper is to focus on the core conceptual essentials of ebSOA and 23bridge the cognitive gap between the business domain experts and the IT infrastructure 24specialists. The Adaptive Service Generation Conceptual Framework supports real-time 25service generation in response to user requirements and real-time user customization. 26The framework functions as a service component factory to generate services from a set 27of available service components in a business service registry at or near real-time. The 28framework supports the interactive and adaptive qualities of the service relationship 29through service components enabled by environmental context and metadata stored in 30business service registries. A Service Component Architecture is developed which 31provides a layered view of componentized service delivery capabilities. 32 33Finally, Semantic Infrastructure Services are developed to provide the metadata required 34to support the information and business architectures. The Semantic Infrastructure 35provides a service interface to a templating framework and content management system 36driven by a semantic registry. Adaptive Service Engineering methodologies utilize this 37interface to engineer composable service patterns for reuse and adaptation by the 38Adaptive Service Generation Conceptual Framework. 39 40Goals? 41If I had the perfect ebSOA, how would I use it and how would I derive value from it and 42how would I communicate the management roles and tasks needed. This paper is 43intended as either a tutorial or an application note to accompany or be integrated into the 44ebSOA best practices document which will accompany the normative standard document. 45The overarching goal of this paper is to focus on the core conceptual essentials of ebSOA
  • 46and bridge the cognitive gap between the business domain experts and the IT 47infrastructure specialists. 48 49Give a roadmap for a possible application of ebSOA to focus the ebSOA TC discussions 50and submissions and provide a conceptual framework for integrating the various 51submissions with a primary focus on the business requirements and how the architectural 52elements and styles support those business requirements. 53 54Rationale? 55Elicit overriding principles to facilitate communication and task goals of ebSOA TC. 56Principle 1: 57 Business User: I just want the information right now and right here to do my job. 58 IT Professional: Semantic Granularity matches the Task Granularity 59 Architectural Support: Separation of Concerns throughout the Development 60 Lifecycle. 61 62How does our ebSOA support this principle? 63e.g. How do we categorize semantics from weak to strong and where do we focus? How 64do we handle the level of concreteness and abstractness? Where do we as an ebSOA 65committee start in the following matrix and where do we migrate to???? 66 Strong Semantics Self Organizing Modal Logic Applications First Order Logic Local Domain Theory Is disjoint subclass of Description Logic with transitivity property DAML+OIL, Owl UML Social Contract Conceptula Model Is subclass of Establishment and RDF/S Maintenance XTM Business Services Extended ER Has narrow Thesaurus meaning than ER Business Schema Foundation Services Source of Y axis: Taxonomy Is subclassification of Figure 7.5, pg 157 Relational Model The Semantic Web Daconta, Orbst, Weak Semantics Smith Very Concrete Very Abstract 67 68What should a reader of our document (Application Note?, Best Practice? or Tutorial?) 69learn? 70 1. Be able to create a “good” ebSOA specification (model?) that exhibits 71 a. Architectural Support for Automation 72 i. Partially executable 73 ii. Declarative precursor to MDA (Model Driven Architecture)
  • 74 b. Comprehensibility 75 i. Understandable semantics that are key to obtaining biz value 76 ii. Design Rationales are visible – often impossible to uncover the 77 important business requirements and imperatives that shaped the 78 model and specification and provide business value. This is often 79 called implicit knowledge or domain knowledge. 80 c. Model or Specification is accessible 81 i. Understand the visual syntax 82 ii. Ability to drive the modeling tool to navigate the model 83 d. Collaboration Oriented 84 e. Traceable to Ontology, Dictionaries, Vocabularies 85 i. Automatable 86 f. Specification supports Community of Interest 87 2. Have an appreciation of the difficult challenge of specifying the appropriate level 88 of concrete abstraction. This translates into the wholeness of a specification and 89 the architectural support for quality: When and who needs a template; and when 90 and who needs a model. In other words, how many transformation steps from 91 abstract to concrete does the framework for the specification require? 92 Traceability of high level requirements to model artifacts relies on the fidelity of 93 the modeling transformations and lacks essential feedback from the non-technical 94 community. The model transformation fidelity requires semantic support 95 linkages. 96 3. Semantic Support in the Architecture/Framework is the major determinant of 97 adoption and technology transfer. How do we measure our success criteria for the 98 following Innovation Drivers1 that increase the rate of adoption by the end 99 customer and the team members: 100 a. Relative Advantage – the degree to which an innovation is perceived as 101 better than the idea it supersedes. The degree to which an individual or 102 organization perceives the innovation as advantageous because of 103 economics, social prestige, convenience etc. 104 b. Compatibility – the degree to which an innovation is perceived as 105 consistent with the existing values, past experience, and needs of potential 106 adopters. 107 c. Complexity – the degree to which an innovation is perceived as difficult 108 to use and understand. Innovation is slower if the adopter has to develop 109 new skills and understandings. 110 d. Trialability – the degree to which an innovation may be experimented 111 with on a limited basis. New ideas that can be tried on the installment 112 plan will generally be adopted more quickly than innovations that are not 113 divisible. Trialable represents less uncertainty to the individual who is 114 considering it for adoption, as it is possible to learn by doing. 115 e. Observability – the degree to which the results of an innovation are 116 visible to others. Visibility stimulates peer discussion of new ideas as 117 peers of an adopter request innovation-evaluation information about it. 118 11 Rogers, Everett M., Diffusion of Innovations, 4th Edition, Free Press, 1995, pp. 15-17
  • 119 4. 120 121
  • 122 Table of Contents 123ebSOA Submittal from BCM and BCM/EPR: Goals and Rationale...................................1 124Introduction..........................................................................................................................7 125 Adaptive Service Generation Conceptual Framework Business Drivers...........................7 126 Adaptive Service Generation Conceptual Framework Architecture Requirements...........8 127 Social and Technical Infrastructures to Support Heterogeneous Experiences................8 128 Rapid Resource Reconfiguration.....................................................................................8 129 Access to Competence.....................................................................................................8 130 Experience Quality Management.....................................................................................9 131 Business Lifecycle Activities Management.....................................................................9 132Adaptive Service Generation Basics..................................................................................10 133 What is a “Service”........................................................................................................10 134 What is a “Service Component”....................................................................................10 135 Service Component Adaptation.....................................................................................11 136 Service Collaboration.....................................................................................................11 137 Adaptive Service Generation Conceptual Framework ....................................................11 138 Business Services Architecture......................................................................................13 139 Shared Infrastructure Services...................................................................................13 140 Shared Infrastructure Service Assembly & Deployment...........................................14 141 Business Foundation Services....................................................................................16 142 Business Services.......................................................................................................18 143 Semantic Infrastructure Services...................................................................................19 144 Pragmatic Semantic Interoperability Support Mechanisms.......................................19 145 Template Lifecycle Management..............................................................................19 146 Business Service Registries.......................................................................................20 147 Deployment Automation for Choices and Adaptation...............................................20 148 Content Management Systems...................................................................................22 149 Enterprise Information Services................................................................................22 150 Adaptive Service Engineering Methodologies .............................................................22 151 Engineering Pragmatic Semantic Interoperability.....................................................22 152 Experience Network Focus........................................................................................23 153 Template Focus .........................................................................................................23 154 Exposed Context Everywhere....................................................................................23 155 Design by Contract....................................................................................................24 156 Applying Adaptive Service Engineering Techniques....................................................24 157 Determining Experience Network.............................................................................24 158 Collaboration Mechanisms............................................................................................25 159 BCM Layered Methodology Mechanisms.....................................................................25 160 Concept Layer using Draft ISO/IEC 15414:6-2002 Enterprise Specification Language 161 ........................................................................................................................................25 162 Business Layer...............................................................................................................27 163 Extension Layer.............................................................................................................27 164 Implementation Layer...................................................................................................27 165Summarization of above into Conceptual Framework Views...........................................27 166 Collaboration View........................................................................................................27 167 Contractual View...........................................................................................................27
  • 168 Execution View..............................................................................................................27 169Realizing Value from Adaptive Service Generation Conceptual Framework in 170Collaborative Commerce...................................................................................................27 171Acknowledgements:...........................................................................................................28 172
  • 173 174Introduction 175 176Recent trends in technology and changes in the business environment for service delivery 177force a re-examination of our understanding of services and how we deliver services. 178Developments like web services and business trends such as service outsourcing make it 179possible to deliver services in new ways. This paper addresses the implications of these 180changes for service delivery and the speed with which new services can be developed and 181deployed though the use of new technologies. The evolution of service-delivery 182technology and the growing complexity of the service economy will demand a service 183engineering discipline just as the growing complexity of information systems demanded 184an information engineering discipline. This does not mean that all such services need to 185be automated. On the contrary, the concepts of service components and Service 186Component Architecture apply equally well to automated and human-delivered services. 187 188This submittal outlines the elements of service engineering and the service customization 189aspects of the Adaptive Service Generation Conceptual Framework and addresses the 190following business issues: 191 192 • IT infrastructure and service consolidation 193 • Satisfying customer support demands for increasingly complex products and 194 services. 195 • Reducing the time required for customized service generation and delivery 196 • Integrating human-delivered and machine-delivered services 197 • The Collaborative Commerce challenge of managing business functions that are 198 the joint effort of multiple business partners 199 • Maintaining private, shared, and public vocabularies, dictionaries and ontologies 200 • Benefits of Service Component Engineering 201 202 203Adaptive Service Generation Conceptual Framework 204Business Drivers 205 206Prahalad and Ramaswamy, in the Future of Competition2, postulate building an 207experience network infrastructure which enables managers to compete on experiences in 208experience networks. Customers build their own thematic communities (Experience 209Network) where they share their knowledge, support services, and peer group access to 210increase the collective expertise of the community by freely sharing best practices. This 211Experience Network is particularly important for highly informated and technology- 212enabled intelligent products where the customer service consumer and the company 213service provider co-discover and co-create new value for both. Competitive 22 Prahalad, C.K., Ramaswamy, Venkat, The Future of Competition: Co-Creating Unique Value with 3Customers, Pg. 97, Harvard Business School Press, 2004
  • 214differentiation depends on the quality of the experience network that service providers 215and service consumers share and depends on the balance of local customization and cost 216efficiencies of standardization. 217 218Adaptive Service Generation Conceptual Framework 219Architecture Requirements 220Social and Technical Infrastructures to Support Heterogeneous 221Experiences 222Infrastructure must support heterogeneous co-creation experiences. Experience networks 223need smart control systems to move the market intelligence to the points of interaction 224and to manage the backbone of the network infrastructure. Both social and technical 225enablers must facilitate the co-construction of experiences and experience networks. 226Service consumer heterogeneity is supported by technical infrastructure for discovering 227and collecting attributes of the service consumer and the interactive behaviors that 228progressively change the capabilities of the service consumer. The framework provides 229the technical feedback mechanism for indicating the quality and effectiveness of changes 230in the service consumer. The social enablers include framework support for creating 231Service Consumer and Service Provider communities that overlap and share information, 232experiences, and knowledge. Social enablers provide Experience Network support 233services such as membership registration, identification, authentication and authorization. 234These core social enablers provide the basis for the Community to build trust networks, 235reputation chains and other Social Contract maintenance activities. 236Rapid Resource Reconfiguration 237Delivering consistently high quality services and experiences requires the ability to 238quickly adjust to shifts in demand for service provider services. The critical ability of the 239experience network to scale up and down requires the capacity to reconfigure resources 240effectively and respond quickly. This marketplace dynamism requires automated service 241delivery mechanisms that generate services in a deployment framework. Dynamic 242service logistics depend on deployment automation which utilizes meta data about the 243service consumer to adapt services for the service consumer. Delivery of services has to 244emphasize the interactive and adaptive qualities of the service relationship in the context 245of an experience network. Componentization of the service delivery capability enables 246adaptation to changing requirements of service consumers and markets. 247Access to Competence 248 Who provides Ecosystem Provisioning Support???? 249 Verify readiness for e-commerce 250 System Operation and Maintenance 251 Content Provision for Users 252 System Administration 253 System Configuration for SMEs 254 System Integration for SMEs
  • 255 e-Learning 256Experience Quality Management 257As service providers and service consumers interact in experience networks 258(Communities of Interest), value lies in the variety of experiences the experience network 259can accommodate as well as the quality of co-creation experiences. Managing the quality 260of co-creation experiences is Experience Quality Management (EQM) as opposed to 261Total Quality Management (TQM) which had a product and process focus. Traditional 262product-oriented TQM taught us to stamp out variation in a bid to control product quality. 263EQM on the other hand means embracing heterogeneity and variability with quality of 264execution. The Service Consumer demands a unique personalized experience while 265simultaneously demanding responsiveness, speed, reliability and cross-channel 266consistency. The experience network must be designed to accommodate variation in 267Service Consumer experiences while reducing variation in the quality of the supply 268processes that are activated to co-construct Service Provider and Service Consumer 269shared experiences. Service Consumer quality is highly dependent on consistent 270experiences in cross-channel access to products and services. Experience Quality is 271driven by the contextual interaction between individual Service Consumer and experience 272environments. 273 274Business Lifecycle Activities Management 275The activities of a business lifecycle – 276The declaration, maintenance and evolution of TRUST. 277Provision Enterprise for Role within the target marketplace 278Contract with Partners 279Provision relationships with Partners 280Transact with Partners 281Settle transactions with Partners 282Resolve discrepancies with Partners 283Terminate relationship with Partners 284 Syndicate transactions through distribution Partners 285 286The concerns associated with the activities of a business lifecycle are Governance to control and direct the making and administration of policy in Accreditation to recognize or vouch for as conforming with a standard Provisions the fact or state of being prepared beforehand Assurance the act or action to make safe as from risk Mediation the act of intervention between conflicting parties to promote reconciliation, settlement, or compromise Syndication the process of selling information for publication through a number of independent distribution channels simultaneously Reconciliation the process to make consistent or congruous Recourse the right to demand payment from the maker or endorser of
  • a negotiable instrument 287 288<This section needs major help and an owner. I just went to the dictionary while setting 289in traffic and pulled the following definitions into my voice recorder. These terms are not 290formal and orthogonal but they seem to capture the eCosystem aspects of the declaration, 291maintenance and evolution of trust and cooperation which is really the essence of 292business.> 293 294Adaptive Service Generation Basics 295What is a “Service” 296While process, defined as an activity with inputs and outputs, takes little account of 297external circumstances, for service, context is crucial. A service focuses on the service 298consumer rather than the business function. Whether provided by a human help desk 299operator or an automated system, a service provides something of value to a service 300consumer via an interactive course of action. The existence of the service consumer of 301the service is important in determining the behavior of the service provider. 302 303Service properties: 304 • Mechanism for discovering attributes of its environment and the attributes of the 305 service consumer 306 • Interactive behaviors that progressively change the capabilities of the service 307 consumer 308 • Feedback mechanism for indicating the quality and effectiveness of those changes 309 in the service consumer 310 • Means for using the attributes of the service consumer to select appropriate 311 service delivery behaviors 312 • Means for adapting the mode of interaction with the service consumer to needs 313 (attributes) of the service consumer 314 • Means for communicating with and building on capabilities of other service 315 providers (collaboration) 316 • Access to skills and other knowledge resources that provide value to service 317 consumer. 318What is a “Service Component” 319The decomposition of services into service components enables the business to identify 320service capabilities and support reusability of service capabilities that are delivered in 321different business contexts. The implementation of business service components depends 322on technical components that support service deployment. The initial modeling of 323services in terms of service components is performed independently of any particular 324technical implementation. 325 326Adaptive Requirements of a Service Component 327 • Acquires custom information about the service consumer
  • 328 • Selects service behaviors appropriate to service consumer 329 • Adapts manner of interaction to service consumer profile 330 • Assesses change in service consumer capabilities 331 • Applies a skill-set and knowledge resource in delivering the service 332 333Change in state of the service consumer becomes part of the customer profile and 334interaction history. Knowledge of service consumer preferences and behaviors in turn 335influences subsequent delivery of services. Service components adapt to the current 336needs of service consumers and the deployment environment. These adaptations are 337standardized for multiple service components but may adjust to factors that depend on 338where, when, how, and to whom the service is to be delivered. 339 340Even though both software components and Service Components share the term service, 341the term has a different meaning for the two domains. In the software domain, service 342often takes on the meaning of a called procedure such as a CORBA service. In the 343service domain, service is an interactive process that changes the capabilities of the 344service recipient to do something of value. A Service Component is the componentized 345formal view of the interaction we call a business service. A web-service is simply a 346standard for software wrapping and identification. Web-services represent a software 347component technology which can be used to implement Service Components. The agile 348semantic interoperability focus of Adaptive Service Engineering refocuses architecture 349decisions away from applications and web services technology toward multi-participant 350collaborative business services that occur within experience networks. 351Service Component Adaptation 352Service components provide for service adaptation in two ways. 353 1. Collaboration Patterns 354 2. Adapt to variation in service consumer needs 355 356policy and profile as a service adaptation mechanism build the adaptation mechanism 357requirements for BCM Choice Point Linking and Switching here 358Service Collaboration 359Like replication of business service components across business units, technical service 360components can be implemented within the reusable Adaptive Service Generation 361Conceptual Framework. See Shared Infrastructure Service Assembly & Execution layer 362of the Business Services Architecture. 363 Adaptive Service Generation Conceptual Framework 364This section of the document will develop a conceptual and architectural framework 365consisting of 366 Business Services Architecture 367 Semantic Infrastructure Services 368 Service Engineering Methodologies
  • 369to address the following service orientation “concepts”. These concepts were cut and 370pasted from Microsoft MSDN3. 371<PasteFromMSDN> 372 • Enterprise architecture—the systematic modeling of an organization's objectives, 373 priorities, resources, and processes to achieve the self-awareness necessary for 374 directed improvement. 375 • Enterprise information integration—creating a set of organizational standards for 376 the business entities—the complex "types" such as "customer," "employee," and 377 "purchase order"—that are manipulated by your application portfolio. 378 • Process orientation—making the business process the focus of design for your 379 enterprise architecture and information technology portfolio. 380 • Business process orchestration—models that support agile business processes by 381 making the sequencing of steps in the process as lightweight and adaptive as 382 possible. 383 • Event-driven architecture—a model in which business events, such as the arrival 384 of parts on the shipping dock or the payment of an invoice, trigger a message to 385 be sent to subscribing services to allow them to take appropriate action. 386 • Virtual enterprises—viewing business processes as value chains that extend 387 across organizations, permitting each organization to focus on its core capabilities 388 and to outsource noncore capabilities to external service providers. 389 • Aspect orientation—providing a means for the consistent handling of cross- 390 cutting concerns, for example the monitoring of business activities, access control 391 to services, and reliability of message delivery. 392 • Human workflow management—the orchestration of information workers and 393 their interactions with business processes to achieve efficiency and 394 responsiveness to customer needs. 395 • Disintermediation—the automation of nonexceptional information exchanges 396 across business boundaries, to eliminate the need for information workers to 397 perform routine tasks such as data entry from written (fax, mail, e-mail) or verbal 398 information exchange. 399 • Agility—systems designed to be responsive to the specific context and content of 400 a business request, as well as to broader changes to business requirements and 401 business strategies. 402 • Model-driven development—driving the solution development process from a 403 higher-level—generally graphical—language that is more closely bound 404 (compared with, say, Visual C#) to the business processes being automated. 405</PasteFromMSDN> 406Missing from the above Microsoft list are the following: 407Federated Semantic Registries 408Domain Taxonomies 409Topic Maps 410Vocabularies 411Dictionaries 412Legal Interaction Models (BPSS, CPA, CPP) 43 Service Orientation and Its Role in Your Connected Systems Strategy. July 2004 5http://msdn.microsoft.com/library/en-us/dnbda/html/SrOrientWP.asp?frame=true
  • 413Interface Rendering and User Interaction 414Agents 415Business Services Architecture 416The Business Services Architecture is layered into four layers or separations of concern. 417The four layers of conceptual abstraction are 418 Shared Infrastructure Services 419 Shared Infrastructure Service Assembly & Deployment 420 Business Foundation Services 421 Business Services 422The first two layers are primarily infrastructure and technology oriented. The second two 423layers are primarily business and domain oriented. You can consider the two layers as a 424pair where one layer provides raw services and the related second layer provides service 425composition and deployment services on top of the raw services. For example, Business 426Services are “assembled” and deployed using Business Foundation Services. 427Graphically, the Adaptive Services Generation Conceptual Framework is abstractly 428bound at each abstraction layer by a contractual view which is influenced by the policies 429in effect in the eCosystem that the service provider and consumer operate. 430 431 432Shared Infrastructure Services 433The Shared Infrastructure Services Layer of the Adaptive Service Generation Conceptual 434Framework generalizes the network model to make it possible to employ or link to other 435technologies such as web services, GRID services, or peer-to-peer networks. This is 436achieved by adopting an abstract model based on actors and services and mapping the 437abstract model to a number of different implementation technologies. 438
  • 439Shared Infrastructure Service Assembly & Deployment4 440This layer treats the Shared Infrastructure Services layer as a collection of Shared 441Services. For example, guaranteed messages could be implemented via ebXML ebMS or 442a stack of Web Services WS-* specifications. When infrastructure services are published 443to the eCosystem, traceability mappings are created for reconciliation and mediation by 444the Business Foundation Services layer. Traceability mappings include the form, 445function, and structure (Morphology) of the configured and enabled Shared Infrastructure 446Services. An Infrastructure Morphology with its own infrastructure contract semantics is 447used for infrastructure service discovery and provisioning. This layer provides a 448virtualization service to separate shared services from network, platform and language 449specific implementations. The abstract metadata of the Infrastructure Morphology is used 450by Model Driven Architecture (MDA) technologies such as Service Model Component 451Compiler technology to generate a “Collaboration Pattern” of deployment frameworks 452including Collaboration, Contractual, Execution and ebXML frameworks for a particular 453service consumer. The generated deployment frameworks are adapted for the eCosystem 454context model and the service consumer policy and profile.5 This layer manages the 455eCosystem ontologies for the infrastructure domains and their associated directories. 456 Actor Domains Collaboration Agent Directory Services Service Domains Service Directory Services Agent Domains Agent Directory Services Platform Domains Platform Directory Services 457 458This layer supports ontology independence and supports dynamically-loaded, defined 459ontologies, policies, and profiles defined by an eCosystem collaborative architect. Once 460ontologies are loaded into a registry, the ebXML Federated Registry becomes the enabler 461for distributed and Federated governance. Conformance and interoperability at the 462Shared Infrastructure Services layer are now a function of shared information and 463collaboration semantics. A search into the EcoSystem Infrastructure Morphology 464Registry can be a constraint-based search for each service policy based on profile 465attributes. This search process might be considered as a matchmaking process, since the 466obtained results are bounded by user-defined constraints. Through registry enabled 467federation, infrastructure service providers can share their service repositories to provide 468infrastructure services.6 Provisioning automation enables both Infrastructure Services 469and Business Foundation Services. Portals can use provisioning automation to establish 470self service processing and if the marketplace grows, leverage incremental automation to 471migrate from people and paper based processes to interactive web based workflow 472processes with automated testing and automatic certification. 473 64 This layer is a conceptualization of the www.lauraproject.org project of a B2B Architecture Based on 7ebXML and Peer-to-Peer Technologies from Kingston University. 85 Strengthen policy and profile as a service adaptation mechanism across this and all other layers 96 How does ebSOA envision testing, and certification services  Self Provisioning and Self Certification 10 BCM Templating mechanism at the BCM Implementation layer here. NO SELF REGISTRATION?
  • 474Generic Open Source JXTA can be used to implement this layer and provide 475virtualization of Shared Infrastructure Services. JXTA is often used for a Mobile 476Middleware Distributed Execution Environment. JXTA generic services provided to this 477layer include 478 • Environment Monitoring 479 • Event Notifications 480 • Service Discovery 481 • Configuration Management 482 • Trust and Privacy Support 483 • Mobile Data Management 484 485In summary, this layer isolates the infrastructure services from the technology functions 486of platforms, network topologies (GRID, P2P, Agents, etc.) and middleware services. 487provides the foundations for automated self provisioning and certification through the use 488of an Infrastructure Morphology Registry. Conformance and interoperability are a 489function of shared ontologies, information models, and collaboration semantics. 490Common SLA Administration and SLA Governance services are provided to both the 491Infrastructure Services and the Business Foundation Services layers. 492 493An implementation of this layer can be found in the www.lauraproject.org which 494conceptualized an architecture for Request-Based Virtual Organizations for sector- 495specific Service Level Agreements7. 496 497Duane Nickull patterns here 498Business Signals and Messaging Patterns 499 - Business Message Dispatch 500 - Business Message Persistent Storage 501 - Business Message Reception 502 o Validation 503 o Security validation 504 o Checking parameters against SLA 505 o Internal Application binding to messaging services 506 o Event notification via messaging API (Internal API) 507 - Business Events 508 o Monitor-able event linking to messaging and acknowledgements 509 510SOA Payload and transaction metadata 511 - Core Components approach 512 - Data Element modelling 513 - Context mechanism 514 - Plurality mechanism 515 - Data element reconciliation 117 This project created a BSN, Business Service Network, with Discovery Services at each of the four levels 12of the Adaptive Service Generation Conceptual Framework implemented through a Generic Discovery 13Service. Open Source JXTA generic infrastructure discovery services were used as an implementation 14model for the Shared Infrastructure Services Assembly and Deployment layer.
  • 516 - Data element aggregation (Content Assembly) 517 - Instance data constraints by metadata 518 - Presentation and view of Business Message Payload 519 520Business Foundation Services8 521This layer of the architecture provides marketplace infrastructure services to the industry 522BUSINESS SERVICE NETWORKs (BSNs). Marketplace infrastructure services 523include 524 Collaboration Community Composition Process 525 Maintenance of Social Contract 526 Collaboration Support Services 527 Ecosystem Performance and Evolution Summarization Data 528This layer is analogous to the Shared Infrastructure Services layer in the IT Infrastructure 529at the “bottom” of the conceptual framework. The Business Services layer could have 530been named Business Foundation Services Assembly & Deployment for framework 531consistency but Business Services is an accepted label, thus Business Services. 532 533Collaboration Community Composition Process 534 Market Provisioning: negotiation, service matching 535 Partner Search 536 Reputation Information Reference Search 537 Selection of Partners 538 Collaboration Contract Proposal 539 Modifications and Negotiations  Formal Responsibilities Contract 540 Voting on Community participation in Virtual Collaboration Community 541 Planning: Scheduling services that provide aggregation, procurement and 542 service matching functions 543 Formalize Virtual Collaboration Community (VCC) 544 Agreement to use advertised services are issued and agreed amongst 545 community participants through formal contracts 546 Define VCC Formal Contracts 547 VCC Choreography 548 VCC Choreography  instantiate into Architecture and 549 Component specific orchestrations  set boundary 550 conditions for further task 551 negotiation 552 Execution Environment 553 Orchestration Decisions 554 Allocation Decisions 555 Invocations 556Maintenance of Social Contract 557 Identification of Maintenance Need 558 Social Interactions in VCC triggered by environmental monitoring 559 activities or VCC member 158 The Concepts for this layer are based on analysis of Cross Flow, REACH and the LauraProject.
  • 560 Re-Choreography and/or Re-Orchestration 561 Replacement of Services 562 Search Directory Services for available Service 563 Identification of Potential Candidates 564 Choice of Candidate and Negotiation of Terms and Conditions 565 Establishment and Amendment of Contracts 566 Group Acceptance 567 Dissolution 568 Termination Conditions are triggered by VCC monitoring function 569 Compensation 570 Determination of Compensation Amounts and Timing 571 Payment in Funds between Agents 572 573Collaboration Support Services 574 Collaboration Policies from Collaboration Profiles in Semantic Registry 575 Formation Conditions of Collaboration Team 576 Dissolution Conditions of Collaboration Team 577 Compensation Terms for Collaboration Inclusion 578 Compensation Terms for Collaboration Expulsion 579 Consensus Mechanism 580 Voting, Veto, etc. 581 Community Access from Community Manager 582 Edit Permissions; Delete Contacts via voting mechanism, 583 Block Access 584 Collaboration Provision  Role Assumption; Task Assumption 585 Add Service Provider 586 Add Service Consumer 587 Virtual Enterprise Creation – provide accessibility for enterprises to 588 publish its own highly available services available to the experience 589 network 590 591 Collaboration Profile Repository Searches of Community Categorizations 592 Geographical Focus 593 Referrals & Incentives 594 Add Rating 595 Add Contacts 596Ecosystem Performance and Evolution Summarization Data 597 Most Commonly used business channels, aggregators, syndicators 598 Number of Registered Users 599 Number of Collaboration Peers 600 Quality Assurance on Suppliers, Quality of Services in Collaborative Commerce 601 Portal 602 Number of Collaboration Communities 603 Number of Searches leading to business transactions 604
  • 605Business Services 606These are the basic services an application service provider would provide to a 607marketplace. 608 609 610 611Figure x.x: Adaptive Service Generation Conceptual Framework Stack Interactions 612 613Business relationship based on a contract, providing a common view of the service, the 614monitoring and control points, and promises defined in the contract. 615 616Service Activation, observing the progress of the service (allowing shadowing in the 617consumer) and providing the consumer with some control over the service provider 618behavior according to the contract at each of the Adaptive Service Generation Conceptual 619Framework Layers. 620 621Business Life Cycle (Round Trip): 622 623Business Goal: Virtual Enterprise through business process crossing organizational 624boundaries and enabled by: 625 Contract Establishment 626 Enactment Infrastructure Creation and Linking 627 Enactment 628 629I need someone to help me map the existing OASIS standards to this stack. BPSS resides 630in either the top of Shared Infrastructure Service Assembly & Deployment or the bottom 631of Business Foundation Services or both around the interfacial between them.
  • 632Semantic Infrastructure Services 633Semantic Infrastructure Services focus business analysts on precise communications 634amongst multiple experience networks with open declarative mechanisms that allow for 635mass customization of diverse vocabularies and models given the environmental context 636of the service providers and service consumers. The organizational memory of the 637eCosystem participants in experience networks is organized as a series of templates 638stored in the Semantic Registry and referenced by the Business Services Registry. 639Benefit statement here on value proposition for private, shared, and public information. 640Pragmatic Semantic Interoperability Support Mechanisms 641Semantic Infrastructure Services provide discovery and navigation of taxonomies, 642classifications and ontologies through template based mechanisms. The Adaptive Service 643Generation Conceptual Framework provides the following structures and support 644mechanism to generate Semantic Infrastructure Services 645 646 1. Taxonomy/Ontology, 647 2. Semantic Registry, 648 3. Workflow, and 649 4. Content management system. 650 651The ontology is comprised of various facetted taxonomy views of the business with the 652capability of defining thesaurus (e.g. synonyms, alias) relationships that reside on a 653registry. The registry provides reference assistance and stores information about the 654supporting classifications and metadata artifacts in templates. Copy in Business First Idea 655here 656Workflow – this is the placeholder for Choreography vs. Orchestration 657Top of the SOA Stack  Choreography and Coordination 658 Business Process, Service Focused 659 Exposed to a trading partner 660 Uses Domain Expert Terminology 661Lower in the SOA Stack  Orchestration and Composition 662 Component Focused 663 Flow of messages between components expressed as a meta language 664 Uses IT Expert Terminology 665Template Lifecycle Management 666directly enables the model; provides coupling between the Templates and the deployment 667environment via distributed customization Choice Points to ensure that the linking and 668switching that occurs in the deployment environment matches the actual business 669requirements. choice point linking and switching as an adaptation mechanism for service 670component composition 671Copy in Business First Idea here? 672Wait on the Business Centric Methodology TC Electronic PRocess (BCM EPR) 673Subcommitte to develop a position on Meta Models and Archetype Patterns9 and their 169 See Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML, Jim 17Arlow, Ila Neustadt, Addison Wesley 2004
  • 674relationship to Templates and the resulting Template Lifecycle Management. I believe 675the BCM EPR eHealthcare requirements will drive this section in three months. 676 677Business Service Registries 678Duane Nickull applicable patterns go here… 6794.2 Registry Discovery and Service Invocation 680 - 4.2.1 Basic Registry for Discovery 681 - 4.2.2 Registry service patterns (Service Interface to Registry, API’s etc.) 682 o 4.2.2.1 Registry account set up(actors) 683 o 4.2.2.2 Registration of Artifacts via Registry API 684 o 4.2.2.3 Management of Registry artifacts via API 685 o 4.2.2.4 Query for Artifacts via API 686 o 4.2.2.5 Registry Federation across multi-registry environment 687 o 4.2.2.6 Assertions of associations by Registry Registered Users 688 o 4.2.2.7 Linking and switching of Registry artifacts 689 - 4.2.3 Service Description Registration 690 - 4.2.4 Service Security Assertion Registration 691 - 4.2.5 Service Parameter Registration 692 - 4.2.6 Service Supporting Artifact Registration 693 - 4.2.7 Registry Interaction Patterns 694 695 696Deployment Automation for Choices and Adaptation 697Choice Point Linking and Switching from OASIS BCM 698 699The BCM utilizes a ‘contract’ to formalize the combination of workflow, processes, 700schema, maps, rules, etc. into BCM artifacts. The underlying principle is that each 701BCM layer solves the problem at that level, and only that level, based on a focused set of 702constraints. Information that is not available or relevant at that point is deliberately 703deferred up to the next layer – thereby simplifying the overall solution. This approach is 704also in alignment with Service Oriented Architecture (SOA) technologies built around 705Web services where service points deliver solutions to discreet requirements, and 706therefore often function like “help from above” from the user’s perspective. 707 708The gathering of Choice Point parameters and control requirements 709 710BCM Templates needed to generate decision points and variables across an identified 711pattern. For example, contract instantiation creates objects at runtime that interact 712as described by the contract; 713 714 18http://www.amazon.com/exec/obidos/ASIN/032111230X/qid=1090990493/sr=ka-1/ref=pd_ka_1/103-6807 19037-6405420
  • 715 716 717Figure xxx Template Contract Choices directed via Choice Point 718 719 720Choice Points can be seen as providing enablers for agile information exchanges: 721 722 · Context criteria, where the scope of the context extends beyond the local decision 723 point, and can also require persistence of decisions 724 725 · Determining context by refining criteria dynamically, and that may include 726 undetermined start points 727 728This is where the BCM differs significantly from current methodologies as it directly 729embraces and provides support for choice based on environmental context tie this to 730Service properties: 731 • Mechanism for discovering attributes of its environment and the attributes of the 732 service consumer 733 • Interactive behaviors that progressively change the capabilities of the service 734 consumer 735 • Feedback mechanism for indicating the quality and effectiveness of those changes 736 in the service consumer 737 • Means for using the attributes of the service consumer to select appropriate 738 service delivery behaviors 739 • Means for adapting the mode of interaction with the service consumer to needs 740 (attributes) of the service consumer 741 • Means for communicating with and building on capabilities of other service 742 providers (collaboration) 743 • Access to skills and other knowledge resources that provide value to service 744 consumer. 745 746
  • 747Content Management Systems 748Nasty hard question: When is Context considered Content??? This is a major interaction 749with Choreography and Interaction 750ebXML Registry Version 3 Capabilities with respect to content 751 Arbitrary Content (Content Repository) 752 Content Specific Validation 753 Content Specific Cataloging 754 Version Control 755 Pre-defined taxonomies 756 Ontology Support 757 User-defined Associations 758 Simple Event Notification 759 Content Based Event Notification 760 Extensible Information Model (Metadata is extensible) 761Enterprise Information Services 762??? 763Adaptive Service Engineering Methodologies 764Adaptive Service Engineering captures and configures the metadata that populates 765Semantic and Business Registries with reusable and composable service patterns for use 766in the service composition factory of the Adaptive Service Generation Conceptual 767Framework. Adaptive Service Engineering focuses the metadata aspects of software 768engineering, business process engineering, and ontological engineering on sustainable 769and agile interoperability mechanisms in the Adaptive Service Generation Conceptual 770Framework. 771 772 The agile semantic interoperability focus of Adaptive Service Engineering refocuses 773architecture decisions away from applications and web-services technology toward multi- 774participant collaborative business services that occur within experience networks. 775 776Link to agents and infrastructure morphology  example of supporting the degree of 777syndication and aggregation here if time  778 779Engineering Pragmatic Semantic Interoperability 780 • Captured rationale and documented constraints are necessary to make 781 transformations from data to information 782 • Templates are used with the various layers of the methodology to collect metadata 783 and business rationale; apply form to this information to establish context; and 784 further constrain it using human capital and experience to produce useful 785 knowledge 786 • Templates simplify data collection , properly classify the resulting information, 787 and reveal underlying patterns within the information. 788 • Extend ontological alignment beyond the contractual layer
  • 789 • Creation of a comprehensive information architecture 790 791Experience Network Focus 792Experience Networks (Communities of Experience) are the focus for managing of 793eCosystem artifacts and governance. This includes the linking of business goals to 794concepts, and exact business requirements, through mappings and generating physical 795implementations via the Adaptive Service Generation Conceptual Framework. The 796Experience Network collaboration partners are then able to reuse their own declarative 797community semantics in loosely-coupled machine readable mechanisms such as 798ontologies, classifications, industry vocabularies, and patterns within their normal 799business processes with precise context when business opportunities arise. 800Template Focus 801Adaptive Service Engineering (ASE) is a philosophy of making business objectives, 802agreements, semantics, and rules of the organization preeminent in system and 803partnership development. ASE uses classifications, ontologies, and patterns to clarify 804and align the business context. 805Exposed Context Everywhere 806Dynamic environmental context is the fundamental driver behind all information 807exchanges. Business context is one aspect of the service consumer’s environmental 808context which is used by service consumers to change the capabilities of the recipient. 809Interactive behaviors progressively change the behavior of the service recipient. ASE 810simplifies the transformation of eCosystem data into context-specific information 811collected in templates. Transactions contain only data unless the context is known as 812well, and then it becomes information. ASE focuses on the need to provide visibility, 813accessibility, and understandability using open declarative mechanisms that allow for 814mass customization of diverse vocabularies and models within heterogeneous experience 815networks. 816 817The OASIS CAM (Content Assembly Mechanism) specification illustrates one way of 818engineering for context as the foundation of the eCosystem’s transactions. It provides a 819mechanism to retroactively apply context to existing transactions. CAM templates also 820enable registry components to direct the semantics across the transactions from a single 821declarative mechanism through its use of content references linked to registry aliases. 822There are many context types that need to be managed. As summary is provided here: 823 824 • Experience Network determination 825 • Business agreement context 826 • Business agreement roles 827 • Classification of artifacts context 828 • Process selection context 829 • Process tracking context 830 • Transaction context
  • 831 • Exception handling context 832 • Decisions context 833 • Rules context 834 835By enabling the exposing and control of these context parameters through declarative 836mechanisms in the ASE Templates, this enables agile semantic interoperability. 837Design by Contract 838 839 840Applying Adaptive Service Engineering Techniques 841This section discusses key implementation techniques and a realistic but simple example. 842Use Domain Specification Language from 843 844Determining Experience Network 845In building interoperable agile information systems, one of the first needs is to select 846common formats for the information. To achieve consensus the participants can either 847seek out existing formats or develop their own. In either case, it is important to
  • 848determine the Experience Network into which the information domain falls and 849authoritative sources within that domain. While this is often overlooked in local 850application system development, where the focus is totally on internal information, as 851soon as any external interaction occurs it becomes apparent that those internal systems 852need to conform to external requirements and that authoritative sources for those are 853needed. Plan immediately to understand the Experience Network and the internal and 854external information requirements for all the participants in the Experience Network. 855This forces a community orientation of the information. 856Once the broad Experience Network has been established, the next classification is within 857the Experience Network itself, and development of ontologies and classifications to 858promote re-use by enabling the purpose and function of artifacts to be clearly determined. 859Again this is often overlooked and artifacts are poorly organized, or placed within too 860broad a grouping. 861 862By identifying the task of Experience Network facilitation the BCM helps focus business 863attention on the need to improve Experience Network alignment. By providing templates 864to address these needs the BCM allows individual enterprises to effect change and 865improve within the Experience Networks. Technology such as federated registries and 866shared directory services are the other metrics in improving discovery and re-use of 867coherent standards. The next section considers in more detail collaboration mechanisms 868between enterprises within a Experience Network. 869 870Collaboration Mechanisms 871Once the Experience Network metrics are determined, two things are needed to more 872effectively interact with enterprise partners within a Experience Network; (1) BCM 873Templates to formulize the information configurations consistently, and (2) methods of 874interacting with and distributing those in a shared environment. Figure x.TBD.x shows 875the technology aspects of this. 876 877BCM Layered Methodology Mechanisms 878Concept Layer 879Business Layer 880Extension Layer 881Implementation Layer 882 883Concept Layer using Draft ISO/IEC 15414:6-2002 Enterprise 884Specification Language 885
  • 886 887Enterprise Specification Concept 888 Field of Application 889 System 890 Scope 891 892Community Concepts 893 Community 894 Enterprise Object 895 Objective 896 Contract of the Community 897 898Behaviour Concepts 899 Action 900 Behaviour 901 Role 902 Process and Step 903 Interface Role 904 905Policy Concepts 906 Rule
  • 907 Policy 908 Authorization 909 Obligation 910 Permission 911 Prohibition 912 Violation 913 914Accountability Concepts 915 Party 916 Commitment 917 Declaration 918 Delegation 919 Authority 920 Agent 921 Principal 922 Evaluation 923 Prescription 924 925Business Layer 926Extension Layer 927Implementation Layer 928Summarization of above into Conceptual Framework 929Views 930Collaboration View 931Contractual View 932Execution View 933 934Realizing Value from Adaptive Service Generation 935Conceptual Framework in Collaborative Commerce 936Walk through of the various components described above with interactions that generate 937business value and satisfy Adaptive Service Generation Conceptual Framework 938Business Drivers from beginning of this paper. 939
  • 940Acknowledgements: 941 942The following people from the OASIS Business Centric Methodology TC made 943contributions to this specification: 944 Dan Pattyn 945 Neil Wasserman 946 David RR Webber 947