Project JebX: A Java ebXML Experience

Project JebX: A Java ebXML Experience P. Brebner, B. Logan CSIRO, CSIRO Vacation Student [email protected]

EbXML is an emerging and ambitious B2B e-commerce standard with the potential to become a significant player in the next few years. We conducted a hands-on evaluation of an early release ebXML product in order to gauge the availability, maturity and utility of ebXML solutions, develop experience with ebXML development, and formulate preliminary ebXML product evaluation criteria. A B2B ebXML application was defined, but after a sustained effort to implement it a fully functional test application eluded us. The strengths of the product being evaluated exacerbated the development problems, as it presented a high-level business process view, making lowlevel debugging of business logic interfaces and messaging services intractable. Our experience so far of ebXML is that it is slow – slow to be understood by the ecommerce community, slow to be taken up by vendors and end users, slow to develop and debug, and slow to execute.

Due to the natural applicability of J2EE to ebXML, and the ease of mapping the ebXML services to J2EE, we decided to focus on Java/J2EE implementations of ebXML. This was fortuitous as the first system out was based on a J2EE platform. The project was time-boxed and had a fixed window of opportunity, and therefore depended on the timely availability of a suitable product. The JAX pack from Sun had become available late in 2001, and would minimally satisfy the requirements, as there is ebXML support in JAXR (Java API for XML Registries) and JAXM (Java API for XML Messaging). However, after initial investigations we fixed on BindSystems as a commercial candidate, and were please to find that a beta version was made available a few days before the project started1. The project was intentionally of fixed duration, and was likely to be a demanding test of ebXML and BindSystems, thereby accurately reflecting real world development scenarios.

1. Project Aims

2. What is ebXML?

In 2001 we began investigating B2B e-commerce standards looming on the horizon, and discovered that ebXML was promising to become a significant player in the next two years. We have previously focused on middleware technology evaluation [1] (e.g. Corba, J2EE, MOM, JMS, Message Brokers), but were considering the EAI, Web services, and B2B e-commerce space in more detail. Our development approach has been rigorous hands on investigation, including the development of a trial application using the technology, stress testing to determine the performance and scalability qualities of the technology, and a level-playing field comparison with other products/technologies. After discussions with the ebXML interoperability committee we decided that a trial evaluation of one ebXML implementation would be conducted in order to further gauge the availability, maturity and utility of ebXML implementations, develop an ebXML evaluation application, and propose the ebXML evaluation criteria.

EbXML (Electronic Business XML) [2], is a set of standards which allow for the creation, publication, discovery and utilisation of B2B-oriented web services. It has the backing of UN/CEFACT and OASIS and presents a standardised framework for doing business on the internet. The ebXML specification consists of three main parts: A registry design, a communication (or messaging) framework and a process for using both of these to conduct business transactions. The first, a registry, is a web service (which can be located using a discovery service such as UDDI), whereby businesses interested in conducting ebXML-based transactions publish their profiles. Profiles are XMLbased documents which describe the types of services or products they offer, what kinds of transactions they can

Abstract

1 A comparative evaluation of more than 1 product was impossible at the time as there were no other products with comparable ebXML coverage.

0-7695-1926-1/03/$17.00 (C) 2003 IEEE

engage in, what their standard terms and conditions are, and what types of connections they support (such as secure versus standard transactions). The second part of the specification, the messaging framework, is an XML-based messaging system that adds business-relevant features to a standard XML messaging format (E.g. Simple Object Access Protocol - SOAP). These features include security, tracking, non-repudiation and business-related context information. This allows ebXML to make use of the available infrastructure (the internet) to reduce the start-up costs of online business, whilst maintaining integrity of the system. High start-up costs were a major downside for similar B2B technologies, such as EDI, often imposing a high entry barrier to small- and medium-sized businesses. It is these types of businesses that stand to gain the most from the adoption of ebXML [3]. The process in ebXML defines the order of steps that must be followed, including discovery, contact, agreement and eventual transaction phases. The process, although simple, defines a sequence through which the registry and messaging framework can be used. EbXML also decrees that the (optional) business process modeling methodology must be UMM (UN/CEFACT Modeling Methodology), a derivative of UML (Unified Modeling Language).

3. Product Selection In the first quarter of 2002 ebXML-compliant tools were few and far between2. Those that were available varied greatly in their intent. Two products were considered for the evaluation: BindPartner [4]and ComponentX [5]. BindPartner is an attempt at a total ebXML application creation solution, while ComponentX is an XML application designer with limited support for ebXML modeling. BindPartner was chosen for the evaluation because of its more ambitious goals. BindPartner is a pure Java platform (in Beta release during the evaluation) that allows for business process modeling, and assistance with creation of a Java-based business application based on the model. It is implemented on top of JBoss, an Open Source “J2EE” Application Server3. BindPartner is presented as a “total solution” for businesses wanting to create an ebXML online presence. It allows for business analysts and 2 For current implementations (some partial or under development) see http://www.jenzundpartner.de/Resources/ebXML_Watchlist/ebxml_wat chlist.htm and http://www.ebxml.org/implementations/ 3 JBoss is not officially J2EE licensed. In theory it can be deployed to any J2EE AppServer.

programmers to work together to create a system that implements required business services.

4. Development Evaluation A two stage evaluation of the development capabilities of BindPartner was followed. Firstly, the supplied demos were used to help understand the product further (these were well documented, and were quick to learn), and then the development of a new application from scratch was attempted.

4.1. BindPartner Demo The BindPartner demo consists of an ebXML/SOAP compliant B2B system comprising of an agreement between two organizations. One organisation plays the buyer role, whilst the other plays the seller role. The interface is web-based and allows the user to specify what vertical industry he/she wishes to trade with: automotive, retail or telecommunications. The user can choose a business agreement to use, or type in one if it is not listed. A quote transaction, as well as a quote and order transaction, is available. The demo outlines the JAXM, JMS (Java Message Service) and “plain Java” support that BindPartner provides. Some of the business agreements are executed in SOAP, whilst some others are in ebXML. The samples require no special configuration, other than installation of BindPartner. The user simply clicks on the provided icons in the toolbar to start the servers for each respective organisation. As more applications were deployed during the evaluation, the server startup times stretched out to many minutes, making startup tedious. Once the servers are running, the web-based demo interface can be started. Source code for the buyer and seller back-end applications is supplied and provided a valuable introduction to using BindPartner. To find out what’s going on behind the scenes, the management console for each organisation can be started, and is useful for tracking messages flowing between business partners.

4.2. Developing a new ebXML Application A sample application designed to model B2B transactions was specified. The intention was to use the resulting application to test the development and performance/scalability characteristics of the product. The initial goal of the sample ebXML application was to model a retailer/warehouse system, implemented with ebXML messaging, with BindPartner modelling a stock query and/or order business transactions. The retailer side

0-7695-1926-1/03/$17.00 (C) 2003 IEEE

would initiate the transaction. Use cases were produced for this application and it was believed (optimistically) that it was simple enough to be implemented in a relatively short and fixed space of time. The Stock Query transaction consisted of a Retailer sending a StockQuery business document, encapsulated in an ebXML message, through the BindPartner system where it would be received by the warehouse. The Warehouse would query a simple database and send an ebXML-formatted message containing a response document. The Retailer would then note this information, and display the data on the screen. A model of the Stock Query transaction, as seen in the modeling phase of BindPartner is shown in Figure 1.

Server” (Java Servlet) so that the system will handle the business messages appropriately. There are a number of integration options – initially the “Java” option was chosen. This option, in addition to configuring the server, produces the code for the interface of the retailer or warehouse (i.e. the other side of role being implemented). Armed with Java interfaces, the next step was to implement the integration logic. The chapter “Integrating a Business Process Using Java Interfaces” within the BindPartner documentation looked helpful in outlining a step-by-approach for this. The integration code was deployed using BindPartner Studio. However, when attempting to start the second server after starting the first, both servers would throw “JVM_BIND” errors and refuse to talk. The “solution” (discovered much latter) was an adjustment of assigned port numbers (through the “Manage Organisations” menu in BindPartner Studio). Attempting to initiate the conversation then threw exceptions relating to BindPartner helper methods, NullPointerExceptions, and at other times the application would hang or die quietly. 4.2.2. Second attempt

Figure 1. Stock Query Model.

4.2.1. First attempt The first step in BindPartner is to model the transaction required within the BindPartner Studio. This is simply a GUI interface whereby entities, documents and transaction flows can be specified by dragging them into place on the model. Two organisations were created – an organisation can have any number of roles within a transaction, but they must be configured one at a time. Each organisation has its own server configuration, which is called by name when the BindPartner servlet is started. Having created an organisation, the GUI interface was used to model a business transaction. This is done by clicking on the required buttons to create new roles, and connecting them with transactions. Each transaction is linked with business documents, defined within the studio. Once the process is modeled, an integration must be produced, one role at a time. Integration simply configures the “BindPartner

At this point the application concept was simplified, and the demo samples used as a starting point. The new attempt would focus on implementing a seller side role within the “ACMEServiceProvider” organisation already defined in the sample and the use of JAXM for integration [6]. One advantage of basing the new attempt on an existing sample was that the business transactions were already fully modeled. The ACMEServiceProvider is geared for the “Seller” role. A new JAXM integration for this role was defined. Specifying this type of integration results in internal server configuration and the integration is created (and can later be linked to an agreement). The sample JAXM-based seller side application is called “EuropeanQuote”. The source code is provided with BindPartner, and a runthrough of this code is presented in the “Integrating a Business Process Using JAXM” section of the BindPartner manuals. This initial JAXM attempt simply used the sample’s hosted application called “MiniEBL” so that the messaging side could be focused on. As the service provided had to be the same as the Buyer expected, many of the same interfaces were implemented. Because the seller’s interface was exactly the same as the Buyer expected, the standard buyer sample application could be used to test the new seller application. JAXM integrations run as a remote client of the server, hence a connection to the server must be created when the

0-7695-1926-1/03/$17.00 (C) 2003 IEEE

application is started (JAXM integrations are started separately, after the servers are started, unlike Java-based integrations). At the line where this occurred, the server window would throw an exception, that solution eventually being that the BindPartner SDK requires a JNDI lookup from an InitialContext to acquire its connection. But an “InvalidClassChangeError” also occurred in the same section, persisting for some time until the development environment’s classpath was completely stripped back and replaced with BindParteronly JAXM and Tomcat SOAP implementations4. Possibly prior to this, some original Sun-provided JAXM packages were in the classpath. BindPartner used JAXM 0.93, whilst the current available version was 1.0. obviously enough to cause an error. With both servers fired up and the newly compiled JAXM application running, the buyer’s JSP page initiated a quote request. The JAXM application then displayed on screen that it had received this message, and a response (the quote) appeared on the screen. A successful JAXM seller-side application had been implemented.

time being. Messages sent by the buyer disappeared into the void. No record of them could be found in the server logs. The first attempt to fix this problem was to remove the business document for the initial message, and simply send a null document, in the belief that this would at least generate some indication that a message had been received. When this failed to fix the problem, the listener filter on the seller side was removed so that it would respond to all messages. The concern here was that the buyer side was sending the wrong service, agreement or conversation data, resulting in the seller ignoring the message. This change resulted in the seller side terminating as soon as it was started. Continual adjustments to the seller side application failed to fix this problem, but as soon as the integration/agreement was deactivated and reactivated in the Studio, the seller side would behave normally. When tested by the regular buyer side, its functionality was the same, with filter or without. The new buyer side application continues to be ignored, however. This was as far as the JAXM buyer side development went due to time restraints.

4.2.3. Third Attempt 4.2.4. Final attempt With the seller side properly implemented, an attempt at a buyer side implementation was made, this time based on the “OpenTradingCommunity” organisation, which represented buyers. Because the seller side was JAXM it was decided to implement the buyer side as a JAXM application too. Unfortunately, there was no JAXM buyer sample and the documentation was limited in this area. The model required no adjustments. All that was required in the Studio was to ensure the agreement outlined for the seller was activated on the buyer side also. Initially the standard OTCBuyerIntegration was used, then a new integration was attempted. In hindsight this makes sense because a new integration must be created to link up to the new agreement, despite the same functionality being provided. A large section of the buyer side is identical to the seller side in functionality – a buyer application still has to register itself as a listener and wait for the response message. Prior to this however, a buyer must generate a quote document and send it to the seller, initiating the conversation. It was decided that the quote document should be taken from the sample, once again for simplicity. This way, the code for a non-JAXM buyer side implementation could be followed, with the resulting message sent via the ProviderConnection. Agreement and service ID’s were hard-coded into the application for the 4

Having failed with a JAXM buyer application, the integration was converted to plain Java. This required deployment on the server, rather than as an external client, but allowed much of the sample code to be re-used. Initially, the code that set everything running was extracted from the web pages and run from a regular java program. However it was quickly realised that this wouldn’t work. Instead, to initiate this transaction, the main JSP page “OTCQuoteResponse.jsp” was modified so that it would call the new integration rather than the sample. As this was the only page that interacted with the back-end architecture, and the sample allows for a new agreement to be specified already, no other pages needed changing. Upon clicking on the “Request Quote” link in the modified JSP page, the server responded with something akin to a “ClassNotFound” error. Checking the server configuration, and ensuring that everything was in the correct directory, failed to reveal any obvious omissions. The “quick-fix” attempt involved renaming the new class to that of the old class, and running the original JSP page. This resulted in a small delay, and an OTC Demo Application Error page popping up. This error usually corresponds to a BindPartner process level error, such as a badly set agreement name. The BindPartner Studio’s agreement and integration setup was scrutinized, and after finding nothing wrong, the agreement was deactivated and

An example of the well known “CLASSPATH” Hell phenomenon.

0-7695-1926-1/03/$17.00 (C) 2003 IEEE

Response time 0.7 0.6 0.5 0.4 0.3 0.2 0.1

JB O SS

AP SO

M nd Pa rtn er /J AX Bi

ar tn er /J av a

0

nd P

BindPartner has a number of features that aid in the development of ebXML business applications. However, due to its beta status, documentation is somewhat lacking. This section provides a few tips and tricks involving Java development issues in BindPartner, based on what was learnt during this project. After you have performed all the required operations in the BindPartner Studio, you still have to write Java code. By far the easiest way to do this is to modify the samples already provided. When you’ve adapted the code to suit, compile it into a jar file and place this file in an appropriate subdirectory in the BindPartner directory. After writing your integration, don’t forget to start BindPartner Studio again, and activate your agreement. This will tie the agreement name (which the JAXM application will usually be listening for) to the integration you have implemented, and ensure the BindPartner server is configured for it. JAXM integrations run as external clients of the server. This means you must first start the server, and then run a “deployment script” to start the JAXM application. Another issue to watch out for is the tendency for agreements to potentially be deactivated behind the scenes. Many times the server would act as though it wasn’t listening for a particular agreement, when in the BindPartner Studio it indicated that it was. Sometimes deactivating and reactivating the agreement would fix this problem.

Time (secs)

4.3. BindPartner Development Conclusions

machine running Windows 2000 Server. Both organisation’s servers were running on the one PC due to the difficulty faced when trying to run the two servers on different machines. Splitting it into two should be easy in theory, however attempts thus far have failed. Both plain Java and JAXM-based implementations were tested. The average response time for repeated runs on a single client load are shown in Figure 2, revealing that Java is faster than JAXM. By comparison, a typical SOAP application (using .NET) is faster again, and comparable to a typical J2EE (RMI client and Stateless Session bean for business logic) running on JBoss (all on the same hardware). JBoss was able to handle 100 concurrent transactions with this average response time. In addition to the leisurely performance, it was discovered that the beta BindPartner platform has problems with concurrency – if two similar requests hit at the same time, the system hangs. However, both the BindPartner/ebXML results were close to saturating the server (for only a single client), which does not bode well for good scalability.

Bi

reactivated again. Running the JSP page in the same manner now results in the system simply not responding and eventually the browser times out. Other attempts have involved application re-installs, reconfigurations and other server-level investigations to find something amiss. However, at this point, the plain Java buyer side integration fails to function properly5.

Figure 2. Comparative Response Times.

5. Performance Evaluation

6. Overall Evaluation

Performance evaluation was originally to be conducted on the newly constructed ebXML application. However, due to the trials and tribulations of the attempt to create such an application described, it was decided to conduct testing on the sample application provided with BindPartner. The tests were run on a dual 800Mhz processor

Prior to and during development a set of ebXML product evaluation criteria were defined as follows:

5 We are grateful to BindSystems for their help in getting us as far as we did. As usual with learning a new technology it is difficult to know if our limited understanding or the tool is at fault, and they were patient in answering our many requests for assistance.

Usability

How easily the user can perform whatever actions are required to complete a task, and how quickly a user can ascertain how these actions can be performed. Documentation Quantity, quality and relevance of documentation in assisting the user to

0-7695-1926-1/03/$17.00 (C) 2003 IEEE

server/web container layers of Application Servers [11]. The strengths of BindPartner lie in business process creation and collaboration modeling, tool usability and administration, and ebXML scope and compliance. The weaknesses are in the execution of ebXML business processes, integration with existing business logic, and debugging. The obvious dangers of using bleeding-edge technologies brought on a sense of deja vu from the initial J2EE evaluations we conducted over two years ago when J2EE implementations were relatively new, which also with lots of teething problems. Based on our observations of the rate of improvements to J2EE we expect ebXML problems to be ironed out within two years at the most (end of 2003) and to become increasingly viable [7,8,9].

complete or gain insight into required tasks. Availability Whether the software can maintain its integrity and predictability regardless of prior actions. Performance How fast is the response time. How many concurrent transactions can Scalability be processed. ebXML Adherence How well the product conforms to ebXML standards. ebXML Scope What range of the ebXML specification the application supports, and how much of the total workload required to implement ebXML solutions is covered. Debugging Support for debugging and tracing a deployed application. Business Processes Support for specifying and using collaborative business processes. Integration Support for integration with existing or new business logic or components. Administration Support for management of product and deployed applications for setting/changing Configuration Support configurations, and robustness of configurations over time.

7. Conclusions

BindPartner was given a relative score from 1 to 10 for each criterion based on our experiences with it to date as follows6 in Figure 3. Debugging Scalability Configuration Integration Performance Availability Documentation ebXML Scope Usability Administration Business ebXML Adherence 0

1

2

3

4

5

6

7

8

9

Figure 3. Rankings.

Dimensions that need substantial improvement for a mature product include debugging, scalability, configuration, integration and performance. It is significant that running on top of J2EE doesn’t automatically give high performance. Contributing factors may include the relatively poor performance of JBoss [10], but more likely the extremely high demands that XML, Web Services and ebXML place on the web 6 5 was the baseline. If features helped us achieve goals and worked correctly we added points. If they hindered us or didn’t work then we deducted points.

10

EbXML, like any standard, will only ever be as strong as those who choose to implement it. At the moment, a number of organizations have indicated their intention to put in place ebXML solutions. Large companies and even countries backing this new standard fares well for ebXML’s adoption in the future. If ebXML’s popularity increases, applications that support ebXML development will also proliferate. BindPartner may be the first of a large number of complete ebXML development solutions. The early dream of this project, to implement an extensive ebXML application, has yet to be realised. BindPartner’s ability to hide the complexity of the underlying ebXML messaging system is a two-edged sword – it simplifies development, to the detriment of debugging. EbXML messages floating around in the server are nearly impossible to find, and it is hard to be determine what component is at fault when something goes awry7. In conclusion, our overall experience of ebXML is that it is slow – slow to be understood by the e-commerce community, slow to be taken up by vendors and end users, slow to develop and debug, and slow to execute. But this is early days in the lifecycle of a new technology, particularly a standards based one with the extensive scope (and hopefully momentum) of ebXML. Stephenson’s Rocket only had a top speed of 39km/hr, but ushered in the industrial transport revolution. Due to its even more grandiose goals ebXML may show similar improvements and pervasive impact8. 7 This is consistent with BindSystems self-assessment that “usability is high, primarily a graphical driven environment, but masking the underlying complexity…” 8 But for an alternative more pessimistic analysis see: http://techupdate.zdnet.com/techupdate/stories/main/0,14179,2865508, 00.html

0-7695-1926-1/03/$17.00 (C) 2003 IEEE

8. References [1] CSIRO Middleware Technology Evaluation Project, www.cmis.csiro.au/adsat/mte.htm. [2] EbXML Technical Architecture Specification v1.0.4, EbXML Technical Architecture Project Team, © ebXML 2000. [3] Duane Nickull, Adoption Strategies for XML Standards and the ebXML Infrastructure, XML Europe 2001, http://www.gca.org/papers/xmleurope2001/papers/html/s03 -3.html [4] BindPartner from BindSystems, http://www.bindsys.com/ [5] ComponentX from Data Access Technologies, http://www.enterprise-component.com/products/ [6] General Programming Concepts For Back-End Integration, Integrating a Business Process using JAXM, Bind Systems Ltd, © 2000-2001 Bind Systems Ltd.

[7] Center for E-Commerce Infrastructure Development (CECID) Hong Kong, ebXML registry implementation: http://www.cecid.hku.hk/Newsletter/VOL1May2002.html [8] Cliff Collins, Michael Ho, Himagiri Mukkamala, B2B Collaboration Using ebXML: A JavaTM Technology-based Implementation, JavaOne 2002 http://servlet.java.sun.com/javaone/sf2002/conf/sessions/di splay-2615.en.lite [9] Nagesh Kanumury EbXML, JavaTM Technology, and Web Services, JavaOne 2002 http://servlet.java.sun.com/javaone/sf2002/conf/sessions/di splay-3380.en.lite [10] JBoss performance and scalability: www.cmis.csiro.au/adsat/jboss.htm [11] Greg Barish, Building Scalable and High-Performance Java Web Applications Using J2EE Technology, AddisonWesley, 2002.

0-7695-1926-1/03/$17.00 (C) 2003 IEEE