Entmystifizieren von SOA, ESB, EDA …

Präsentation zum Thema: "Entmystifizieren von SOA, ESB, EDA …"—  Präsentation transkript:

1 Entmystifizieren von SOA, ESB, EDA …

2 IT Complexity & Cost IT Budgets (Source: Accenture et al.)

3 The Software Crisis (ca. 2004)
$250B/yr in US (average $430K to $2.3M per project) 16% on time and budget but deliver less than planned (avg 42%) 53% overrun (avg 189%) 31% are canceled, losing $140B/yr Mobile devices, digital media, smart appliances, B2B commerce Need to spend less time housekeeping and more time designing

4 SOA!

5 Der SOA Hype Mythos Realität
SO ist ein architekturelles Paradigma um verteilte Systeme zu realisieren SO ist evolutionär SO ist Mittel zum Zweck SO kann und sollte ein inkrementeller Prozess sein SOA ist eine Technologie SOA ist revolutionär SOA ist das Endziel SOA bearf einer Überholung von Technologie und Business Unfortunately, the benefits offered by service orientation and “service-oriented architecture” (SOA) have been obscured by the hype and confusion that increasingly surround the terms. As awareness and excitement around SOA have swelled, the clear lines that once defined service orientation have been blurred. Analyst groups publish hundreds of SOA-focused reports in response to client demand, with many reports providing conflicting definitions of SOA. Print and online publications targeting a wide range of roles from CXO to developer and IT professionals are filled with articles on SOA. And software vendors scramble to reposition software and service offerings in an attempt to take part in the SOA revolution. SOA is not a product/technology. You don’t buy an SOA in a box or as a service. SOA is an architectural principle expressed independently of technology. SO is evolutionary – like we saw in the last slide. It is a means to an end rather than the end goal itself. SO can and should be an incremental process – one that can often be done in-house. The only way you can use SOA for everything is to rename everything to ‘SOA’ Roy Schulte, Gartner

6 SOA definiert ein Prinzip
Wieder- und Mehrfachverwendung von Softwarekomponenten im Sinne von koppelbaren Services Service Ein Service ist Applikationslogik die Daten verarbeitet verbunden ist mit anderen Services und über Nachrichten kommuniziert

7 Die vier SO Prinzipien (Tenets)
Boundaries are Explicit Code an der Dienstgrenze ist explizit für diesen Zweck vorgesehen. Enthält keine Logik sondern delegiert an Logik. Das Überschreiten von Dienstgrenzen ist explizit im Code sichtbar. Services are autonomous Dienste kontrollieren und kapseln ihren internen Zustand. Sie können unabhängig von anderen versioniert und weiterentwickelt werden. Sie können eigenständig periodische Arbeiten verrichten. Share schema & contract, not class Dienste sind nie binär miteinander verknüpft. Dienste kommunizieren nie über implemen-tierungsspezifischen Datentypen an der Dienstkante Compatibility based on policy Anforderungen und Beschreibung von Leistungsmerkmalen werden separat von der Dienst- und Datenbeschreibung gehalten und ausgetauscht.

8 Topology Independence
It’s important to call out that, just as Service Orientation is independent of technology, it is also independent to service network topology. The two concepts are orthogonal to one another. Service oriented development can be applied across traditional centralized topologies, decentralized hub-and-spoke, or across highly distributed meshes of services. Again, service orientation is simply defined by the four tenets. Centralized Decentralized Distributed

9 Prozesse und „Business Capabilities“ in der Architektur
Flexibilität Process Model BPEL4WS Stabilität Capability Model Service Definition

10 ESB ?

11 The ESB Architecture ESB Client Software Installed on every node
Transport and repository ESB Client Software Installed on every node What is a Bus-based architecture? In short, the notion of a Bus is, they’re a set of nodes. Those nodes talk to each other through a Bus. For most of the vendors in this space, that Bus is, in fact, the network. Each one of these nodes has installed on it the vendor software. If I want to talk to the Bus, I need to, on each one of these nodes, install my vendor software. That increases some complexity and some pricing challenges, because, of course, I’m probably paying in each instance for each node that I install the software on. The Bus architecture is not the be-all and end-all of architectures. There are some high throughput, low latency scenarios that, for instance TIBCO uses in financial services, where the additional cost or expense of this architecture may make some sense. In many integration scenarios, being locked into a single vendor implementation and intrusively installing that software on each one of the nodes, is not really something that customers are looking for in this space. .NET Application J2EE Application Web Service Endpoint

12 Brokered and Unbrokered Communication
BizTalk Server First and foremost, as a customer on the Microsoft platform you have a choice. You can choose to do unbrokered communication. There is value in doing that, it’s certainly a very easy thing to do, and it becomes even easier through the Indigo API sets that will ship as part of the Longhorn wave (also with support on XP and 2003). We’ll drill into Indigo in more detail. You can think of Indigo, of course, as the unified programming APIs for distributed computing, as well as providing standard support through Web Services. For unbrokered communication, Indigo provides options. For brokered communications, the combination of BizTalk Server and Indigo provides the ability, as you can see, manage the interactions between these multiple application end points in a structured way, and take advantage of the latest generation of Web Services infrastructure.

13 Common ESB Characteristics
Brokered Communication. The basic function of an ESB is to send data between processes on the same or different computers. An ESB, like a MOM product, interposes a software intermediary between the sender and the receiver. Address indirection and intelligent routing. The notion of an intermediary is essential to the ability of an ESB to provide address indirection, rules-based routing, message transformation, etc. An ESB attempts to make clients relatively independent of (less coupled to) their respective servers, and its makes event sources very independent of their event sinks (event consumers). Basic Web services. ESBs typically support WSDL and SOAP, along with associated foundational standards such as TCP/IP and XML. Endpoint metadata. An ESB must have (or have access to) metadata that documents service interfaces and message schemas. The interesting thing here is, that same set of requirements is a subset of the requirements, as I was explaining before, that are delivered in integration servers, and have been through EAI for some period of time. There is not much new here. The new here is more on the SKUing, and the packaging, and the subsetting of the problem.

14 Typical Integration Requirements
The Enterprise Services Bus provides a brokered communication, decoupling and routing, end-point metadata and basic Web Services. Microsoft provides a broader solution. Some of the key requirements that customers have in the integration space that they’re looking for features from vendors from include, if I start on the bottom right-hand side, comprehensive management. Customers in the integration space are looking for the ability to comprehensively manage the interactions between multiple systems through end-to-end tracking, through deployment across multiple environments, through visibility into anything that goes wrong. You typically get a subset of that functionality through the ESB. Even more importantly than that, customers who are connecting multiple applications together with a broker are only taking advantage of a small percentage of their return on investment. Customers who have made the next step and are taking advantage of business process technology, mapping what the businesses asked for into software, which then will underneath it take advantage of brokered communication, routing, end-point metadata, and Web Services, get a lot more value here. Once you have business process in your enterprise, you can then really start adding value to the business through things like business rules. The notion of business rules means that you can define a rule no longer in code, but in a manner where the business person comes to you, the IT person, and says, I really need you to change the rules that we use for a mortgage application. Today the mortgage rates have changed, I need that immediately changed in terms of that set of complex rules inside software. In the past that’s been a very hard requirement to fulfill, takes a lot of time to fix. With business rules technology as part of integration, you can achieve that very rapidly. Finally, and this is really a key thing, and we’ll drill into this in more detail, what the business is often asking for, and never gets enough of is real visibility into their processes as they’re moving backwards and forwards. How long does it take for a procurement process? How long does it take for a manufacturing process? What are the sticking points that I need to optimize? Those things can make dramatic business impacts. What’s more, if you can deliver through integration visibility into those in real time, then the business is absolutely going to be looking to purchase more of this infrastructure and use this infrastructure. The key thing here is, Microsoft provides all of the ESB infrastructure requirements, and in addition, very important requirements in the integration space: business process, business rules, business activity monitoring, and comprehensive management.

15 Integration Leadership – April 2005
Challengers Leaders Niche Players Visionaries Ability to Execute Of course, from a Gartner perspective, Microsoft is by far the leader in terms of ability to execute in the integration space. Source: Gartner Group Completeness of Vision

16 EDA ?

17 Gartner on EDA “Event-Driven Architecture: The Next Big Thing”
Roy Schulte, Gartner, Application Integration & Web Services Summit 2004 Context: Gartner started this debate off last year Key point: the change in tone from analyst (not the “next big thing” anymore) – which was our viewpoint on this all-along – its not a silver bullet. Note the EDA acronym change – its Event-based application design. Just to roll back time about 12 months or so, last year at the Gartner Application Integration Summit, Roy Shulte really kicked off a flood of activity with his session where he said ‘Event-driven Architecture: The next big thing’. We had the community, the industry, architects, application developers thinking about, well, if this is the next big thing, then what I am supposed to do with it? If you go forward 12 months to this year’s Conference, Roy had a session where he spoke about ‘Event-based application design, a different mindset’. Now, this is good, because this is something that we have been saying all along, that EDA is about application design. I would not even call it architecture. It’s not a product; it’s not a SKU. It’s about application design principles, and it is a mindset of how you think about addressing your business problems. In some way, this session that Roy did at this year’s summit is actually a vindication of our viewpoint. It’s not the next big thing; it’s not a silver bullet. It is our responsibility to work with the customer, and to help them figure out where it makes sense to use these principles, and maybe where it does not make sense to use these principles. “Event-Based Application Design: A Different Mind-Set” Roy Schulte, Gartner, Application Integration & Web Services Summit 2005

18 Processing Events Business impact derives from processing the events
Event processing is multi-faceted Correlation Transformation Routing Processing Events What Gartner calls Mediated events, Event-enabled processes and Complex event processing are all about the processing of the events and less about the actual communications. Like we said earlier, we can sense and we can communicate the events, but the business impact truly derives from processing the events. Event processing is a multi-faceted thing. Firstly, there is correlation. Obviously, if you have a PO and as the PO goes through various lifecycle stages, you want the information to be linked back and say, all of this data is about this PO. You want to transform the content of the message, the information about the event, you want to be able to go back and forth across various schemas, for instance, you want to route and orchestrate these events as they go through the enterprise. Lastly, they’re all driven by business rules fundamentally, because the business rules determine how to transform, how to route, and so on and so forth. The key takeaway here is to say, yes, processing is very important, but processing is a multi-dimensional thing. As you think about processing, think about correlation, transformation, routing, orchestration, and then all of these being driven by business rules Orchestration Business Rules

19 Architectural Guidance -Design Patterns
Topologies Point-to-point Broker Message bus Publish/Subscribe Integration Patterns Pipes and Filters Gateway When engaging with customers don’t forget to leverage the architecture guidance on MSDN. This is both a way to demonstrate thought-leadership, and to help customers break their scenarios down using design patterns. "Each pattern describes a problem that occurs over and over again in our environment and then describes the core of the solution to that problem in such a way that you can use this solution a million times over without ever doing it the same way twice.” - Christopher Alexander

20 Business Activity Monitoring
Biztalk Server Business Rules Inference Engine Orchestration Receive Port Send Port Receive Adapter Send Adapter Host When an event arrives, BTS 2004 routes it to either an orchestration (one that’s already running or, if necessary, starting a new one to process this message) or an outbound pipeline (more precisely, to a send port). A subscription determines exactly what happens to each incoming message. Subscriptions can be defined based on message content (“productID=50 AND quantity > 400”) and context about the message, e.g., what protocol it came in on, and they’re actually stored in the MessageBox. A single message can be sent to multiple destinations, e.g, an orchestration and a send pipeline. BAM - A purchasing manager might need to see how many POs are approved and denied each day, for instance, while a sales manager might want an hourly update on what products are being ordered. Meeting these diverse needs requires a general framework for tracking what’s going on with a particular business process. This is exactly what Business Activity Monitoring (BAM) provides. Receive Pipeline Receive Pipeline Send Pipeline Receive Pipeline Host Host MessageBox Publish/Subscribe Business Activity Monitoring

21 Web Services Leadership – July 2005
A key to overcoming technology integration challenges is Web services. Since we first introduced the idea of .NET almost 5 years ago, MS has made major investments in Web services. From our tools and frameworks to Office and Windows, to our server products, Web services provide a foundation of connected systems on the Microsoft platform. For more than three years running, Microsoft has led the industry in our support for Web services. Source: Gartner Group

22 CEP ??

23 Everything is Event Driven!

24 defense against situations you don’t like
CEP in vier Schritten defense against situations you don’t like Detecting patterns of events in a context Understanding aggregating and abstracting patterns of events Predicting the Impact modelling causality between past and future Reactive Planning – be prepared eventsreactive processes, in place, ready to go (react to prediction events). Take advantage of situations you like

25 Global Event Cloud

26 Local IT Systems live in Event Clouds
Control systems for power grids, dams, nuclear power stations, etc. Chip fabrication lines Automobile assembly lines Automated warehouses RFID tracking systems

27 The Software Crisis (ca. 2004)
$250B/yr in US (average $430K to $2.3M per project) 16% on time and budget but deliver less than planned (avg 42%) 53% overrun (avg 189%) 31% are canceled, losing $140B/yr Mobile devices, digital media, smart appliances, B2B commerce Need to spend less time housekeeping and more time designing

28 Sicht von Microsoft zu:
SOA ESB EDA EAI DSI Software Factories CEP neu!

29 Connected Systems Connected Systems Integrated Tools and Modeling
Orientation Service Integrated User Experience Pervasive Workflow Federated Identity Federated Data To successfully build systems that connect your organization — And further connect your organization to your suppliers, partners, and customers — You need trustworthy technology to deliver on these core requirements, Supported by proven principles, patterns, models and tools, That deliver on cross-cutting concerns such as security, management, and governance. Integrated Management and Governance

30 Location transparency
Unified Programming Model ASMX .NET Remoting Interop with other platforms Extensibility Location transparency Speaker Notes Indigo provides you with a unified programming model that brings together the best aspects of existing Microsoft technologies. What this means is that, with Indigo, you will no longer need to wonder “which technology do I use (ASMX, Remoting, etc)” when building a connected system. All of the application-to-application and intra-application communication for your connected will be handled by Indigo. This unified programming model is exposed to you through the System.ServiceModel namespace. Since Indigo provides all of the features of these existing Microsoft technologies, Indigo supports all of the scenarios currently supported by these technologies. In addition, Indigo enables new scenarios that are currently not possible or very hard to implement with existing technologies because Indigo allows you to compose functionality across these existing technologies. For example, this means that you’ll be able to achieve secure, reliable, transacted Web services by combining/composing the functionality that previously existed in silos. On a related note, we’re also doing a lot of work to preserve your existing investments in ASMX, ES, and other existing technologies shown on this slide. We do this through a number of mechanisms including the ability to communicate between Indigo services and existing ES-based applications for example. We’ll talk about this more later in the presentation. Transition to next slide: …but how do we accomplish the union of these various technologies? The secret is in architecture… Attribute- Based Programming Message- Oriented Programming WS-* Protocol Support Enterprise Services System.Messaging WSE

31 Die Microsoft Plattform deckt den kompletten IT-Stack ab. Mit
Die Microsoft Plattform deckt den kompletten IT-Stack ab. Mit .NET als Softwareplattform werden alle Technologien miteinander verbunden und über VisualStudio programmierbar, ein hohes Maß an Integration ist vorhanden.

32 The Software Crisis (ca. 2004)
$250B/yr in US (average $430K to $2.3M per project) 16% on time and budget but deliver less than planned (avg 42%) 53% overrun (avg 189%) 31% are canceled, losing $140B/yr Mobile devices, digital media, smart appliances, B2B commerce Need to spend less time housekeeping and more time designing