From Middleware to Service-Oriented Architecture (SOA)

Transcription

1 From Middleware to Service-Oriented Architecture (SOA) 莊 裕 澤 Dept. of Information Management National Taiwan University Mar, /3/6 Middleware and SOA 1

2 Communication Paradigms Message-passing: usually for computer networks. Communication primitives-- send and receive Synchronization: Synchronous (blocking): sender waits until the receiver has received the message. Asynchronous (non-blocking): sender does not wait Communication patterns: Remote procedure call (RPC) Multicast Broadcast Shared memory: usually for tightly-coupled system such as parallel machines. Communication primitives-- read and write /3/6 Middleware and SOA 2

3 Interprocess Communications Message destination in the Internet protocols, messages are sent to (Internet address, local port) Each computer typically has 2 16 possible ports for local processes, where are reserved for system use the Internet transport-level protocols UDP and TCP use an abstract communication channel called socket for endpoint communication between processes /3/6 Middleware and SOA 3

4 UNIX IPC (Interprocess Communication) Interprocess communication consists of an exchange of some information by transmitting it in a message between a socket in one process and a socket in another process. socket message agreed port socket client other ports server Node 1 Conceptually, a socket is a pipe; Node 2 objects flow through the pipe. /3/6 Middleware and SOA 4

5 Unix Sockets A socket must be created before it can be used. Before a socket can be used it must have an address bound to it. A socket lasts until it is closed, or every process with the socket descriptor exits.to initiate a connection, a client (the process that initiates a connection) calls error_code = connect (socket, serveraddr, serveraddr_len) The server (the process that receives or responds to a connection) first calls the following procedure to prepare connections error_code = listen (socket, backlog) Connections are then received, one at a time, by the following call new_socket = accept (socket, clientaddr, clientaddr_len) /3/6 Middleware and SOA 5

6 Unix Sockets (cont.) A variety of calls are available for sending and receiving data, including read, write, send, recv, sendto, recvfrom, sendmsg, and recvmsg. In connectionless communication, the connect, listen, and accept procedures are not necessary. /3/6 Middleware and SOA 6

7 To summarize In the client-server model, sockets require the client and server to engage in applications-level protocols to encode and decode messages for exchange, and the design of such protocols is cumbersome and can be error-prone. /3/6 Middleware and SOA 7

8 Procedure Calls Procedure calls are a more natural way to communicate Every language supports them Semantics are well-defined and understood Natural for programmers to use Branch_A.balance(account_no) ; /3/6 Middleware and SOA 8

9 Remote Procedure Calls A remote procedure call makes a call to a remote service look like a local call RPC makes transparent whether server is local or remote RPC allows applications to become distributed transparently RPC makes architecture of remote machine transparent Most common means for remote communication Network File System (NFS) is implemented as a set of RPCs DCOM, CORBA, Java RMI, etc., are all basically just RPC Client Server dooperation : (wait) : (continuation) Request message Reply message getrequest select object execute method sendreply /3/6 Middleware and SOA 9

10 How to Implement RPC? Have servers exported a set of procedures that can be called by client programs Similar to module interfaces, class definitions, etc. Clients just do a procedure call as if they were directly linked with the server Under the covers, the procedure call is converted into a message exchange with the server /3/6 Middleware and SOA 10

11 Lots of issues How do we make this invisible to the programmer? What are the semantics of parameter passing? How do we bind (locate, connect to) servers? How do we support heterogeneity (OS, arch, language)? How do we make it perform well? /3/6 Middleware and SOA 11

12 RPC Model A server defines the server s interface using an interface definition language (IDL) The IDL specifies the names, parameters, and types for all client-callable server procedures A stub compiler reads the IDL and produces two stub procedures for each server procedure (client and server) The server programmer implements the server procedures and links them with the server-side stubs The client programmer implements the client program and links it with the client-side stubs The stubs are responsible for managing all details of the remote communication between client and server /3/6 Middleware and SOA 12

13 RPC Stubs Stubs act as proxies for the client and the servers A client-side stub is a procedure that looks to the client as if it were a callable server procedure A server-side stub (sometimes called skeleton) looks to the server as if a client called it The client program thinks it is calling the server In fact, it s calling the client stub The server program thinks it is called by the client In fact, it s called by the server stub The stubs send messages to each other to make the RPC happen transparently Client process Server process /3/6 Middleware and SOA 13 object program Client stub request reply Communication module server stub Server procedure

14 View in Layers Client Server Stub Skeleton Remote Reference Layer Transport Layer Layer 1 is the Application Layer Layer 2 is the client stub/skeleton layer. These are the proxy objects these are produced by the stub compiler Layer 3 is the remote reference that deals with the the actual remote invocations Layer 4 is the transport layer responsible for actually setting up the connections and handling the transport of data between machines /3/6 Middleware and SOA 14

15 Marshal/Unmarshal Marshalling is the packing of procedure parameters into a message packet The RPC stubs call type-specific procedures to marshal (or unmarshal) the parameters to a call The client stub marshals the parameters into a message The server stub unmarshals parameters from the message and uses them to call the server procedure On return The server stub marshals the return parameters The client stub unmarshals return parameters and returns them to the client program Client Client Stub Stub Skeleton Skeleton Server Server Method Method Invocation Invocation Marshalled Parameters and Return Values Method Method Invocation Invocation /3/6 Middleware and SOA 15

16 RPC Binding Binding is the process of connecting the client to the server The server, when it starts up, exports its interface Identifies itself to a network name server Tells RPC runtime its alive and ready to accept calls The client, before issuing any calls, imports the server RPC runtime uses the name server to find the location of a server and establish a connection The import and export operations are explicit in the server and client programs Breakdown of transparency /3/6 Middleware and SOA 16

17 To summarize Compiler generates from API stubs for a procedure on the client and server Client stub Server stub Marshals arguments into machine-independent format Sends request to server Waits for response Unmarshals result and returns to caller Unmarshals arguments and builds stack frame Calls procedure Server stub marshalls results and sends reply /3/6 Middleware and SOA 17

18 Middleware Software that allows applications to operate over one or more machines (possibly running different OS) to interact across a network. Applications, Services Middleware OS: kernel, libraries & servers OS1 Processes, threads, communication,... OS1 Processes, threads, communication,... Platform Computer & network hardware Computer & network hardware Node 1 Node 2 /3/6 Middleware and SOA 18

19 Why Middleware? Distributed applications Enterprise Application Integration (EAI) the process of linking applications within an organization together to simplify and automate business processes to the greatest extent possible, while avoiding having to make sweeping changes to the existing applications or data structures. /3/6 Middleware and SOA 19

20 Types of Middleware Remote Procedure Call (RPC) Message Oriented Middleware (MOM) Object Request Broker (ORB) /3/6 Middleware and SOA 20

21 Message Oriented Middleware (MOM) Software that connects separate systems in a network by carrying and distributing messages between them. Messages may contain data, software instructions, or both. Support autonomous publish-subscribe messaging. Typically built around a queuing system that stores messages pending delivery, and keeps track of whether and when each message has been delivered. Similar term: Enterprise Service Bus Proprietary technologies: IBM MQSeries Microsoft Message Queuing (MSMQ) TIBCO Rendezvous Emerging standards Java Message Service (JMS) OASIS Web Services Reliable Messaging (WSRM) TC /3/6 Middleware and SOA 21

22 Object Request Broker (ORB) Incorporate Object-Oriented (OO) programming into the design of middleware. Three major technologies CORBA DCOM Java RMI ORB locate service establish communication activate service Client Application communication Remote Service (Object) /3/6 Middleware and SOA 22

23 What is an Object? Collection of data items usually called attributes or slots Collection of behavioral attachments usually called methods Features: Inheritance (reusability) Data Encapsulation/Abstraction Polymorphism Account_no Name Balance Get_info( ) deposit( ) withdraw( ) /3/6 Middleware and SOA 23

24 Why Objected-Oriented? inheritance encapsulation modularity polymorphism /3/6 Middleware and SOA 24

25 Distributed Objects The object-based programming model is extended to allow objects in different processes to interact with one another. Client/Server Object References Interfaces Remote Method Invocation Exceptions A B C local invocation local invocation local invocation D E remote invocation F /3/6 Middleware and SOA 25

26 A Dealing Room System Dealer s computer External source Dealer s computer Dealer Notification Notification Dealer Notification Information provider Notification Dealer s computer Dealer Notification Notification Notification Information provider External source Notification Dealer s computer Notification Notification Dealer Source: G. Coulouris et al., Distributed Systems: Concepts and Design /3/6 Middleware and SOA 26

27 CORBA (Common Object Request Broker Architecture) A non-proprietary standard defined by the Object Management Group (OMG) to free the object programmer and user from the intricacies of network programming. What is distributed computing all about in CORBA Viewing everything as an object applications are implemented by request for services of distributed objects. Goal is to break up a monolithic application into smaller clientserver-based components Client Request Response Server /3/6 Middleware and SOA 27

28 CORBA (cont.) CORBA glues together different objects models regardless of implementation language In order to do so it uses a common Interface Definition Language (IDL) that needs to be compiled separately for every language for which there is a binding The fundamental idea behind CORBA is an Object Request Broker (ORB). An ORB receives invocations from a client and delivers them to a target object, putting network complexity behind the scene. C++ IDL Client Java IDL Server ORB /3/6 Middleware and SOA 28

29 CORBA Object Interfaces The notion of interacting objects is central to CORBA. Each object has an interface defined in IDL. Each interface defines the operations that can be called by clients. An interface defined in IDL can be mapped to a definition in programming languages such as C++ and Java. An interface can be implemented in one language and then called from any other. IDL includes features such as inheritance of interfaces, exceptions, and basic and compound data types. CORBA IDL is a simple subset of C++ /3/6 Middleware and SOA 29

30 Role of IDL Separate Interface From Implementation Client Side C Object Implementation Side COBOL C++ I D L I D L C COBOL Ada I D L I D L Small talk I D L I D L I D L JAVA ORB I D L I D L ORB I D L I D L I D L C++ JAVA Ada Small talk /3/6 Middleware and SOA 30

31 CORBA Programming Steps Steps typically required to write a distributed clientserver system in CORBA and C++: Define the interfaces, using the standard IDL. Implement these interfaces with C++ classes. Write a server main function which creates instances of these classes, and then inform the underlying CORBA implementation. Register the server. Write a client main function to connect to the server and to use the server's objects. /3/6 Middleware and SOA 31

32 How the IDL is Used Client Code Stub Code IDL Compiler IDL Object Implementation Code Skeleton Code Language Compiler and Linker Client Stub Object Skeleton ORB /3/6 Middleware and SOA 32

33 The CORBA Architecture interface repository Implementation repository client server client program proxy for A ORB core Request Reply ORB core object adapter skeleton Servant A or dynamic invocation or dynamic skeleton /3/6 Middleware and SOA 33

34 CORBA Architecture: within the same site Client IDL Stub Object implementation IDL Skeleton Request Object Request Broker /3/6 Middleware and SOA 34

35 CORBA Architecture: across the net Client Object Client Object Stub Skel Stub Skel ORB1 IIOP Protocol ORB1 Each ORB must be able to communicate with all others, using a protocol known as the Internet Inter-ORB Protocol (IIOP). IIOP uses a message format called GIOP (General Inter-ORB Protocol), which can be layered on TCP/IP as well as other transport protocols. /3/6 Middleware and SOA 35

36 The CORBA Architecture (another view) IDL Compiler Client Object Implementation Dynamic Invocation Interface Client Stubs ORB Interface IDL Skeletons ORB Interface ORB IDL Compiler Interface Repository Implementation Repository /3/6 Middleware and SOA 36

37 Java RMI RMI (Remote Method Invocation) provides distributed computing ability on the specific system(jvm) for the specific language (Java) CORBA, RPC System Heterogeneity Language Heterogeneity RMI based on homogeneity and strength it Language Integration -- distributed object model similar interface, preserve some behavior exception: report errors in the computation System Integration mobile behavior security /3/6 Middleware and SOA 37

38 Remote Interfaces, Objects and Methods A distributed application built using Java RMI is made up of interfaces and classes An object becomes remote by implementing a remote interface, which has the following characteristics A remote interface extends the interface java.rmi.remote. Each method of the interface declares java.rmi.remoteexception in its throws clause, in addition to any application-specific exceptions. /3/6 Middleware and SOA 38

39 RMI System Architecture Application Client Server RMI System Stubs Skeleton Remote Reference layer Transport /3/6 Middleware and SOA 39

40 Comparison of Java RMI and CORBA RMI is Java to Java based JNI (Java Native Interface) allows Java to other languages: Java code running in the Java virtual machine (JVM) can call and be called by native applications and libraries written in other languages, such as C, C++ and assembly. No mapping of objects no IDL RMI deals only with byte code No complicated request broker - just a simple registry Makes a distinction for a remote object -allows errors to be handled /3/6 Middleware and SOA 40

41 RMI Distributed Object Applications Locate remote objects Applications can use one of two mechanisms to obtain references to remote objects. An application can register its remote objects with the rmiregistry - RMI's simple naming facility An application can pass and return remote object references as part of its normal operation Communicate with remote objects Details of communication between remote objects are handled by RMI From the perspective of the programmer it s as if the objects are local There is some overhead that makes it slower but the communication looks like a standard Java method invocation Load class bytecodes for objects that are passed around The types and the behavior of an object, previously available only in a single virtual machine can be transmitted to another, possibly remote, virtual machine. /3/6 Middleware and SOA 41

42 Using RMI General Steps Design and implement the components of your distributed application. Defining the remote interfaces Implementing the remote objects Implementing the clients Compile sources and generate stubs and skeletons Make classes network accessible In this step you make everything--the class files associated with the remote interfaces, stubs, and other classes that need to be downloaded to clients--accessible via a Web server Starting the application includes running the RMI remote object registry, the server, and the client. Start the application. /3/6 Middleware and SOA 42

43 MICROSOFT COM COM (Component Object Model). Its distributed version is referred to as DCOM. It is a programming model for binary components reuse and a foundation of OLE (Object Linking and Embedding) and ActiveX controls. COM interfaces are defined in the interface definition language IDL and compiled by MIDL.EXE. /3/6 Middleware and SOA 43

44 The COM Programming Model A scalable programming model In the same process Fast, direct function calls Client Component On the same machine Fast, secure IPC Client Process Server Process Client COM Component Across machines Client Machine Server Machine Secure, reliable and flexible DCE-RPC based DCOM protocol Client COM DCE RPC COM Component /3/6 Middleware and SOA 44

45 DCOM Architecture Flexible and extensible Pluggable Transports Client Machine Server Machine Clients D C O M TCP, UDP IPX, SPX HTTP Msg-Q D C O M COM Object /3/6 Middleware and SOA 45

46 DCOM Architecture Flexible and extensible Pluggable Security Client Machine Server Machine Clients D C O M TCP, UDP NT4 Security SSL/ Certificates IPX, SPX NT Kerberos HTTP DCE Security Falcon D C O M COM Object /3/6 Middleware and SOA 46

47 Comparison: CORBA, RMI, DCOM Stability COM/DCOM has large market presence, installed software base, Microsoft OS support CORBA has large industry consortium backing, many commercial and freeware products, many programming language bindings RMI is new and language-specific, and generally less efficient RPC is commonly available in Unix (other OS?) portability/ market penetration CORBA first (many programming languages, platforms), COM/DCOM second (installed NT base), RMI third (for brokering), RPC is superfluous /3/6 Middleware and SOA 47

48 Enterprise Application Integration (EAI) /3/6 Middleware and SOA 48

49 Application Services Nightmare Partners Customers Internal Users Suppliers /3/6 Middleware and SOA 49

50 Enterprise Application Integration (EAI) Partners Customers Internal Users Suppliers Enterprise Application Integration Environment Conceptually, EAI is simply a middleware! /3/6 Middleware and SOA 50 back to why Middleware

51 An Example: Banking 交 易 處 理 系 統 異 質 性 平 台 通 路 EAI mainframe 分 行 末 端 系 統 自 動 化 服 務 系 統 (ATM/Kiosk) 語 音 銀 行 網 路 銀 行 行 動 銀 行 adapter Data Data Transforming Transforming Message Message Process Process Dispatching Dispatching Modeling Modeling adapter adapter Open system Other legacy system 管 理 系 統 異 質 性 平 台 CRM EIS DS DW /3/6 Middleware and SOA 51

52 Another Example EAI bridges the gap between front-end applications and back-end systems and data stores within a single company. Web Server Personalization Server Database ERP System Order Processing System Wireless Server EAI Middleware Mainframes Database Field Service Application Call Center Application HR System Financial System /3/6 Middleware and SOA 52

53 EAI Category Platform integration Data integration Component integration Application integration Process integration Business-to-business (B2B) /3/6 Middleware and SOA 53

54 From EAI to B2B Needs to leverage standards or trading partner agreements to ensure data exchanged is usable Substantial overlap between EAI and B2B functionality EAI Process Automation Flow Management Transformation Routing & Rules Messaging Security Services Metadata Management Adapters/Connectors Data Externalization E-Collaboration Community Management Partner/Profile Mgmt. Standards Mgmt. (e.g., XML) B2B Process Mgmt. B2B /3/6 Middleware and SOA 54

55 High-level EAI-to-B2B Architecture B2B using XML can serve to link disparate standards among trading partners, including distinct data formats resulting from EAI implementations, and to make internally integrated data available for external exchange or collaboration. Company A Company B System 1 System 2 System 1 EAI Translate EAI System 3 Route System 2 Exchange Site Rules Company C System 2 System 1 System 1 EAI System 3 /3/6 Middleware and SOA 55

56 Leading Companies in EAI IBM Webspher Business Integrator MQSeries Integrators (MQSI) TIBCO TIBCO BusinessWork TIBCO Active Portal BEA BEA WebLogic Integration /3/6 Middleware and SOA 56

57 Example: IBM MQSeries Integrators /3/6 Middleware and SOA 57

58 Service-Oriented Architecture (SOA) /3/6 Middleware and SOA 58

59 Service-Oriented Architecture (SOA) Not a well-defined term, mostly for marketing purposes. An architecture that relies on service-orientation as its fundamental design principle services with defined interfaces can be called a standard way services are loosely coupled the service does not need foreknowledge of the calling application the application does not need to know how the service actually performs its tasks. why the trend goes to loosely coupled? loosely coupled requires interoperability. /3/6 Middleware and SOA 59

60 Architectural Style Rather Than Technology not tied to a specific technology may be implemented using DCOM, CORBA or Web Services The interface definition hides the implementation of the language-specific service. Services written in one platform (say.net) and services written in another (say, Java EE) can both be consumed by a common composite application. /3/6 Middleware and SOA 60

61 Still, Some Technology is Needed To achieve loose coupling among interacting software agents, we need A simple and ubiquitous interfaces A schema for describing messages delivered through the interfaces. /3/6 Middleware and SOA 61

62 Elements of SOA Enterprise SOA. Dirk Krafzig, et al. Prentice Hall, 2005 /3/6 Middleware and SOA 62

63 More on SOA Definitions Definition from OASIS A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. /3/6 Middleware and SOA 63

64 More on SOA Definitions (contd.) For marketing A design for linking business and computational resources (principally organizations, applications and data) on demand to achieve the desired results for service consumers (which can be end users or other services). Have you heard of on-demand computing? on-demand software/service? (or software on-demand)? /3/6 Middleware and SOA 64

65 Why SOA? Links computational resources and promotes their reuse thereby allowing businesses to respond more quickly and costeffectively to changing market conditions Promotes reuse at the macro (service) level rather than micro level (objects). Some Ads from IBM /3/6 Middleware and SOA 65

66 SOA Guiding Principles Reuse, granularity, modularity, composability, componentization, and interoperability Compliance to standards (both common and industryspecific) Services identification and categorization, provisioning and delivery, and monitoring and tracking /3/6 Middleware and SOA 66

67 Modeling and Design Methodology Service-Oriented Analysis and Design A design methodology for developing highly-agile systems in a consumer/producer model that abstracts implementation from process, such that a service-provider can be modified or changed without affecting the consumer. /3/6 Middleware and SOA 67

68 SOA and Web Services SOA = Web Services?? SOA may be built on Web services standards (e.g., SOAP) to provide greater interoperability and some protection from lock-in to proprietary vendor software. Think more carefully about the challenges of building an SOA across business partners and you will know the relation between SOA and Web Services! /3/6 Middleware and SOA 68

69 Some Slides from IBM /3/6 Middleware and SOA 69

70 The Time For SOA Is Now! Customers are saying it.. Nearly 70% of SOA users say they will increase their use of SOA 1 The analysts are saying it.. It is time to dispense with excuses and begin your move to SOA. 1 SOA impacts EVERY aspect of IT and business. Results across IBM and Business Partners PROVE it 2006 Software: Revenue up, WebSphere +22% and Wall Street is noticing! SOA demand [is] the bright spot driving reacceleration in IBM s core middleware growth. 3 /3/6 Middleware and SOA 70

71 What is..? a service? A repeatable business task e.g., check customer credit; open new account service orientation? A way of integrating your business as linked services and the outcomes that they bring service oriented architecture (SOA)? An IT architectural style that supports service orientation a composite application? A set of related & integrated services that support a business process built on an SOA /3/6 Middleware and SOA 71

72 What are the barriers to business flexibility and reuse? Lack of business process standards Architectural policy limited Point application buys to support redundant LOB needs Infrastructure built with no roadmap /3/6 Middleware and SOA 72

73 SOA builds flexibility on your current investments The next stage of integration Service Orientated Integration Enterprise Application Integration (EAI) Messaging Backbone Point-to-Point connection between applications Simple, basic connectivity EAI connects applications via a centralized hub Easier to manage larger number of connections Flexibility Integration and choreography of services through an Enterprise Service Bus Flexible connections with well defined, standards-based interfaces As Patterns Have Evolved, So Has IBM /3/6 Middleware and SOA 73

74 What differentiates SOA from claims like this in the past? Standards Broadly adopted Web services ensure welldefined interfaces. Before, proprietary standards limited interoperability Organizational Commitment Business and IT are united behind SOA (63% of projects today are driven by LOB)* Before, communication channels & vocabulary not in place Degree of Focus SOA services focus on business-level activities & interactions Before, focus was on narrow, technical sub-tasks Connections SOA services are linked dynamically and flexibly Before, service interactions were hard-coded and dependent on the application Level of Reuse SOA services can be extensively re-used to leverage existing IT assets Before, any reuse was within silo ed applications /3/6 Middleware and SOA 74 *Source: Cutter Benchmark Survey

75 SOA is a Response to Business At the end of the day its about IT How do we increase the flexibility of my business processes, strengthen my underlying IT infrastructure, and retain and reuse my existing assets? /3/6 Middleware and SOA 75

76 SOA Fundamentals: Part of a broader portfolio to meet your every need WebSphere Integration Developer* Rational Application Developer* Process: WebSphere Process Server* WebSphere ESB* & Message Broker* WebSphere Partner Gateway & Adapters People: WebSphere Portal* WebSphere Everyplace Deployment* Workplace Collaboration Services* Information: WebSphere Information Integrator* Application Infrastructure: WebSphere Application Server & XD* WebSphere Business Modeler* Rational Software Architect* WebSphere Business Monitor* Tivoli Composite Application Manager* Tivoli Identity & Access Manager * New or Enhanced /3/6 Middleware and SOA 76

77 Services Oriented Architecture steps CBM Strategy SOMA Modeling SOA Realization Step 1: Break down your business into components Component Business Modeling Decide what is strategically important, and what is just operations in the value chain domains Analyze the different KPIs attached to these components Prioritize and scope your transformation projects Step 2: Define a Service Model Service Oriented Model and Architecture Identify your business services based on your business components Identify your business processes Specify the services, processes and components accordingly Make SOA realization decisions based on architectural decisions Step 3: Implement a Service Model Develop a service-oriented architecture to support the Componentized Business Implement service based scoping policy for projects Implement appropriate governance mechanism /3/6 Middleware and SOA 77 Business-Aligned IT Architecture

78 Service-Oriented Modeling and Architecture Service-Oriented Modeling and Architecture (SOMA) provides in-depth guidance on how to move from business models to the models required by SOA. Develop New Markets and Products Acquire and Manage Customers Develop and Provide Network Services Manage Enterprise Marketing New Product Development Sales Customer Management and Care Billing and Collections Provisioning & Fulfillment Service Assurance Network Resource Development Business Management Planning and Analysis Market and Brand Strategy Product Portfolio Planning Partner Product Dev. Strategy Sales Channel Strategy Alliance Strategy Customer Care Strategy Fulfillment and resource Planning Service Strategy and Readiness Planning Technology and Resource Strategy and Capacity Planning Strategic Enterprise Planning Supply IT Strategy Chain/Value Net Strategy Stakeholder Mgmt/ Legal and Regulatory Tactics Operate and execute (Direct, React and Control) Brand Management Product Development and Retirement Marketing Communicatio ns, Advertising and Promotion Service Development and Marketing Retirement Research and Analysis Customer Analytics and product matching Execute Campaigns an d market Launch Product fulfillment Sales, Billing & Channel, and Collections Alliance Management Customer Management Care Management Account Planning Loyalty and Retention Customer Interface Management Customer Contact Operations Sales Problem B&C Rating Customer Billing Sales Problem Handling and Supplier/ Resolution Partner Settlement and Billing Device and Supplier Order Management Order Handling Service Configuration, Activation and Disconnects Resource Provisioning Service Management Customer SLA / QoS Management Supplier/ Partner Problem Reporting & Management Service Problem Management Network Resource Performance Management Supplier/ Partner Performance Management Enable resource provisioning (Engineering and Construction) Service Testing and performance management Inventory Management Financial and Asset Management HR Management Procurement Technology Management (IT, R&D, Disaster Recovery) Stakeholder and External Relations Management Services Services SOMA Services Services Services Services Services Services Services Services Services /3/6 Middleware and SOA 78

79 SOMA activities are grouped into three major steps Identification of candidate Services, Components, Flows Specification of Services, Components, Flows Realization Decisions What we do Identification Specification Realization How we do it The first major step of the SOMA identifies candidate services and enterprise components The second major step selects and specifies the services that will be exposed and enterprise components to realize them The third major step captures realization decisions Domain Decomposition component flow specification information specification Subsystem Analysis Component Specification Goal-Service Modeling Service Specification Service Realization Decisions service allocation to components component layering Existing System Analysis service flow specification message & event specification /3/6 Middleware and SOA 79

80 Business process management is key to your SOA Flexible business demands automating and optimizing business processes Identify and eliminate redundancies and bottlenecks Reduce risk by gaining an understanding of process impacts prior to operationalizing Automate process implementation, eliminating manual deployment tasks Immediately execute new business rules and processes Visualize actual process performance against key performance indicators Pinpoint future process improvements Without business process management, this would be achieved manually or through a dis-integrated set of tools from multiple vendors /3/6 Middleware and SOA 80

81 Discussions Question 1: The term on-demand has been used in business to refer to services that can promptly react to customers needs and deliver values to them. Give a short presentation about the how this term has been used and applied in business and in IT-related services. /3/6 Middleware and SOA 81

82 Discussions Question 2: We have seen in the class that IBM has put much effort in prompting the term SOA, and has a series of products for building SOA applications. Other heavy-weight software companies (e.g., SAP, Oracle, Microsoft, HP, Sun ) are also backing up the architecture and have their strategies/products for the solution. Give a brief presentation about this. /3/6 Middleware and SOA 82