| <html> |
| <head> |
| <title>Solving the Software Paradox with Tool Integration</title> |
| <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> |
| </head> |
| |
| <body bgcolor="#FFFFFF" text="#000000"> |
| |
| <table border=0 cellspacing=0 cellpadding=2 width="100%" > |
| <tr> |
| <td align=LEFT valign=TOP colspan="2" bgcolor="#0080C0"><b><font face="Arial,Helvetica"><font color="#FFFFFF"> Eclipse |
| Corner Article</font></font></b></td> |
| </tr> |
| </table> |
| <h1> <img src="../images/Idea.jpg" height=86 width=120 align=CENTER></h1> |
| <center> |
| <h1> Solving the Software Paradox<br> |
| With Tool Integration</h1> |
| </center> |
| <center> |
| <h3> How a Workspace with integrated tools can facilitate<br> |
| application development of all resource types and for <br> |
| the whole team</h3> |
| </center> |
| <blockquote><b>Summary</b> <br> |
| Developing Web applications is difficult due to conflicting demands for high |
| quality applications built in Web time, and to immature, unintegrated, and constantly |
| changing technologies. Web application design patterns help manage this complexity |
| and indicate the required tools. Tools need to be integrated and manage the |
| relationships between their associated artifacts. A tool integration platform |
| provides the required "integration-ware" enabling the development |
| of products consisting of integrated, configurable, roles appropriate, and end-to-end |
| development tools based on best practice design patterns. To reduce acceptance |
| barriers, this integration-ware must be based on open standards as much as possible |
| and Open Source where standards don't exist. To be effective, tools need to |
| be integrated into a common workbench. The workbench and integration-ware must |
| support flexible tool integration appropriate to vendor business objectives |
| by providing various conformance levels of integration. Conformance levels define |
| what any vendor must do to integrate at a level, what technologies are required, |
| and any integration expectations.<br> |
| </blockquote> |
| <b>By: <a href="mailto:Jim_Amsden@oti.com">Jim Amsden</a></b> |
| <p> |
| <hr width="100%"> |
| <h3>The Web is changing everything</h3> |
| <p>Customers are discovering the opportunities and challenges of e-business applications. |
| Current integrated suites of office tools like Microsoft Office and Lotus SmartSuite |
| set high expectations for integrated application development tools. The Internet |
| is changing the face of business integration resulting in rapidly changing business |
| models due to BPR in order to leverage the Web. These e-business applications |
| can be complex, difficult to maintain, and demand interoperability. Interoperable |
| applications consisting of highly integrated artifacts demand integrated tools |
| supporting a prescriptive methodology in order for application development to |
| be a rational, controllable, and repeatable process.</p> |
| <h3> Web Application development results in the need for layered tools<br> |
| </h3> |
| <p>The explosion of Web technologies including client display architectures, communication |
| protocols, application servers, and backend systems has resulted in rapidly |
| changing and complex application architectures. The Web represents a complex, |
| highly dynamic, rapidly changing application development problem space. A Web |
| application incorporates many resource types representing diverse, highly interrelated |
| components including: HTML, GIF, JPEG, DHTML, scripting, Java Applets, ActiveX |
| controls, servlets, EJBs, connectors to legacy systems, etc. In most cases, |
| these resources are never collectively compiled in order to validate the intended |
| relationships. This can result in applications that are fragile, difficult to |
| test, scale, and maintain. </p> |
| <p>Because of these diverse content types, and their contents, building a Web |
| application requires diverse, highly specialized development skills including: |
| GUI programmers, server programmers, graphic designers, database designers, |
| business experts, and document designers. Client web browsers and HTTP web servers |
| establish the overall architecture of Web applications. The resulting distributed |
| applications require compromises between accessibility, availability, integrity, |
| ease of use, performance, and footprint. Web applications are targeted at a |
| broad audience, which requires emphasis on ease of use, appealing look and feel, |
| and masking resource and distribution technologies. Web application development |
| is pushed from two conflicting directions: the need so support high quality |
| applications, and the need to develop them very fast on emerging and un-integrated |
| technologies.</p> |
| <p>The techniques for developing Web applications are changing fast. This often |
| results in new and immature technologies and many tools: new tools, new revisions |
| of old tools, and beta releases of emerging tools. As a result, there is a significant |
| opportunity for point tools supporting these new emerging technologies that |
| facilitate the development of Web applications. However, these tools must be |
| effectively integrated in order to speed Web application development, provide |
| end-to-end debugging, minimize gaps and overlaps between tools, and provide |
| a positive developer experience.<br> |
| </p> |
| <h3>Patterns help manage the complexity<br> |
| </h3> |
| <p>Fortunately, web application development choices tend to fit into patterns |
| based on application functionality and network, middleware, and runtime topologies. |
| Patterns help focus on customer needs, the technologies, tools, and techniques |
| that are used to build web applications. Each pattern is instantiated through |
| the creation or reuse of a number of web resources. Each resource requires a |
| tool to author the resource and a repository for storage. Resources are integrated |
| and linked together to support relationships existing in the target business |
| application. Tools must be integrated in order to facilitate development of |
| an application built from integrated artifacts. Otherwise the developer must |
| maintain these relationships manually. This is both tedious and error prone. |
| </p> |
| <p>Effective tool integration requires open standards, a component and programming |
| model, frameworks, APIs, file formats, etc., collectively called "integration-ware". |
| Integration-ware provides the base platform in which extensions can be applied |
| to provide domain specific tooling. All these components must be integrated |
| with a central workbench that provides access and control of the entire site |
| across all resource types and application development roles. The benefits are |
| reduced gaps and overlaps between tools, elimination of repetitive, manual, |
| tedious, and expensive on-site tool integration, less redundant data input, |
| and a more positive user experience. <br> |
| </p> |
| <h3>Realizing the Tools Opportunity<br> |
| </h3> |
| <p>Web and e-business application development, and a tool integration platform |
| result in a significant opportunity for ISVs to develop application development |
| tools. In order to be successful, tool vendors need to focus on the value added |
| by their tools while minimizing their investment in infrastructure, porting |
| to other operating systems, browsers, and/or web servers. ISVs also need to |
| minimize the amount of ancillary functionality they must be develop in order |
| for their tools to be accessible and useful. Minimizing this investment involves |
| integrating tools with other complementary tools and IDEs in such a way that |
| the integrated result provides more value to the end user than the individual |
| tools by themselves. However, integrating tools can require a significant investment. |
| Each tool or IDE that is a candidate for integration provides its own set of |
| extensibility and integration mechanisms. In order to achieve maximum market |
| penetration, a tool vendor will want to integrate with as many other tools and |
| IDEs as possible, and in such a way that the tools compliment each other without |
| creating undue redundancies and coupling.</p> |
| <h3>Eclipse provides the required tool integration framework<br> |
| </h3> |
| <p>A tool integration platform is required to exploit this tooling opportunity |
| by providing a platform for deploying integrated, configurable, roles appropriate |
| tools for developing end-to-end, Web-based, e-business applications. As well |
| as enabling tool integration, a platform helps minimize the cost of tool integration |
| by providing a large number of reusable libraries, APIs, and frameworks that |
| enable provide common services. This minimizes the tool vendors development |
| costs and allows them to focus on their value add. <br> |
| Wherever possible, the platform must use open standards like WebDAV, XMI, JavaBeans, |
| etc. to remove barriers to acceptance, limit tool vendor investment, and reduce |
| time to market. In those cases where there either is no standard, or there are |
| multiple conflicting standards, Open Source can be exploited to establish momentum |
| within the development and tool communities to define defacto standards. <br> |
| </p> |
| <h3>A Workbench Provides Flexibility and Centralized Project Control<br> |
| </h3> |
| <p>The tools required to build an application must vary in order to match the |
| customer's preferred application patterns. There are three ways developers can |
| use tools to develop applications:<br> |
| </p> |
| <ol> |
| <li>Simple applications can be built using independent, specialized tools with |
| all component relationships and publication managed by the developer. <br> |
| </li> |
| <li>An IDE can be used to provide all the integrated tools required to build |
| the entire application. <br> |
| </li> |
| <li>Use a workbench to integrate tools matching customer needs.<br> |
| </li> |
| </ol> |
| <p>The first approach has the advantage that it provides hands on development |
| where the developer knows everything. Developers can choose any tool they want |
| to build any resources they want. However, this approach doesn't scale to larger, |
| more complex, highly linked projects requiring multiple versions, and a larger |
| development team. It becomes increasingly difficult for a single individual |
| to comprehend the complete project. Taking this approach can often result in |
| applications that are hard to understand, extend, validate, and maintain.<br> |
| </p> |
| <p>The second approach is appealing because all the tools required for building |
| and maintaining applications are incorporated into a single product. The developer |
| gets everything needed in a single product from a single vendor. This presumably |
| results in well-integrated tools. However, these IDEs are extremely difficult |
| to build because there are so many component types, and technologies are changing |
| too fast. IDEs can be sufficiently complex that they cannot keep up with changes |
| in application domains, deployment architectures, technologies, or development |
| processes. It is difficult for an IDE to match the features of a best-of-breed |
| point tool resulting in mediocre tools and poor user experience. Users do not |
| have the flexibility to choose and integrate the tools in a manner that best |
| matches their preferred development style and e-business application pattern.<br> |
| </p> |
| <p>The workbench approach solves these problems by providing a central integration |
| point for project control and an integration mechanism to include resource-specific |
| tools. This approach allows a user to build applications using any components |
| they want with any tools while at the same time providing a common view of the |
| complete application across all components and the entire team. This allows |
| flexibility and choice necessary to select and integrate tools that meet different |
| e-business patterns and developer roles but still keeps the application under |
| control. The workbench can provide services common to, or across tools including |
| reporting capabilities, managing relationships or dependencies between components, |
| component management, and publishing services. Using a workbench simplifies |
| tool integration by allowing tools to integrate with the central workbench instead |
| of each other. This may significantly reduce the number of integrations that |
| must be developed, and provides a more consistent environment for the end user. |
| The workbench can be configured with the tools that best map to the e-business |
| development patterns.<br> |
| </p> |
| <p>The combination of a workbench and integration-ware for developing integrated |
| tools is a win-win situation for platform vendors, ISVs, and application developers. |
| Platform vendor(s) provide integration-ware and services enabling the efficient |
| development of integrated tools. ISVs contribute to the portfolio of integrated |
| tools while minimizing their costs through reuse of the platform and complimentary |
| components produced by other ISVs. Business application developers have best-of-breed |
| tools integrated together supporting their development process.<br> |
| </p> |
| <h3>Integration Conformance Levels<br> |
| </h3> |
| <p>In order to provide flexible tool integration, a tool integration platform |
| must define a number of conformance levels that tool vendors can target based |
| on the desired level of investment, time to market, and specific tool needs. |
| Each level specifies what tool vendors must do to achieve that level of integration, |
| and the required technologies that must be employed. By defining these integration |
| conformance levels, tool vendors have choices while at the same time specific |
| rules for advertising conformance to a particular level. This makes it easier |
| for tool vendors to determine what they must do to integrate their tools with |
| the platform, what technologies have to be supported, and establishes a consistent, |
| deterministic end-user experience. The integration conformance levels are:<br> |
| </p> |
| <p>None: No integration, tools are separate and independent. This is fine for |
| situations where tools operate on independent resources that are not linked |
| or otherwise integrated. It is typical of tool integration today, and often, |
| no further integration is needed.</p> |
| <p>Invocation: Integration is through invocation of registered applications on |
| resource types. Most operating systems and IDE provide this level of integration. |
| A user or installation program can register an application on a particular resource |
| type, and when that resource is selected, the application is invoked on the |
| selected resource in a separate window. There is no further integration. Invocation |
| integration is better than none because it allows the user to browse a collection |
| of artifacts in a file browser, Web browser, or other tool and invoke the correct |
| application to author the resource.</p> |
| <p>Data: Integration is achieved through data sharing between tools. This is the |
| type of integration that was attempted in the past with technologies like IRDS, |
| PCTE+, and the IBM ADCycle program. In this level of integration, tools share |
| each other's data. This provides much better integration than simple tool invocation |
| because now the tools know about each other's resources and can manage relationships |
| between them. Data integration consists of there basic concepts: access, interchange, |
| and transformation. Access is the protocol or API used by the tool to physically |
| access the data. Interchange is the form the data takes once it is accessed, |
| i.e., its schema. Transformation is concerned with modifying the data to meet |
| the needs of the target tool when the interchange format or schema isn't in |
| the form the tool requires. Transformation can also be used to integrate date |
| from many tools into a new single data model meeting the needs of some new tool. |
| </p> |
| <p>Data integration between tools creates a combinatoric explosion of access, |
| interchange, and transformation protocols. In the past, we tried to solve this |
| problem by specifying a repository and schema for all tools to integrate with. |
| This turned out to be impossible because tool vendors couldn't let a single |
| vendor (often a competitor) control such strategic aspects of their infrastructure, |
| and no one repository or extensible schema was sufficient to meet all vendor |
| needs. A better solution is exploit open standards that isolate tools from each |
| other and their underlying repositories and schemas. Fortunately there are a |
| number of standards that exactly meet our needs. WebDAV (Web Distributed Authoring |
| and Versioning)</p> |
| <p> using WebDAV for data access, XML/XMI/MOF for data interchange, and XSLT for |
| data transformation and integration.<br> |
| API: Tools interact with other tools through JavaBeans that abstract tool behavior |
| and make it publicly available.<br> |
| UI: Tools and their user interfaces are dynamically integrated at runtime with |
| a common desktop.<br> |
| The Workbench Tool Integration Platform is Different<br> |
| Then we need to establish a set of patterns that describe typical architectures |
| used by ISV tools. These might include:</p> |
| <p>Java/Swing application using files in the file system for persistence<br> |
| OLE Document editor<br> |
| Java/Swing application using a non-file based repository (object repository |
| or relational, doesn't really matter which)<br> |
| C++ client/server application with proprietary client/server communication protocol |
| and proprietary repository<br> |
| etc.</p> |
| <p>Then we look at each one of these patterns and explore how they can transition |
| to Workbench technologies through the levels of integration. What we'll see |
| is that there are patterns here too. Things like:<br> |
| Launching the application client on a resource type<br> |
| File based tools can use the workbench resource management model versioning, |
| access control, synchronization, disconnected work, etc.<br> |
| OLE Document editors can easily integrate their UIs, but need to do additonal |
| adaptor work to integrated with the outline, properties, and task views.<br> |
| Java/Swing applications can run in the same JVM so they can access other plug-in |
| API (other tools' busines models). <br> |
| Java/Swing applications can be easily converted to Desktop editors by modifying |
| their menu contribution to use either Swing menus or desktop contribution depending |
| on who launches them. They can also put their top-level component in an SWT |
| container so they can easily integrate with the rest of the workbench, similar |
| to ActiveX controls.<br> |
| Tools with proprietary repositories can start by exporting data out of their |
| repositories as XMI document through queries that represent typical units of |
| work. These XMI documents can be consumed by new tools integrated with the workbench |
| while existing C++ based clients work on the same repository.<br> |
| The next step for these tools would be to provide an interfact to their tools |
| model in a Java plug-in. The Java model could use the XMI documents, the repository |
| directly, or both for persistence. Using the new editor extension-points, this |
| Java model could be used to develop new editors on the tool's model while maintaining |
| the same repository.<br> |
| The repository could implement a WebDAV interface to provide a standard protocol |
| for accessing the XMI documents.<br> |
| and so on.</p> |
| <p></p> |
| </body> |
| </html> |