Perfect Integration

2 / 32 1. Architectural approach to IntegrationIT Architecture divides its world in a few parts. Various frameworks have variousmodels, but I still like Capgeminis one best, since it follows people and organisationstructure. Above, my own visualisation of thatBusinesses thrive on business. They do business. Without business, there is nobusiness - need I continue?Business defines the business rules, the business exceptions. They make and needbusiness cases with which they can justify investments, change, growth. Businessevents occur at a certain frequency and volume. When all that matches with otherpeople, business agreements can be made with other companies, allowing them todo business across the barriers of their own companyInformation is in the input for business, and the output for it. Information needs tocomply with the business rules and exceptions. People support the business here byhandling this information: usersInformation systems allow the business to scale. They automate what can beautomated, store history, make life as pleasantly as possible for the end-user whoworks for the business. They serve as vehicles for the informationThe technical infrastructure supports and carries the systems: the iron, thenetworks. They form the firm base for the information systems, they are the roads thetraffic travels onWhat if two businesses want to do business?Both parties can’t just exchange information like one would normally do in atelephone call or in a conversation with someone else; usually the business is toocomplex for that. Nor can users do this, as there usually is a high degree ofcomputerisation involved due to the required speed of processing information, andthe volume of information___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

3 / 32The information systems themselves can exchange information, but not one systemin the world is exactly alike another one: they always differ in structure, size,business they support and operating system or database used to support it: thereforea common layout (interface) needs to be chosen to enable the technical translationfrom one system to anotherThat interface must then be supported by the underlying infrastructure: as theseinfrastructures differ from one another as well, a common interface needs to bechosen here tooOn all levels in the enterprise the common theme returns: looking for and definingcommon grounds or subsets, and translating those to common interfaces.If all four levels mentioned (Business, Information, Information Systems, andInfrastructure) supported these subsets, integration can become a factIt’s like establishing a common topic to talk about in a conversation with someoneelse: • what is the shared interest (Business) • which information do you want to share (Information) • which definitions are mutually exchangeable (Information Systems) • how do you want to exchange ideas (Infrastructure)In the next chapter, Ill go into detail with regards to the three themes of integration:messaging, transportation and transformation___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

4 / 32 2. Common subset and transformationThe common subset found on all levels in the previous chapter was: • what is the shared interest (Business) • which information do you want to share (Information) • which definitions are mutually exchangeable (Information Systems) • how do you want to exchange ideas (Infrastructure)Information exchange form: messagingAfter having agreed on mutual business and information to be exchanged,transferring information in a certain message layout from and to systems is thelogical next step.As different systems almost always produce different message layouts, there has tobe a conversion in between these different message layouts: this conversion iscalled interface, where a message that originates from one system is converted to amessage that has another system as destinationThis conversion is purely on a physical level: the logical and functional informationin the message should not be altered. Good interfacing doesn’t involve more thansimple formatting changes like periods to comma’s or vice versa in decimal fields,and translation from and to solid standards such as ISO and EAN. There are many,many standards on the business document level such as EDIFACT and X12, HL7,SWIFT, ClieOp, etcetera. Normally, in mature and high-volume high-frequencyindustries such as banking, automotive and logistics, these standards are easy tofind and hard ( = expensive) to deviate from.In less mature industries or those closer to government and non-profit, one will findthat people find the leisure to play around with non-interoperable standards byusually inventing their own XML and SOAP.Information exchange method: transportationMessages need to be transported from the originating system to the destinationsystem (and vice versa). Ideally, a communication protocol must be chosen that issupported by all parties involved. A communicastion protocol is nothing more than aworldwide standard: telephone, television, fax, telex, the internet: all thouse wouldnthave been possible without simple, static, clear and unambiguous standards.Fortunately there aren’t as many communication protocols as there areapplication systems, so a choice can be made. Communication protocols are, asopposed to information systems, highly standardised on a global scale. Therefor achoice can be made, instead of having to convert one transportation protocol to theother. Next to that, almost all (simple) transportation protocols are free. The ones that___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

5 / 32are more complex and offer a higher degree of functionality and built-in reliabilityusually aren’t freeHowever, when integration is considered to be “door-to-door”, meaning startingat the very originating system at e.g. one company, and ending at the verydestination system of e.g. another company, there almost always is some kind ofconversion involved, as chances are slim that both systems are connected end-to-end on the exact same common communication protocol. From a security point ofview there also are many restrictions that simply wont allow for a direct connectionbetween an internal system and external systemThe integration topic: transformationInformation exchange is the only goal of integration.The only purpose is doing business on a cost-effective basis in order to make orsave (more or better) money.The integration theme is to establish a common subset, and this subset canphysically be realised via transformation.Messaging and Transportation can be defined as the two main methods ofintegration.Transformation is the sole integration topic: business, nor information, norinformation systems, nor infrastructure are alike when integration is exercised on anenterprise scaleStandardisation: dynamics and staticsStandardisation is key to integration. Standardisation makes matters static, and worththe effort of translating. Not standardised or volatile things are dynamic, andimpossible or at least very costly to automate, and keep automatedGas, electricity and water are so standard that we can actually put the plumbing inour floors, ceilings and / or walls. Gasoline is so very standard that we can get iteverywhere, because it will always be the same.The fact that these products are so very static as well as standard, is nocoincidence. Electricity, gas and water nor gasoline have changed over the lastdecades or centuries.Like I have argued in every single chapter so far, standardisation resides in the lowerarchitectural IT layers, and not in the top ones, as dynamics at the top, in thebusiness where people are involved, are far larger than at the bottom, theinfrastructure where machines are involved.No one has rewritten the TCP/IP stack or the HTTP protocol. Have databasessignificantly changed?So, standardisation in IT can be achieved, and already is partially achieved.But, it will only be achieved “down below”, and not in the business area. Businesssimply is way too dynamic for thatSo how do we achieve standards between dynamic businesses? That, in thenext chapter___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

6 / 32 3. Common language: semantics firstThis chapter will elaborate on messaging and transformation (part I), andexplain how information exchange works in the daily world, considering simple orcomplex information exchanges. That will then be related to IT, and the basic ways of“writing down” information in IT will be explained.If you want to have a chat with someone else, what do you do?First, a common theme to discuss has to be found - usually not that hard. Thefavourite ones in e.g. IT usually are new technologies, cars, and the occasionalsports.The topics then have to be found, which is a bit harder. Do we discuss hardwaretechnologies, or software technologies, or is it architecture or open source we want todiscuss?If the topics have been identified, last but not least the definitions have to bechecked: are we talking about the same subjects?The Greek philosopher Socrates filled entire conversations, and books, withmerely trying to establish that he and his counterpart were talking about the samething. There are numerous occasions on which he talked half a dozen times or moreto someone, only to mutually agree on the fact that they didn’t mean the same thingwhile using the same word, and then end the discussion.Nowadays this is a serious topic in integration: establishing a common mindsetand “dictionary”. Semantic Interoperability is a very interesting and worthwhile itemto closely investigate and embrace, before engaging any inter-company integration.Even when conducting integration within a mid-sized enterprise itself, it is veryvaluable to have a common dictionary that explains in detail what words mean to allparties involved.After all, what is the use of a service-oriented enterprise and its service repository ifthe function of a certain service can be interpreted in more than one unambiguousway?So, for arguments sake, lets assume that you have • an elaborate dictionary of all the relevant business words used in your enterprise • and their full, unambiguous meaning___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

7 / 32 • complete with the structures they fit in • and the order in which they do so • for each and every business process they occur inNow, on a semantical level, everything is clear: the most important part has beensuccessfully completed. Secondly, agreement has to be reached on another level:the syntactical partWhen setting up information exchange between two parties, life can be simple. Acommon form will have to be chosen, with which both parties feel comfortable: is itOK to converse by fax only, or is the topic so intimate that it can only be done face-to-face? When living in entirely different time zones, it will be practical to have a wayof conversation that is not that interactive, e.g. writing old-fashioned letters orsending emails. And when living far apart, it is a costly business (well, at least italways used to be) to make long phone calls.In IT, this common form is (again) called an interface. The interface chosen shouldalways be a message, a static representation of an event. The idea is that aninformation system itself takes its dynamic, internal data, and exports that outside ofits own system in the form of a static message. That message will always reflect thestate of that small subpart of the system at that specific time.The other system is expecting a similar message, and will import that into its ownsystem, using the static data to update its own dynamic data.To bridge the gap between the two systems, the one static message will have tobe converted to the other static message, preferably outside the systemsThis transformation of messages, which involves designing and creating interfaces,also known as interfacing, can be compared to the day-to-day world of translationof languages. People who speak different languages can’t understand each otherunless one speaks the language of the other. However, the scale on which alanguage should be mastered differs considerably from that of a simple interface orservice.On the other hand, if you just met this mysterious foreigner and only want toexchange a few romantic words over a warm campfire, usually a 30-minute crash-course suffices.But, being an application or system in an enterprise IT-landscape, there regularly is aneed for far more than just mere pleasantries: it therefore is fair to compareinterfacing and servicing to the every-day art of translating and interpretinglanguages___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

8 / 32 4. Common language: direct translationThis chapter is about my favourite subject: translation. Long, long, long ago Iaspired to become an interpreter - but changed my mind. Still, I consider myself alinguist and a good one at that, speaking 6 languages of which 3 fluent. Theexistence of extreme diversity in languages of the world, and the same existence indiversity in an average enterprise IT landscape have always hooked my attentionJust like people speak different dialects and languages, so do applications: notone of them can perfectly understand the other without changing a thing. Even wheninterfacing between SAP systems, there will be differences on the technical level thathave to be resolved.So, how do you solve these misunderstandings at the technical level? How do you"translate" between the different languages and dialects spoken? One of the sideshas to adapt, or maybe both? When, and how?To answer that, lets look at the everyday world of natural languages. A completelydifferent world, with an identical problem - and a working solutionLearning a language can be very hard and time-consuming, and very few willever master a non-native language perfectly. Most of us know someone within thesame country that has an accent and just can’t seem to get rid of it; those that haveconnections across the border might have heard other people speak their languageand have difficulties understanding them. Or one has heard a colleague or neighbourspeak a foreign language and, while not being able to speak that language fluentlythemselves, has good reason to suspect that there will be people on the other sidehaving difficulties understanding that “version of the language”In short, a language spoken by a so-called non-native speaker always has acertain external “flavour” to it. If a Dutchman, a German and a Frenchman all haveto learn English in order to exchange information with each other, it is almost aguarantee that that English will have elements of all those three languages in it. It willnot be British English, nor will it be American English; it will be some kind of Englishthat sounds a bit like English combined with Dutch, German and French. Dunglish,Genglish and Frenglish combined: it will make for a hilarious comedy, unless its aserious professional occasion.Learning a language takes time, money, and last but not least talentIn professional business, therefore, often interpreters are used: people who havemade it their profession to be fluent in at least 2 languages, and in that way can___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

9 / 32interact between two persons or parties who only speak one of them. There nolonger is a need for individuals to master a foreign language: people can speak theirown, and the interpreter will just translate them.Professional interpreters come at a price: it is obvious why not everyone canafford one, and thus has to learn a foreign language himselfOn the other hand, some people can’t afford the time needed to invest in a foreignlanguage: it is of course inconceivable that a president or CEO is sent on a languagecourse for several years in order to master a language: that simply is an investmentthat would never render a return. Even worse, a person in that position would nothave to be fluent in only two, but perhaps a dozen languages. So, learning alanguage yourself comes at a price too. Mastering a language in a perfect way is"priceless" for mostMoving the interpreter into place provides not only a short term benefit, but also along-term one: if the president or CEO is ever succeeded, the successor doesn’thave to be sent on a language course either. One interpreter: a lifetimeinvestment that returns every single day. And the best news? Interpretersthemselves are fairly disposable too...So, in certain strategic positions within a company, it is a very wise investment tomake use of interpreters. In general those positions are characterised by people thathave unique, expert knowledge and skills that make them highly valuable for thecompany. A lot of time and money was invested to either cultivate or buy thosespecific characteristics: one can easily compare that to the careful selection of abusiness-critical application or system within the IT-landscapeTranslating one language to the other, however, whether done by people themselvesor with the help of an intermediate like an interpreter, is still not eliminatingdependencies: there are only exactly two languages involved, and the onlytranslation possible is based on the combined knowledge of those two. Heres whathappens when you do the math on that:When e.g. a German, a Frenchman and an Englishman would participate in aconversation, there would be a need for three interpreters: one that translates fromGerman to French (and vice versa), one from German to English (and vice versa),and one from French to English (and vice versa).If another person would participate, e.g. a Dutchman, three additional interpreterswould be needed: one that translates from German to Dutch (and vice versa), onefrom English to Dutch (and vice versa), and one from French to Dutch (and viceversa)Two parties, one interpreter; three parties, three interpreters; four parties, sixinterpreters: this is going the wrong way!It seems like there is a formula for direct translation and parties involved: for n partiesinvolved, there are n/2 * (n – 1) interpreters needed: one interpreter for every twoparties (n/2), and as many interpreters as there are other languages (n – 1)That formula exists, is widely recognised and true, and that is why in real lifethe solution is only one: next stop, the European Parliament___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

10 / 32 5. Common language: indirect translationThis chapter is about indirect translation, in contrast with the direct translationshown in the previous chapter, which came with costly, exponential dependenciesWhen looking towards large-scale use of translators, e.g. the European Committeein Brussels, it is easily observed how these dependencies can be greatly reduced: alllanguages are first translated into English, French or German, after which either oneof those is translated into the final destination languageOf course this is doubling the effort involved, as everything has to be translatedtwice. However, an intermediate channel is created that everyone can use: comparethat to villages and towns, each digging and building their own roads in order to traveltowards each other, or a municipality that builds a highway for all to use; in this case,all that has to be done is just construct a small piece of road to connect to thehighway, considerably reducing the effort, time and money involvedThus, in the European Parliament a common language is defined, viz. English,French and German. In the specific example of the European Parliament the morethan 500 possible combinations are now reduced to 75.For political and linguistical reasons the choice is made to support more than oneintermediary language in the European Parliament for the purpose of interpretation:real-time translation between humans. Spanish and Italian are languages that arevery closely related, but Serbian and Chinese have nothing in common. The chanceof finding an interpreter that speaks Italian as well as Spanish is far greater thanfinding one that speaks Serbian as well as ChineseIn general any language would suffice for discussing any topics: grammar andsyntax allow for carrying across messages that are complicated as well as simple.Languages that couldnt be compared to or fit onto each other could be languagesthat are far apart on an evolutionary scale, for instance languages that are only usedby a few people living in tribes in the Australian bush and only have a small___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

11 / 32vocabulary and no noticeable grammar, in relation to an average language in themodern world with a vocabulary of tens of thousands of words and a complicatedgrammar that allows for a few different past tenses.In IT, there are such differences as well: if you have to hand-translate in between anold-fashioned mainframe and XML, the distance would be simply too great. You canland a Boeing on a highway in case of emergency, but if you do so on a trail youre alot less likely to succeedSo what needs to be done in information exchange, after establishing the semantics,is finding a common language: in interfaces, this common language is formed by acommon, or rather generic, intermediate form. Both parties can (and rather, should)still speak their own language, but the translation is done "in the middle".This interface, like the languages, needs to be able to hold the logical structure ofthe desired information interchange, and the functionality desired.When this logical and functional structure has been designed, a format needs to bechosen in which this can reside. As with languages themselves, it doesn’t reallymatter what exactly this format is, as long as it is easily accessible, commonlyavailable, as simple as possible and fit-for-purposeTranslating that to IT, first of all a logical and functional design has to be made todetermine the scope of the common subset, and determine which exactly is thedefinition of the various (sub)topics and functional entities, as shown in chapter three.Such constructs are generally referred to as Canonical Models, or Common ObjectModels.They effectively establish a business language that is spoken within theenterprise, making the extreme diversity of the underlying IT-landscape fullytransparent, or rather, from a business point of View, irrelevantCanonical Models do, what IT should have done ages ago: let the business notbother about the trivialities of IT.Direct translation enables this in an efficient way: rather than sending specialisedapplications on a language course and teach them the business language of theirfreshly-joined company, the translators will do that work for them.Indirect translation perfects this in the best cost-efficient way: professional translatorstranslate the diverse application mumbo-jumbo to the generic company businesslanguage: a win-win-win situationThis concludes the first 5 chapters, dealing with the semantical level. The next twochapters will go one level deeper, and drill down to the syntactical level. After that,well resurface to the semantical level again, to deal with addressing in generalIn the next chapter, a word about interface message formats, or rather: if I wereto define such an interface, what are my choices?___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

12 / 32 6. Common language: syntaxesIn the previous chapters I explained semantics, syntax, and the fastest, cheapest andeasiest way to get from diverse IT applications to one uniform business language.This chapter will take a deep dive into message formats such as Flat file,EDIFACT, XML and JSONEver wondered about the pros and cons of XML? JSON? What it is really? Whatother possible message syntaxes are?When semantics and a logical structure has been defined, and functional groups andfields have been identified, just about any message format can be chosen.Choosing message formats (or rather, predefining them) is a rather pragmaticmeasure that narrows down the margin for discussion when it comes to choosing aform for your common languageMessage formats can be divided into two characteristics: length and dimension.Length can be fixed-width or delimited, and dimension can be are horizontal orvertical. Basically, thats all theres to itFixed-length messages have records and fields, containing the information, thathave a fixed width. The same type of information will always be found at the samelocation (position) within a record or field. Fields not fully used (the information in it isphysically shorter than the maximum length of the field allows for) will be filled withspaces or zeroes, depending on the data type of those fields.E.g. An empty record consisting of 5 fields, with a total length of 500 characters, willalways be 500 characters longDelimited or variable-length messages have records and fields, containing theinformation, that have a delimited width. All records and fields are delimited by so-called delimiters, i.e. commonly defined characters that indicate the end of a recordor field.The same type of information will always be found after the same delimiter. Fields notfully used (the information in it is physically shorter than the maximum length of thefield allows for) will be just totally emptyE.g. an empty record consisting of 5 fields, with a total length of 500 characters, willalways be 5 characters (delimiters) long___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

13 / 32Horizontal messages look much like traditional files: fields within a record are foundat the same line, one after another. This message format is the most common andresembles files or database-tablesVertical messages look much like a single-row table: fields within a record are foundeach at a new line, one line after another. This format is not widely used but solvesthe fixed-width problem in an easy way: each field starts on a new line, preceded bya so-called “tag” that identifies the function of the field. The field ends when the lastcharacter on that line is encounteredNowadays EDIFACT is the most common language used, mainly for its globalapproach, broad business document standards (over 200 different functionalmessages) and the fact that its delimited type allows for minimum message size. It isin existence since 1986, and evolved on ANSI X12 (1979). ANSI X12 is in use in theUnited States, whereas EDIFACT is widely used in the rest of the worldXML was gaining grounds, but due to lack of standards, and the fact that it is anunlucky combination of a delimited interface with fixed-width field names it will notplay a large role any time soon, unless it is pushed and supported by organisationssuch as the UNECE. Evangelising Web Services as having to be encapsulated inXML however have sped up the evolution of it.Additional push is delivered by most new applications offering XML-supportnowadays when it comes to disclosing information.A general pull is delivered by Google, Twitter and Facebook moving away, or havingmoved away already, from the format. Facebook is on the verge of doing so, Googlenever has used XML, and Twitter deprecated its use last year. Both Twitter andFacebook have embraced JSON, a far more simple and concise message structurethat serves the same purposeIDOC is a standard invented by SAP that is just a simple fixed-width interface,however supported by large organisations. Needless to say, however, that as SAP-implementations differ all over the world, so do the iDOCsInformation exchange via physical files goes back decennia. A decade ago linksstarted being made via COM, CORBA, DCOM etc, during which information wasn’texchanged between systems via physical messages but via memory objects.This in fact meant that applications were tightly coupled via a virtual point-to-pointinterface. Development and maintenance of such solutions has proven to be (much)too expensiveThere’s a lot of talk about loosely-coupled things these days: the ancient hard-coupling (point-to-point interfacing, COM, CORBA, etc) appeared to be very time-consuming and costly with regards to development and maintenanceNowadays it’s architects that use the term loosely-coupled: some of them thinkthat applications should be loosely-coupled towards the architecture, instead of viceversa. These never are business-architects, but IT-architects. Business architectsknow that applications change at high speed, and that -fast changing- businessneeds should be supported by IT, being able to move in or out applications or___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

14 / 32systems when need be - the European Parliament approach as sketched in theprevious chapter.Loosely-coupled means that applications and systems should plug in and out of theenterprise almost overnight. Plugging in an application should happen as fast andcheap as possible. Regard it as just another politician speaking in Brussels: justanother (relatively cheap) translator has to be found, after which business cancontinue as usualSo, applications must always speak their native language. This is the mostsimple and cost-efficient idea, leaving the application to do what it’s best at: providefunctionality. The translator will provide its own specialty, which is translatingmessages from any language into any other language - the common language thatserves your company as a uniform, tool- and platform independent businesslanguage that is relatively timeless and understandable to allFor an Oracle Siebel CRM application this usually means speaking Siebel XML, forSAP this usually means speaking iDOC; a mainframe will feel most comfortable withfixed or delimited flat files, etc.If you visit China, youll talk Chinese, in Greece its Greek, and when wanting tospeak English you better distinguish between UK English, US English, AustralianEnglish or, what is generally in use in social media networks: global EnglishThis was the deep dive into messaging formats, concluding the informationexchange form: messaging. Now lets resurface and address the informationexchange method: transportation___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

15 / 32 7. Information exchange: transporation[Image courtesy of Ferdinand Reus]After creating and or choosing a common or generic format to exchange theinformation, there is one other field to explore: the facilitation of variouscommunication protocols through which this information can be transportedWhat applies to messages, also applies to transport: a common language is tobe advised as "main artery" for all the traffic. Besides that, each application mustspeak its own language here as well, and use its own infrastructure as much aspossible. Adjusting applications for transport protocols can be even harder than doingso for messages: transport protocols are very, very static and rely on worldwidestandards. Making your own version of it is highly unappreciatedTransportation of data is, like integration itself, a necessary evil. It doesn’t reallymatter how information gets from A to B, as long as it stays the same. Informationexchange by letter, fax, phone, email, SMS, video etcetera, will always be in differentformats, but the general contents will always be the same. It will be influenced bycertain boundaries and limitations inherent to each protocol, but it won’t change inessence - fortunately!The average opening scene of a James Bond movie sets a good example of theinfrastructural variations one can encounter: almost all vehicles imaginable are usedby Bond while "travelling from A to B" (usually that means escaping death from hispursuers). The same applies to a message that needs to be transported: on theenterprise level theres nearly all transport protocols one could think of, and ideallythey should all be supported – within reasonA glance at all possible ways to get information acrossThe most widespread and easy to use communication protocol is via file systems.Usually, networks and applications within a company are "close enough" to find a___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

16 / 32mutual place where they can drop off and pick up files, just like one would at or froma post-office.For intra-company transportation this might suffice, but inter-company informationexchange calls for a protocol that can easily connect to and from different operatingsystemIn the old days, FTP (file transfer protocol) was the easiest and most widespreadprotocol. It is free, widely available, runs on all platforms, and capable of being aseparate layer on top of entire applications, systems, enterprises. It is limited in itscommands itself but allows for all the desired transportation methods.Other common protocols are SMTP (the protocol used for email), and HTTP (theprotocol used for web). JMS is quickly gaining grounds because it’s a queuingmechanism, and free. Queuing systems offer a high degree of reliability, withguaranteed delivery and retry-mechanisms built-inThere is a growing need for security in general, with inter-company communicationspreading "around the world". Dedicated bilateral communication lines are no longerthe default, communication is now largely based on transportation via internet.AS1 and AS2 are secure applications of SMTP and HTTP, respectively. Bothspecifications were created by EDI over the Internet (EDIINT), a working group of theInternet Engineering Task Force (IETF) for developing secure and reliable businesscommunications standards.The added value of AS1, AS2 and AS3 is the fact that they offer so-called “non-repudiation”: on successful physical reception of a file a receipt is sent back in return,through which it is indisputable that the message has been sent and received. Thesework with certificates on both sides, so all parties can authenticate themselves in atrusted and secure mannerAs security is a hot topic when it comes down to communication, guaranteeddelivery is one when it comes to transportation.The basic way to ascertain guaranteed delivery is to receive notifications for eachmessage having been delivered, from the recipient. This way theres always proofthat a message has been delivered. When e.g. an order appears to not have made itto the warehouse it saves a lot of time when the sender has a receipt of the actualmessage sent that contained the orderIn the old days proof of delivery was given by keeping log files of messages sent andreceived, using checksums, etc. Proof of delivery was something that could berequested in exceptional situations, with manual intervention by people. With the useof a.o. queueing systems such mechanisms became built-in, and nowadaysguaranteed delivery is something that has moved from being available in exceptions,to becoming part of the ruleAgain, on the transportation level: a good diversity in between them all, and acommon subset needed in order to be able to share the same means ofinformation exchange. Next up: how to link messaging to transportation___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

17 / 32 8. History of the last decadesIn the first seven chapters, the approaches to Integration have been shown. Thearchitectural top-down approach, the common subset theme, and the centralintegration methods: messaging, transformation and transportation.Now the approach to successful integration has been set out, a brief story aboutintegration in the real IT world, over the last decades, is in its placePoint to point interfacingPoint to point connections, is a term that describes how applications can beconnected. Point to point interfacing was commonly used to link applications together"in the early days", and was a reasonable solution as long as the scale of integrationstayed smallPoint-to-point interfacing involved applications having to speak each otherslanguage; the resulting IT-landscape was a tightly interwoven one, where a lot ofeffort and time was spent in information exchange. Replacing an application byanother one meant that all connected applications had to change their interface to itat the same time.Point-to-point interfacing has proven to be complex, costly and unreliable for anymid-sized enterprise or up.Point-to-point interfacing lacked centralisation and standards, making it very hard totrace and solve issuesThere is a formula for point-to-point interfacing: it is n * (n - 1)That means that for every connected / interfacing application in an enterprise, thereare n * (n - 1) connections: each application (n) needs to support an interface to allother applications (n - 1)___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

18 / 32However, the enterprise formula is not that interesting: the formula that is valid foreach connected application, has far more impact: 2 * (n - 1)That means that every connected / interfacing application has to support 2 * (n - 1)interfaces: 1 * (n - 1) to give information to all other applications connected (as ananswer to their request), and 1 * (n - 1) to do so the other way around (requesting ananswer from them)Point-to-point connections thus posed a considerable problem to a company: themore widespread its usage became, the harder it was to maintain and monitor.It in fact reduced all flexibility with regards to upgrading or replacing applications toalmost zeroMoreover, point-to-point connections are hard to build, as they form a direct linkbetween 2 applications: the combined knowledge of both applications is needed tosupport themPoint-to-point connections are hard to support, as theyre usually built astemporary interfaces without much documentation, although that is just a historicalnote and has little to do with the (lack of) success of point-to-point interfacesthemselves.Point-to-point connections are hard to control, as theyre mostly built on top of anexisting application, meaning that a proprietary application has to bend and stretchitself in order to comply with another application, and vice versa: and that repeatedmany timesAs an answer to the problems point-to-point interfacing caused, EAI was developedEnterprise Application Integration (EAI) is a term that describes how applicationscan be connected. EAI is commonly used to link applications together, and is ananswer to the disadvantages of point-to-point interfacing.EAI introduces a centralised hub, that takes over the interfacing effort from thesurrounding (i.e. connected) applications. Not only is the translation performed by thehub, but centralisation also manages to bring a great span of control to an enterprise.Within the hub, there usually still is point-to-point interfacing involved.However, EAI-tools are very well suited to do so, thus lifting the burden fromapplications to the right place.With EAI, replacing an application by another one means that all connectedapplications dont have to do anything: only within the hub an effort would have tobe made.EAI interfacing has proven to be complex but very cost-efficient. However, it didntsolve the diversity-problem___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

19 / 32There is a formula for EAI: it is n2That means that for every connected / interfacing application in an enterprise, thereare n2 connections: each application (n) needs to have an interface translated by thehub for each application (n)The enterprise formula for EAI is thus greater than that of point-to-point interfacing;on the other hand the formula that is valid for each connected application, hasbecome smaller: nThat means that every connected / interfacing application has to support ninterfaces: 1 to give information to all other applications connected (as an answer totheir request), and (n - 1) to do so the other way around (requesting an answer fromthem)EAI connections are hard to build, as they form a direct link between 2 applications:the combined knowledge of both applications is needed to support them.EAI connections are easy to control, as theyre centralised in one tool and place.As an answer to the problems EAI interfacing didnt solve, ESB developedAn Enterprise Service Bus (ESB) is a virtual bus through which services travelwithin an enterprise. • An ESBs primary goal is to offer a very high degree of standardisation • An ESB encompasses services, which are usually, but not exclusively, Web servicesThose services are wrapped in envelopes which are usually, but not exclusively,designed according to SOAP.Theres no consensus about whether an ESB does, or doesnt, transform messages.Some say its not part of it, others say it is but that it should happen "outside the bus".___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

20 / 32The strict version of an ESB is that the connected applications all comply with thestandard message and protocol used in the bus, and the ESB itself only routes themessages - establishing a clear difference between itself and Enterprise ApplicationIntegration (EAI)There is a formula for ESB: it is nThat means that for every connected / interfacing application in an enterprise, thereare n connections: each application (n) needs to port their own interface to the bus.On the application level, the formula is also n.That means that every connected / interfacing application has to support n interfaces:1 to give information to all other applications connected, and (n - 1) to do so the otherway around.Formula-wise, ESB is the best of all solutions so farESB connections are very hard to build, as they require the ability to support highlycustomized messages from just day-to-day applications. ESB connections are hardto control, as theyre mostly built on top of an existing application.ESB services involve applications having to speak the language of the bus; withthis approach, IT is in fact back to the point-to-point interfacing of somedecades ago, although the diversity in messages exchanged has now becomeslightly less. On the application level, a lot of effort and time is spent in informationexchange.Replacing an application by another one means that the new application has tosupport all the existing interfaces in the IT-landscape before it can be connected.ESB is a very nice thought on the IT enterprise level, were not much has to be done:on the application level however, ESB interfacing has proven to be very complex,costly and time-consuming. Most applications, that arent specialised in creatinghighly customised interfaces, produce unstable and unreliable interfacesFrom a business and ROI point of view, pure ESBs are financial disasters___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

21 / 32In the next chapter, which will be slightly shorter, the differences between allthese approaches, and of course the pros and cons___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

22 / 32 9. History with hindsightIn the previous chapter, the history of Integration passed: point-to-point, EAI andESB. For those who read and grasped chapter 1 through 7, itll be clear why I favourwhich one - but let me explain it in more detailWhat are the differences between the different historical approaches?The crucial difference is that EAI describes a hub and spoke architecture, whereproprietary messages to and from applications are translated by a central integrationbroker. Yes, that is the European Parliament chapter, among othersAs described, applications can plug in and out of the landscape this way, and thenecessary transformation of information is taken care of by the central hubIn an ESB, there is no hub: the hub has become a bus. Transformation ofinformation is done by the applications themselves, who thus custom-built their(small) integration engine which does the job. If you want to plug into the Matrixthere, you have to follow all the courses - and that takes a lot of time and money,unlike Neo learned combatThere are advantages and disadvantages to EAI as well as ESBGreatest advantage of EAI is its cost effectiveness, and the fact that it can supportjust about anything.Greatest advantage of ESB is the fact that it doesn’t support just about anything, butneeds and enforces a highly standardised environmentThe biggest disadvantage of EAI is the fact that scalability might become an issuebecause everything goes through the central hub, but that worry was years ago. Thebiggest disadvantage of an ESB is the fact that there are either numerous andvarious integration brokers in the landscape, each tightly coupled to the applicationsthemselves, with a highly specialized knowledge required, and a lot of licensing costsinvolved, or add-ons to existing applications and systems that might not be part of thedefault architecture in mind.___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

23 / 32In either case, theyre mostly uncontrolled, bespoke, and hard and costly to maintain.And basically, in this scenario, the ESB does nothing else than route messages -now how exciting is that?From an IT enterprise point of view, there is not much of a difference betweenproperly conducted EAI and ESB: applications are decoupled and accessible viaservices (or standardized interfaces) and as such appear to be plug-and-playable tothe business. From a business PoV, however, cost plays a role, time-to-market, andflexibility: and thats where pure ESBs lose hard, compared to EAIIt is somehow even strange that EAI has been “followed up” by ESB, as hardwarecosts have dramatically decreased over the last few dozen years.On the other hand, integration has become so obvious that most packages nowoffer a small integration suite with the system itself. However, these are still asmonolithic as the majority of those systems themselves, and never capable ofhandling enterprise-wide integration if there are more packages involved than justtheir own (cf. SAP XI / PI. Getting better every year, they pale in comparison tointegration brokers 15 years ago). They are small message brokers, capable of doingsome lightweight transformation at bestIn order to make ESB viable, integration suites coming along with entire systemsshould be fully able to handle Enterprise Integration, and they should be included inthe system, not sold separately as an option. If it’s not part of the default package,where is the benefit? In the 21st century, every single application should be able tointegrate with other applications by "disclosing their functionality" in the form of amessage.Message transformation will always be necessary, as there can be no such thingas a worldwide agreement on business documents, as the experience of the past 30years has clearly shown. No matter which standard exists, parties will always maketheir own subset, or grow away from it; compare this to the average dictionary thatdescribes a full language, and of which no more than very small subsets are used inday-to-day communicationSo, currently, put your money on the hub-and-spoke architecture of EAI, due tothe fact that it is still very -very- costly to realise a true Enterprise Service Bus withinmost companies the pure ESB way. It is far easier, faster and cheaper to use the EAImodel and a Canonical in order to achieve a uniform language across your diverseIT-landscapeIn chapter no. 10, Ill address the magical mechanism that enables all of this: oneuniform business language across an ocean of diverse IT applications, messagesbeing translated from any language into an intermediate one, and everything beingseamlessly transported from A through B and back to finally Z; the most importantpart of integration, usually if not always forgotten:the envelope___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

24 / 32 10. The missing link: envelopeWith a common language, a common transport protocol, and the need to exercisethe necessary translation and transformation on both levels in between, there is agrowing need to be able to identify all "service requests" on a generic level tooNumerous and various requests will be made, in different formats, via differenttransport protocols. This certainly is not Utopia, but a pragmatic observation that ismaintained in almost an evolutionary way: within successful companies IT systems,like people, are selected based on professional excellence (meaning specialistinstead of generic properties).Excelling in one area usually means being moderate in a few others, and beingcapable of good and generic integration is usually one of those. Intellectualsupermodels, and good-looking scientists: they are either scarce or non-existentWhen all those requests are being made in different ways too, it becomes nearlyimpossible, but at least very time-consuming and costly, to collect and streamline allthe information. Whatever the flexibility on the messaging and transportation levelmay be, addressing all those variations must be made possible in a generic andstructured wayIn the ideal world, all service requests are sent in an envelope, like in the old-fashioned mail. Like in the old-fashioned mail, however, we already see standards ona national level conflicting with those of another country, so even there is no uniformenvelope-definition on a global scale. However, the differences are minimal. Anyonecan deliver a letter anywhere in the world, simply by reading the envelope - how coolis that? The wheel is there, extremely round, and has been for centuries, if notmillenniaWhat needs to be on an envelope? Recipient is a must, Sender would be nice ifyou want to get feedback, some unique reference and a date timestamp would makeit complete. Look at an envelope, and youll see it all there: a recipient, a sender, anda unique address in 4 stages: country; zip; street and number. In fact, the countryindicates how the address is exactly made up: cant use a UK address notation for anNL address, or vice versa. Just do in Rome as the Romans do...The envelope will conceal any diversity and carry across anything. Itsarchitecture and design is so splendid and loosely coupled, that it even allows for___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

25 / 32letter bombs. Of course those are lamentable, but it shows the awesome power of asimple yet sufficient and efficient mechanism.Theres only one but: global mail is just one way of delivering a message. Theresalso UPS, DHL, small couriers, troikas and rickshaws: they need "an envelope" aswell.Then, the big problem has to be tackled: what if your envelope isnt equal to myenvelope? Yet again, the answer to that is in the FAQIf you order a book at Amazon, they look it up. They put it in a brown carton, andput a barcode on top - Amazons own envelope. At the doorstep of Amazon, e.g.UPS picks it up. They put the brown carton inside a plastic bag, and stick abarcode on it that is also humanly legible - UPSs own envelope. Across borders,national couriers take over. They probably just turn the plastic bag around andslap another barcode sticker on it - their own envelope.So, history repeats itself: each envelope is wrapped in another one. What does thefinal recipient do? As he is the only one interested in the package content itself, heunwraps all envelopes. As he has no need for them in the future, he throws themawayBeen there done that, havent we? Lets compare that to our favourite mailman • You have a letter, which you put in an envelope • The envelope makes it to the mailbox • When the mailman makes it to the mailbox, he takes out his own envelope and wraps that around all other envelopes. That envelope is what people usually call a mailbag. He tags the mailbag so he knows who the sender was (this very mailbox), thus adding Sender, unique reference and date-time • At the post office or sorting center, he unwraps the envelope / empties the mailbag. The content gets sorted, and makes it into other envelopes: mailbags to carry them to the final destination • Those envelopes make it to distribution centres, are once more emptied, and sorted again into smaller portions, fitting a street or district / quarter • The mailman delivers the envelopes to their addresses, et voila, done dealSo, another mystery solved: 1. An envelope will be the link between messaging and transportation, and survive transformation 2. All attributes on an envelope are mandatory, well-defined and highly standardised 3. If its not your envelope, just wrap your own around it 4. If you want to read its content, youll have to unwrap all other envelopesNext: messaging, transportation and envelope collaboration bringing you100% BPM, SOA or EDA___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

26 / 32 11. OrchestrationIve compared the diversity of an IT application landscape and managing itsinformation exchange in a uniform way to translation, with the European Parliamentas a perfect example of translating dozens of languages via three intermediatelanguages. In IT, we only need one, as languages (syntaxes) there are far lesscomplex than in the linguistic worldIve used a similar metaphor to explain how different transport protocols can behandled, by referring to James Bonds opening scenes, where he takes all kinds oftransportation in order to escape death. He simply manages by getting off one kind oftransportation, and getting on another one. Clever hey?In the previous chapter, Ive explained the no. 10 of Integration: the envelope. Iexplained that mechanism that neednt be explained by pointing out how theeveryday mailman handles letters, by wrapping and unwrapping envelopes overenvelopesTogether with the hub-and-spoke architecture, it is evident that an IntegratedEnterprise needs a single point of entry for all this to make real sense. An airporthas one control tower, a house has one front door, a lock has one keyhole, alabyrinth has one centre, a process has one starting point, everything has abeginning and an end...And an orchestra has one orchestratorWith all interfaces and services passing through the same Enterprise Integration frontdoor, they can be perfectly orchestrated. There will be many points of physicaltransport entry, and these will have to guarantee delivery to the singleOrchestration point of entry. Every single message can then be received,transformed and routed to its destination point. There, business logic will be applied,and something will be sent back in return: a technical confirmation receipt, afunctional acknowledgment, a reply to a request, an error: all that is up to theagreements made between the sender of the message and its recipient.___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

27 / 32They will make it past the Orchestrator again, completing the transaction, who thenhas to guarantee delivery by the many points of physical exitThis way, everything going on externally and needing your business processtouch, will be handled by one single person - well itll of course be a machine, butstick with me please. Will that effectively give you the ability to manage thoseexternally offered business processes? Yes. Maybe manage is a big word, but it willgive you full traceability over them: youll know who did what when, what and whenthe outcome to that was - it will all pass the Orchestrator and you can decide to keepthe record of that foreverWhat if youd also send and receive your internal service requests through theOrchestrator? Dont mention the O-word nor the P-word (Overhead andPerformance), just think about it from a logical, conceptual point of view.Would it be possible? I think so, why not? Would it be helpful? I think so, why not?Would it give you Enterprise-scale BPM via a small-step approach, where you cantake one application or system at a time? YesTick of the BPM box right there then, no need for massive million dollardevouring seemingly endless big bang projectsIf you dont do the BPM, but just stay there, with all externally-used and internallyused service requests routing through one and the same Orchestrator, wouldnt thatbe a nimble yet full-blown SOA?Wouldnt it? YesTick of the SOA box right there then, no need for massive million dollardevouring seemingly endless big bang projects___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

28 / 32 12. The donts of IntegrationThis chapter is about debunking TLAs and FLAs. XML, SOAP and REST primarily,but Webservices and other concepts whose added value is flimsy or even absent, willget proper attentionXML is a syntax, making it part of the Integration messaging themeBack in 2000, when I started to say that XML doesnt add anything to Enterprisebusiness application integration other than overhead, complexity and confusion, themost-heard pro of XML was "its the language of the future"I always responded with "I cant do business with the future, can I?" and explainedhow 1,000 years ago we Europeans (economically, politically) all spoke Latin inEurope, followed by French in 1700s, and English in 1900s, without anything everchanging to (economical, political) business itself as a result.Was there a businesscase for speaking the new language? At some point, when agrowing minority started to speak it, yes. Has this ever been the case with XML? No,never. And it never will:Google never used XML, didnt even think about it. Twitter deprecated XML use in2010, and Facebook is doing so now. Google moved to a proprietary format, Twitterand Facebook "will go flat-file": JSONDont use XML for Integration. It is nice for humans to read, but in the machine-to-machine integration world, it has failed to prove its value in the last 10 years- because there is no valueSOAP cant be placed in any of the Integration themes (messaging, transportation,transformation). It touches some aspects of The EnvelopeSOAP was originally started in 1998 by Microsoft as an attempt to do what it says:Simple Object Access Protocol. W3C adopted it to describe exchanging structuredand typed information between peers in a decentralized, distributed environment.It is an exchange mechanism, but relies exclusively on a fixed message format (XML)and a fixed transportation protocol (HTTP). Its main focus is on the SOAP envelope,yet doesnt describe that at all: the only mandatory thing in there is the wordEnvelope itself.___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

29 / 32Everything SOAP tries to implement has already been taken care of by SMTP, thetransport protocol used for email, in a far better, standardised and successful way.SOAP will cause you to reinvent the wheel and describe your own envelope, yet tieyou down with highly interpretable mandatory or optional elements. Will it audit orcertify your SOAP inventions? No. So whats the use?Dont use SOAP for Integration. It restricts you to one message syntax, onetransportation protocol, and leaves it up to you to reinvent your own SOAPthing. It has failed to prove its value in the last 10 years - because there is novalueWeb services cant be placed in any of the Integration themes (messaging,transportation, transformation). Like SOAP, they focus on a very fixed tech solutionfor unknown business problemsW3C defines a Web service as "a software system designed to support interoperablemachine-to-machine interaction over a network. It has an interface described in amachine-processable format (specifically Web Services Description LanguageWSDL). Other systems interact with the Web service in a manner prescribed by itsdescription using SOAP messages, typically conveyed using HTTP with an XMLserialization in conjunction with other Web-related standards".Whats the goal? The point? What are the alternatives? Why is this the best solution?Every single format can be processed by machines, if -and only if- it can beunderstood and agreed upon by humans doing business. W3C doesnt knowanything about doing business, and XML, SOAP, WSDL, UDDI and Web Services allwere invented by themDont use Web services for Integration. They restrict you to one messagesyntax, one transportation protocol, one way of writing down your web service,and leave it up to you to reinvent your own web service. It has failed to proveits value in the last 9 years - because there is no valueI have struggled to write this down, as a chapter with a subject like this basically onlydestroys. There is one big positive thing to mention: all these concepts were inventedby W3C. Tim Berners-Lee heads that organisation, who accidentally invented theInternet - so thats why people put value onto W3C conceptsWhat these acronyms all have in common, is inventing their own way of layingdown the exact structure of How things should be said - without taking intoconsideration What can be said___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

30 / 32 13. The dos of IntegrationFinal chapter, this is the summary and conclusion, to be used as some sort ofchecklist if you likeWhen conducting enterprise business application integration, within theenterprise IT landscape among applications and systems, or from there to others atanother company or even directed towards the customer, here are the pragmaticrules:Start at the business level, and write down which process it concerns. What is thebusiness event, which its trigger, how often does it occur, how sensitive is the data?Why should this be automated, in other words, what is the manual alternative and thebenefits and concerns of both?Write out the functionality it concerns. List the entities, their cardinalities, and allattributes concerned, and describe them as complete as possible. Heres an exampleThere are about 20,000 employees, each one of which has 1 or 2 addresses, andworking on 1 to 5 assignments. The employee data has attributes, of which thefunctional description is shown.At this level, anyone can read and understand what is to be exchanged: businesspeople, tech people, inside people, outside people, suppliers, customers: everyoneDepending on the bsiuness goal, some of these will be required, and somewont: specify that as well. When creating a new employee, First name, last nameand personal ID will be required, but not an employee number: that will be handedout by the system. When modifying an employee, that employee number will berequired, including the last name, but perhaps not the personal ID.So, for the intended business goal, write down which attributes are required andwhenThen, with this Information list in hand, make the transition to the systems onboth sides: do those requirements meet and match on both sides? If so, you can dobusiness, if not, you have an issue. This indeed means that business agreement,functional analysis and information system (gap) analysis is part of the preliminaryphase and could result in the conclusion that business simply cant be done___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

31 / 32If successful, both sides will add their information system requirements (theseare actually limitations) to the Information: Last name will be 30 characters in onesystem, and 25 in the other - what to do? Is the business agreement still in place ordo we have to revise it?Apart from the messaging level, there will now be limitations on the transportationlevel as well: what are the existing possibilities to get messages across? Datasensitivity as defined by the business will lead to transport security and encryptionand access restriction requirements, and these will meet limitations: again, thecommon subset has to be found.Again, is the business agreement still in place or do we have to revise it?On both sides there will now be a full technical description of the interface,complete with field length, datatype, format. The business frequency and the givencardinalities will give a rough guesstimation of the resulting file size, thus the volumeand load, making it possible to calculate storage requirements and capacity planning.Files will have to be kept online for a certain amount of time, and archived as well,depending on compliancy requirements the business has to follow up - all that costsspace as well.For the transformation into an intermediate language, this will have to berepeated of course. Here the IT department will mostly determine how long thesehave to be available. If used as basis for a full-blown BPM, the underlying processeswill drive these requirements too, although files should only be used for resending(on failure) and "evidence" of what was received and sentAt this point, the issue arises: what file format and transportation protocolshould we use?Which ever ones are most practical and pragmatic, will be the answerFor A2A (application-to-application, a TLA used to describe internal integration) theusual pick will be flat-file for the message and shared folders for transport. A flat-filecan be a CSV, a fixed flat-file, JSON, whichever makes you feel good. Maybe its anXML, an iDoc: all that is up to the applications themselves. When you use anintermediate language and a canonical model, you will have to choose a file formatyourself.If volumes and frequencies are high, a more sturdy transport protocol might berequired; thing of queueing mechanisms. XML will definitely pose capacity andstorage problems there, ask Google, Twitter and Facebook and companies in thetraditional B2B areaIf one of the A2A interfaces "makes it out there", i.e. is a candidate for exchanginginformation with external parties and you engage in B2B or B2C, the question of fileformat and transportation protocol will arise once again - just in a different context.What is most appropriate then?Again, do in Rome as the Romans do. Speak X12 in US industries, EDIFACT inEurope, Swift in banking, HL7 in health, etcetera. Transport? FTP or FTPS for static___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

32 / 32solutions, HTTP for more dynamic ones and AS1 or AS2 for the "bigger boys". Treateach of these questions as a simple daily one: should I pick UPS, global or local mailor courier to transport my package? That of course depends on what the package is,and how fast it should get somewhereLast but absolutely not least, you should define an envelope for each interface:who is the sender, who is the recipient, what does it contain? This will enable you toroute its contents freely across the globe, just like SMTP (email) does, withoutopening the envelopes and looking at the letters. Dont address envelopes to URLsor other silly notations, youre doing business with an organisational entity, not amachine: let the organisation make up where exactly they want to route their stuffinternally, but keep that transparent for the outside worldIn an effort to keep this chapter short, Ill just mention that business integrityrequirements will lead to business rules and exceptions, which can be translated intoerror handling and (user) feedback on a functional and technical level. These willlead to functional and technical acknowledgments on the interface level, retrymechanisms when a file cant be sent out, and exception handling and agreementsfor that.To really define the interface, the byte-level has to be spelled out as well: charactercode (ASCII or UTF-8, EBCDIC or UCS-2, any other flavours), hexadecimal form ofdelimiters, periods or commas, etcetera: the real dirty stuffThis concludes my thoughts on Perfect Integration. I hope I touched all possiblequestions and answers, and helped unravel the mystery of buzzword Three LetterAcronyms. I think I have reached a satisfactory level of detail without losing yourattention - but youll be the judge of that___________________________________________________________© Copyright 2011 – Martijn Linssen martijnlinssen.com

Perfect Integration

by Martijn Linssen

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

Perfect Integration Document Transcript