logosworld.comlogosworld.com/.../soacamp/soacity_soacamp_day2-da… · web viewthe term...

1

Mid

dlew

are

and

Com

mun

icati

on

Patt

erns

Building SOA CityAn introduction to SOA and Web 2.0 for Enterprise

Leaders and Technology Experts

Logosworld Technology Research, LuxemburgnLeague Technologies Alpharette, Georgia, USA

nLeague Technology Labs, HITEX, Hyderabad, India

/tt/file_convert/5ea27701709c9914821ac233/document.docxSaturday, 08 November 2008 22:56 A=Axel[Abstract]

Building SOA CitySOA Blue Books Series

Axel AngeliLynton GriceSrinath NagabhiravaSreekanth KanthamneniVarun Reddy

2

1

<Con

tent

s

2

<Contents

/tt/file_convert/5ea27701709c9914821ac233/document.docxAxel Angeli, /75; 5/18/2023 Last saved by Axel

3

1

<Con

tent

s

3

<Contents

1 Middleware and Communication PatternsThe term middleware has long time been the placeholder for SOA in general. Middleware is software that is designed to work as the central exchange market place for message and control all traffic between connected applications. In plain words it is the General Post Office for all message exchange within the network. Middleware delivers essential services at a central place, like data conversion and mapping, guaranteed delivery, rule based receiver determination, temporary data storage and collision and contention handling.


4

1

<Con

tent

s

4

<Contents

1.1 Message Pattern in Middleware

1.1.1 Message ForwardingForwarding a messsge is an elementary and a heavily used in messaging scenarios. It corresponds to the general von-Neumann priniciple of

Input Process Output

The message works with two end points:

Input channel Output channel

In between there is nothingthan a vector that builds a path between inpout and output channel.

An important rule in SOA is that the design of a message flow is independent from the physical nature of the channels. Channels are mapped to a physical source during run time (or configuration time) only.

1.1.1.1.1 Example: The following scenarios are all the same, only the data channels are differently mapped later.

File Copy: Read file Process Write File

In this case we assign file datasources to both the input and output channel

Receive to File: Receive message via HTTP process Write File

In this case we assign a file datasources to the output channel and an HTTP-Channel to the input

Get file content: Read file Process Return as HTTP

In this case we assign a file datasources to the input channel and an HTTP-Channel to the output

1.1.1.2 Exercise for XI:

1.1.1.2.1 Step 1 – Define the Message Scenriao in Integration Builder:Define a simple scenario in SAP PI integration builder that receives a message and hands it over to the output without manipulation. Use the following message structure:


Nature of datasource is not part of the pattern

5

1

<Con

tent

s

5

<Contents

<?xml version="1.0"?><message id=”messageID”>

<header></header><body></body>

</message>

1.1.1.2.2 Step 2 – Configure sample uses in Integration Directory:In the Integration Directory please define three different configurations for the cases in the examples given before.

File Copy HTTP to File File to HTTP

Inorder to keep the exercise simple, use the MEssageID as filenames if appropriate and assume the the directory of the file location is static for now.

Figure 1: Sample Middleware Landscape


6

1

<Con

tent

s

6

<Contents

The middleware is the central message brokerto coordinate the many-to-many communication in a network. The standard features of a middleware are:

Protocol conversion Temporary data storages and queuing Data serialization

In addition to the basic services all modern middleware products offer support for workflow, commonly known as Business Process Monitoring (BPM). BPM will be discussed in a separate chapter.

1.1.2 Message drivethroughThis is the most elementary messaging pattern. A message is received from an endpoint and handed to another endpoint.


Adapter-Format Document-Format

7

1

<Con

tent

s

7

<Contents

In this process we see three layers of components.

1.1.2.1 Document FormatsIn this example we are deling with three document formats.


external FormatAdapter-FormatAdapterAdapter-Format Document-Format external FormatAdapter-FormatAdapter

8

1

<Con

tent

s

8

<Contents

1.1.2.1.1 PayloadWe shall call the information carried by the native format the “Payload”.

1.1.2.1.2 Native FormatThis is the format which is delivered by the external applications. E.g. it is the content of the file as a plain string or the HTML document when calling via HTTP.

The quick brown fox jumps over the lazy dog.<html>

<body>The quick brown fox jumps over the lazy dog.</body></html>

1.1.2.1.3 Adapter Standard Format (Internal Transport Format)Since the middleware should be able to see the same information independent of the data source, the adapter is responsible to repackage the payload into a harmonized internal format.

<message><id>1234567890</id><body>The quick brown fox jumps over the lazy dog.</body>

</message>

You may well compare the internal format with some standard container boxes that all have the same size, so that you can stack and pile them easily. No matter whether you transport bottles, meat, letters or toys: the crates will have the same size and for the transporter the content does not matter when he does his logistics plannings.

1.1.2.1.4 Logical FormatThe internal format is somehow arbitrary and may not meet really the needs of your application. This is not so much a problem if you work within a single middleware or workflow system and are sure that this never changes. If you say, PI will stay forever, then it is fine to work on the internal format directly. If you, however, plan to juggle data between several middleware instances of different brands, then it is more handy to have a common meta data structure across the organisation. We call this the logical format.

For our exercises we define a simple meta format like this:


File Format:HTML Format

9

1

<Con

tent

s

9

<Contents

<message>< id>1234567890</id><head></head><body>The quick brown fox jumps over the lazy dog.</body>

</message>

In real world applications you might rather consider to use JMS or AMQP formats instead.

1.1.2.2 Conversion layers

1.1.2.2.1 The Adapter layerThe adapter layer is responsible for building the interface between the application programming interface and the device specific protocol. The adapter converts the data rectrieved from the device into a harmonize format. After conversion of the data by the adapter, the data is in a standard format. No matter which adapter you pliug in, the result of the adapter will be the same. Other names for adapters are “drivers” or “protocol converters”.

1.1.2.2.2 The Mapping LayerThe mapping layer serves the sole purpose to produce a harmonized document container out of the adapter delivered format.

1.1.2.2.3 The Process LayerThe process layer does manipulations of the document that is handed over. It can be made up of a single step or a complete sub-workflow, which is seen as a single compound procedure.

1.1.2.3 VB.NET Example:

Class AdapterFunction read as StringEnd FunctionFunction write (dataStream as string)

End Class

Class FileAdapter Inherits AdapterDim lFileName as String = 'dummyIn.txt'Function Overwrites read as String

return readfile(lFileName)End Function

Function Overwrites write(dataStream as string) as String return readwrite(lFileName, dataStream)

End Function


10

1

<Con

tent

s

10

<Contents

Function ReadFile(filename as string) as StringDim buffer as variantbuffer = (read the file)return buffer.toBase16

End Function

Function WriteFile(filename as string, fileString as string) as boolean

Dim buffer as variantbuffer = (read the file)return buffer.toBase16

End FunctionEnd Class

1.1.2.4 Exercise: Define a simple File Copy Scenario in SAP PI

1.1.2.5 Exercise: Add a mapping of the file format to a document format to the File Copy Scenario in SAP PI


11

1

<Con

tent

s

11

<Contents

2 Module 1: What is SOA good for?

2.1.1 In-Sourcing External Services

2.1.1.1 Amazon

2.1.1.2 eBAY

2.1.1.3 Google

2.1.1.4 Unified messaging

2.1.1.5 (more)


12

1

<Con

tent

s

12

<Contents

2.1.2 Out-Sourcing Services

2.1.2.1 Basis Services

2.1.2.1.1 Archiving

2.1.2.1.2 Data backup

2.1.2.1.3 Printing

2.1.2.1.4 Mailing

2.1.2.1.5 (more)

2.1.2.2 Business Services

2.1.2.2.1 Invoicing

2.1.2.2.2 Central ordering

2.1.2.2.3 EDI

2.1.2.2.4 Compliance checks

2.1.2.2.5 Online Payments

2.1.2.2.6 (more)

2.1.2.3 Security

2.1.2.3.1 Virus-Checks

2.1.2.3.2 Access-verification

2.1.2.3.3 (more)

2.1.3 Decentralizing Enterprise Services

2.1.3.1 From R/3 to Netweaver

2.1.3.1.1 SAP ERP

2.1.3.1.2 SAP APO

2.1.3.1.3 SAP BI

2.1.3.1.4 SAP Enterprise portal

2.1.3.2 From Netweaver to Best of Breed

2.1.3.2.1 SAP ERP


Certificates

Credit Card Verification

13

1

<Con

tent

s

13

<Contents

2.1.3.2.2 Microsoft Dynamics Satellites

2.1.3.2.3 Shared demand Planning

2.1.3.2.4 Business Objects

2.1.3.2.5 Microsoft SharePoint Portal and Services

2.1.4 SOA Goals

2.1.4.1 Interoperability

2.1.4.2 Central Process Control

2.1.4.3 Automation

2.1.4.4 Reduction of contradicting redundancy

2.1.4.5 Reuse of functionality and knowledge

2.1.4.6 Electronic Collaboration

2.1.4.7 Clouds: Smear borders between individual computers


14

1

<Con

tent

s

14

<Contents

2.2 Module 2: The Components of the SOA Market

2.2.1.1 Governance

2.2.1.2 Front-end

2.2.1.2.1 Multiple Browser

2.2.1.2.2 AJAX

2.2.1.2.3 Themes and styles

2.2.1.2.4 Portals

2.2.1.2.5 CMS

2.2.1.2.6 Collaboration Tools

2.2.1.2.7 Customizing

2.2.1.2.8 Access Control

2.2.1.3 Services

2.2.1.3.1 Atomic services

2.2.1.4 Atomic services

2.2.1.5 Abstraction

2.2.1.6 Middleware


Screen-Sharing

Multi-Media

StreamingRoaming Profiles

Cookies

Kerberos

Message to and from File

Message from and to storage

Compression

Archiving

Staging

Content based routing

Timed services

Event handling

Asynchronous decoupling

15

1

<Con

tent

s

15

<Contents

2.2.1.6.1 Protocol Conversion

2.2.1.6.2 Data mapping

2.2.1.6.3 Business Process Execution (Workflow)

2.2.1.6.4 Quality of service

2.2.1.6.5

2.2.1.7Persistence

2.2.1.7.1 File System

2.2.1.7.2 Databases

2.2.1.7.3 Message Queues

2.2.1.7.4 Archives

2.2.1.7.5 Synchronization

2.2.1.7.6 Staging

2.2.1.8 Virtualization

2.2.1.8.1 CPU-Sharing

2.2.1.8.2 Simulation and Test

2.2.1.8.3 CPU-Clustering

2.2.1.9 Safety


Automation

Dashboards

Cockpits

Business Process Monitoring

Guaranteed delivery

Registered delivery

Content based routing

Broadcast

Tracking

Use case: Weak lines

VM-Ware, VPC

Reset to defined state

On-Demand Clouds

16

1

<Con

tent

s

16

<Contents

2.2.1.9.1 Firewall and Virus-Protection

2.2.1.9.2 Content isolation

2.2.1.9.3 Data loss protection

2.2.1.9.4 Side-effects

2.2.1.9.5 Availability

2.2.1.9.6 Redundancy

2.2.1.9.7 Amorph redundancy

2.2.1.10 Security

2.2.1.10.1 Security

2.2.1.11 Hardware


Encryption

Address verification

Compliance

17

1

<Con

tent

s

17

<Contents

2.3 Module 3: Technical Components of SOA

2.3.1 Technical Components of SOA

2.3.1.1 Message Queues

2.3.1.2 Enterprise Service Bus

2.3.1.3 Universal Protocol Services

2.3.1.3.1 HTTP

2.3.1.3.2 FTP

2.3.1.3.3 SMTP

2.3.1.3.4 SOAP

2.3.1.3.5 XMLRPC

2.3.1.4 Asynchonous vs Synchronous Communications

2.3.1.5 Convenience Services

2.3.1.5.1 Service Discoveries

2.3.1.6 Frontend Design Concepts

2.3.1.6.1 Model-View-Controller

2.3.1.6.2 CSS and XSLT

2.3.1.6.3 AJAX

2.3.1.6.4 Multi-Browser and Multi-Client frontends

2.3.2 Minimum SOA Equipment

2.3.2.1 Basic Services

2.3.2.1.1 SMTP, FTP, HTTP

2.3.2.1.2 SOAP, JSON, XMLRPC, SAP, ODBC, ORACLE, EXCEL

2.3.2.1.3 Unified Data Storage: WebDAV

2.3.2.2 Managed Runtime

2.3.2.3 Message Queue

2.3.2.4 Agility Tools


UDDI, SAP ESR

18

1

<Con

tent

s

18

<Contents

2.3.2.4.1 Unified Data Browser

2.3.2.4.2 Service Directories

2.3.3 Building on Top of an MQ

2.3.3.1

2.3.3.2

2.3.4 Use cases of SOA


19

1

<Con

tent

s

19

<Contents

2.4 Module 4: Business Process Modelling

The main activity in enterprise driven IT is building automated workflows between existing processes. In this chapter we explain the concepts of BPM and what basic architecture is needed to make BPM useful for everybody and allow mashups of process flows across arbitrary software applications.


20

1

<Con

tent

s

20

<Contents

2.5 Module 5: Guide to Introduction of a SOA Framework


21

1

<Con

tent

s

21

<Contents

2.6 Module 6: Principles of SOA Governance

SOA requires a completely different methodology to control the whole interaction of processes and flows. The challenge lies in getting a nice control over myriads of components that appear and vanish often quicker than you can register them.


22

1

<Con

tent

s

22

<Contents

2.7 Module 7: Managing SOA Life Cycle


23

1

<Con

tent

s

23

<Contents

2.8


24

1

<Con

tent

s

24

<Contents

3 Atomic Patterns


25

1

<Con

tent

s

25

<Contents

3.1 Pig RunsPig runs are patterns that simulate a flow without carrying information from end to end. In fact compares to a transport without payload. Such transports are done in real life every time when a route is new or it is unknown if the route is free of barriers. Before a life transport with a genuine payload is sent over the path the vehicle (“the pig”) is fired across the parcours.

3.1.1 Round Trip (Loopback test)This is the most simple of all patterns. The system sends a message to itself. No payload manipulation takes place here. The message is taken from a data source and stored in a second data source on the same system.

3.1.1.1 Exercise 1:Using PI read a message from a file with fixed file name and store it in another file.

3.1.1.2 Exercise 2: Multichannel testData sources are data channels only, so they must not be part of the process definition. In this example we want to change the datasource from case to case to see if different channels are treated equally well.

3.1.1.3 Exercise 2a: Dynamic file naming

3.1.1.4 Exercise 2b: Database to database

3.1.2 WatchdogsWatchdogs are used to control the execution of services. In a traditional development environment this is something that is very difficult to achieve. In a proper SOA, a watchdog is a basic service. Any service action can be run under the control of a watchdog. The watchdog controls whether the started service meets certain conditions and behaves well.

Running under the control of a watchdog can explicitelky be requested by the service itself or set as a policy by the execution environment. Am example of a policy enforced watchdog is in In SAP the execution of a dialog process that cannot run longer then 300 seconds without having a user


26

1

<Con

tent

s

26

<Contents

interaction. This is handled by a built-in watchdog of the ABAP runtime, therefore set by the system policy.

3.1.2.1 Implementing a watchdogThere are several strategies to implement a watchdog.

If the service runs on the same machine it may be possible to kick off an asynchronous process and kill the process through a system command.

If the service is run remotely this may be much more difficult. A proven strategy is working with a message queue.

Start the watchdog as a proxy Watchdog pokes the message in a queue and calls the external service If the request does not return in time, the watchdog returns a default response and cuts the external

connection

3.1.2.1.1 HeartbeatsHeartbeats are special form of watchdog control. In this case the watchdog requires that the controlled service reports regularly its activity to show a sign of live. Naturally they require the active cooperation of the controlled service.

3.1.3 TimerTimers are one of the most commonly used components in a service based environment. There are several kinds of timers.

3.1.3.1.1 Timer TriggersSuch timers are uded to start execution of a service or a flow periodically or at a preset moment of time.

In a traditional programming environment you would define a timer and then call a program when the time has reached the preset lap.

In SOA we mainly think in terms of loosely coupled services. Therefore the timer will not call a program, buit rather raise an event. The ebent will then go to an event dispatcher that decides which services need to be alerted and triggered.

Timer raises event Dispatcher caches the event one or more services are triggered

Figure 2: ### Drawing for above Timer Events


27

1

<Con

tent

s

27

<Contents

3.1.3.1.2 Watchdog timersWatchdog timers are a special form of a watchdog. They control if a service is run within a given time window and runtime does not exceed a preset amount of time.

3.1.3.1.3 Countdown (Wait) TimersCountdown timers are mainly used to delay the start of execution of a service.

3.1.3.2 Exercise: Execute the pig run every 10 secondsImportant: Protocol the runs somehow

3.1.4 Fire & Forget

3.1.4.1 Exercise: Send an email with a payload

3.1.5 Parallel execution

3.1.5.1 Exercise Pig run with notification: o a pig run and every time the message is send on its way an email is sent out to a fixed address for monitoring purposes.

3.1.5.2 Exercise: Send message to multiple destinations and wait for replySend out messages to two destinations and then wait until all have replied, then send out a message with the results.

3.1.5.3 Exercise: Monitor behaviour of aboveSome scenario but this time monitor the replies for time-outs.


28

1

<Con

tent

s

28

<Contents

3.1.5.4 Exercise: Making an HTTP call to an external service

3.1.5.4.1 ZIP a list of filesWe have written a small web service in .NET that allows adding a list of files to a ZIP archive. Define a client call to send a list of filenames and receive the filename of the resulting ZIP-archive.

In order to test the service call, define a process that does the following.

Copy some existing files from a known location into a work directory

Call the service with the name of the files that have been copied

Copy the received archive to a known output directory.

3.1.5.4.2 Splitting a fileWe have written a small web service in .NET that allows splitting a file into several small chunks. Define a client call to send the name of an existing file and receive a list of filenames that are the created file chunks.

In order to test the service call, define a process that does the following.

Call the service with the name of the file to chunk Copy the received files from its current locatiuon to a predefined directory.


29

1

<Con

tent

s

29

<Contents

3.2 FrontendFrontends are delivered nowadays mainly in form of web browser applications. However, the browser is only a special variant of an HTTP client.

Browser is only an HTTP client with presentation Browsers differ in capabilities Some browsers allow “callback”, called AJAX

Exercise 1:

Create a simple web service in your favourite application development environment, that returns a lost of the current time in different time zones:

<table style="width: 100%" class="style1"><tr>

<th>Zone</th><th>Time</th>

</tr><tr>

<td>UTC</td><td>23.05.2008 12:00:01</td>

</tr><tr>

<td>UTC-1</td><td>23.05.2008 11:00:01</td>

</tr> <tr><td>UTC-3</td><td>23.05.2008 09:00:01</td>

</tr><tr>

<td>UTC+1</td><td>23.05.2008 13:00:01</td>

</tr></table>


30

1

<Con

tent

s

30

<Contents

3.3 Test first; prepare the pig runBefore we even start implementing any middleware pattern we need to be prepared to test the defined processes and components. We must not consider any component or process as being finished and ready to use until we have a clearly defined testing scenario that demonstrates the use of the implemented work and


31

1

<Con

tent

s

31

<Contents

3.4 Quality of Service


32

1

<Con

tent

s

32

<Contents

3.5 Coping with massive traffic

3.5.1.1.1 Throttling

3.5.1.1.2 Staging

Pseudo-Synchronous Execution

3.5.1.1.3 Sizing

3.5.1.1.4 Managing Threads

3.5.1.1.5 Clustering and Hologramming

3.5.2 Exercise: File CopyDefine a process in SAP PI that copies the content of a file from one place to another.

3.5.2.1 Solution:Copying a file is actually a special case of a content forwarding scenario. So the process should be defined as a simple content passthrough.

Sender (process) receiver

There are many ways to solve the file copy problem. The usual quick and dirty approach would simple open the file from the adapter and juggle the received information to the destination port where another adapter would take the load and save the file into another destination.

This is a working solution but not something that not universal enough. Please keep in mind that we build now a scenario that should be independent of the datasource. In fact the process that we design is very simple, it does indeed nothing at all. Kit receives the data and lets the data flow onwards to the next step, which is the adapter endpoint.

Inbound.Adapter (Process that does nothing) Outbound adapter


The theory behind:

33

1

<Con

tent

s

33

<Contents

3.5.2.1.1 What does the adapter do?This is a device specific driver, that reads the data from the data source – here: our file – and converts the data into a harmonized data format, the adapter meta data.

3.5.2.1.2 Why do we need the meta format?There are many distinct data channels. Files, databases, TCP/IP channels. Since our process is only interested in the payload delivered from the external channel, the adapter needs to unwrap the envelope from information. After transforming the information into a meta-format we can easily swap the adapter without making any changes in the process itself. We use the same process for any adapter format. The adapter that we are going to use in reality will be assigned by the configuration of the process after deploying it.

3.5.2.1.3 Defining a document formatSince the data of the file may be encoded and we might also need to pass additional information we define an envelope data structure that will both carry the data payload and the extra meta information pragmas. Example:


<header></header><body>

hier goes the payload</body>

</message>

Since the adapter engine (file adapter) may deliver a format that is not 100% compatible with our document format, it might be necessary to add some “meta-adapter” on process level, that maps the information delivered by the adapter into the transport structure.

Sender File adapter Meta-FileAdapter -> (process) Meta-

FileAdapter File adapter receiver

Meta File Adapter: Maps between the format delivered by the file adapter into the payload segment of the XML


34

1

<Con

tent

s

34

<Contents

FileAdapter outputs FileContent.

Mapping:


<header><filename>D:\\inputfile.txt</filename>

</header><body>

FileContent</body>

</message>


35

1

<Con

tent

s

35

<Contents

4 A real life scenario


36

1

<Con

tent

s

36

<Contents

4.1 Bluefant CorporationBluefant Corp is a large niche manufacturing business. It sells, procures and produces cooking ingredients and convenience dishes for the nutrition industry and gastronomy. With this business description it belongs to the non-discrete manufacturing industries.

Bluefant is a global business with factories in several continents. The main plants are located in Paris, Capetown, Singapore and San Francisco. There are following distribution channels for the business.

Direct shipment just-in-time to large food-processors like Nestle, Nabisco, Dr.Oetker, Procter&Gamble and more. The production line of the latter are designed in a way that they can buffer no more than two hours of supply chain disruption before it causes significant impact on the smooth flow of production.

Bluefant franchises the semi-processed dishes to smaller restaurant under the name Bluefant Deli. The Bluefant Deli offers snacks from across the world like various noodle specialities, Pakora, Samosa, Baji and Dim Sun variations (see the menu here: ### menu ###). The franchise line Bluefant Deli, which is an independent company owned 51% by Bluefant and the rest belonging to some investors. Bluefant Deli furnishes the restaurants, including the equipment for the kitchen like stoves and cooling machinery. All restaurants report daily their consumption and Bluefant Deli calculates then the required supply to be delivered from a local distribution centre.

4.1.1 Abstracting the Business Process


37

1

<Con

tent

s

37

<Contents

4.2 Self-Service Service for Field ServiceYour management has decided that from now on your company will interact with the external field service engineers through a web-based self-service kiosk. For that purpose a framework contract for each contracting party is created. The contract lists all the items that are subject to the self-service scenario. Whenever a service is provided or a product is delivered against one of the existing items in the contract, the respective booking is done against the item line.

4.2.1 A simple caseThe contract shall be created in SAP ERP. The external supplier should be presented a kiosk style web page, where he can choose the contract, view the possible contract items and make postings against the item.

4.2.1.1 Solution Path

4.2.1.1.1 Module testA mini application in SAP will first be created to mimic the data entry from the web and to allow an isolated test of the module

In order to make sure that frontend and backend functionality are truly independent, create the screen in another SAP client than the processing routine

4.2.1.1.2 Agility-TestGenerate a simple data entry web form on the framework of your choice where you can enter data and save the data through calling a backend service.

WebDynpro

BSP-WebForm

Microsoft ASP.NET

CGI


Rapid Frontend Design

Making the call to backend

38

1

<Con

tent

s

38

<Contents

REST

SOAP

XMLRPC

JSon

4.2.1.2 Making Webservice CallsSome of the information for the postings like the price has now been stored in a different place at the vendors site. We want to retrieve this information by making an HTTP call to the other server.

http://ecs.amazonaws.com/onca/xml?Service=AWSECommerceService&AWSAccessKeyId=0C95TZGS3T612ZW2T1R2&Operation=ItemSearch&SearchIndex=Books&Author=Mark%20Twain&Version=2008-04-07

4.2.1.3 Proxy-ScenarioThe solution architects have made a decision that for security reasons no direct connection between front end and backend can be permitted. More than that: the web server has been chosen to run on a framework that uses a different technology than the backend.





39

1

<Con

tent

s

39

<Contents

4.3 Outsourcing Special Services

4.3.1 Central billingRecently Bluefant Corporation had some trouble in finding skilled accountants to cope with the enormous amount of invoices they send out and receive. This triggered the responsible to have the efficiency of the accounting analyzed. The result was a bit surprising for everybody. Although every accountant worked at a considerable high personal performance, the overall efficiency of the department was fairly poor if compared to other bigger organisations. They also found out that both Bluefant Corporation and Bluefant Deli were using expensive equipment like scanning and document archives only at 40% of their capacity. Waiving the initial idea to consolidate the accounting departments of Deli and Corporation the external business process experts suggested outsourcing the billing and accounting process completely to a specialized firm. Since Bluefant had no experience in Central Billing before the decision was made to outsource to three independent firms, one in Poland, one in India and one in Mexico. The idea was that the Central Billers receive the printed documents or the electronic invoices and deliver the data to a central electronic inbox. Depending on capacity any one of the three firms would then pick the next available document and process it accordingly, i.e. either verify an incoming invoice or produce an outgoing one.

4.3.1.1 IT Challenge for Central billingWe find here a situation of many-to-many communication. There are several companies on the side of Bluefant and a limited number of service providers. Data needs to be sent between any of the providers to any of the corporate members. Since the external providers shall have access to a common pool of documents we need to cater for mechanism that allows a collaborative access and synchronization of works.

Another challenge peeks out of the situation that the involved service providers and the corporate plants are spread around the Globe and hence need to cope with different time zones, multiple languages and legal


40

1

<Con

tent

s

40

<Contents

variations. The possibility that processing paths may change rapidly requires a higher degree of agility just as well.

The chosen solution strategy is based on a procedure that is well known from manual processing. Both inbound and outbound invoices are stored in a central storage that can be accessed by any authorized Bluefant user and by the concerned external clerks simultaneously.

4.3.1.2 Business Abstraction

4.3.2 Solution Path:

4.3.2.1 Day 1: Install a common Data StorageIn the initial scenario we defined a server that was centrally accessible through normal file system from any participating member. This is created on a Microsoft SharePoint with access to it via normal file system or WebDAV.

Every time a document is scanned it is automatically routed to the central storage.

Every time a document is processed it is flagged as “in process” so that other users cannot modify the document meanwhile.

Every time a document is changed an event is raised. The ESB will be responsible to consume the event.

4.3.2.2 Day 2: Unified data accessThere have been identified a number of business partners who wanted to deliver their invoices directly to the servers. However, they all have different preferred protocols.

We had 100 larger Franchise partners. 30 of them were able to deliver data via WebDAV or FTP. Some of the larger business partners had a strict company policy that external data exchange needs to be executed via X400 services. The others were only able to deliver data reliable via email or by depositing them on a local server where the data can be picked up.

Instead of forcing the BP to write some dedicated protocol conversion, we decided to deliver a protocol conversion service that accepts data in multiple formats and saves them easily to a file.


41

1

<Con

tent

s

41

<Contents

4.3.2.2.1 Multichannel-Conversions:All protocols have a common morphology. The blocks you find there are:

Envelope Header Sender information Optional: Logical recipient Optional: Routing information Optional: Processing Pragmas Payload The data that is part of the message FTP SMTP HTTP Put and Get FILE Header: Directory information Payload: Content


Example:

42

1

<Con

tent

s

42

<Contents

5 SOA Governance


43

1

<Con

tent

s

43

<Contents

5.1 SOA Communications and PR

5.1.1 How to tell your boss

5.1.2 How to tell business

5.1.3 How to tell the IT

5.1.4 How to tell the business partners


44

1

<Con

tent

s

44

<Contents

5.2 SOA Team Organisation


45

1

<Con

tent

s

45

<Contents

5.3 SOA Implementation Strategy

5.3.1 General Strategies

5.3.2 Industry specific strategies

5.3.2.1 Industry

5.3.2.2 Government and Public Services

5.3.2.3 Regulated Industries

5.3.3 Differences SMB and big industries


46

1

<Con

tent

s

46

<Contents

5.4 SOA vendor politics


47

1

<Con

tent

s

47

<Contents

5.5 SOA Skill Forming


48

1

<Con

tent

s

48

<Contents

5.6 SOA Enforcement


49

1

<Con

tent

s

49

<Contents

5.7 SOA Cost Balance Sheet 100 Franchise Partner

25 could deliver WebDAV and/or FTP 5 needed to install sFTP instead of FTP for security reasons Costs for each partner: 7 Mandays in average; Total=35 MD

Since we offered a central data transformation service, costs had been reduced as follows:


50

1

<Con

tent

s

50

<Contents

5.8 SOA in uncertain environments


51

1

<Con

tent

s

51

<Contents

5.9 Dealing with external SOA partners


52

1

<Con

tent

s

52

<Contents

5.10 SOA Risk Containment


53

1

<Con

tent

s

53

<Contents

5.11 Planning and Running SOA Projects


54

1

<Con

tent

s

54

<Contents

6 Alternate Outline


55

1

<Con

tent

s

55

<Contents

6.1 Module 1 Fundamentals of SOA v2.0.ppt


56

1

<Con

tent

s

56

<Contents

6.2 Module 2 Planning and Running SOA Projects v2.0.ppt


57

1

<Con

tent

s

57

<Contents

6.3 Module 3 Building the SOA Infrastructure v2.0.ppt


58

1

<Con

tent

s

58

<Contents

6.4 Module 4 Creating the SOA Metamodel v2.0.ppt


59

1

<Con

tent

s

59

<Contents

6.5 Module 5 Building a Governance Framework v2.0.ppt


60

1

<Con

tent

s

60

<Contents

6.6 Module 6 Implementing SOBAs v2.0.ppt


61

1

<Con

tent

s

61

<Contents

6.7 Module 7 Managing the SOA Lifecycle v2.0.ppt


62

1

<Con

tent

s

62

<Contents

7 Attachments


63

1

<Con

tent

s

63

<Contents

7.1 The Components of the SOA Market

7.1.1.1 Governance

7.1.1.2 Front-end


SOA MarketGovernanceFront-endServicesAbst-ractionMiddle-warePersis-tenceVirtua-lizationSecurity & SafetyHard-wareSOA MarketFront-endServicesAbst-ractionMiddle-warePersis-tenceVirtua-lizationSecurity & SafetyHard-wareGovernance

64

1

<Con

tent

s

64

<Contents

7.1.1.3 Services

7.1.1.4 Abstraction

7.1.1.5 Middleware

7.1.1.6 Persistence

7.1.1.7 Virtualization

7.1.1.8 Security & Safety

7.1.1.9 Hardware


65

1

<Con

tent

s

65

<Contents

8 Contents1.1 Building SOA City1.2 Visual SOA: Practical Training Concept

The concept of this training is based on seeing it working. The key driver is “Example-First”. Before diving into the theory of SOA and Web 2.0 we shall build a small real life demo application on top of a virtual enterprise to demonstrate the difference of the SOA paradigm versus the traditional enterprise computing approach. The examples will make use of a mash-up of SAP, Microsoft and Open Source technologies spiced up with some other, prominent SOA products. For SAP addicts this will bring an additional benefit in understanding how SAP process Infrastructure (PI) works and how competing technologies seamlessly cog into each other.

1.2.1 GoalThe goal of the SOA Camp is to enable the IT savvy to understand in depth the new trend topic of the Service Oriented Architecture and the correlated prominent use case Web 2.0 and Enterprise 2.0.

1.2.2 Our Vision for this CourseDruing this course we want to build a small, working prototyping application that allows vsiualizing the core matters of SOA. We want to start with a small communication scenario between two applications, then add more applications via different channels and finally end up in a loosly coupled web of several computers, something which is known as computing cloud and stands firm as the basis for planning Ultra Large Systems.

2 Module 1: Getting a feeling for SOADuring this first day we want you to walk through the SOA City and understand a little bit more how a world of SOA looks like, what you can achieve with SOA and how some basic principles work.

2.1 What is SOASOA is a new paradigm in computing architecture that will build an underlying common infrastructure that allows breaking applications into reusable and recombinable components. In the end we shall have a large society of small service components that are loosly coupled and temporarily interact with each other. The ultimate goal of SOA is to obfuscate the distinction between individual computers and let the whole internet appear as one single computer as the base ground of building Ultra Large Systems.

2.2 Hurray! It said Mama! An Excursion in SOA TerminologySince we are all good scientists and knowledge engineers we shall start our learning sessions with an exercise in naming the things and disambiguate the meaning of extensively used expression.

2.2.1.1 SOA – Service Oriented Architecture2.2.1.1.1 Synononyms:2.2.1.1.2 Definition

2.3 The SOA ParadigmSOA is much more than architectureSOA favors Darwinistic governanceSOA favors collaboration


66

1

<Con

tent

s

66

<Contents

SOA implies agilitySOA is not bottom-up nor top-downSOA fails by too much governanceSOA has no purpose on its ownSOA requires developer satisfactionSOA creates new and better business models

2.4 SOA Challenges2.4.1 SOA Challenge 1: Making Computers talk with each other

2.4.1.1 Calling programs remotely2.4.1.1.1 Protocol API2.4.1.1.2 Proxy-Communication

2.4.1.2 Exchange documents between computers2.4.1.2.1 File exchange – Managed Data Transfer2.4.1.2.2 Message Queues2.4.1.2.3 Database Exchange

2.4.1.3 Multichannel architecture2.4.1.3.1 Adapters and Protocol Converters2.4.1.3.2 Proxy-Communication - Managed Execution

2.4.2 SOA Challenge 2: Common Look and Feel and MobilesThere is more than a Windows computer. There are Macs, there are Linux PCs; there are several browsers now out there, besides the Internet Explorer there are Opera, Firefox, Safari and maybe more. And there are Mobile devices like the Windows Mobile and the Apple iPhone. But also other computers are trying to access another computer via the same protocol channel.

2.4.2.1 Coping with multiple browsers2.4.2.2 Protocols for different needs

2.4.2.2.1 HTTPOne request One ResponseRequest via HTTP:Response from HTTP

2.4.2.2.2 FTP2.4.2.2.3 SMTP2.4.2.2.4 Secure Variations: HTTPS, SFTP

2.4.3 SOA Challenge: Traffic Congestion and bad routes2.4.3.1 Message Queues2.4.3.2 Quality of Service

2.4.4 SOA Challenge: Message delivery services2.4.4.1 Postman as messenger2.4.4.2 Postman as message store2.4.4.3 Subscription Services

2.4.4.3.1 Example: Drupal Newsletter Alert2.4.5 SOA Challenge: Simple Automation2.4.6 SOA Challenge: On Demand Computing2.4.7 SOA Challenge: Computing Clouds

2.4.7.1.1 Examples:


67

1

<Con

tent

s

67

<Contents

TimestampsCalculate Road TollsConsult Expert Systems

2.5 SOA LiveSOA Examples that we find in the WWWInternet as the SOA for Webservices

2.5.1.1 Playing with AmazonAmazon is the web service pioneer

2.5.1.1.1 Simple REST query2.5.1.2 Web Service descriptions

2.5.1.2.1 AMAZON WSDL2.5.1.2.2 AMAZON Webservice Query2.5.1.2.3 Generate Code from WSDL

2.5.1.3 Service that are not webservices2.5.1.4 DCOM and Intellisence2.5.1.5 SMTP&POP: Sender&receiver example

2.6 Module 2: Writing your own web servicesCreating web services yourself is fairly simple, at least if you have the right toolboxes and development environments at hand. In this first example we shall use Visual Studio as the elementary component and see how we can integrate components of arbitrary legacy like SAP or AMAZON.

2.6.1 Writing a simple backend application2.6.1.1 Making call-offs from an existing contract

2.6.2 Writing a backend test proxy2.6.2.1 Write request to DB and acknowledge

2.6.3 Writing a simple frontend2.6.3.1 AgentID, ServiceID, Date, Start, End

2.7 Module 3: Test First Paradigm: Pig Runs and crash test dummies2.7.1 Monitoring and Control Dashboards

A dashboard is a utility that lets us easily define and manipulate a test scenario and view the result of the process execution.

2.7.1.1 Monitoring Subjects2.7.1.1.1 Process Runtime2.7.1.1.2 Exceptions2.7.1.1.3

2.7.1.2 Dashboard Plugs2.7.1.2.1 Exception restart

2.7.1.3 Exercise: Simple HTTP Client2.7.2 Crash Test Dummy

Crash test dummies are known from the automobile test. They are used to see what effect a certain predictable accident has in reality. For our testing scenarios a crash test dummy is a message that is designed deliberately false.

2.7.3 Pig RunPig runs are patterns that simulate a flow without carrying information from end to end. In fact compares to a transport without payload. Such transports are done in real life every time


68

1

<Con

tent

s

68

<Contents

when a route is new or it is unknown if the route is free of barriers. Before a life transport with a genuine payload is sent over the dedicated route an empty dummy vehicle (“the pig”) is fired across the parcours.

2.7.4 Exercises: Sample Pigs2.7.4.1 Message Drivethrough (Null-proxy, Message-Forwarder)

2.7.4.1.1 Exercise 1:2.7.4.1.2 Exercise 2: Multichannel test

2.7.4.2 Message Loopback2.7.5 Parallel execution

2.7.5.1 Exercise Pig run with notification:2.7.5.2 Exercise: Send message to multiple destinations and waitr for reply2.7.5.3 Exercise: Monitor behaviour of abov

2.7.6 Service health check2.8 Terminology2.8.1 Fighting Babylonian Cacophony2.8.2 Message Oriented Middleware2.8.3 SOA - Service Oriented Architecture2.8.4 ESB-Enterprise Service Bus2.8.5 WSDL – Web Service Description Language2.8.6 UDDI – Universal Discovery, Description, and Integration2.8.7 BPML - Business Process Modeling Language2.8.8 BPEL – Business Process Execution Language2.8.9 EDI - Electronic Data Exchange

3 Middleware and Communication PatternsThe term middleware has long time been the placeholder for SOA in general. Middleware is software that is designed to work as the central exchange market place for message and control all traffic between connected applications. In plain words it is the General Post Office for all message exchange within the network. Middleware delivers essential services at a central place, like data conversion and mapping, guaranteed delivery, rule based receiver determination, temporary data storage and collision and contention handling.

3.1 Message Pattern in Middleware3.1.1 Message Forwarding

Nature of datasource is not part of the pattern3.1.1.1.1 Example:

3.1.1.2 Exercise for XI:3.1.1.2.1 Step 1 – Define the Message Scenriao in Integration Builder:3.1.1.2.2 Step 2 – Configure sample uses in Integration Directory:

3.1.2 Message drivethrough3.1.2.1 Document Formats

3.1.2.1.1 Payload3.1.2.1.2 Native Format

File Format:HTML Format

3.1.2.1.3 Adapter Standard Format (Internal Transport Format)


69

1

<Con

tent

s

69

<Contents

3.1.2.1.4 Logical Format3.1.2.2 Conversion layers

3.1.2.2.1 The Adapter layer3.1.2.2.2 The Mapping Layer3.1.2.2.3 The Process Layer

3.1.2.3 VB.NET Example:3.1.2.4 Exercise: Define a simple File Copy Scenario in SAP PI3.1.2.5 Exercise: Add a mapping of the file format to a document format to the File Copy Scenario in SAP PI

4 Module 4: What is SOA good for?4.1.1 In-Sourcing External Services

4.1.1.1 Amazon4.1.1.2 eBAY4.1.1.3 Google4.1.1.4 Unified messaging4.1.1.5 (more)

4.1.2 Out-Sourcing Services4.1.2.1 Basis Services

4.1.2.1.1 Archiving4.1.2.1.2 Data backup4.1.2.1.3 Printing4.1.2.1.4 Mailing4.1.2.1.5 (more)

4.1.2.2 Business Services4.1.2.2.1 Invoicing4.1.2.2.2 Central ordering4.1.2.2.3 EDI4.1.2.2.4 Compliance checks4.1.2.2.5 Online Payments4.1.2.2.6 (more)

4.1.2.3 Security4.1.2.3.1 Virus-Checks4.1.2.3.2 Access-verification

CertificatesCredit Card Verification

4.1.2.3.3 (more)4.1.3 Decentralizing Enterprise Services

4.1.3.1 From R/3 to Netweaver4.1.3.1.1 SAP ERP4.1.3.1.2 SAP APO4.1.3.1.3 SAP BI4.1.3.1.4 SAP Enterprise portal

4.1.3.2 From Netweaver to Best of Breed4.1.3.2.1 SAP ERP4.1.3.2.2 Microsoft Dynamics Satellites


70

1

<Con

tent

s

70

<Contents

4.1.3.2.3 Shared demand Planning4.1.3.2.4 Business Objects4.1.3.2.5 Microsoft SharePoint Portal and Services

4.1.4 SOA Goals4.1.4.1 Interoperability4.1.4.2 Central Process Control4.1.4.3 Automation4.1.4.4 Reduction of contradicting redundancy4.1.4.5 Reuse of functionality and knowledge4.1.4.6 Electronic Collaboration4.1.4.7 Clouds: Smear borders between individual computers

4.2 Module 5: The Components of the SOA Market4.2.1.1 Governance4.2.1.2 Front-end

4.2.1.2.1 Multiple Browser4.2.1.2.2 AJAX4.2.1.2.3 Themes and styles4.2.1.2.4 Portals4.2.1.2.5 CMS4.2.1.2.6 Collaboration Tools

Screen-SharingMulti-MediaStreaming

4.2.1.2.7 Customizing4.2.1.2.8 Access Control

Roaming ProfilesCookiesKerberos

4.2.1.3 Services4.2.1.3.1 Atomic services

Message to and from FileMessage from and to storageCompressionArchivingStagingContent based routingTimed servicesEvent handlingAsynchronous decoupling

4.2.1.4 Atomic services4.2.1.5 Abstraction4.2.1.6 Middleware

4.2.1.6.1 Protocol Conversion4.2.1.6.2 Data mapping4.2.1.6.3 Business Process Execution (Workflow)

Automation/tt/file_convert/5ea27701709c9914821ac233/document.docxAxel Angeli, /75; 5/18/2023 Last saved by Axel

71

1

<Con

tent

s

71

<Contents

DashboardsCockpitsBusiness Process Monitoring

4.2.1.6.4 Quality of serviceGuaranteed deliveryRegistered deliveryContent based routingBroadcastTracking

4.2.1.6.54.2.1.7 Persistence

4.2.1.7.1 File System4.2.1.7.2 Databases4.2.1.7.3 Message Queues4.2.1.7.4 Archives4.2.1.7.5 Synchronization4.2.1.7.6 Staging

Use case: Weak lines4.2.1.8 Virtualization

4.2.1.8.1 CPU-SharingVM-Ware, VPC

4.2.1.8.2 Simulation and TestReset to defined state

4.2.1.8.3 CPU-ClusteringOn-Demand Clouds

4.2.1.9 Safety4.2.1.9.1 Firewall and Virus-Protection4.2.1.9.2 Content isolation4.2.1.9.3 Data loss protection4.2.1.9.4 Side-effects4.2.1.9.5 Availability4.2.1.9.6 Redundancy4.2.1.9.7 Amorph redundancy

4.2.1.10 Security4.2.1.10.1 Security

EncryptionAddress verificationCompliance

4.2.1.11 Hardware4.3 Module 6: Technical Components of SOA4.3.1 Technical Components of SOA

4.3.1.1 Message Queues4.3.1.2 Enterprise Service Bus4.3.1.3 Universal Protocol Services

4.3.1.3.1 HTTP4.3.1.3.2 FTP


72

1

<Con

tent

s

72

<Contents

4.3.1.3.3 SMTP4.3.1.3.4 SOAP4.3.1.3.5 XMLRPC

4.3.1.4 Asynchonous vs Synchronous Communications4.3.1.5 Convenience Services

4.3.1.5.1 Service DiscoveriesUDDI, SAP ESR

4.3.1.6 Frontend Design Concepts4.3.1.6.1 Model-View-Controller4.3.1.6.2 CSS and XSLT4.3.1.6.3 AJAX4.3.1.6.4 Multi-Browser and Multi-Client frontends

4.3.2 Minimum SOA Equipment4.3.2.1 Basic Services

4.3.2.1.1 SMTP, FTP, HTTP4.3.2.1.2 SOAP, JSON, XMLRPC, SAP, ODBC, ORACLE, EXCEL4.3.2.1.3 Unified Data Storage: WebDAV

4.3.2.2 Managed Runtime4.3.2.3 Message Queue4.3.2.4 Agility Tools

4.3.2.4.1 Unified Data Browser4.3.2.4.2 Service Directories

4.3.3 Building on Top of an MQ4.3.3.14.3.3.2

4.3.4 Use cases of SOA4.4 Module 7: Business Process Modelling

The main activity in enterprise driven IT is building automated workflows between existing processes. In this chapter we explain the concepts of BPM and what basic architecture is needed to make BPM useful for everybody and allow mashups of process flows across arbitrary software applications.

4.5 Module 8: Guide to Introduction of a SOA Framework4.6 Module 9: Principles of SOA Governance

SOA requires a completely different methodology to control the whole interaction of processes and flows. The challenge lies in getting a nice control over myriads of components that appear and vanish often quicker than you can register them.

4.7 Module 10: Managing SOA Life Cycle4.8

5 Atomic Patterns5.1 Pig Runs5.1.1 Round Trip (Loopback test)

5.1.1.1 Exercise 1:5.1.1.2 Exercise 2: Multichannel test5.1.1.3 Exercise 2a: Dynamic file naming


73

1

<Con

tent

s

73

<Contents

5.1.1.4 Exercise 2b: Database to database5.1.2 Watchdogs

5.1.2.1 Implementing a watchdog5.1.2.1.1 Heartbeats

5.1.3 Timer5.1.3.1.1 Timer Triggers5.1.3.1.2 Watchdog timers5.1.3.1.3 Countdown (Wait) Timers

5.1.3.2 Exercise: Execute the pig run every 10 seconds5.1.4 Fire & Forget

5.1.4.1 Exercise: Send an email with a payload5.1.5 Parallel execution

5.1.5.1 Exercise Pig run with notification:5.1.5.2 Exercise: Send message to multiple destinations and wait for reply5.1.5.3 Exercise: Monitor behaviour of above5.1.5.4 Exercise: Making an HTTP call to an external service

5.1.5.4.1 ZIP a list of files5.1.5.4.2 Splitting a file

5.2 Frontend5.3 Test first; prepare the pig run5.4 Quality of Service5.5 Coping with massive traffic

5.5.1.1.1 Throttling5.5.1.1.2 Staging5.5.1.1.3 Sizing5.5.1.1.4 Managing Threads5.5.1.1.5 Clustering and Hologramming

5.5.2 Exercise: File Copy5.5.2.1 Solution:

The theory behind:5.5.2.1.1 What does the adapter do?5.5.2.1.2 Why do we need the meta format?5.5.2.1.3 Defining a document format

6 A real life scenario6.1 Bluefant Corporation6.1.1 Abstracting the Business Process6.2 Self-Service Service for Field Service6.2.1 A simple case

6.2.1.1 Solution Path6.2.1.1.1 Module test6.2.1.1.2 Agility-Test

Rapid Frontend DesignWebDynproBSP-WebForm


74

1

<Con

tent

s

74

<Contents

Microsoft ASP.NETMaking the call to backend

CGIRESTSOAPXMLRPCJSon

6.2.1.2 Making Webservice Calls6.2.1.3 Proxy-Scenario

6.3 Outsourcing Special Services6.3.1 Central billing

6.3.1.1 IT Challenge for Central billing6.3.1.2 Business Abstraction

6.3.2 Solution Path:6.3.2.1 Day 1: Install a common Data Storage6.3.2.2 Day 2: Unified data access

6.3.2.2.1 Multichannel-Conversions:Example:

7 SOA Governance7.1 SOA Communications and PR7.1.1 How to tell your boss7.1.2 How to tell business7.1.3 How to tell the IT7.1.4 How to tell the business partners7.2 SOA Team Organisation7.3 SOA Implementation Strategy7.3.1 General Strategies7.3.2 Industry specific strategies

7.3.2.1 Industry7.3.2.2 Government and Public Services7.3.2.3 Regulated Industries

7.3.3 Differences SMB and big industries7.4 SOA vendor politics7.5 SOA Skill Forming7.6 SOA Enforcement7.7 SOA Cost Balance Sheet7.8 SOA in uncertain environments7.9 Dealing with external SOA partners7.10 SOA Risk Containment7.11 Planning and Running SOA Projects

8 Alternate Outline8.1 Module 1 Fundamentals of SOA v2.0.ppt8.2 Module 2 Planning and Running SOA Projects v2.0.ppt


75

1

<Con

tent

s

75

<Contents

8.3 Module 3 Building the SOA Infrastructure v2.0.ppt8.4 Module 4 Creating the SOA Metamodel v2.0.ppt8.5 Module 5 Building a Governance Framework v2.0.ppt8.6 Module 6 Implementing SOBAs v2.0.ppt8.7 Module 7 Managing the SOA Lifecycle v2.0.ppt

9 Attachments9.1 The Components of the SOA Market

9.1.1.1 Governance9.1.1.2 Front-end9.1.1.3 Services9.1.1.4 Abstraction9.1.1.5 Middleware9.1.1.6 Persistence9.1.1.7 Virtualization9.1.1.8 Security & Safety9.1.1.9 Hardware

10 Contents

N.N.


logosworld.comlogosworld.com/.../soacamp/soacity_soacamp_day2-da… · web viewthe term...

Documents