Middleware Technologies for B2B Integration Feras T. Dabous, Fethi A. Rabhi, Pradeep K. Ray {f.dabous, f.rabhi,
[email protected]} School of Information Systems, Technology and Management The University of New South Wales, Sydney, Australia Boualem Benatallah {
[email protected]} School of Computer Science The University of New South Wales, Sydney, Australia November 5, 2002
Abstract Several middleware technologies and frameworks have emerged with the aim to support interoperability between distributed systems and therefore facilitating their integration process. Within the context of Business-to-Business (B2B) e-commerce, this paper reviews the major emerging technologies that support different levels of interoperability that facilitate rapid application development for e-businesses. These technologies are illustrated with a case study in global financial industry with a view to see the efficacy of existing middleware to solve the integration problems between systems within a specific domain.
1
Introduction to middleware for e-commerce systems
Middleware is defined as a set of common business-unaware services that enable applications processes (i.e. components) and end users to interact and interoperate with each other across a network. In essence, middleware is the software that resides above the network and below the business-aware application software [8]. The ideal middleware should mask out the differences in network protocols, operating systems, platforms and programming languages in addition to the quality attributes such as performance, reliability, safety, security and real-time. In other terms, the perfect middleware would make the process and the content connectivity among dispersed autonomous systems as if they are components of the same systems. Middleware is still evolving and it is not mature enough to support higher levels of interoperability abstractions across systems and applications. Within the e-commerce framework, these interoperability abstractions aim at supporting integration between and across different B2B architectures. Benatallah [2] has referred to three variations of B2B architecture type: centralised, federated and dynamic (on-the-fly). The first type relies on a central entity (i.e. organization) to control the global business process. This type focuses on process efficiency by supporting a static, long-termed and tightly coupled relationship among participants (i.e. partners). The second type also focuses on process efficiency but has no centralised control entity. It supports static, long-
1
termed, and tightly or loosely coupled relationship. The last type focuses on transaction efficiency by supporting transient, short-termed and loosely coupled relationship between participants. An e-commerce system comprises four different software layers: infrastructure, content, business process and presentation layers. These layers, which are discussed in [2], reflect the requirement for different levels of middleware support. This requirement is also conformant with the interoperability layers supported by the integration framework which is discussed in the next subsection. This paper is organised as follows: section 2 discusses an existing integration framework for B2B solutions and describes the interoperability layers this framework supports. Sections 3,4, and 5 discusses what we consider to be the three levels of middleware that support the levels of interoperability for B2B e-commerce systems. These three middleware levels, which are the transport, content, and business process levels, are discusses within the context of current and emerging technologies that support each of the interoperability levels. Section 6 presents the capital market integration as a case study with a view to explore the efficiency of existing middleware support to facilitate the integration of different capital market systems. Finally, we conclude with a discussion on lack of a single middleware technology that support all levels of interoperability.
2
B2B Integration
B2B integration refers to the provision of a uniform view of the e-commerce system to the interacting entities involved, e.g., buyers and sellers. B2B integration is also concerned with connecting front-end systems to back-end systems. These systems possibly include legacy data sources and applications or outside partners systems [2]. B2B integration is a challenging task in the Web-based e-commerce era because of the following factors: • Information formats are becoming more diverse. • The information space is large and dynamic. • Semantic integration of data, is far from resolved. • Most systems are autonomous (i.e. their architecture is not centralised). • The integration needs to be simple, fast, secure and adaptable to changes. Integration can be conducted at the various layers of an e-commerce system, using various middleware technologies. The B2B Integration Framework that is discussed in [5] provides integration at these following different levels (see figure 1): Communication Layer (Transport) is concerned with the exchange of messages among partners. Multiple protocols and frameworks have been developed that varies from network level of communication to the distributed objects frameworks. This layer’s interoperability objective is to provide independence from such protocols and frameworks by translating and converting messages between heterogeneous protocols Content Layer (Data) resolves semantic and structural heterogeneity issues. For example, it determines if a document represents a purchase order or a request for a quote or a product description etc. Structural differences arise from the use of diverse information formats. Semantic differences come from different interpretations of the same concept. For example, a data item called “price” can mean a price that includes or excludes tax. Therefore, this layer’s interoperability objective is to provide independence from data models, formats and 2
e-services
e-services
B2B process integration
Content (data) level:
Application X
Application Y
Business process level:
Transport level
Figure 1: B2B interoperability layers languages. Solutions are based on information translation and integration, Examples include wrappers and mediators. Business Process Layer (Process Flows) deals with the semantics of interactions that correspond to joint business processes. For example, the following steps constitute a joint business process: send order, process order, deliver product, make payment. This layer resolves issues such as what is the meaning of a message, what actions are allowed, what responses are expected, etc. Therefore, the layer’s interoperability objective is to allow transparent peer-to-peer interactions with any partners. This is a very difficult problem. Amongst potential solutions are: Application Programming Interface (API), Document-based solutions and Workflow-based solutions
3
Transport level middleware
We intend to use the term low-level middleware to refer to the integration process that is based on the lowest levels of interconnectivity. We will include two concepts at this level: the network protocols that are used to transfer raw data and the remote procedure call (RPC) as first form of distributed computing framework.
3.1
Network-protocol level
Early distributed systems were built using few available options to achieve interconnectivity. Those options are using relatively low-level programming and more related to the underlying network protocols. Distributed systems that are built directly over the TCP/IP protocol-suite, have considered 3
these protocols as an underlying middleware. TCP/IP enables the communication of different systems across many operating systems, platforms and programming languages because TCP/IP is defined for a diverse set of operating systems and platforms. APIs are also defined for many programming languages. Yet this approach needs tremendous programming skills and knowledge of low-level issues of the network. Therefore, it is time consuming, cumbersome and can be error-prone as the programmer has to reinvent the wheel in every program code.
3.2
Object and component-based middleware
Object Oriented and component-based becomes the leading methodologies in developing distributed systems. The different types of middleware presented in this section is best suited for the centralised architecture for B2B distributed systems because it support tightly coupled connectivity. The nature of tightly coupled connectivity of this middleware mandates that the interconnected components be aware of each other object/component interface, therefore, it is not a good choice for inter-enterprise connectivity. Object Oriented (OO) development approach has emerged steadily as a paradigm that focuses on granularity, productivity and low maintenance. Unlike the procedural paradigm, which is still endorsed by some developers, the OO has proven itself to be an effective development method. This is because it represents real-time entities as objects, therefore, reducing the gab between real-world and software concepts [2]. Nevertheless, others [10] have shown that OO is not the silver bullet for software development because not everything can be modeled as an object. There should be a more granularity level that allows a number of object to cooperate to perform an atomic task and to be used as a plug-and- play component in a software. The ambition of the component development paradigm is to make the construction and a software as simple as plugging together lego-style components (i.e. constructs). According to [4], a component is an independent delivery piece of functionality presented as a black-box that provides access to its services through a defined interface. Objects and components have been in use in the distributed computing in such a way that an object or a component can invoke another remote object or component functionality through their interfaces. This requires a middleware environment that implements the communication issues of objects/components interaction. In this section, we will discuss two variations of such middleware: Java-based (RMI and EJB) and OMG CORBA. The platform-independent Java language has now become the dominant language for developing networked systems. The early maturity and stability of Java has led to the development of Javabased frameworks for facilitating the B2B distributed systems development. There are two major Java frameworks: RMI [24] which is developed on top of the TCP/IP and the EJB [18] which is developed on top of the RMI. EJB provides a framework for “plugging in” server components into a larger server application, thereby extending that application’s functionality. It is intended to hide the low-level system details of managing server resources such as transaction processing, threads management and databases access. It also helps in clearly identifying the responsibilities of the client, the server and all other individual components. EJB deals with issues such as scalability, replication, distributed processing, deployment, security, or transactions. One of the most important standards that have emerged from the Object Management Group (OMG) [13] [3] is the Common Object Request Broker Architecture (CORBA). The CORBA’s infrastructure provides mechanisms to deal with platform heterogeneity, transparent location and implementation of objects, interoperability and communication between software components of a distributed object environment. CORBA uses a language-independent Interface Definition Language (IDL), and is therefore more interoperable than Java RMI. However, Java RMI and CORBA distributed objects can be integrated through the Java RMI versions that run on top of the In4
ternet Inter-ORB Protocol (IIOP). CORBA can also be integrated with the EJB because EJB specification does not dictate the protocol used to communicate with an EJB.
4
Content level middleware
A data transfer format defines how the data should be formatted in order for different components, not only within the same distributed business system, but also across different systems resides in different companies and technologies, to exchange messages, data, and even documents that they can interpret and understand. Both sender and receiver should agree initially on the shared format. The sender component usually has a software (i.e. embedded component) that encodes the contents of the message into a well-defined format that is sent using the middleware protocols to remote object/component. This receiving component interprets the message to retrieve the original application data. Typical distributed systems components agree on specific data format that each component uses to encode and interpret sent and received data. Having non- standard data formats (incompatible data format) would not allow different components in different system to interact unless extra adapter software is provided to convert between the two different data formats. This difficulty becomes very clear when considering distributed systems integrated with the web. In most situations, the web browser would act as a client that should be able to use the same data format of the system it is interacting with. Having a standard data format would allow new business systems not to bother about how their web clients would interpret exchanged data. In the next two subsections, we will discuss two major content level middleware: Electronic Data Interchange (EDI) and a number of XML-based frameworks.
4.1
Electronic Data Interchange(EDI) based integration frameworks
Electronic Data Interchange (EDI) [17] is well-defined and well-established in the industry in the sense that it provides the both defined syntax and defined vocabularies for values of the EDI message fields [5]. Trading partners exchange business documents via a value-added-networks (VAN) using EDI standards. EDI has been in use long time before the emergence of the Internet. It depends on a moderately sophisticated technology infrastructure based on proprietary and expensive VANs and ad hoc development that needs direct communication with the partner. Therefore, it remains unaffordable for the majority of the business community. EDI is also a partial solution for ecommerce since partners must not go beyond the agreed upon document standards and therefore limiting the integration of large number of dynamic services [2]. The emergence of the Internet as a global standard for data exchange has influenced the extension of EDI in many directions. The Open Buying on the Internet (OBI) [22] is an initiative that leverages EDI to define an Internet-based procurement framework thereby utilising the free use of the Internet instead of the expensive VANs. [2]. EDI is an established technique for B2B integration. When assessing its role in the various interoperability layers, EDI is more focused on communication interoperability where VANs are used to handle message delivery and routing. EDI standards also provide a single homogeneous solution for content interoperability, but the set of supported document types is limited. This means that EDI is limited to enable a rich set of possible B2B interactions. In addition, EDI standards, as currently defined, do not support interoperability at the business process level
5
4.2
XML-based frameworks
The Extensible Markup Language (XML) [29] [32] is an emergent set of open standards in the production and consumption of content managed by the World Wide Web Consortium (W3C). XML is a data oriented technology, based on a lightweight subset of the Standard Generalisation Markup Language (SGML), suitable for the definition, storage and retrieval of structured data. XML is inherently language independent [32]. XML brings with it a huge promise in the same way Java did for portability of code; XML claims to do for portability of data. Sun has even been touting the slogan: “Java + XML = Portable Code + Portable Data” [7]. XML is a compromise between the strong rigid structure of databases and the weak semantics and comparative freedom of the HTML. It has been devised with the objective to facilitate sharing of data among applications, both across platforms within the same enterprise and sharing data between enterprises [2]. Inspired by the promising future of being the standard format for data transfer and object communication in the distributed systems, many special purpose frameworks are built around XML making use of its extensibility features. The Electronic Commerce(eCO) [16] framework aims to address the problem of interoperability by providing standard facilities for businesses to discover each other, determine possible trading relationships, determine capabilities of trading partner systems, and establish trading relationships regardless of the e- commerce standards and protocols. Commerce XML (cXML) [14] targets non- strategic transactions which are Maintenance, Repair and Operations (MRO) of materials, office supplies, laboratory supplies, etc. It is a simplified, XML and Internet-based version of EDI. BizTalk’s [12] approach to applications interoperation is based on leveraging several existing standards and technologies including the SOAP, XML and Multipurpose Internet Mail extensions (MIME). RosettaNet [25] provides a set of XML- based standard interfaces for supply chain management in information technology and electronic component industry. The Electronic-Business-XML (ebXML) [15] vision is to create a single global electronic marketplace where enterprises of any size and in any geographical location can meet and conduct business with each other through the exchange of XML based messages.
5
Business process middleware
Business processes are descriptions of the activities required by an organisation’s to fulfil its mission, such as, a business contract or satisfying a specific customer request. Gaining control of these processes allows an organisation to reengineer and improve each process or adapt them to changing requirements [2]. A business process is defined as a set of one or more linked procedures or activities which collectively realise a business objective or policy goal, normally within the context of an organisational structure defining functional roles and relationships [11]. A few approaches have emerged for the purpose of facilitating inter business process interoperability. Among these approaches are: • Application Programming Interface (API): consists of working out business processes offline, determining the overall connection and coordination of operations and then defining universally-agreed abstract interfaces which provide remote operation invocations and connectors for back-end systems. Middleware and database technologies are then used for mapping these abstract interfaces to physical implementations. Example of such approaches is CORBA-based solutions. • Document-based solutions: a set of documents is exchanged according to a protocol. There is no prior agreement as partners publish their documents independently. Each document is self-
6
describing and contains enough information about the business process involved. Examples include EDI, BizTalk, eCO and RosettaNet. • Traditional workflow systems are based on the premise that the success of an enterprise requires the management of business processes in their entirety. Indeed, an increasing number of organisations have already automated their internal process management using workflows and enjoyed substantial benefits in doing so. Current business processes within an organisation are integrated and managed either using ERP systems such as SAP/R3, Baan, PeopleSoft or various workflow systems like IBM’s MQ Series Workflow or integrated manually on demand- basis. However, B2B e-commerce requires the flexible support of cross-enterprises relationships. Traditional workflow systems are ineffective when we consider the needs of B2B e-commerce, with its complex partnerships, possibly among a large number of highly evolving processes. The purpose of inter-enterprise workflows is to automate business processes that interconnect and manage communication among disparate systems. An inter-enterprise workflow (IEWf), is a workflow consisting of a set of activities that are implemented by different enterprises, that is, it represents a business process that crosses organisational boundaries [1]. There are several efforts to deal with IEWfs’ issues such as managing dynamic relationships among heterogeneous and autonomous organisation’s WfMSs, and supporting scalability and availability. However, no current approach seems to provide a complete generic solution. A number of these approaches has been summarised in [2]. Agent technology is also a potential solution for realising inter-enterprise workflows. • The Web Services model [30] is emerging steadily as a loosely- coupled, document-based integration framework for Internet-based applications. Unlike traditional workflows, Web services support inter-enterprise workflows where business processes across enterprises can interact in a loosely coupled fashion by exchanging XML document-based messages. The Web Services model idea is to break down web accessible applications into smaller services. These services are accessible through electronic means, namely the Internet. They are selfdescribing and provide semantically well-defined functionality that allows users to access and perform the offered tasks. Such services can be distributed and deployed over a number of Internet-connected machines. A service provider is able to describe a service, publish the service and allow invocation of the service by parties wishing to do so. A service requester may request a service location through a service broker that also support service search. Web services are loosely coupled allowing external applications to bind to them. Web services are also reusable allowing many different parties to use and reuse a service provided. There are three emerging standards for web services: the Simple Object Access Protocol (SOAP) [27] which is an XML-based protocol for exchanging document-based messages across the Internet, Web Services Description Language (WSDL), [31] which is a general purpose XMLbased language for describing the interface, protocol bindings and the deployment details of Web services, and the Universal Description, Discovery and Integration (UUDI) [28] which refers to a set of specifications related to efficiently publishing and discovering information about Web services. In conclusion, Web Services model is trying to use XML as basis to re-invent or improve the integration model by using SOAP at the communication layer and inter-enterprise workflow at the business process layer.
7
Pre-trade Analytics Buyer trader
Seller trader
Broker
Corporate registry MICROSOFT CORPORATION
Sec ond ary M ark et
Next trade
Set tlem ent
Exchange Trading
R egistry
Corporate
Se ll orders
Buy orde rs
Broker
P ost -tra de A nalyt ic s
Prim ary M ark et
New Issues (underwriter holding)
MICROSOFT CORPORATION
$
$
Buyer bank acount
Broker
Broker
Seller bank account
Figure 2: Securities trading cycle
6
Case study: Capital Market Systems Integration
Trading in capital markets such as New York Stock Exchange and Australian Stock Exchange has become more and more a global activity because of the recent technological developments that have facilitated the instantaneous exchange of information, securities and funds worldwide. Trading decisions have become more complicated because they involve decisions made by different people interacting across wide geographical boundaries and different time zones. A large number of good trading opportunities are lost because traditional communication medium are inefficient and slow to take advantage of these opportunities. The traditional communication medium for different systems within the same market or across different markets may use the telephone, fax and email because most of these systems are not integrated in a way that allows business processes to flow smoothly across different systems without human intervention. This section presents the technologies available that facilitates the integration at various levels of interoperability for capital market securities’ trading. Figure 2 demonstrate the various phases in completing a trade in a capital market. Security trading automation, within this context, means the automation of all trading stages without human interference. It is highly desirable to have fully interoperable, web-enabled and integrated software components that support online placement of orders, online settlement and registry once a trade is matched, real- time surveillance and real-time information dissemination (announcements, quotes, trades, etc.). Figure 3 shows the three levels of integration between different software components in an integrated service. In the upper level, the business process level is the highest level in the hierarchy. It offers business services in a way that “hides” the underlying data formats or middleware platforms. It represents the appropriate level for defining integrated services that correspond to particular
8
CM e-services Exchange trading
Trading data
Broker
Surveillance
Settlement
...
Content (data) level
:
FIX, FIXML, XML, FIN, etc.
Trasport level Network level : TCP/IP, SWIFT, SwiftIP, VANs, etc. Distributed object level : Java RMI, CORBA, EJB, DCOM, .Net, etc.
Figure 3: Interoperability levels in capital market systems
9
Capital Market Application X
Capital Market Application Y
Process Flow level : APIs, document exchange, orders and trades flow, etc.
business models. The content (data) level defines the structure and format of messages between the software components. The transport level defines the interfaces of communication between the various software components.
6.1
Transport level
For security reasons, most financial systems interact with each other using private or dedicated networks. An example is the SWIFT Transport Network (STN) based on the X.25 protocol. As communication software is non-standard, this is a very expensive solution. Other than for historical reasons, there is less and less interest in integration at this level because of the low level nature of the corresponding programming interfaces. Another reason is that nowadays every networked platform supports the Internet Protocol (IP), which is the common reference for a suite of networking protocols based on TCP/IP. Even private networks are now moving towards IP-based solutions (Intranets and Extranets). For example, SWIFT is now developing a new generation of interactive services (called SWIFTNet) using an IP-based network called the Secure IP Network (SIPN). Few of the major capital market systems utilise distributed object technologies discussed earlier such as CORBA and EJB to facilitate connectivity with other systems within the same market. The main reason for that is the performance penalty when handling large rate of real-time transactions
6.2
Contents (data) level
In parallel with XML developments, a number of international organisations were already working towards the adoption of common standards in the financial area. One of such standards is the Financial Information eXchange (FIX) [19] protocol for communicating securities transactions between two parties. Since FIX does not define how data is transported, an XML version of FIX called FIXML [20] has been defined. FIXML facilitates real-time delivery of messages and it supports multiple currencies and financial instruments types. It also specifies how the trading orders are advertised, acknowledged, placed, rejected and executed. It also can be used to manage settlement instructions between the trades parties. Another standard is the Financial Products Markup Language (FpML) [21] supports business information exchange standard for electronic dealing and processing of financial derivatives instruments. It establishes a new protocol for sharing information and dealing in financial derivatives over the Internet. The FpML is currently focuses on partial derivatives instruments such as interest rate swaps and forward rate agreement. The SMARTS [26] surveillance system has adopted its own FAV format that can accommodate different types of markets and trading instruments. Research Information Exchange Markup Language (RIXML) [23] is an initiative for developing an open industrial standard to tag and deliver investment research. It provides a structure for classifying financial research in a way that will enable users to define specific sorting, filtering and personalisation criteria across all research publishers. In each case, a working group defines a Data Type Definition (DTD) that defines the XML tags and how they can be legally combined. These DTDs can then be used with XML parsers and other XML tools to rapidly create applications to process and display the stored information in whatever way is required. Other related standards include ISO15022 which defines a standard for messages in banking, securities and related financial services. This standard is suitable for inclusion within an XML format. Another standard is SWIFT’s messaging service, FIN, which runs on its private network (STN) and enables financial institutions to exchange standardised financial messages worldwide.
10
CM e-services Exchange trading
Trading Data Service
Issuer Data Service
Settlement Service
Registry Service
Communication / Middleware Infrastructure
Pre-trade Analytics Service
Surveillanc e Service
Broker Service
Figure 4: Essential services associated with securities trading
6.3
Business process level
Each software component provides either a basic service or composite (integrated) service. The former is where the service logic is totally provided by that architectural component. The latter is where the architectural component interacts and requires other services (called outsourced services) to fulfil its role. Therefore, a service-based approach separates between business concerns (i.e. the use of the service) and technological considerations (i.e. the computing and networking infrastructure to support a service). Figure 4 shows the essential basic and integrated services that are associated with securities trading. Very few capital market systems are integrated at this level. Therefore, the B2B integration at this level in capital markets domain is an active research area [9]. Based on our study [6] conducted on the SMARTS surveillance system [26], we came to the conclusion that many capital market systems still cooperate at low levels of interoperability that is the network protocol because there isn’t a standard for content and service levels of those systems. Therefore, we have initiated research and projects that aim to facilitate the integration of capital market processes in a way that does not depend on the underlying middleware technology. Our ongoing work includes investigating software architecture for distributed capital market system that is abstracted from the underlying middleware technologies.
7
Conclusion
In this paper, we have discussed the interoperability of B2B e-commerce applications at three levels: transport (low level and object and component level), contents, and business process levels. Throughout the paper, we have seen how different middleware technologies support interoperability at different layers. However, there isnt a middleware technology that supports all the three levels. In the following is a brief discussion of the interoperability support for major middleware technologies: • Low-level interaction middleware supports an ad hoc interoperability at the communication level. Network-level TCP/IP supports loosely coupled interaction at lowest level. RPC is the earliest form that supports tightly coupled interaction. • Component and object-based frameworks focus on interoperability at the communication layer in the context of tightly coupled services. They are more appropriate to integrate intra11
enterprise services. • EDI focuses more on interoperability at communication and content layers in the context of loosely coupled services. It is an appropriate approach for integrating inter-enterprise services with long-term and static trading relationship. • XML-based frameworks vary in their support of interoperability at the different layers. In general, they focus on interoperability at communication and content layers in the context of loosely coupled Internet-based services. Only few efforts in RosettaNet and ebXML provide support for interoperability at the business process layer. • Workflow-based systems focus on interoperability at the business process layer in the context of tightly coupled services; however, emerging efforts in this area aim at supporting all interoperability layers in the context of inter-enterprise services. We have discussed e-commerce enabling technologies in general terms. We have focused on interoperability facilitated by these technologies and the restrictions they impose on software built using these technologies. As the number of such technologies is increasing with no dominant leader, more inter-technologies interoperability and integration problems will arise. This would enforce competing technologies to provide integration solutions with other major technologies. This solution has performance penalty because it adds more adapter layers in order to achieve interoperability across applications with different middleware architectures. We have also presented the interoperability requirements for supporting high levels of interoperability for facilitating the integration of capital market systems which is the base for our ongoing research activities.
References [1] J Yang ans M. Papazoglou. Interoperation support for electronic business. CACM, 43(6):39–47, Jun 2000. [2] B. Benatalla, F. Rabhi, and N. Mehandjiev. E-Commerce enabling Technologies. Pearson SprintPrint, 2002. [3] Gerald Brose, Andreas Vogal, and Keith Duddy. Java Programming with CORBA: Advanced Techniques for Building Distributed Applications. John Wiley & Sons, Inc, 3rd edition, 2001. [4] A. W. Brown. Large-Sclae, Component-Based Development. Prentice Hall, 2000. [5] Christoph Bussler. B2b protocol standards and their role in semantic b2b integration engines. Bulletin of the IEEE Computer Society Technical Committee on Data Engineering, 24(1), 2001. [6] Feras Dabous and Fethi Rabhi. Smarts architecture and performance. Technical report, School of ISTM, The University of NSW, June 2002. confidential document that concluded seed grant from CMCRC. [7] Brett McLaughlin. Java and XML. O’Reilly, 2000. [8] Amjad Omar. Object-Oriented Client/Server: Internet Environment. Prentice Hall, 1997. [9] Fethi Rabhi and Boualem Benatalla. An integrated service architecture for managing capital market systems. IEEE Networks, 1:1–16, 2002.
12
[10] Clements Szyperski. Component Software: Beyond Object-Oriented Programming. AdisonWesley, 1998. [11] Workflow management coalition, terminology and glossary. Http://www.aiim.org/wfmc/mainframe.html, Feb 1999. Document Number WFMC-TC-1011. [12] Biztalk web site. Http://www.biztalk.org. [13] Object management group (omg) web site: Corba specification. Http://www.omg.org. [14] Commerce xml (cxml) web site. Http://www.cxml.org. [15] Electronic-business-xml (ebxml) web site. Http://www.ebxml.org. [16] Electronic commerce (eco) web site. eco.commerce.net. [17] Electronic data interchange (edi) web site. Http://www.edi-information.com. [18] Enterprise javabeans web site. Http://java.sun.com/j2ee. [19] Financial information exchange (fix) protocol web site. Http://www.fixprotocol.org. [20] Fixml protocol web site. Http://www.fixml.org. [21] Financial products markup language (fpml) web site. Http://www.fpml.org. [22] Open buying on the internet (obi) consortium web site. Http://www.openbuy.org. [23] Research information exchange markup language web site. Http://www.rixml.org. [24] Java rmi specification. Http://java.sun.com. [25] Rosettanet web site. Http://www.rosettanet.org. [26] Smarts surveillance system web site. Http://www.smarts.com.au. [27] The simple object access protocol (soap) specification web site. Http://www.w3.org/SOAP. [28] The universal description, discovery and integration (uddi) web site. Http://www.uddi.org. [29] World wide web consortium web page. Http://www.wc3.org. [30] Ibm tutorials and articules web site. Http://www-106.ibm.com/developerworks/webservices. [31] Web services description language (wsdl) specification web site. Http://www.w3.org/TR/wsdl. [32] Extensible markup language (xml) web site. Http://www.xml.com.
13
