View All Attachments for Bug 185019

Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Attachment #65556
The article	text/html	2007-05-01 21:29:10 EDT	19.31 KB	no flags	Details

<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">
&nbsp; 
<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">&nbsp;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 &quot;integration-ware&quot; 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 &quot;integration-ware&quot;. 
  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>