Integrating for Enterprise Support IST 421 Supplement


Published on

  • Be the first to comment

  • Be the first to like this

Integrating for Enterprise Support IST 421 Supplement

  1. 1. Integrating for Enterprise Support IST 421 Supplement Fall, 2005 Ed Green Lecturer – IST The Pennsylvania State University The Abington College 215-881-7332 [email_address]
  2. 2. Overview and Focus <ul><li>Assemble and integrate </li></ul><ul><ul><li>Unified approach to contemporary integration issues </li></ul></ul><ul><li>Discussion elements </li></ul><ul><ul><li>Service view of architecture </li></ul></ul><ul><ul><li>Components and their use </li></ul></ul><ul><ul><ul><li>Legacy elements </li></ul></ul></ul><ul><ul><ul><li>COTS (traditional) </li></ul></ul></ul><ul><ul><ul><li>Open Source cibsuderation </li></ul></ul></ul><ul><ul><li>Messaging </li></ul></ul><ul><ul><li>Grid computing </li></ul></ul><ul><ul><li>Mobility edge </li></ul></ul>
  3. 3. Some Terms in Common Use <ul><li>Service Oriented Architecture (SOA) </li></ul><ul><li>Customer Relationship Management (CRM) </li></ul><ul><li>Enterprise Relationship Management (ERM) </li></ul><ul><li>Middleware </li></ul><ul><li>Grid Computing </li></ul><ul><li>Web Services </li></ul>
  4. 4. Services View of Architecture
  5. 5. A Couple of Definitions <ul><li>Service Oriented Architecture </li></ul><ul><ul><li>Application-based </li></ul></ul><ul><ul><li>Delivery of business services to users/customers </li></ul></ul><ul><li>Services </li></ul><ul><ul><li>Architecture-based </li></ul></ul><ul><ul><ul><li>All elements of architecture </li></ul></ul></ul><ul><ul><li>Engine components that produce business services </li></ul></ul>
  6. 6. . . . and an analogy Service Oriented Architecture is to Services as Functional Requirements are to Technical Requirements
  7. 7. Integration Services Message Queue Adapter Message Queue Adapter Message Queue Message Queue Staging Message Queue Intranet Facilities Personal Computers Messaging Services Organization Directory Security Services System Management Knowledge Management Metadata Repository Archiving Service Enterprise Infrastructure Portals B2B Messaging Enterprise COTS Application BSD Legacy System BSD Distributed Component- based BSD Decision Support System BSD Plant Control System
  8. 8. Networking Model Private Intranet Public Internet External Users Message Queues Web Server Application(s) Business System Domain Directory Services Device Services Message Broker Services Internal Users Organization Structure Service Trader Services Firewall Employee Remote Access Enterprise Web Server Public Application(s) Message Queues Public Web Applications B2B Web Server(s) B2B Message Queues Business Partners Remote Employees Internal Systems
  9. 9. Workflow Process Model Personal Work List Resource Assignment Facilities Process Manager Requestor Process Definition Process Instance Process Instance Process Definition
  10. 10. Component-based BSD* Model Organization Directory Name Service Exception Service System Management Persistence Service Component Containers Business Processes Web Server Transaction Service Message Queues Security Service Business Document Archive Business System Domain * Business System Domain
  11. 11. Enterprise Data Storage Model Business Applications Business Document Archives Enterprise Master Database Document Management Operational Data Stores Meta Data Data Warehouse Data Marts
  12. 12. Enterprise Architecture and Integration <ul><li>Application architectures are good </li></ul><ul><li>Stovepipes may result </li></ul><ul><ul><li>Each application has its own architecture </li></ul></ul><ul><ul><li>Boolean intersection  Null Set except by accident </li></ul></ul><ul><ul><li>Very common in legacy application situations. </li></ul></ul>
  13. 13. Business As Unusual <ul><li>No longer exists </li></ul><ul><ul><li>“ Business as usual” inadequate to survive in the current technology-driven business environment </li></ul></ul><ul><ul><li>Internet e-business no longer exists in only a technology domain </li></ul></ul><ul><li>In 2001, </li></ul><ul><ul><li>Gartner Group </li></ul></ul><ul><ul><ul><li>“ e-commerce applications and technology elevated to a core competency” </li></ul></ul></ul><ul><ul><li>Forrester – e-business market will exceed $1.3 trillion by 2005 </li></ul></ul><ul><ul><li>IDC – enterprises will invest $10 billion by 2005 to create e-business infrastructure </li></ul></ul>
  14. 14. Defining the “ Extended Enterprise” <ul><li>Automate electronic interfaces that link the computer systems of </li></ul><ul><ul><li>The ultimate selling businesses, </li></ul></ul><ul><ul><li>Partners that finance or manage the transaction </li></ul></ul><ul><ul><li>External suppliers, carriers, and support organizations </li></ul></ul><ul><li>In turn these external partners connect with numerous internal systems that support </li></ul><ul><ul><li>Customer service </li></ul></ul><ul><ul><li>Sales </li></ul></ul><ul><ul><li>Logistics </li></ul></ul><ul><ul><li>Manufacturing </li></ul></ul><ul><ul><li>Procurement </li></ul></ul><ul><ul><li>Accounting </li></ul></ul><ul><ul><li>Human resources </li></ul></ul><ul><ul><li>Corporate finance </li></ul></ul>
  15. 15. Event-Driven Economy <ul><li>An economy where demand realized translates into demand satisfied </li></ul><ul><ul><li>In near-real time </li></ul></ul><ul><li>Demand realized </li></ul><ul><ul><li>Accomplished by extending capabilities and reach of existing IT infrastructure so that enterprise applications are bound by a business event-driven paradigm </li></ul></ul><ul><ul><ul><li>Inter-enterprise </li></ul></ul></ul><ul><ul><ul><li>Intra-enterprise </li></ul></ul></ul>
  16. 16. Defining Characteristics of an Event-Driven Economy <ul><li>Almost instantaneous </li></ul><ul><ul><li>Definitely occurs in real time </li></ul></ul><ul><li>ALL participating systems are able to communicate in any direction </li></ul><ul><ul><li>With any other system </li></ul></ul><ul><ul><li>Automatically </li></ul></ul><ul><ul><li>In real time </li></ul></ul><ul><li>Systems bound at both data and process levels </li></ul><ul><ul><li>More than exchanging information </li></ul></ul><ul><ul><li>Business rules and processes shared </li></ul></ul><ul><ul><li>Data processed with common integrity constraints enforced </li></ul></ul><ul><ul><li>Common business model determine path and order of each business event </li></ul></ul><ul><ul><ul><li>Spans business systems </li></ul></ul></ul><ul><ul><ul><li>Defines properties of a business event </li></ul></ul></ul><ul><ul><ul><ul><li>Order </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Behavior </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Information characteristics </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Public and private processes </li></ul></ul></ul></ul><ul><ul><li>All relevant information accessible by any other participating system </li></ul></ul>
  17. 17. Component-based BSD* Model Organization Directory Name Service Exception Service System Management Persistence Service Component Containers Business Processes Web Server Transaction Service Message Queues Security Service Business Document Archive Business System Domain * Business System Domain
  18. 18. Local BSD Networking Included Servers Directory Services Web Server Database Server Application Server Application Server * Business System Domain
  19. 19. Request Broker Connectivity Security Services Organization Directory Web Server Exception Service Name Service Transaction Service Message Queues Business Processes Component Containers Persistence Service Business Document Archive Message Broker
  20. 20. Message Structure Message Header Includes destination Identifies source Identifies message (type) Message Trailer Indicates end of message Message Contents Must be defined in such a way that it is understood by BOTH sender AND receiver
  21. 21. Interface Definition Language (IDL) <ul><li>Used to define network interfaces of network-accessible objects </li></ul><ul><ul><li>Object method signatures </li></ul></ul><ul><ul><li>Attributes </li></ul></ul><ul><li>CORBA and ISO standard </li></ul><ul><li>Defines interfaces and not implementations </li></ul><ul><ul><li>Different object classes can implement the same interface </li></ul></ul><ul><li>Strongly typed </li></ul><ul><ul><li>Parameters </li></ul></ul><ul><ul><li>Return values </li></ul></ul><ul><ul><li>Attribute values </li></ul></ul><ul><li>Basis for generating proxy objects on sending (client) server </li></ul>found in method signatures
  22. 22. Interface Definition Language (IDL) <ul><li>Object reference – information necessary and sufficient to locate the actual object </li></ul><ul><ul><li>Passed over the network using IIOP </li></ul></ul><ul><ul><li>Includes return value requirements </li></ul></ul><ul><li>Proxy object – represents the target object </li></ul>Proxy Object Skeleton Object Target Object Object Request Broker Object Request Broker Message IIOP* * International Interface Object Protocol
  23. 23. How Data Is Processed -Schematic <ul><li>Data has been entered onto a screen </li></ul><ul><li>ENTER, SUBMIT, etc. command has been given </li></ul><ul><li>Screen contains fixed and variable items </li></ul><ul><li>Screen also contains items that are non-visible but transmittable </li></ul>Computer Program Variable and other transmittable items sent to a computer program Data from screen Trailer (end of data) Header (identification) Data is transmitted in the form of a message Errors have been detected; user advised Database Data is stored in data base Computer Program Data is forwarded to another program for further processing Operation successful; user advised DBMS Computer program contains a “template”that identifies data as well as the rules for interpreting that data. This program: - Identifies the data - Determines presence of required data - Validates data - Determines next action SERVLET
  24. 24. Introduction to Components
  25. 25. Components <ul><li>A component is a software entity that provides a cohesive set of functional capabilities through a specified interface </li></ul><ul><li>“Stand-alone” capability that supports one business function </li></ul><ul><li>Shareable </li></ul><ul><ul><li>Capability can be used by many managed processes </li></ul></ul><ul><ul><li>Needs may be different </li></ul></ul>
  26. 26. Component Granularity <ul><li>Granularity represents a component’s capabilities </li></ul><ul><ul><li>Size – </li></ul></ul><ul><ul><ul><li>How large? </li></ul></ul></ul><ul><ul><ul><li>How many included functions </li></ul></ul></ul><ul><ul><ul><ul><li>Coarse versus Fine Grain </li></ul></ul></ul></ul><ul><ul><li>Scope – functionality included </li></ul></ul><ul><li>Configurability </li></ul>
  27. 27. Interfacing <ul><li>Enterprise-level architecture components often too large to be viewed as single objects </li></ul><ul><ul><li>Can be entire systems decomposable into separate functional modules </li></ul></ul><ul><ul><li>Systems of their own </li></ul></ul><ul><li>Enterprise architecture components do have well specified interfaces </li></ul><ul><ul><li>Best defined and controlled using distributed object technology </li></ul></ul>
  28. 28. Reuse <ul><li>Ability to use a software element more than once </li></ul><ul><ul><li>‘Create once, use often’ </li></ul></ul><ul><ul><li>Provide a standard means for </li></ul></ul><ul><ul><ul><li>Computation </li></ul></ul></ul><ul><ul><ul><li>Validation </li></ul></ul></ul><ul><ul><ul><li>Comparison </li></ul></ul></ul><ul><ul><ul><li>Presentation </li></ul></ul></ul>
  29. 29. Component Reuse <ul><li>Reusability is an important characteristic of components </li></ul><ul><li>What is reuse? </li></ul><ul><ul><li>A (reusable) common service that persistently maintains some data of interest to multiple applications </li></ul></ul><ul><ul><li>The ability to use the same module of software code in separate executing instances </li></ul></ul>
  30. 30. Component Layers <ul><li>Application-Specific Components </li></ul><ul><ul><li>Application-unique services </li></ul></ul><ul><li>Business Domain Components </li></ul><ul><ul><li>Fundamental business entities and processes of the enterprise </li></ul></ul><ul><ul><li>Shared across applications </li></ul></ul><ul><li>Extended Platform Components </li></ul><ul><ul><li>ORB </li></ul></ul><ul><ul><li>DBMS </li></ul></ul><ul><ul><li>Web server </li></ul></ul><ul><ul><li>Application server </li></ul></ul><ul><ul><li>Transaction monitor </li></ul></ul><ul><li>Platform/Network Components </li></ul><ul><ul><li>Basic services used by applications to support business logic </li></ul></ul>Application-Specific Components Business Domain Components Extended Platform Components Platform/Network Components
  31. 31. Dependency <ul><li>Outgrowth of vertical partitioning of applications </li></ul><ul><li>Components lower in the architecture are independent of higher level ones </li></ul><ul><li>Key architectural consideration to ensure adaptability and modifiability </li></ul><ul><li>With proper dependency relationships </li></ul><ul><ul><li>Upper-layer components easily modified </li></ul></ul><ul><ul><ul><li>No changes to lower-layer components </li></ul></ul></ul><ul><ul><li>Lower-layer components can be modified or replaced without impact to upper-layer components </li></ul></ul><ul><ul><ul><li>Requires continuity of interface support </li></ul></ul></ul>
  32. 32. Dependency <ul><li>Commercial lower-layer almost always independent of higher-level custom code </li></ul><ul><li>Dependency relationships must be considered </li></ul><ul><ul><li>Dependencies between platform and extended platform components </li></ul></ul><ul><ul><li>Dependencies between business domain and application-specific components </li></ul></ul><ul><ul><li>Layer skipping </li></ul></ul><ul><ul><ul><li>Interfacing with a component further down in the architecture </li></ul></ul></ul>
  33. 33. Defining Architectural Layers Application ; Business domain; Extended platform; Platform/network Enterprise Application ; Business domain; Extended platform; Platform/network Security Business domain; Extended platform; Platform/network Connector Application ; Business domain; Extended platform; Platform/network New technology component Application ; Platform/network Extensions to existing system Application ; Platform/network Existing system Layers Defined Architecture
  34. 34. Existing Applications as Components <ul><li>Definition established applications as higher-level components </li></ul><ul><ul><li>Containing lower-level elements as objects </li></ul></ul><ul><li>Architecture must be defined at enterprise level, not at application level </li></ul><ul><li>Legacy applications have two views </li></ul><ul><ul><li>Logical </li></ul></ul><ul><ul><ul><li>Key software purposes of internal functionality </li></ul></ul></ul><ul><ul><ul><li>Software interrelationships </li></ul></ul></ul><ul><ul><li>Physical </li></ul></ul><ul><ul><ul><li>Software interfaces for interoperating with applications </li></ul></ul></ul>
  35. 35. Extending Applications <ul><li>Frequently less expensive than replacement </li></ul><ul><li>Identify nature of extension </li></ul><ul><ul><li>Additional functionality </li></ul></ul><ul><ul><li>Additional data </li></ul></ul><ul><ul><li>New processing logic </li></ul></ul><ul><ul><ul><li>Data and functionality that extends capabilities </li></ul></ul></ul><ul><li>Architecture must detail extensions </li></ul>
  36. 36. Identifying Component Interface Specifications <ul><li>Interface specifications abstract in nature at enterprise level </li></ul><ul><li>Interface specifications should state: </li></ul><ul><ul><li>Specific functionality that can be invoked </li></ul></ul><ul><ul><li>Specific data supported by each function </li></ul></ul><ul><ul><li>Interface invocation sequence </li></ul></ul>
  37. 37. Adding New Components <ul><li>New technology components </li></ul><ul><ul><li>Deliver new functionality and data as part of legacy application extension </li></ul></ul><ul><li>Allocate to layers </li></ul><ul><li>Clearly identify interconnectivity between components </li></ul><ul><ul><li>Within a layer </li></ul></ul><ul><ul><li>Between layers </li></ul></ul>
  38. 38. Introducing Components – An Example A COTS ERM product is introduced to replace a variety of legacy management applications. However, in order to do business with the federal government DoD, billing must be sent electronically using a specified format. This format is not included in the COTS ERM; hence the legacy application must be retained and integrated. COTS ERM LEGACY REPORTER USER Event Trigger Send Bill Interface Data Request Transform Data Delivery DoD Bill Electronic
  39. 39. Summary (so far) <ul><li>Components are key elements for enterprise application integration </li></ul><ul><li>Four discrete layers demand consistency and connectivity </li></ul><ul><li>Legacy applications will have a place in integrated application architectures for the foreseeable future </li></ul>
  40. 40. Component Containers <ul><li>Makes the component transactional </li></ul><ul><li>Resolves access conflicts </li></ul><ul><li>Provides for event management </li></ul><ul><li>Sustains component-state persistence </li></ul><ul><li>Implements life-cycle operations </li></ul><ul><li>Removes or simplifies consideration of component complexities </li></ul>
  41. 41. Component Containers <ul><li>Application software that provides the execution of a single business process or function </li></ul><ul><ul><li>Inputs </li></ul></ul><ul><ul><li>Processes </li></ul></ul><ul><ul><li>Outputs </li></ul></ul>Out In Wrapper Component Provides output to other components in a specified format Accepts input form other components in a specified format
  42. 42. Encapsulation and Abstraction <ul><li>Descriptions of interfacing with a component </li></ul><ul><li>Applies to both in and out interfaces </li></ul><ul><li>An encapsulated interface is one where the available knowledge about a component is limited to the information contained in the interface definition </li></ul><ul><li>An abstracted interface is one where the accessibility to a component is published in the interface definition but where it is possible to acquire further knowledge about the component via other means </li></ul>
  43. 43. SAP Overview Operating System DBMS API and GUI BASIS SAP Functionality Application Modules and Business Processes* <ul><li>Tools: </li></ul><ul><li>ABAP Workbench </li></ul><ul><li>Computer Center Management - Database Administration </li></ul><ul><li>Configuration Management </li></ul><ul><li>Data </li></ul><ul><li>Source Libraries </li></ul><ul><li>Data Dictionary </li></ul><ul><li>Repository </li></ul><ul><li>Temporary Data </li></ul><ul><li>Print Queues </li></ul>Database * Object based end-to-end business process Source: SAP R/3 System Administration Guide , ISBN 0-7821-2426-7
  44. 44. SAP Functional Architecture SAPGUI Database Host Application Servers Application Server External Processes API
  45. 45. data SAPGUI External Processes Business Process Application Servers SAP Tools Business Process . . . Database Host DBMS Interpretive code SAP Architecture - A Process View Data which is on the GUI API BAPI <ul><li>Batch, including real time </li></ul><ul><li>Best of breed (legacy) </li></ul><ul><li>Other COTS/NDI </li></ul><ul><li>Transitory applications </li></ul><ul><li>Bolt-ons </li></ul><ul><li>Human Interface </li></ul>Developed “applications” - BAPI APIs - ABAP Workbench ALL else is SAP-provided WF DD DB
  46. 46. Example – Producing a Bill Question: Using what you know, and the fact that contract costs are contained in SAP module “CM”, re-draw the example below (from chart 178) to reflect utilizing SAP. COTS ERM LEGACY REPORTER USER Event Trigger Send Bill Interface Data Request Transform Data Delivery DoD Bill Electronic
  47. 47. Messaging Infrastructure
  48. 48. Messaging Infrastructure <ul><li>Design Objectives </li></ul><ul><li>Messaging Structures </li></ul><ul><li>Messaging Format Abstractions </li></ul><ul><li>Design Considerations </li></ul><ul><li>Example </li></ul>
  49. 49. Messaging Infrastructure – Design Objectives <ul><li>Store and forward </li></ul><ul><li>Message broker </li></ul><ul><li>Guaranteed delivery </li></ul><ul><li>Message sequence </li></ul><ul><li>Symbolic routing </li></ul><ul><li>Request-response </li></ul><ul><li>Event messages </li></ul><ul><li>Message transformation </li></ul><ul><li>Ad hoc destination </li></ul><ul><li>Exception resolution </li></ul><ul><li>Standards </li></ul><ul><li>File transfers </li></ul>
  50. 50. Message Infrastructure - Structures <ul><li>Message queues </li></ul><ul><li>Basic messaging facilities </li></ul><ul><li>Point-to-point messages </li></ul><ul><li>Publish-and-subscribe messages </li></ul><ul><li>Message format abstractions </li></ul><ul><li>API object model </li></ul>
  51. 51. Messaging Infrastructure – Message Broker Concept A C D B C B D A Point-to-Point (Without Message Brokering) With Message Brokering
  52. 52. Message Structure Message Header Includes destination Identifies source Identifies message (type) Message Trailer Indicates end of message Message Contents Must be defined in such a way that it is understood by BOTH sender AND receiver
  53. 53. Messaging Infrastructure – Message Format Abstraction Destination Delivery Mode Message ID Timestamp Correlation ID Reply To Redelivered Type Expiration Priority Message Properties
  54. 54. Messaging Infrastructure – Design Considerations <ul><li>Product interoperability </li></ul><ul><li>Transformation service </li></ul><ul><li>File transfers </li></ul><ul><li>B2B messaging </li></ul><ul><li>Security </li></ul><ul><li>Scalability </li></ul><ul><li>Application execution </li></ul><ul><li>Exception handling </li></ul>
  55. 55. Messaging Infrastructure Example <ul><li>Using everything to this point, let’s consider the process with ordering something from a supplier. </li></ul><ul><li>Recall from IST 331, we discussed the process for creating a purchase order </li></ul><ul><li>Now, let’s look at the e-business aspects </li></ul>
  56. 56. Traditional IT Framework Interface to Applications . . . . . . Clients Independent Applications <ul><li>Developed independently, frequently in a vacuum in the absence of standards </li></ul>
  57. 57. Enterprise IT Framework Application Integrator . . . . . . User Interface Security Clients Independent Applications Software that provides “common view” capability <ul><li>Authentication </li></ul><ul><li>Authorization </li></ul>WEB Browser <ul><li>Finance </li></ul><ul><li>Manufacturing </li></ul><ul><li>Sales/Marketing </li></ul><ul><li>Personnel </li></ul><ul><li>Engineering </li></ul>
  58. 58. e-World Concept of Operations <ul><li>e-Process begins with a buyer and a seller </li></ul><ul><ul><li>Goods/services wanted and available </li></ul></ul><ul><li>GLOBAL EXCHANGE facilitates the electronic transaction </li></ul><ul><li>Seller’s catalog reviewed by buyer </li></ul><ul><ul><li>Needed items available </li></ul></ul><ul><li>Purchase order prepared and transmitted to global exchange </li></ul><ul><li>Global exchange routes to seller </li></ul><ul><li>Order entry prepared </li></ul><ul><li>Production schedule established or updated </li></ul><ul><li>Inventory checked; replenishment ordered </li></ul><ul><li>Manufacturing resources assigned </li></ul><ul><li>Labor availability checked </li></ul><ul><ul><li>Resources assigned OR HR to staff prepared </li></ul></ul><ul><li>Sub-assemblies and other resources reserved </li></ul><ul><li>Production package prepared </li></ul><ul><ul><li>Bill of materials </li></ul></ul><ul><ul><li>Manufacturing/assembly instructions </li></ul></ul><ul><ul><li>Drawings/blueprints </li></ul></ul>
  59. 59. e-World Concept of Operations (continued) <ul><li>Production process is monitored </li></ul><ul><li>Labor time & attendance is recorded </li></ul><ul><li>Test results and quality analysis recorded </li></ul><ul><li>Shipping is scheduled </li></ul><ul><li>Customer Service is advised </li></ul><ul><li>Billing is notified </li></ul><ul><ul><li>Customer billing is prepared </li></ul></ul><ul><li>Order is shipped </li></ul><ul><li>Order is received </li></ul><ul><li>Receiving inspection conducted; test results recorded </li></ul><ul><li>Bill is received </li></ul><ul><li>Payment is made </li></ul><ul><li>Questions arise </li></ul><ul><li>Supplier customer service is contacted </li></ul><ul><ul><li>Call is recorded </li></ul></ul><ul><ul><li>Question is researched in the product reference materials </li></ul></ul><ul><ul><li>Answer is provided </li></ul></ul>
  60. 60. Trading Partner Challenge Application Integrator . . . . . . User Interface Security Application Integrator . . . . . . User Interface Security Application Integrator . . . . . . User Interface Security Application Integrator . . . . . . User Interface Security Application Integrator . . . . . . User Interface Security
  61. 61. Messaging <ul><li>What are the messages? </li></ul><ul><li>What do each of the messages contain? </li></ul><ul><li>What are the implications? </li></ul>
  62. 62. Persistent Services <ul><li>Object Mapping </li></ul><ul><li>Database Operations </li></ul><ul><ul><li>Create </li></ul></ul><ul><ul><li>Delete </li></ul></ul><ul><ul><li>Update </li></ul></ul><ul><li>Queries </li></ul><ul><li>Connection Management </li></ul>
  63. 63. Security Service <ul><li>Supports authentication and authorization within BSD </li></ul><ul><li>Determines identity of user from </li></ul><ul><ul><li>Digital certificates </li></ul></ul><ul><ul><li>Userid and password </li></ul></ul><ul><li>May be implemented in </li></ul><ul><ul><li>Web server </li></ul></ul><ul><ul><li>Application server </li></ul></ul><ul><ul><li>Both </li></ul></ul><ul><li>Best outside of application server </li></ul><ul><ul><li>Reduces complexity </li></ul></ul><ul><li>SSL protocol ensures integrity and confidentiality of data transmitted on network </li></ul>
  64. 64. Security Service Web Server Document Archive Application Server(s) Security Service Message Queue Organization Service Messaging Service Web Browser HTTPS SSL
  65. 65. Transaction Services <ul><li>Serialization </li></ul><ul><li>Deadlocks </li></ul><ul><li>Concurrency services </li></ul><ul><li>Locking services </li></ul><ul><li>Transactional context </li></ul><ul><li>Callback </li></ul><ul><li>Transaction control services </li></ul><ul><li>Phased commits </li></ul><ul><li>Recovery </li></ul><ul><li>Nested transactions </li></ul>
  66. 66. Example – The Systems Integration Challenge Aerospace Global Trading Exchange Boeing BAE Lockheed Martin Raytheon Supplier Community Opportunity: significant savings through economies of scale Problem: everyone “does their own thing” Challenge: find the common ground
  67. 67. What is B2B Application Integration <ul><li>Controlled sharing of data and business processes </li></ul><ul><li>Leveraged assets </li></ul><ul><ul><li>All existing systems </li></ul></ul><ul><ul><li>Bound within or between enterprises </li></ul></ul><ul><ul><li>Support any and all business requirements </li></ul></ul><ul><li>Access to perfect information on demand to outside trading partners </li></ul><ul><ul><li>Enables instant reaction to a business event </li></ul></ul>But, remember that a business transaction takes at least as long as the slowest system in the loop
  68. 68. Issues – Leveraging Assets <ul><li>Ancient technology critical to workings of enterprise </li></ul><ul><ul><li>Hard to impossible to adapt </li></ul></ul><ul><ul><li>Communications and sharing difficult (at best) </li></ul></ul><ul><li>Package applications </li></ul><ul><ul><li>Natural stovepipes </li></ul></ul><ul><ul><li>Clearly compound the problem </li></ul></ul>
  69. 69. Applying Technology <ul><li>Traditional middleware </li></ul><ul><ul><li>Built to integrate applications within an enterprise </li></ul></ul><ul><ul><li>Fails to account for B2B special needs </li></ul></ul><ul><li>Point-to-point solutions </li></ul><ul><ul><li>Remote procedure calls </li></ul></ul><ul><ul><li>Message queues </li></ul></ul><ul><li>Significant alterations to both source and target system are required </li></ul>May work within an enterprise; Out of control across enterprises
  70. 70. Traditional Middleware Application Green MD TCT EH PSR TXT FMT TSK QM DBBMS WFM MDM BUF DBMS Application Orange DBMS Application Red DBMS Application Green DBMS API Abbreviations API – Application Interface TCT – Task Control Table EH – Error Handler PSR – Parser TXT – Transaction Control Table FMT – Response Formatter TSK – Task Manager QM – Queue Manager WFM – Workflow Manager MDM – Metadata Manager BUF – Buffer Pool MD – Metadata Data Base Stovepipe business applications. Databases are application-centric and DBMS’s are not necessarily the same Interactive human users
  71. 71. B2B Application Integration <ul><li>Focuses on integration of both business-level processes and data between organizations </li></ul><ul><li>Includes notion of reuse in addition to distribution of business processes and data across linked enterprises </li></ul><ul><li>Application-to-application concept </li></ul><ul><ul><li>Near real time </li></ul></ul><ul><ul><li>Back end </li></ul></ul><ul><ul><li>Minimal user interaction </li></ul></ul><ul><li>Enables users with limited detail understanding of applications to integrate them </li></ul><ul><li>Incorporates notion of common agreements between trading organizations; support those agreements through information exchanges </li></ul><ul><li>Assumes most source and target systems cannot be altered and points of integration must be non-intrusive </li></ul><ul><li>Takes into account differences between integrating applications within and between enterprises; supports a single process model that spans both </li></ul><ul><li>Takes advantage of advanced security standards to protect information moving between companies </li></ul>
  72. 72. EAI versus B2B <ul><li>EAI – typically deals with the integration of applications and data within an enterprise to solve a local problem </li></ul><ul><li>B2B Application Integration deals with the integration of applications between organizations to solve any business problem </li></ul>
  73. 73. EAI versus B2B
  74. 74. Middleware and B2B Application Integration <ul><li>Middleware is a simple mechanism </li></ul><ul><ul><li>Accessible way to integrate external resources using a common set of application services to move information and shared business logic between applications </li></ul></ul><ul><ul><li>Hides complexities of underlying operating system and network </li></ul></ul><ul><ul><ul><li>Facilitates integration of various enterprise systems </li></ul></ul></ul><ul><ul><ul><li>API’s –general purpose data movement or process invocation mechanisms acting on behalf of an application </li></ul></ul></ul><ul><ul><li>Provides a means to connect distributed computing elements </li></ul></ul><ul><ul><ul><li>Clients to servers </li></ul></ul></ul><ul><ul><ul><li>Clients to clients </li></ul></ul></ul><ul><ul><ul><li>Servers to servers </li></ul></ul></ul>
  75. 75. Retooling Middleware for B2B <ul><li>Support inter- and intra-process integration </li></ul><ul><li>Support for B2B standards </li></ul><ul><ul><li>RosettaNet </li></ul></ul><ul><ul><li>ebXML </li></ul></ul><ul><ul><li>EDI </li></ul></ul><ul><li>Support for Internet-enabled information exchange </li></ul><ul><li>Support for advanced security models </li></ul>
  76. 76. Approaching e-Business <ul><li>Business rules integration </li></ul><ul><li>Information integration </li></ul><ul><li>Process integration </li></ul><ul><li>Collaboration </li></ul>
  77. 77. Business Rules Integration <ul><li>Binding of application logic between two or more business partners </li></ul><ul><ul><li>Composite applications accessible to all parties </li></ul></ul><ul><ul><li>Exchange of information and business rules fully automated </li></ul></ul><ul><li>CORBA standard implementation mechanisms </li></ul>
  78. 78. Information Integration <ul><li>Platform for exchanging relevant data in order to support e-Business initiatives </li></ul><ul><ul><li>Functions below Business Rules Integration </li></ul></ul><ul><li>Requires few changes to participating systems </li></ul><ul><ul><li>Relatively inexpensive </li></ul></ul><ul><li>Utilizes message brokers, data replication engines, and data migration engines </li></ul><ul><li>XML provides common information exchange format for incompatible applications and data sources </li></ul>
  79. 79. Process Integration <ul><li>Set of processes that function above both business rules and information integration </li></ul><ul><li>Process model resides on top of middleware </li></ul><ul><ul><li>Provides logical and physical information flows over existing business systems </li></ul></ul><ul><ul><li>Abstract business layer </li></ul></ul>
  80. 80. Process Integration
  81. 81. Collaboration <ul><li>Providing geographically dispersed workgroup with opportunity to share information in real time to support a business need </li></ul><ul><li>Greatest strength – supporting virtual communities of participating humans and computers </li></ul><ul><ul><li>“Information Anywhere” concept </li></ul></ul><ul><li>Centralized set of middleware to manage information </li></ul>
  82. 82. Collaboration <ul><li>CRM </li></ul><ul><li>Product Development </li></ul><ul><li>Logistics </li></ul><ul><li>Knowledge Management </li></ul>
  83. 83. Types of B2B Application Integration <ul><li>Data-oriented </li></ul><ul><li>Application interface-oriented </li></ul><ul><li>Method-oriented </li></ul><ul><li>Portal-oriented </li></ul><ul><li>Method-oriented </li></ul><ul><li>Process integration-oriented </li></ul>
  84. 84. Data Oriented Application Integration <ul><li>Simple process </li></ul><ul><ul><li>Information extraction from one database </li></ul></ul><ul><ul><li>Processing as required </li></ul></ul><ul><ul><li>Updating in one or more databases as required </li></ul></ul><ul><li>Advantage – cost </li></ul><ul><ul><li>Mostly leaving application code unchanged </li></ul></ul>
  85. 85. Application Interface-Oriented Application Integration <ul><li>Leveraging of interfaces exposed by custom or packaged applications </li></ul><ul><ul><li>Access both business processes and simple information </li></ul></ul><ul><ul><li>Bundle any number of applications to share business logic and information </li></ul></ul><ul><ul><li>Limitations </li></ul></ul><ul><ul><ul><li>Specific features and functions of the application interfaces </li></ul></ul></ul>
  86. 86. Method-Oriented <ul><li>Sharing of business logic that exists within the enterprise </li></ul><ul><li>Numerous mechanisms </li></ul><ul><ul><li>Distributed objects </li></ul></ul><ul><ul><li>Application servers </li></ul></ul><ul><ul><li>Transaction processing monitors </li></ul></ul><ul><ul><li>Frameworks </li></ul></ul><ul><ul><li>New applications </li></ul></ul><ul><li>Two approaches </li></ul><ul><ul><li>Create shared set of application servers on shared physical platform </li></ul></ul><ul><ul><li>Share already existing methods using distributed method-sharing technology </li></ul></ul>
  87. 87. Portal-Oriented <ul><li>Expanding paradigm due to increasing popularity and utility of web </li></ul><ul><li>Shared access to information through a common utility interface </li></ul>
  88. 88. Process Integration-Oriented <ul><li>Abstract business-oriented layer on top of traditional B2B information movement techniques and mechanisms </li></ul><ul><li>Provides business-oriented, process-automation view of business information flow between trading partners </li></ul><ul><li>Deals with abstract and shared processes </li></ul><ul><ul><li>People </li></ul></ul><ul><ul><li>Invoices </li></ul></ul><ul><ul><li>Orders </li></ul></ul><ul><ul><li>Companies </li></ul></ul><ul><ul><li>Merchandise </li></ul></ul><ul><li>Does not deal with physical integration flows or physical systems </li></ul>
  89. 89. Dimensions of B2B Application Integration Method Application Interface Data Process Integration Portal Interaction Points of Integration
  90. 90. Data-oriented B2B Application Integration <ul><li>Issues </li></ul><ul><li>Coupling versus cohesion </li></ul><ul><li>XML (Extended Markup Language) </li></ul><ul><li>Example </li></ul><ul><li>Database to database B2B application integration </li></ul><ul><li>Federated databases in B2B application integration </li></ul><ul><li>Consideration of data sources </li></ul>
  91. 91. Issues <ul><li>Entry point for B2B application integration </li></ul><ul><li>Allows for data to be moved between data stores </li></ul><ul><li>Numerous tools exist </li></ul><ul><li>Few significant change to application logic or database structure </li></ul><ul><li>Understanding does not make this easy </li></ul><ul><ul><li>Complexity of database world </li></ul></ul><ul><ul><li>Information flow through an enterprise </li></ul></ul><ul><ul><ul><li>How the data is used </li></ul></ul></ul>
  92. 92. Coupling versus Cohesion <ul><li>Coupling </li></ul><ul><ul><li>Creates one application and database out of many with tight dependencies </li></ul></ul><ul><li>Cohesion </li></ul><ul><ul><li>Logical agreement among independent applications and databases </li></ul></ul><ul><ul><li>Greatest flexibility </li></ul></ul><ul><ul><ul><li>Systems can be added/changed/removed without requiring significant changes to other systems in the problem domain </li></ul></ul></ul><ul><ul><li>Message brokers provide infrastructure </li></ul></ul><ul><ul><ul><li>Resolve differences in application semantics within a middle tier process </li></ul></ul></ul>Cohesion generally more optimal than coupling
  93. 93. Grid Computing Tutorial
  94. 94. Grid Technology Abstract <ul><li>Emerging new field </li></ul><ul><ul><li>Beyond distributed computing </li></ul></ul><ul><ul><li>Focus </li></ul></ul><ul><ul><ul><li>Large-scale resource sharing applications </li></ul></ul></ul><ul><ul><ul><li>High-performance orientation </li></ul></ul></ul><ul><ul><li>Requires </li></ul></ul><ul><ul><ul><li>Flexible, secure, coordinated resource sharing </li></ul></ul></ul><ul><ul><ul><li>Involves dynamic collection of </li></ul></ul></ul><ul><ul><ul><ul><li>Individuals </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Institutions </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Resources </li></ul></ul></ul></ul><ul><ul><li>Characterized by unique authentication, authorization, resource access, and resource discovery </li></ul></ul>The virtual organization
  95. 95. Introduction and Background <ul><li>Term “grid” originated – mid 1990’s </li></ul><ul><ul><li>Proposed infrastructure for science and engineering </li></ul></ul><ul><ul><li>Expanded to include broadest technology spectrum </li></ul></ul><ul><ul><ul><li>From advanced networking </li></ul></ul></ul><ul><ul><ul><li>To artificial intelligence </li></ul></ul></ul><ul><ul><ul><li>And everything in between </li></ul></ul></ul><ul><li>Addresses real and specific problem space </li></ul><ul><li>Distinct and separate from popular technology trends </li></ul><ul><ul><li>Internet </li></ul></ul><ul><ul><li>Enterprise computing </li></ul></ul><ul><ul><li>Distributed computing </li></ul></ul><ul><ul><li>Peer-to-peer computing </li></ul></ul><ul><li>Symbiotic opportunities when popular technologies “grow into” the grid problem space </li></ul>
  96. 96. Grid Problem Space <ul><li>Coordinated resource sharing and problem solving in dynamic, multi-institutional, virtual organizations </li></ul><ul><li>Essential needs </li></ul><ul><ul><li>Highly flexible sharing relationships ranging </li></ul></ul><ul><ul><ul><li>From client-server </li></ul></ul></ul><ul><ul><ul><li>To peer-to-peer </li></ul></ul></ul><ul><ul><li>Sophisticated and precise levels of control over use of shared resources </li></ul></ul><ul><ul><ul><li>Fine-grained and multi-stakeholder </li></ul></ul></ul><ul><ul><ul><ul><li>Access control </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Delegation </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Application of local and global policies </li></ul></ul></ul></ul><ul><ul><ul><li>Sharing of resources </li></ul></ul></ul><ul><ul><ul><ul><li>From programs, files, and data </li></ul></ul></ul></ul><ul><ul><ul><ul><li>To computers, sensors, and networks </li></ul></ul></ul></ul><ul><ul><ul><li>Diverse usage modes </li></ul></ul></ul><ul><ul><ul><ul><li>From single-user to multi-user </li></ul></ul></ul></ul><ul><ul><ul><ul><li>From performance sensitive to cost-sensitive </li></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Quality of service </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Scheduling </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Co-allocation </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Accounting </li></ul></ul></ul></ul></ul>Not addressed by current generation of distributed computing technologies
  97. 97. What Grid Technology Offers <ul><li>Security solutions that support management credentials and policies across multiple enterprises </li></ul><ul><li>Resource management services and protocols to support </li></ul><ul><ul><li>Secure remote access to computing and data resources </li></ul></ul><ul><ul><li>Co-allocation of multiple resources </li></ul></ul><ul><li>Information query protocols and services that provide configuration and status information about </li></ul><ul><ul><li>Resources </li></ul></ul><ul><ul><li>Organizations </li></ul></ul><ul><ul><li>Services </li></ul></ul><ul><li>Data management services that locate and transport datasets between storage systems and applications </li></ul>Compliment existing distributed computing technologies rather than competing with them!
  98. 98. Grid Technology Placement – a Perspective <ul><li>Virtual organizations </li></ul><ul><ul><li>Set of collaborating enterprises </li></ul></ul><ul><ul><ul><li>Viewed as a single logical entity </li></ul></ul></ul><ul><ul><li>Leverage collaborator </li></ul></ul><ul><ul><ul><li>Processes </li></ul></ul></ul><ul><ul><ul><li>Policies </li></ul></ul></ul><ul><ul><ul><li>Systems </li></ul></ul></ul><ul><ul><ul><li>Resources </li></ul></ul></ul><ul><li>Single-enterprise viewpoint ( s ) </li></ul><ul><ul><li>Collaboration among diverse business units </li></ul></ul><ul><ul><ul><li>Merger/acquisition/divestiture ramifications </li></ul></ul></ul><ul><ul><li>Cooperative processing among less-than-compatible systems </li></ul></ul><ul><li>Multi-enterprise viewpoint ( m ) </li></ul><ul><ul><li>Collaboration among diverse enterprises </li></ul></ul><ul><ul><li>m=s n where n is the number of enterprises </li></ul></ul><ul><li>Global considerations </li></ul>
  99. 99. Virtual Organizations <ul><li>Collaboration to achieve a common goal </li></ul><ul><li>An enterprise can participate in multiple virtual organizations </li></ul><ul><ul><li>Domain-relevant </li></ul></ul><ul><ul><ul><li>Market-centric </li></ul></ul></ul><ul><ul><ul><li>Industry-oriented </li></ul></ul></ul><ul><ul><li>Problem-centric </li></ul></ul><ul><ul><ul><li>Opportunity-centric </li></ul></ul></ul><ul><ul><ul><li>Economics-driven </li></ul></ul></ul><ul><ul><li>Dynamic over time </li></ul></ul><ul><li>Resource sharing is managed </li></ul><ul><ul><li>“ Need to know” accessibility </li></ul></ul><ul><ul><li>Conditional availability – who, what, when, how </li></ul></ul><ul><ul><li>Discovery mechanism required to characterize the state of relationships at some particular point in time </li></ul></ul><ul><ul><li>Peer-to-peer considerations </li></ul></ul><ul><ul><ul><li>Providers and consumers </li></ul></ul></ul><ul><ul><ul><li>Subset relationships </li></ul></ul></ul><ul><ul><li>Single resource, multiple sharing opportunities </li></ul></ul>Common Interest
  100. 100. Concept of Grid Architecture <ul><li>Grid architectures require establishment of sharing relationships among potential participants </li></ul><ul><ul><li>Central issue  interoperability  protocols </li></ul></ul><ul><li>Grid architecture is a protocol architecture </li></ul><ul><ul><li>Mechanisms for users and resources to negotiate, establish, manage, and exploit sharing relationships </li></ul></ul><ul><li>Standards-based open architecture </li></ul><ul><ul><li>Facilitates extensibility, interoperability, portability, and code sharing </li></ul></ul><ul><ul><li>Standard protocols enable definition of standard services that provide enhanced capabilities </li></ul></ul><ul><ul><li>Application Programming Interfaces (API) </li></ul></ul><ul><ul><li>Software Development Kits (SDK) </li></ul></ul>
  101. 101. Importance of Interoperability <ul><li>Need to initiate sharing relationships among arbitrary partners </li></ul><ul><li>Need to accommodate new partners dynamically across different computing environments </li></ul><ul><ul><li>Hardware </li></ul></ul><ul><ul><li>Software </li></ul></ul><ul><li>Need to promote multilateral sharing arrangements </li></ul><ul><ul><li>Avoid bilateral resource sharing </li></ul></ul><ul><ul><li>Ensure availability of sharing mechanisms in a dynamic partnership environment </li></ul></ul>
  102. 102. Importance of Protocols <ul><li>Protocol definition specifies </li></ul><ul><ul><li>How distributed system elements interact with each other to achieve a specified behavior </li></ul></ul><ul><ul><li>Structure of information during interaction </li></ul></ul><ul><li>Virtual organizations compliment existing enterprises/institutions </li></ul><ul><ul><li>Sharing mechanisms must avoid substantial changes to local policies </li></ul></ul><ul><ul><li>Sharing must preserve individual (institution) control of (their) resources </li></ul></ul><ul><li>Protocols </li></ul><ul><ul><li>Govern the interaction between components </li></ul></ul><ul><ul><li>Do not govern implementation of components </li></ul></ul><ul><li>Without standard protocols, interoperability requires </li></ul><ul><ul><li>Single implementation at the API level or </li></ul></ul><ul><ul><li>Having every implementation know details of every other </li></ul></ul>
  103. 103. Grid Architecture Description Application Collective Resource Connectivity Fabric Grid Protocol Architecture Application Transport Internet Link Internet Protocol Architecture A relationship exists between the Grid Protocol Architecture and the Internet Protocol Architecture.
  104. 104. Fabric Layer – Local Control Interface <ul><li>Provides resources to mediate shared access to system facilities by Grid protocols </li></ul><ul><ul><li>Physical system facilities require external protocols – computational components, storage systems, catalogs, network and/or sensors </li></ul></ul><ul><ul><li>Logical system facilities require internal protocols – distributed file system, computer cluster, and/or distributed computer cluster </li></ul></ul><ul><li>Implements local, resource-specific operations on specific (logical or physical) resources as the result of higher-level sharing operations </li></ul><ul><li>Interdependence between fabric-layer functions and sharing operations </li></ul><ul><ul><li>Tightly coupled </li></ul></ul>
  105. 105. Delivering Functionality <ul><li>Can be combined in a variety of ways to deliver functionality to applications </li></ul>Application Co-reservation Service API & SDK Co-reservation Service Co-Allocation API & SDK Resource Mgmt API & SDK Network Resource Network Resource Compute Resource Compute Resource Co-reservation Protocol Resource Management Protocol Collective Layer Resource Layer Fabric Layer
  106. 106. Fabric Layer – Local Control Interface <ul><li>Minimum implementation </li></ul><ul><ul><li>Enquiry mechanisms that permit discovery of resource structure, state, capabilities </li></ul></ul><ul><ul><li>Resource management mechanism that provide control of delivered quality of service </li></ul></ul><ul><li>Capabilities </li></ul><ul><ul><li>Computational resources – starting, monitoring, and controlling the execution of programs </li></ul></ul><ul><ul><li>Storage resources – getting and putting of files </li></ul></ul><ul><ul><li>Network resources – managing network transfers </li></ul></ul><ul><ul><li>Code repositories – managing versioned source and object code </li></ul></ul><ul><ul><li>Catalogs – implementing catalog query and update capabilities </li></ul></ul>
  107. 107. Connectivity – Communication and Authentication Protocols <ul><li>Communication protocols – enable exchange of data between Fabric Layer resources </li></ul><ul><li>Communications includes </li></ul><ul><ul><li>Transport </li></ul></ul><ul><ul><li>Routing </li></ul></ul><ul><ul><li>Naming </li></ul></ul><ul><li>Authentication protocols </li></ul><ul><ul><li>Build on communications services </li></ul></ul><ul><ul><li>Provide cryptographically secure mechanisms for identity verification </li></ul></ul><ul><ul><ul><li>Users </li></ul></ul></ul><ul><ul><ul><li>Resources </li></ul></ul></ul><ul><li>Security aspects – standards based </li></ul>
  108. 108. Authentication Solutions for VO Environments <ul><li>Single sign on – one-time authentication provides access to allowed Grid resources </li></ul><ul><li>Delegation – ability to endow a program to execute on the named user’s behalf </li></ul><ul><li>Interoperate with local security solutions </li></ul><ul><li>User-based trust relationships </li></ul>
  109. 109. Resources Layer – Sharing Single Resources <ul><li>Defines protocols, API’s, and SDK’s for </li></ul><ul><ul><li>Secure negotiation </li></ul></ul><ul><ul><li>Initiation </li></ul></ul><ul><ul><li>Monitoring </li></ul></ul><ul><ul><li>Control </li></ul></ul><ul><ul><li>Accounting </li></ul></ul><ul><ul><li>Payment processing </li></ul></ul><ul><li>Call Fabric Layer functions to access and control local resources </li></ul><ul><li>Concerned entirely with individual resources </li></ul><ul><li>Primary protocols </li></ul><ul><ul><li>Information protocols – obtain information about state and/or structure of resources </li></ul></ul><ul><ul><li>Management protocols – negotiate access to a shared resource </li></ul></ul>Operations
  110. 110. Collective Layer – Coordinating Multiple Resources <ul><li>Protocols, API’s, and SDK’s </li></ul><ul><ul><li>Not associated with any one particular resource </li></ul></ul><ul><ul><li>Global in nature </li></ul></ul><ul><ul><li>Capture interactions across collections of resources </li></ul></ul>
  111. 111. Collective Layer Services <ul><li>Directory services – discover existence and/or properties of VO resources </li></ul><ul><li>Co-allocation, scheduling, and brokering services – </li></ul><ul><ul><li>Allow VO participants to request allocation of one or more resources </li></ul></ul><ul><ul><li>Allow VO participants to schedule tasks on appropriate resources </li></ul></ul><ul><li>Monitoring and diagnostics services – monitor VO resources for failure, adversarial attack, or overload </li></ul><ul><li>Data replication services – support placement of data to maximize data access performance with respect to metrics such as response time, reliability, and cost </li></ul><ul><li>Grid-enabled programming services – allow use of familiar programming models to be used in Grid environments to address resource discover, security, and resource allocation </li></ul>
  112. 112. Collective Layer Services <ul><li>Workload management systems and collaboration frameworks – </li></ul><ul><ul><li>aka problem solving environments </li></ul></ul><ul><ul><li>Provide for description, use, and management of multi-step, asynchronous, multi-component workflows </li></ul></ul><ul><li>Software discovery services – discover and select most appropriate implementation and execution platform based on parameters of problem being solved </li></ul><ul><li>Community authorization services – enforce community policies governing resource access, to generate access capabilities to community resources </li></ul><ul><li>Community accounting and payment services – gather resource usage information for accounting, payment, and/or resource usage management </li></ul><ul><li>Collaboratory services – supports information exchange among users </li></ul>
  113. 113. Applications <ul><li>Utilize services defined at any of the other layers </li></ul><ul><ul><li>Construction </li></ul></ul><ul><ul><li>Utilization </li></ul></ul><ul><li>Implemented using SDK’s </li></ul><ul><ul><li>Exchange protocol messages with appropriate services to perform desired actions </li></ul></ul><ul><li>Utilize </li></ul><ul><ul><li>Frameworks </li></ul></ul><ul><ul><li>Libraries </li></ul></ul>= Φ (well-defined protocols)
  114. 114. Applications Collective API’s & SDK’s Collective Services Connectivity API’s Resource API’s & SDK’s Resource Services Fabric Key API/SDK Service Collective Service Protocols Resource Service Protocols Connectivity Protocols Language & Framework Applications
  115. 115. Bilateral Relationships
  116. 116. Multilateral Relationships Grid
  117. 117. Grid Architecture Services Storage systems, computers, networks, code repositories, catalogs Fabric Communications, service discovery, authentication, authorization, discovery Connectivity Access to computation, access to data, access to information about system structure, state, performance Resource Resource discovery, resource brokering, system monitoring, community authorization, certificate revocation Collective (generic) Check-pointing, job management, failover, staging Solver coupler, distributed data archiver Collective (application-specific) Application 2 Application 1
  118. 118. An e-Business Process Flow Purchase Order/Order Entry Between Customer and Supplier
  119. 119. In the beginning . . . Inventory Management Process Inventory Database Prepare Purchase Order Recognizes EOQ/JIT level Supplier Catalog Purchase Order Message sent for review/approval Review Purchase Order Purchase Order reviewed, approved, and submitted to supplier Security Check <ul><li>Authorized submitter </li></ul><ul><li>Authorized named personnel </li></ul><ul><li>Authorized supplier </li></ul>Header shows destination as reviewer Header shows destination as supplier To Supplier Purchase Order DB Purchase Order Message Purchase Order Message Firewall Destination Delivery Mode Message ID Timestamp Correlation ID Reply To Redelivered Type Expiration Priority
  120. 120. Next, . . . From Purchaser Security Check <ul><li>Authorized submitter </li></ul><ul><li>Authorized named personnel </li></ul><ul><li>Authorized trading partner </li></ul><ul><li>Authorized recipient </li></ul>Order Entry System Inventory Database Manufacture Database Purchase Order System Fulfillment System If in inventory, message Sent to fulfillment system Manufacturing System Inventory Database Manufacturing Message Purchase Order Message If not in inventory, message Sent to manufacturing system Manufacturing system uses data in inventory and manufacturing databases If raw materials required, purchase order message is sent When order has been completed, a message is sent to the fulfillment system Order Receipt Message Acknowledgement message sent Purchase Order Message Purchase order is admitted through firewall and passed to order entry system Orders Database Firewall Fulfillment Message Fulfillment Message
  121. 121. Continuing, . . . Security Check <ul><li>Authorized submitter </li></ul><ul><li>Authorized named personnel </li></ul><ul><li>Authorized trading partner </li></ul><ul><li>Authorized recipient </li></ul>Security Check <ul><li>Authorized submitter </li></ul><ul><li>Authorized named personnel </li></ul><ul><li>Authorized supplier </li></ul>Purchase Order Management Message is transmitted Validated message sent to Purchase Order Management System Purchase Order DB Messages sent to named stakeholders Firewall Order Receipt Message Firewall Order Receipt Message Stakeholder Status Message
  122. 122. Meanwhile, . . . Fulfillment System Shipping System Billing System Inventory System Inventory Database Fulfillment System sends messages to Shipping and Billing Systems Billing System prepares and sends bill Billing System prepares and sends bill Fulfillment System Shipping System Billing System Inventory System Inventory Database Fulfillment System sends messages to Shipping and Billing Systems Billing System prepares and sends bill Security Check <ul><li>Authorized submitter </li></ul><ul><li>Authorized named personnel </li></ul><ul><li>Authorized trading partner </li></ul><ul><li>Authorized recipient </li></ul>Billing Database To Purchaser Fulfillment Message Fulfillment Message Billing Message Fulfillment Message Firewall Fulfillment Message Shipping Notice Message Fulfillment Message Fulfillment Message Billing Message Fulfillment Message Fulfillment Message Shipping Notice Message
  123. 123. And, . . . Security Check Accounts Payable Electronic Payment General Ledger DB Purchase Order DB Receiving System Purchase Order DB Billing message is sent to Accounts Payable <ul><li>Authorized submitter </li></ul><ul><li>Authorized named personnel </li></ul><ul><li>Authorized supplier </li></ul><ul><li>Authorized submitter </li></ul><ul><li>Authorized named personnel </li></ul><ul><li>Authorized supplier </li></ul>Security Check Shipping Notice message is sent to Accounts Payable Receipt message is sent to Accounts Payable Electronic Payment is sent to supplier From Supplier To Supplier Firewall Billing Message Shipping Notice Message Firewall Receipt Message
  124. 124. Finally Security Check <ul><li>Authorized submitter </li></ul><ul><li>Authorized named personnel </li></ul><ul><li>Authorized supplier </li></ul>Electronic Payment Payments Payment Processing General Ledger Orders Database Billing Database Payment is processed From Purchaser Firewall
  125. 125. Considering the State of the Practice <ul><li>Service-Oriented Enterprise </li></ul><ul><li>Integration Landscape </li></ul><ul><li>Open Source Integration Considerations </li></ul><ul><li>Mobility </li></ul>
  126. 126. Service-Oriented Enterprise (SOE) <ul><li>Architectural strategy to improve the integration of processes and data within an operational enterprise </li></ul><ul><ul><li>Enterprise definition separate and distinct from the set of systems that comprise it (the enterprise) </li></ul></ul><ul><ul><li>Enterprise is not a single, massively large system </li></ul></ul><ul><ul><li>Optimized enterprise integration strategy is not (necessarily) congruent with a “system of systems” strategy </li></ul></ul><ul><li>Objective – service excellence for users and/or customers </li></ul><ul><li>Operational enterprise – the set of individual organizations that collaborate to conduct business </li></ul>
  127. 127. Structural Elements of SOE <ul><li>Smart Data </li></ul><ul><li>Smart Grid </li></ul><ul><li>Smart Services </li></ul>
  128. 128. Structural Elements of SOE – Smart Data <ul><li>Data equipped with semantic content using metadata </li></ul><ul><ul><li>Characterization </li></ul></ul><ul><ul><li>Model-based representation via defined process </li></ul></ul><ul><li>Smartness – measurable quantity </li></ul><ul><ul><li>Rigor </li></ul></ul><ul><ul><li>Precision </li></ul></ul><ul><ul><li>Accuracy </li></ul></ul><ul><ul><li>Structure </li></ul></ul><ul><ul><li>Abstraction </li></ul></ul>
  129. 129. Structural Elements of SOE – Smart Grid <ul><li>Interface-driven interconnection across the enterprise </li></ul><ul><ul><li>Physical structure </li></ul></ul><ul><ul><li>Protocol routines </li></ul></ul><ul><li>Corresponds to SOA implemented using shared-language paradigms </li></ul><ul><ul><li>Technology-neutral </li></ul></ul><ul><ul><li>Defined independently </li></ul></ul><ul><li>Smart grid characteristics </li></ul><ul><ul><li>Shared interconnection network architectures; common entry and messaging methods </li></ul></ul><ul><ul><li>Message management capability to insure reliable data delivery and appropriate statusing (success and failure) </li></ul></ul><ul><ul><li>Information assurance controls to prevent corruption of enterprise communication process </li></ul></ul><ul><ul><ul><li>Intentional </li></ul></ul></ul><ul><ul><ul><li>Unintentional </li></ul></ul></ul><ul><ul><li>Adequate resources to support interconnectivity requirements </li></ul></ul>
  130. 130. Structural Elements of SOE – Smart Services <ul><li>Synonymous with semantic services </li></ul><ul><ul><li>Shared resources </li></ul></ul><ul><ul><li>Configured as Web Services </li></ul></ul><ul><ul><li>Assets available to the enterprise regardless of physical ownership </li></ul></ul><ul><li>Enterprise Global Repository </li></ul><ul><ul><li>Structured resource that provides access to </li></ul></ul><ul><ul><ul><li>Metadata </li></ul></ul></ul><ul><ul><ul><li>Process and data models </li></ul></ul></ul><ul><ul><ul><li>Metamodels </li></ul></ul></ul><ul><ul><ul><li>Process and data constructs </li></ul></ul></ul><ul><ul><li>Build-time resource </li></ul></ul><ul><ul><ul><li>Supports integrate-ability </li></ul></ul></ul><ul><ul><li>Run-time resource </li></ul></ul><ul><ul><ul><li>Supports active data translations across systems </li></ul></ul></ul>
  131. 131. SOE Disciplines <ul><li>Data Engineering – developing and documenting semantic content for enterprise data throughout the enterprise lifecycle </li></ul><ul><li>Grid Engineering – developing and evolving the smart grid architecture </li></ul><ul><ul><li>Selection of integration tools, processes and standard protocols </li></ul></ul><ul><ul><li>Establishes rules of engagement for application and system participation </li></ul></ul><ul><ul><li>Prescribes methods for integrating legacy systems and applications </li></ul></ul><ul><li>Process Engineering – designing and documenting enterprise processes </li></ul><ul><ul><li>Enables process improvement </li></ul></ul><ul><ul><li>Develops rules for process interaction and associated enforcement </li></ul></ul><ul><ul><ul><li>Includes associated elements of data </li></ul></ul></ul>
  132. 132. Enterprise Engineering Data Engineering Unmanaged, ad hoc Formalized Information Modeling Systematic Data Definitions Metadata-driven information integration Grid Engineering Unmanaged, ad hoc Encapsulation/object oriented Capture of Business Intelligence Externalization of Business Intelligence Unmanaged, ad hoc Business Rule Standardization Process Modeling Outcome-driven processes Process Engineering
  133. 133. Integration Platforms - SOA <ul><li>Integration Requirements </li></ul><ul><ul><li>Composite applications </li></ul></ul><ul><ul><li>Real-time business intelligence and analysis </li></ul></ul><ul><ul><li>Internal collaboration </li></ul></ul><ul><ul><li>External collaboration </li></ul></ul><ul><li>SOA Provides </li></ul><ul><ul><li>Message bus and application integration as core features </li></ul></ul><ul><ul><li>Integrated process management capability </li></ul></ul><ul><ul><li>Presentation and other interaction features </li></ul></ul><ul><ul><li>Industry protocols and collaboration formats </li></ul></ul><ul><ul><li>Life-cycle management facilities </li></ul></ul>
  134. 134. Integration Platforms - SOA <ul><li>Available from vendors by class </li></ul><ul><ul><li>Application </li></ul></ul><ul><ul><li>Enterprise application </li></ul></ul><ul><ul><li>Independent integration </li></ul></ul><ul><ul><li>Data integration </li></ul></ul><ul><li>Key factors for determining the most appropriate platform </li></ul><ul><ul><li>Separate application integration from data integration </li></ul></ul><ul><ul><li>Consider the context – application, enterprise, or data </li></ul></ul><ul><ul><li>Align architecture at the optimum level – product, vendor, standards, technology </li></ul></ul><ul><ul><li>Level of convergence </li></ul></ul>
  135. 135. Open Source Integration <ul><li>Alternative way of building an infrastructure using best-of breed components </li></ul><ul><li>Complexity factors </li></ul><ul><ul><li>Global sourcing </li></ul></ul><ul><ul><li>Independent release schedules </li></ul></ul><ul><ul><li>Frequent release schedules </li></ul></ul><ul><li>Benefits </li></ul><ul><ul><li>Reduced cost and effort for installation and configuration </li></ul></ul><ul><ul><li>Increased confidence in reliability and stability </li></ul></ul><ul><ul><li>Improved ability to troubleshoot applications </li></ul></ul><ul><ul><li>Easier infrastructure management </li></ul></ul><ul><ul><li>Infinite combination of components </li></ul></ul><ul><ul><li>Multiple component use </li></ul></ul><ul><ul><li>Different service models </li></ul></ul><ul><ul><li>Enhanced value add </li></ul></ul>
  136. 136. Open Source Integration <ul><li>Key elements for success </li></ul><ul><ul><li>Common management tools </li></ul></ul><ul><ul><li>Common security model </li></ul></ul><ul><ul><li>Consistent and coordinated maintenance </li></ul></ul><ul><ul><li>Component compatibility </li></ul></ul><ul><ul><li>Consistent licensing model for utilized components </li></ul></ul>
  137. 137. Mobility <ul><li>Ability of an individual to work anywhere at any time utilizing all of the features and capabilities of the system environment </li></ul><ul><li>Includes </li></ul><ul><ul><li>Computing </li></ul></ul><ul><ul><li>Communications </li></ul></ul><ul><li>Benefits </li></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><li>Productivity </li></ul></ul><ul><ul><li>Cost savings </li></ul></ul><ul><ul><li>Cost avoidance </li></ul></ul>
  138. 138. Historic Mobility <ul><li>Linked to </li></ul><ul><ul><li>Portable computing </li></ul></ul><ul><ul><li>Wireless telephony </li></ul></ul><ul><li>Based upon “fixed port” accessing </li></ul><ul><ul><li>Required physical connectivity </li></ul></ul>
  139. 139. New Mobility <ul><li>Outgrowths of wired technology </li></ul><ul><li>Transcends enterprise network perimeter </li></ul><ul><ul><li>Wherever the user needs information </li></ul></ul><ul><ul><li>Voice and data </li></ul></ul><ul><li>Key benefits </li></ul><ul><ul><li>Freedom of access to information </li></ul></ul><ul><ul><li>Identity-based security </li></ul></ul><ul><ul><li>Network economics </li></ul></ul>
  140. 140. Capabilities for New Mobility <ul><li>Identity-based security to protect both network and user </li></ul><ul><li>Non-disruptive integration into existing networks </li></ul><ul><li>Secure convergence for mobile VoIP and data services </li></ul><ul><li>Adaptive radio management for self-configuring WLANs </li></ul><ul><li>Remote extensions for instant enterprise hot spots </li></ul><ul><li>Enterprise-grade scalability, reliability, and performance </li></ul><ul><li>Open mobility platform for application development and integration </li></ul>
  141. 141. Problem Scenario <ul><li>Purchasing Collaborative As the result of a professional society survey initiative, a number of enterprises in some particular industry determine that they purchase similar items from a common set of suppliers. Upon reviewing the supplier’s terms and conditions, a cost saving benefit is recognized if the several industry enterprises can engage in a common procurement activity. From the enterprise perspective, there would be common pricing based on shared catalogs price with advantages for larger orders. From the supplier perspective, there would be fewer purchase orders to handle, thereby reducing labor-intensive activities and associated operating costs. Initial discussions with the supplier community are encouraging; the problem is that every participant has an individual information processing environment that offers minimal commonality. </li></ul><ul><li>Could this problem be solved using traditional computing methods? </li></ul><ul><li>What solution possibilities are offered by grid computing? SOE? Mobility? </li></ul><ul><li>Develop a schematic that illustrates a solution proposal. </li></ul>