Implementing SOA in an ESB Framework

1,400 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,400
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
61
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Implementing SOA in an ESB Framework

  1. 1. T-76.5650 SEMINAR IN SOFTWARE ENGINEERING, SPRING 2006: Implementing SOA in an ESB Framework 1 Implementing SOA in an ESB Framework Miikka Lötjönen Abstract—this study is an introduction to Service Oriented Listener Architecture (SOA) and Enterprise Service Bus (ESB). It starts Loose Coupling from business needs; why are SOA and ESB needed in the first Message place. Main concepts, related technologies and benefits of SOA Orchestration will be introduced. Two typical software engineering problems are taken as practical examples that could be solved with SOA – Persistence in this case ESB-driven Web Services. For selecting the ESB Point-to-Point framework, an evaluation of the ESB products on the market is Publish-and-Subscribe conducted. The approach is practical: two implementations will Routing be done with the selected frameworks. Scalability Schema Index Terms— Service Oriented Architecture (SOA), Web Services (WS), Enterprise Service Bus (ESB), Simple Object Service Access Protocol (SOAP) Store-and-Forward Synchronous GLOSSARY Transformation EJB Enterprise Java Bean XPath ESB Enterprise Service Bus 1. INTRODUCTION EAI Application Integration J2EE Java 2 Enterprise Edition 1.1 Description of the Environment JBI Java Business Integration As a motivation to this study, we begin by introducing the JCA J2EE Connector Architecture (also J2CA) company and the various challenges it is facing. For security JMS Java Message Service reasons, the company and its projects that are discussed are JNDI Java Naming and Directory Interface not mentioned by name. The company is simply referred to as MOM Message Oriented Middleware “the company” and projects are named “Project D” and PTP Point to Point (also P2P) “Project M”. Everything is based on reality, but some parts of QoS Quality of Service the environment and the projects are deliberately simplified RPC Remote Procedure Call and generalized, to keep the focus in the essential things. SOA Service Oriented Architecture Although the aim is to solve the problems of this company, SOAP Simple Object Access Protocol the discussion is kept in a generic enough level to be applied UDDI Universal Description, Discovery and Integration to other environments. W3C World Wide Web Consortium The company in its current form is the result of a recent WS Web Service merger that united many smaller companies working in the WSDL Web Service Description Language same business area. This has created a highly heterogenic XML eXtensible Markup Language environment; the company is distributed geographically and XSLT eXtensible Stylesheet Language Transformation organizationally. Although the company is working with one name, it is divided into 21 sites in 8 countries, all of which Concepts to be explained: have their own projects, processes, technologies, tools and methods of working. Also the projects inside one site are Adaptor somewhat independent of each other, but sometimes would Asynchronous benefit from reuse between them. Auditing From the technological point of view, the types of variation Bean (EJB, XML) between the sites are numerous. Within the company, various Bridge types of architectures, platforms, frameworks, applications, Broker tools, and programming languages are used. In most cases, Channel there are no common interfaces to help inter-operation Cluster between the systems. The situation is acknowledged and the Container (EJB, ESB) direction is towards integration, but the change is slow. Endpoint Concrete actions are needed to help this process and leverage Legacy Application the existing solutions. Integration is the actual issue that this
  2. 2. T-76.5650 SEMINAR IN SOFTWARE ENGINEERING, SPRING 2006: Implementing SOA in an ESB Framework 2 study addresses; two example scenarios are taken into closer chapter 4. inspection. A Web Service is of the possibilities to implement SOA. Enterprise Service Bus (ESB) is a Service Oriented 1.2 Project D Overview and Problems Architecture that can be implemented with an ESB The company is in service business; both of the discussed framework. projects will result in a service for end users. The end product In both projects it was decided that a Web Service would be of project D is a java-based application, running on an implemented, but the developers weren’t yet assigned for this. application server. The importance of the service that this After some discussions it became my responsibility to learn application is providing is growing in various other projects of about the subject, make a decision about the framework to be the company, and it is necessary to make it more accessible used, and then develop the services. from various different systems. The goal is also to make servers easily replicable, add a possibility for clients to use 2. OBJECTIVES AND SCOPE OF THE STUDY multiple servers, and extend to support command line interface. The main problem is therefore accessibility. 2.1 Objectives The problem is that if this kind of extensions to support The primary objective is to investigate and report the new ways to access the system is implemented in the possibilities of Web services, SOA and ESB. The secondary traditional methods, each additional access method will objective is to present practical solutions to practical produce extra cost, extra work and extra maintenance. In the problems: 1. ESB framework selection, and 2. worst case, the new applications must be implemented as implementations of two example scenarios. separate applications. New interfaces and data exchange Besides this paper to be published, the study process will methods have to be introduced. Maintenance costs will grow also produce source code architectural descriptions as as new components with dependencies to the old ones are deliverables to the company. introduced. All of the things mentioned above add to the complexity of 2.2 Research questions the product. A good solution would be if it was possible to use 1. What are the needs and problems of the current the same application for everything, and interact with many environment (i.e. architectures, tools and methods different clients through the same interfaces. Even a better currently used in the projects)? solution would be if these interfaces were standard-compliant. 2. How can the current environment be improved Much of the effort could be saved through using standard off- through SOA and ESB? the-shelf tools to handle the interaction between the server and 3. What are the requirements for an ESB framework? clients. 4. Which ESB framework would be the most suitable? 1.3 Project M Overview and Problems 2.3 Scope The corporation has an online portal with all the The research paper started with a short introduction to the applications bundled into the same platform. Now a new projects and their needs, followed by some discussion about project created in a subsidiary of the corporation needs to the reasons that drive this change towards SOA. The reasons connect to this system, to be able to access customer will be further discussed and later on used as bases when information etc. defining criteria for the evaluation. The portal is running on a commercial J2EE application Due to the broad range of possible themes, neither SOA nor server that the Project M will not be using, and there are no Web Services will be covered extensively. There will be an ways to access the databases from the outside. To add a bit introduction to both themes that will serve as the motivation more challenge, the operation platform for the new project is for doing things “the SOA way” in these two example yet to be defined. An inter-organizational, platform projects. Enabling technologies such as XML and SOAP will independent, and very scalable A2A solution is needed. The be discussed in the detail that is necessary to describe the main problem in Project M is therefore integration. overall functionality of Web Services. ESB will be introduced through its relation to SOA. ESB 1.4 Field of study frameworks will be introduced from two viewpoints; first For both of these tasks, Service Oriented Architecture describing them in generic terms, and then finding out how (SOA) seems to offer a good starting point, and it is actually they fulfil the company-specific and project-specific needs. the basis of the corporate-wide reference architecture. The details of the ESB frameworks are left outside the SOA is and architectural style whose goal is to achieve scope. Although the practical part includes digging pretty loose coupling among interacting software clients. (viite deep into the products, the findings are covered only in the jostain ns. Arvostetusta julkasusta) The main business drivers extent that is needed to make the conclusions about which of SOA are flexibility and efficiency. Flexibility comes mostly software package to use. The documentation and examples from the abstraction that an SOA offers. Efficiency is the that are available online, will be referred to, but not described result of using standards-based approach and reuse. SOA and as a whole. the related concepts and technologies are introduced in
  3. 3. T-76.5650 SEMINAR IN SOFTWARE ENGINEERING, SPRING 2006: Implementing SOA in an ESB Framework 3 Although the research will result in source code and 4. SERVICE ORIENTED ARCHITECTURE OVERVIEW architectural descriptions for both example projects, these will not be provided except for generic principles behind them. 4.1 Introduction Service oriented architecture is actually nothing new. It is 3. RESEARCH METHODS AND STRUCTURE OF THE REPORT more of a collection of principles and a way of thinking than a The structure of the paper is briefly described, linking it to real technology. (He 2003) explains SOA quite well, with the objectives of the study and research methods. examples. The paper will be a constructive study that addresses both List basic concepts, benefits and drawbacks. theoretical and practical issues. It is roughly divided into (Doernhoefer 2005) is a very high-level description about literature study and empirical work, but due to the practical SOA and online resources concerning SOA. Another good nature of the subject, the themes will undoubtedly overlap. source of basic information is IBM’s (Gottschalk et al. 2002). The approach to the theme is practical. During the study 4.2 Why SOA? process I came to realize that there is a great deal of general • Company-wide benefits information about SOA and software architectures. Also there • Project D benefits are plenty of documents in practical level, such as tutorials on • Project M benefits how to implement web services. • (Moad 2005)describes the benefits of SOA. If you are new to the field, many times the generic • (Linthicum 2003) describes application integration descriptions are too general to serve as understandable through Web Services introductions, and the technical details are too narrow and • (Leymann, Roller & Schmidt 2002) introduces SOA detailed to provide the overall view. I figured that there is a from the business perspective gap to fill in. I wanted to present the big picture, starting from ideological principles, presenting the essential things that are 4.3 SOA and Patterns needed to know and wrapping the presentation up by Many features of a SOA can be described by using design implementing useful things following these principles. patterns. There are many types of patterns, for different uses. (Hohpe, Woolf 2005) introduces an extensive set of Enterprise 3.1 Literature Study Integration Patterns that are the basis for many SOA/ESB The literature study is an overview of SOA, ESB and concepts, for example messaging patterns. related technologies. Chapter 4 serves as introductory material to the problem domain, introduces the challenges in traditional 4.4 SOA and Java Enterprise Edition methods and explains the benefits of SOA. The following SOA is often mentioned in java context. This is only chapter 5 is a short market overview of SOA product support. because of Java’s popularity as a programming language. Now that some background information has been provided, SOA itself is an architectural style, and is not bound to any chapter 6 gives an overview of Enterprise Service Bus and the programming language or protocol. As mentioned before, implementing products. The relation to SOA is explained, SOA doesn’t even have to be implemented with an object together with illustrations and examples. The chapter prepares oriented language; internal details of the services are ignored. for the practical part of the study, by giving criteria and Focus is on component level, interfaces, architectures and reasoning for ESB product selection. Two candidates will be integration approach. selected for further inspection. 4.5 SOA and Web Services Addressed research questions: - Question 2 in chapter 4.2 • A short introduction to Web Services, referencing to - Question 3 in chapter 7.1 (Alesso, Smith 2005). • A bit more technical point of view in (Farrell, Kreger 3.2 Empirical Work 2002). The case company, projects and problems have already • Mentioning Semantic Web as described in (Daconta, been analyzed in chapter 1. Most of the actual empirical Orbst & Smith 2003) and (Korotkiy, Top 2006). material is presented in chapter 7 in the form of evaluation 4.6 SOA and Supporting Standards between two ESB framework candidates. Most of the Extensible Markup Language (XML) has become very discussion is based on the example scenarios that are popular as a data exchange language, and it is not a big implemented. surprise that it is also an essential part of many SOA Addressed research questions: implementations. XML is a simple, text-based, generic use - Question 1 in chapter 1 markup language that is used to describe data through user - Question 4 in chapter 7 defined tags. XML is a cross-platform, software and hardware independent tool for transmitting information. The universal nature of XML is also the biggest strength of the language; it can essentially describe anything you want. The grammar that defines the allowed tags and their
  4. 4. T-76.5650 SEMINAR IN SOFTWARE ENGINEERING, SPRING 2006: Implementing SOA in an ESB Framework 4 relations is described in separate documents, Either Data Type 5. SOA PRODUCT SUPPORT Definitions (DTD) or XML Schema Definitions (XSD) that It is possible to implement an SOA from scratch, but there are defined in (W3 Consortium 2006). XML The focus is on are also standard based tools to help with the process. Schema because it is more expressive and the current W3C recommendation. Schemas can be used as sort of agreements 5.1 J2EE Application Servers between remote applications, and also the validity of the General description. Motivation is that these will be used in messages can be verified by checking the received XML the project M, and also that these products are common message against its Schema. platforms for SOA development. Include references to all the XML helps in transfer of arbitrary data, but still it is just a company websites (currently not listed in the references). data storage format. A communications protocol is needed to Most of the major vendors of application servers and provide the actual transfer services. Also this can be similar products have introduced or announced to introduce implemented in XML: Simple Object Access Protocol their ESB solution. (SOAP) is a commonly used communications protocol that delivers XML-encoded SOAP messages on top of HTTP • BEA Weblogic protocol. It is a platform and language independent way to • IBM WebSphere (referencing (Cuomo 2005)) communicate between applications and send messages. • Oracle Application Server • Visual Studio .NET <?xml version="1.0"?> • JBoss <soap:Envelope • Caucho Resin xmlns:soap="http://www.w3.org/2001/12/soap- envelope" • Apache Tomcat soap:encodingStyle="http://www.w3.org/2001/12/soa p-encoding"> <soap:Header> 5.2 Middleware ... ... • What is the purpose of middleware? </soap:Header> <soap:Body> • Some architectural diagrams ... • ESB frameworks, general description about what ... ESB is. Based on (Chappel 2004). <soap:Fault> ... • Apache Axis, implementation of the Simple Object ... Access Protocol (SOAP). </soap:Fault> </soap:Body> 5.3 Other tools </soap:Envelope> While the commercial development software packages For describing web services, there is a separate language, normally come with a extensive set of tools, the situation with Web Services Description Language (WSDL), which is also open source development is a bit different. XML-based. Due to limited space, I will not introduce more Usually things can be done with very basic tools but the code examples. An example of a WSDL and related SOAP workload can be dramatically decreased with proper tools. envelopes can be found from (Prud'hommeaux 2001). There is no point in writing hundreds of lines of XML with For locating the services, there is a protocol called UDDI notepad, if there is a good XML editor available, or better yet, (Universal Description, Discovery and Integration). a tool that will write these XML files for you. XML Spy is a great tool when writing XML code. It 4.7 SOA Criticism simplifies work and takes care of many routine tasks, such as SOA is a nowadays a fairly well-known way of thinking, creating schemas for XML-documents. but it does not solve all the problems of developing complex Eclipse is a popular, free and powerful integrated systems. development environment (IDE) that has a wide and active The first obstacle is that it takes time to learn it. While community extending the functionality by developing Eclipse learning, the solutions may be far from perfect; it is easy to plug-ins. The number of plug-ins is impressive, with new ones misunderstand or misuse the tools. When starting from an being developed all the time. From the ESB point of view, object-oriented viewpoint, designing a SOA requires a slight Eclipse is a good platform also; many vendors have their change of mindset, and the process can be time consuming. future tools implemented as Eclipse plug-ins. For example It is not self-evident where to use SOA approach and where Mule IDE, ServiceMix IDE, and even the upcoming BEA not. In some cases, such as some time-critical real-time Weblogic Workshop 9.2 are Eclipse plug-ins. systems, it may not work at all. Reusable services sound very good in principle, but in 6. ESB FRAMEWORKS practice, the maintenance may turn out to be more of a challenge than expected, especially if the services go through 6.1 What is an ESB? lots of changes. ESB is not an easy term to define. Just like with SOA, the definitions vary a lot from person to person, and from vendor
  5. 5. T-76.5650 SEMINAR IN SOFTWARE ENGINEERING, SPRING 2006: Implementing SOA in an ESB Framework 5 to vendor. (Silver 2004) discusses this confusion. o Sonic ESB (10 000€ / processor) In most publications, ESB is seen as a lightweight o Cape Clear ESB alternative to monolithic and centralized Enterprise • Open Source Products Application Integration (EAI) broker architecture. An ESB o SymphonySoft Mule framework is an example of Message Oriented Middleware o Apache ServiceMix (JBI) (MOM). o Project Open ESB According to (Silver 2004), an ESB has these four essential o Sun Java Enterprise Service Bus (JBI) capabilities: These are just examples of ESB offerings, and for sure not 1. Universal connectivity of services via XML messaging, the only possibilities. In addition, for example Microsoft interconnecting requesters and providers across diverse Visual Studio .NET and BizTalk can also be used in a fashion platforms and data models, providing a common backbone for similar to ESB. requests, messages, and events. The power of commercial ESB products is that they can be 2. Vendor-independent communications standards, such as integrated easily to the other products of the same vendor. SOAP and Java Messaging Service (JMS). One might imagine that this leads to faster learning due to the 3. Quality of service features, including reliable delivery, similarity of concepts, easier coordination of projects’ transaction management, and scalable performance. components because of well-defined and well-known 4. Service mediation features, providing loose coupling interfaces, and more automated and streamlined development between requesters and providers. because of well-thought integration between the tools. The definite downside of the commercial products is that A list of common characteristics (adapted from (Chappel they are costly. When making decisions about integrating all 2004)) follows: the systems of the company into an ESB solution, investing • Pervasiveness, serves for building integration tens of thousands of euros for an ESB framework may be solutions that can span through the whole justified, but for a proof-of-concept application or a single organization task, it does not seem feasible. This is why all commercial • Highly distributed, event driven SOA. products are excluded from this evaluation. • Selective deployment of integration components. 6.4 Selection of Two Candidates for Evaluation Adapters, distributed data transformation services, Based on previous discussion, two ESB frameworks are and content-based routing services can be selected for further evaluation. Since the two example selectively deployed when and where they are implementations are pilot projects by nature, the company needed does not want to invest in the ESB framework, especially • Security and reliability are basic functionalities of since good open source candidates are available. In this case ESB messaging there are at least two good free options, SymphonySoft Mule • Orchestration and process flow, for managing both and Apache ServiceMix. local and remote services. Mule is based on Universal Messaging Objects (UMO), • Autonomous yet federated managed environment, while ServiceMix is slightly more Java-oriented with its Java brought by loose coupling. Business Integration (JBI) approach. Both frameworks are • Incremental adoption. An ESB can be used for feature-rich, and include support for various types of small projects by separately adding them to the messaging through generic endpoints. Both are java ESB. frameworks, but as ESB products they support applications • XML as a native data type written in any other language. Essentially, they are made for • Real-time insight. For example monitoring the the same purpose, but solve the problems in slightly different data. ways. They can also be made to co-operate; Mule has a JBI binding that enables it to interact with ServiceMix JBI 6.2 Why ESB container, and also Mule code can be reused in ServiceMix • General Description of ESB Pattern, using just like any other JBI components. (Newcomer, Lomow 2004) chapter 4. In addition to these two open source products, a commercial • Benefits option may be evaluated later on. The company is evaluating 6.3 Available ESB Framework Products BEA Weblogic to be the future development platform, and considering this, it may make sense to invest in BEA • Commercial Products Aqualogic Service Bus. Since Weblogic already supports o BEA Aqualogic Service Bus o Oracle ESB many features that ESB frameworks offer, there is no hurry to o IBM WebSphere ESB (referencing (Cuomo do this either. Also open-source frameworks can be used with 2005)) Weblogic. ESB products are mostly used with existing o Fiorano ESB (50 000€ / processor) applications. This means that if the need arises, migration to
  6. 6. T-76.5650 SEMINAR IN SOFTWARE ENGINEERING, SPRING 2006: Implementing SOA in an ESB Framework 6 use the Aqualogic ESB should not be difficult. The benefits of effort that it can not be done in the timeframe of this paper. an ESB increase when the framework is used throughout the They are important things, but for now it is assumed that the company. serious candidates (that are in production use in many companies) will meet the requirements. 6.5 ESB Frameworks Feature Comparison In terms of technology support, the two are almost 7.2 Experience from practice identical. No critical differences can be found. Both either As mentioned before, starting learning SOA and ESB currently support or will support soon most of the major without any training, just reading online materials is not technologies. necessarily easy. Both from ideological and practical Based on (ServiceMix.org 2006) some differences can be perspectives, it is a bit of a challenge at first. found, though. The biggest difference is in the approach: Mule My first attempt designing a SOA ended up with nothing existed well before ServiceMix, which started as a Java but a series of synchronous Web services that were point-to- Business Integration (JBI) container and extended into a full point remote procedure calls (RPC) in nature, and actually the ESB. system didn’t benefit at all from the ESB. It didn’t perform Mule started before JBI even existed, and a new API called content based routing, message brokering, or in fact any of the UMO (Universal Messaging Objects) was introduced. Mule’s advanced features that make ESB worthwhile. architectural design is based on a services container and Also the first steps writing XML Schemas, WSDL files and configuration of message endpoints. ESB configuration files by hand can prove to be trickier than Mule is endpoint centric, while ServiceMix also offers it sounds when started from zero. Once you start integration to Apache Geronimo Application server. understanding how everything works, it becomes more routine In practice, many differences will probably come up due to and you learn things that save time. the different approach. But on paper, both products have a 7.3 Suitability for Project D similar feature set. Due to schedule-related reasons, ESB could not be tested 7. EMPIRICAL EVALUATION OF SELECTED ESB FRAMEWORKS with project D. 7.4 Suitability for Project M 7.1 Basis for Evaluation Some preliminary testing has been done with project M and Criteria Reason it seems that both of the frameworks would be equally Compatibility with This is actually the reason why functional, with Mule maybe being a bit easier to implement. current technology ESB is taken into use (“legacy systems”) 7.5 Subjective Evaluation Compatibility with the To not start using something that ServiceMix with its JBI support is a natural step for technology of future cannot be used with future companies that have their current products running with Java. products products Mule is configured by its own configuration files, making it a Learning curve Many people will need to learn to bit “less standard”, but in the other hand, this approach makes use the framework, and it should the service orchestration almost invisible. No special not cause much extra work. annotations or any other ESB-specific things need to be Quality of documentation is also a programmed in java code. This is closer to the “ESB spirit” of thing worth noting. favouring configuration over programming. The framework is Extendibility and The technologies of future the invisible glue that connects the endpoints together, but is flexibility projects are yet to be undefined, and the framework should stretch separated from the implementation. to fulfil the future needs In the end, both candidates are viable solutions; they have Robustness The services that will be running been proven to do their work well in practice. In terms of on the ESB are critical for the development work, they are both in a mature state, and still success of the company. In many evolving rapidly. Their support for different technologies is cases, 99,999% uptime is required. similar; both of them can be used with the existing software in The ESB must be stable enough to the company. One might even say that it is a matter of taste meet these requirements. which one to start using. Performance Many of the systems that the An important thing in this case is the learning curve. company is developing are Neither of them is really difficult to learn, but it takes time, performance-critical, both in terms and many questions arise on the way. Mule has already been of throughput and response time. successfully used in one branch of the company, so if The ESB should not add too much problems with Mule occur, there is “support personnel” that extra overhead. may be able to help in the same building. • Ease of use, learning curve Performance and robustness testing would require so much • Intuitive interfaces
  7. 7. T-76.5650 SEMINAR IN SOFTWARE ENGINEERING, SPRING 2006: Implementing SOA in an ESB Framework 7 • Programming model He, H. 2003, 2003-09-30-last update, What Is Service- Oriented Architecture [Homepage of www.xml.com], 8. RESULTS [Online]. Available: Answers to research questions are still mostly open at this http://www.xml.com/pub/a/ws/2003/09/30/soa.html [2006, 2006-04-22 19:22] . point of the study when not all the necessary practical parts have been done. Hohpe, G. & Woolf, B. 2005, Enterprise Integration Patterns, 8.1 Selection of the Framework with Rationale 5th edition edn, Pearson Education, USA. To sum up chapter 7, a final selection of a framework will be made. Korotkiy, M. & Top, J. 2006, "Onto-SOA: From Ontology- Mule is selected as the framework for doing the new proof- enabled SOA to Service-enabled Ontologies", Telecommunications, 2005. AICT-ICIW '06. of-concept implementations. This is partly because of its International Conference on Internet and Web features, but mostly because there is more Mule-experience in Applications and Services/Advanced International the company. Since I started experimenting with Web services Conference on, vol. vol. 00, no. -, pp. 124-131. in Mule framework, I got familiarized with it first. 8.2 Two Example Implementations Using an ESB Framework Leymann, F., Roller, D. & Schmidt, M.T. 2002, "Web This chapter will introduce the implementations as UML services and business process management", New Developments in Web Services and E-commerce, vol. 41, diagrams and architectural drawings in the detail that is no. 2, pp. 198-211. needed to give a practical view of the benefits and functionality of ESB frameworks. Some excerpts of source Linthicum, D.S. 2003, Next Generation Application code will be generalized and explained. Integration - From Simple Information to Web Services, 2nd edition edn, Addison-Wesley, United States of 9. SUMMARY AND CONCLUSIONS America. Conclusion will gather the lessons learned during the study and sum up the results from Chapter 8. Moad, J. 2005, "Software architecture", Managing Automation, vol. 20, no. 5, pp. 28-30. REFERENCES Newcomer, E. & Lomow, G. 2004, Understanding SOA with Web Services, 1st edition edn, Addison-Wesley, United Alesso, H.P. & Smith, C.F. 2005, Developing Semantic Web States of America. Services, 1st edition edn, A K Peters, Canada. Prud'hommeaux, E. 2001, 2001-03-26 11:12:20-last update, Chappel, D. 2004, Enterprise Service Bus, 1st edition edn, Annotated WSDL Examples [Homepage of W3 O'Reilly, United States of America. Consortium], [Online]. Available: http://www.w3.org/2001/03/14-annotated-WSDL- Cuomo, G.(. 2005, "IBM SOA "on the edge"", SIGMOD '05: examples.html [2006, 2006-04-22 23:22] . Proceedings of the 2005 ACM SIGMOD international conference on Management of dataACM Press, , pp. ServiceMix.org 2006, 2006-01-01 00:00:00-last update, How 840. does ServiceMix compare to Mule? [Homepage of The Apache Software Foundation], [Online]. Available: Daconta, M.C., Orbst, L.J. & Smith, K.T. 2003, The Semantic http://servicemix.org/How+does+ServiceMix+compare+ Web: A Guide to the Future of XML, Web Services, and to+Mule [2006, 2006-04-21 13:12] . Knowledge Management, 1st edition edn, Wiley Publishing, United States of America. Silver, B. 2004, Enterprise Service Bus Technology for Real- World Solutions, Bruce Silver Associates. Doernhoefer, M. 2005, "Surfing the net for software engineering notes", SIGSOFT Softw.Eng.Notes, vol. 30, W3 Consortium 2006, 2006-02-05 16:44:46-last update, no. 6, pp. 5-13. Extensible Markup Language (XML) [Homepage of W3C], [Online]. Available: http://www.w3.org/XML/ Farrell, J.A. & Kreger, H. 2002, "Web services management [2006, 2006-03-16 12:31] . approaches", New Developments in Web Services and E- commerce, vol. 41, no. 2, pp. 212-227. Gottschalk, K., Graham, S., Kreger, H. & Snell, J. 2002, LIST OF FIGURES "Introduction to Web services architecture", New Developments in Web Services and E-Commerce, vol. 41, no. 2, pp. 170-178.

×