EP1751657A1 - Plate-forme d'execution de portail - Google Patents

Plate-forme d'execution de portail

Info

Publication number
EP1751657A1
EP1751657A1 EP05731562A EP05731562A EP1751657A1 EP 1751657 A1 EP1751657 A1 EP 1751657A1 EP 05731562 A EP05731562 A EP 05731562A EP 05731562 A EP05731562 A EP 05731562A EP 1751657 A1 EP1751657 A1 EP 1751657A1
Authority
EP
European Patent Office
Prior art keywords
portal
framework
portal server
net
java
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP05731562A
Other languages
German (de)
English (en)
Inventor
Tsufit Naor
Ofer Feldman
Ariel Bentolila
Yossi Pik
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SAP SE
Original Assignee
SAP SE
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/851,696 external-priority patent/US7716640B2/en
Priority claimed from US10/851,469 external-priority patent/US7406510B1/en
Priority claimed from US10/853,024 external-priority patent/US7681202B2/en
Application filed by SAP SE filed Critical SAP SE
Publication of EP1751657A1 publication Critical patent/EP1751657A1/fr
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/20—Software design

Definitions

  • the present invention relates to providing runtime support for applications developed for different frameworks, and more specifically to techniques for providing a portal that is capable of executing portal components developed based upon different frameworks and languages.
  • Various computing frameworks or platforms have evolved over the years in the computer industry. Examples of such computing frameworks include the .NET computmg framework from Microsoft Corporation, Java-based frameworks such as the Java 2 Platform, Enterprise Edition (J2EE) framework from Sun Microsystems, Inc., and others. Each framework can be considered a group (sometime called a "stack") of common services that each framework provides to applications that are built with or run on the framework.
  • the .NET framework is a framework provided by Microsoft for programming support for web services that provide a user the ability to use the Web rather than the user's computer for various services. .NET provides users with a Web-enabled interface for applications and computing devices and makes computing activities increasingly Web browser-oriented.
  • the .NET framework includes servers; building-block services, such as Web-based data storage, and device software.
  • the .NET framework also enables developers to create reusable modules that can be used in the .NET framework.
  • Common Language Runtime (CLR) provides a foundation for building applications and components for the .NET framework.
  • J2EE is a Java-based application server framework from Sun Microsystems, Inc. for the development of distributed applications. J2EE and is designed for simplifying application development in a multi-tiered environment by enabling users to create standardized, reusable modular components. J2EE includes many components of the Java 2 Framework, Standard Edition (J2SE).
  • J2EE framework consists of a set of services, application programming interfaces (APIs), and protocols that provide the functionality for developing multi-tiered, Web-based applications.
  • Each framework generally supports its own set of programming languages, design environments, programming conventions, programming methodologies, programming APIs, messaging services, security services, etc. that may be used to build applications for the specific framework.
  • the Java language is used to build applications for the J2EE framework.
  • a Java Development Kit (JDK) is provided for building applications for the J2EE framework.
  • languages that can be used to build applications for the .NET framework include C++, C#, Visual Basic .NET, J#, ASP.NET, etc (referred to as the ".NET languages").
  • the runtime environment that is needed to support and execute applications written for a particular framework also differs from the runtime environment for other frameworks.
  • Java stack or Java Virtual Machine (JVM) running on a UNIX machine is generally needed for running applications that are built for the J2EE framework.
  • An Internet Information Services (US) Server running on a Microsoft Windows machine and CLR compilers are generally needed for running applications developed for the .NET framework.
  • SAP AG enterprise portal products developed by SAP AG are based upon a Java framework such as J2EE framework.
  • a SAP Portal supports components (e.g., portal snippets or iViews) developed in a J2EE environments using Java. Such components are commonly referred to as Java components.
  • Components developed for a .NET framework (“.NET components") using a .NET language cannot be properly integrated to use services provided by the SAP Java-based portal. This has proven to be a major impediment for .NET developers to write components for SAP portals.
  • Embodiments of the present invention provide techniques that enable an application or component developed according to a first framework specification to use services provided by an application executing on a second framework that is different from the first framework.
  • a portal architecture is described that is capable of running portal snippets developed according to different framework specifications.
  • a J2EE framework-based portal is configured to execute portal snippets developed using Java for a Java-based framework and also to provide support for and execute portal snippets that have been developed using a language supported by (or compatible with) another framework such as .NET framework.
  • a first portal server executing according to a first framework receives a request from a first computer identifying a portal snippet that is developed using a first language supported by a second framework different from the first framework.
  • the request is communicated from the first portal server to a second portal server that is configured to process portal snippets configured using a language supported by the second framework.
  • a response to the request is generated at the second portal server and communicated from the second portal server to the first portal server.
  • the response is communicated from the first portal server to the first computer.
  • a first portal server is provided that is configured to process portal snippets developed using a first language supported by a first framework.
  • a second portal server is provided that is configured to process portal snippets developed using a second language supported by a second framework.
  • the first portal server receives a request from a first computer identifying a portal snippet that is developed using the second language.
  • the request is communicated from the first portal server to the second portal server.
  • a response to the request is generated at the second portal server.
  • the response is communicated to the first computer via the first portal server.
  • FIG. 1 is a simplified block diagram of a distributed network comprising an enterprise portal that may incorporate an embodiment of the present invention
  • Fig. 2 depicts a .NET proxy object created for a Java class and a wrapper created for the .NET proxy object according to an embodiment of the present invention.
  • FIG. 3 depicts a simplified high level information flow between various components of a portal for processing .NET portal snippet requests according to an embodiment of the present invention
  • Figs. 4A, 4B, 4C, 4D, 4E, and 4F show examples of deployment models according to embodiments of the present invention.
  • Embodiments of the present invention provide techniques that enable an application or component developed according to a first framework specification to execute and use services provided by an application executing on a second framework that is different from the first framework.
  • a portal architecture is described that is capable of running portal snippets developed according to different framework specifications..
  • a SAP portal environment is described that executes in a Java-based J2EE environment.
  • the SAP portal In addition to executing portal snippets developed using Java for a Java-based framework, the SAP portal also provides support for and executes portal snippets that have been developed using a language supported by another framework such as .NET framework
  • .NET framework Another framework
  • the teachings of the present invention are however not limited to the J2EE or .NET framework but can be applied to other frameworks.
  • a portal provides a central gateway through which users can access various information sources and services/applications.
  • a portal may include several components including one or more portal pages.
  • a portal page may comprise one or more portal snippets that enable data to be retrieved and displayed on the portal page.
  • Portal snippets are generally programs that retrieve data from an information resource and display it on a portal page. Examples of portal snippets include portlets, SAP's iViews, Plumtree's gadgets, Microsoft's web parts, etc.
  • Portals generally allow a user to select and customize portal snippets that are included in the user's portal page or pages. In this manner, the user can customize the content that is retrieved and displayed on the user's portal page.
  • a portal snippet can be considered as an information query (or multiple queries) having one or more input parameters that is executed to retrieve information from one or more information sources.
  • the parameters to the query and their values may be set by the portal administrator, the portal snippet designer/programmer, or some other user, or may be set by default.
  • each portal snippet is typically allocated a location on a page or screen where the retrieved information is to be displayed.
  • the portal snippet is automatically invoked.
  • the one or more parameterized queries corresponding to the portal snippet are executed to obtain the relevant information from one or more information resources. Examples of queries include a query accessing stock information, a query accessing weather information, a query to access company news, query to access a particular set of documents, etc.
  • the retrieved information is then displayed on the section of the page allocated to the portal snippet.
  • a portal snippet might be developed using Java language, such as a Java code module or a Java class object.
  • Java portal smppet a portal snippet programmed using Java for a Java-framework specification, such as J2EE
  • Java portal smppet may use APIs and services provided by the J2EE Java- framework and may be developed in a Java Integrated Development Environment (Java IDE).
  • Portal snippets may also be developed in other frameworks such as the .NET framework from Microsoft Corporation.
  • a portal snippet may be developed using a language supported by (or compatible with) the .NET framework such as C#, VB.NET, J#, C++, ASP.NET, Visual Basic, etc.
  • a portal snippet programmed using a .NET language will be referred to as a ".NET portal snippet" (sometimes also referred to as a ".NET iView”).
  • a .NET portal snippet may use APIs and services provided by the .NET framework and may be developed in a .NET Integrated Development Environment (.NET IDE) such as Visual Studio .NET from Microsoft Corporation.
  • .NET IDE .NET Integrated Development Environment
  • .NET portal snippets can be executed in a Java-framework (e.g., J2EE) based portal.
  • a .NET portal snippet can use services and objects provided by a SAP portal executing in a J2EE framework.
  • a .NET portal snippet might be written in a way similar to developing an ASP.NET page.
  • a .NET portal snippet may comprise an ASP.NET page and its compiled code.
  • other formats may be used for developing a .NET portal snippet.
  • a .NET portal snippet can use portal APIs and services that were developed in Java as though they were developed in .NET. .NET conventions of writing web pages can be used to write the portal snippets. .NET developers can easily develop portal snippets using their .NET skills. .NET and Windows components (e.g., COM objects) may be used to develop portal snippets. Embodiments of the present invention thus give users that are not Java developers the ability to develop portal snippets (content) for a Java-based Portal such as the SAP Portal.
  • a new object class — SAP.Portal.Web.UI.PortalComponent - is provided to the portal snippet designers.
  • This new class derives from System. Web.UI.Page class.
  • a .NET portal snippet is like an ASP.NET page along with its associated compiled code.
  • .NET iViews that can execute in a SAP Java-based portal environment inherit from the new object class.
  • Portal-specific contextual objects such as profile (gives specific information of the instance of an iView), logger (logs problems in the Java or .NET portal server in one log), user information, theme information, etc.
  • .NET portal snippets are made available through properties of the iView. All ASP.NET objects such as requests, responses, sessions, applications, etc. are available to iView developers. The implementation of .NET portal snippets is however not limited to using ASP. NET— various other techniques and formats may also be used to develop .NET portal snippets in alternative embodiments.
  • FIG. 1 is a simplified block diagram of a distributed network 100 comprising an enterprise portal 102 that may incorporate an embodiment of the present invention.
  • Fig. 1 is merely illustrative of an embodiment incorporating the present invention and does not limit the scope of the invention as recited in the claims.
  • One of ordinary skill in the art would recognize other variations, modifications, and alternatives.
  • a client computer 104 is coupled to enterprise portal 102 via communication network 106.
  • Portal 102 provides a central gateway through which applications, such as browser 108 executing on client computer 104, can access various information and services/applications from information sources 110.
  • Information sources 110 may include various applications (either internal or external to the enterprise portal) 112, documents 114, source from the Web 116, various databases 118, and other information sources 120.
  • Client computer 104 may be a personal computer (PC), a PDA, a mobile phone, or any other computing device.
  • Communication network 106 may be a local area network (LAN), a wide area network (WAN), a wireless network, an Intranet, the Internet, a private network, a public network, a switched network, or any other suitable communication network.
  • Communication network 106 may comprise many interconnected computer systems and communication links such as hardwire links, optical links, satellite or other wireless communications links, wave propagation links, or any other mechanisms for communication of information.
  • Various communication protocols may be used to facilitate communication of information via communication network 106, including TCP/IP, HTTP protocols, extensible markup language (XML), wireless application protocol (WAP), protocols under development by industry standard organizations, vendor-specific protocols, customized protocols, and others.
  • the runtime environment for enterprise portal 102 includes a Java-framework compliant server such as J2EE portal server 122 depicted in Fig. 1 and a .NET portal server 124.
  • J2EE portal server 122 is coupled to .NET portal server 124 via interoperability framework 126.
  • the runtime environment may also include a unification server 128 and knowledge management (KM) 130.
  • unification server 128 is configured to provide a business unification layer that enables dynamic integration of both applications and information from various sources.
  • the business unification layer enables the creation of a unified object model, so that a portal user may dynamically integrate applications and information.
  • Knowledge management (KM) 130 is a set of services for managing knowledge and collaboration. KM 130 provides a framework to harmonize various business tools under one business management framework regardless of the physical location of data.
  • KM 130 includes a repository framework that manages the content of documents and corresponding document attributes, classification engine that organizes contents in folder or tree structures, and other components for managing information.
  • J2EE portal server 122 is a component that is configured to provide portal services.
  • J2EE portal server 122 includes a web server 132, a repository 134, and a portal runtime (PRT) 136.
  • Web server 132 is configured to facilitate transfer of data to and from J2EE portal server 122. For example, web server 132 receives portal snippet requests from client computers and communicates responses to the requests to the appropriate client computers. Web server 132 may also be configured to provide authentication services.
  • Repository 134 provides a persistent store for information and objects that are used for providing portal functionality.
  • Repository 134 might store application objects, connector service objects, templates, portal snippets, portal roles information, portal pages, and the like.
  • SAP's Portal Content Directory One example of such a repository is SAP's Portal Content Directory.
  • PRT 136 is an engine that is responsible for Portal specific behaviors, including responding to Java or .NET portal snippet requests. It provides a framework for creating, deploying, and running Java Portal Services, Java Portal Components, .NET Portal Components 138 and .NET Portal Service 140. It has some layers of abstraction of Portal objects. PRT 136 provides cache features that components could use for the processing. According to an embodiment of the present invention, PRT 136 may be implemented as a Java servlet that could be added to any Web Application Server (WAS). In alternative embodiments, the various services and components may be integrated as part of PRT 136. PRT 136 may also be integrated with J2EE server 122 in alternative embodiments.
  • WAS Web Application Server
  • .NET Portal Components 138 comprise code (logic) that is executed for portal snippets supported by portal 102. Based upon the portal snippet request received from a client computer, a particular .NET Portal Component may be selected and executed for the portal snippet.
  • a .NET Portal Component is a standard Java portal component that calls .NET Portal Service 140.
  • NET Portal Service 140 is configured to provide services for running portal snippets and servers that provide portal functionality.
  • .NET Portal Service 140 enables applications developed compliant to the .NET framework to use Java portal services.
  • An application is considered compliant to the .NET framework if it is programmed using a .NET language and/or uses protocols and APIs provided by the .NET framework.
  • .NET Portal Service 140 provides the ability to use Java portal services from a .NET environment.
  • .NET Portal Service 140 also provides Java services that extend the functionality that a developer may use. For example, it may provide portal services such as system landscape, user management, look and feel, and others.
  • .NET Portal Service 140 provides the ability to use Java portal services from a .NET portal snippet using interoperability framework 126.
  • .NET Portal Service 140 creates and exposes wrappers to proxies generated by interoperability framework 126.
  • the wrappers contain code that optimizes communication and other operations performed by J2EE portal server 122 and .NET portal server 124.
  • Various techniques such as caching, batch calls, minimizing information trips between J2EE portal server 122 and .NET portal server 124, etc. are used to achieve the optimization.
  • .NET Portal Service 140 might contain Java code that enables communication with .NET portal server 124.
  • .NET Portal Service 140 is a standard Java portal service that includes the necessary logic for enabling communications between J2EE portal server 122 and .NET portal server 124.
  • the .NET portal snippets also use services provided by interoperability framework 126. As a result, the core code of the portal runtime does not need to be changed in order to provide support for running .NET portal snippets.
  • .NET portal server 124 is configured to perform processing for supporting .NET portal snippets.
  • .NET portal server 124 includes .NET Framework code 142.
  • .NET Framework code 142 may include ASP.NET code comprising ASP pages that are executed responsive to receiving .NET portal snippet requests. Accordingly, an IIS server is not used for execution of .NET portal snippets—instead, an ASP.NET networking process is used. ASP.NET objects such as requests, responses, sessions, applications, etc. are available to portal snippet (iView) developers.
  • .NET Framework code 142 may include other types of code that is to facilitate execution of .NET portal snippets.
  • different application domains may be used for executing the portal snippets.
  • one application domain may be used for all the portal smppets.
  • the portal snippets may be separated into separate applications. Pool of application domains may be used.
  • Application domains provide a secure and versatile unit of processing that the common language runtime can use to provide isolation between applications. Several application domains can be run in a single process with the same level of isolation that would exist in separate processes, but without incurring the additional overhead of making cross-process calls or switching between processes.
  • a monitoring process may be used to monitor .NET portal server 124.
  • the .NET Portal server may also run as a NT service, leveraging all the features of a NT service, including automatic recovering after failure.
  • interoperability framework 126 provides a mechanism that enables communication of information between .NET portal server 124 and J2EE portal server 122.
  • Interoperability framework 126 allows API calls from J2EE portal server 122 (also referred to as the Java stack) to .NET portal server 124 (also referred to as the .NET stack) and vice versa.
  • Objects can be passed by reference or by value between J2EE portal server 122 and .NET portal server 124 depending on the context of use.
  • a Java proxy object is created, and vice versa.
  • Interoperability framework 126 may use .NET remoting technology on the .NET side.
  • the transport channel used by interoperability framework 126 may be optimized for one or more machines. The transport channel could be implemented as HTTP, TCP, Shared memory, etc.
  • interoperability framework 126 may be implemented using third party products such as the Ja.NET product from
  • Ja.NET provides a bridge between the Java/J2EE world and the .NET world.
  • Ja.NET provides a framework that allows data to be exchanged between Java applications executing in a Java- framework (e.g., J2EE) and applications executing in a .NET framework.
  • J2EE Java- framework
  • .NET applications executing in a Java- framework
  • Ja.NET applications executing in a Java- framework
  • Ja.NET can access Java/J2EE applications as though they were .NET applications.
  • Ja.NET Java and J2EE application can access .NET components as though the .NET components were written in Java.
  • Ja.NET leverages .NET remoting which is Microsoft's distributed objects communication protocol.
  • .NET remoting provides services for communicating data between .NET applications and components executing in a distributed environment.
  • .NET remoting is used within .NET to enable common language runtime (CLR) components in different application domains to talk to each other.
  • Java components are exposed as CLR components and CLR components are exposed as Java components.
  • Ja.NET proxies are used. These proxies might be generated during compile time and represent objects corresponding to objects in the opposite stack (i.e., within the .NET stack or Java stack). During runtime, a proxy object is used as any other local object, from the caller's perspective.
  • Java classes are exposed to .NET designers.
  • a .NET proxy object is created for each Java class that can be called from .NET.
  • a .NET wrapper class is created for each proxy class.
  • a .NET proxy object 204 is created for a Java class 202.
  • a wrapper 206 is created for .NET proxy object 204. Since it is a wrapper, its interface might be different from the proxy. For example, it might have only one method m3() that internally uses methods ml() and m2() depicted in Fig. 2.
  • Proxies may be divided into two types: (1) By Value; and (2) By Reference.
  • Communicating a proxy object by value implies that when a proxy of a particular object on a first server is sent to a second server, the proxy already contains all the data of the particular object on the first server. The data is serialized and when it is used by the second server, no round trips are needed to the first server or local server.
  • a reference type proxy object means that the proxy contains only references (pointers) to the object on the original provider server. Accordingly, when a proxy is communicated by reference from a provider server to a consumer server, only a reference to the object is passed. When a method on the object is called on the consumer server, the code that is executed actually runs on the provider server.
  • invocation of a method on a Java object from .NET results in the following processing:
  • a wrapper object is created using the "new" method. Processing may be optimized by caching the wrapper object for later calls.
  • the proxy object is created and the Java object is created (by the interoperability framework).
  • the (.NET) proxy object holds a "reference" to the Java object.
  • step 3 might be different in that the (.NET) proxy object gets a 'reference' to an exiting Java object.
  • a symmetrical flow happens when calling from Java to .NET.
  • Fig. 3 depicts a simplified high level information flow between various components of a portal for processing .NET portal snippet requests according to an embodiment of the present invention.
  • Fig. 3 is merely illustrative of an embodiment incorporating the present invention and does not limit the scope of the invention as recited in the claims.
  • processing is initiated when a request for a .NET portal snippet is received by J2EE portal server 122 from a client computer 104.
  • the .NET portal snippet request may be automatically generated at client computer 104 when a user views a page comprising the portal snippet using a browser executing on client computer 104.
  • the generated .NET portal snippet request is then communicated from client computer 104 to J2EE portal server 122.
  • the .NET portal snippet request might be received by web server 132.
  • Web server 132 may then perform user authentication operations.
  • web server 132 may forward the .NET portal snippet request to PRT 136.
  • the .NET portal snippet request that is received comprises information that identifies a specific portal snippet (or iView).
  • PRT 136 uses that information o identify a .NET Portal Component 138 that contains code that is responsible for execution of the requested portal snippet. If the .NET portal snippet is part of a page, the page might be responsible for launching the appropriate .NET Portal Component 138. .NET Portal
  • Component is a standard Java portal component that calls .NET Portal Service 140.
  • .NET Portal Service 140 is a standard Java portal service that includes the necessary logic for enabling communications between J2EE portal server 122 and .NET portal server 124.
  • .NET Portal Service 140 collects the necessary information from J2EE portal server 122 using Java API calls.
  • One or more additional Ja.NET proxy objects may be created that contain the data for the request, for example, Request, UserContext, Headers, etc. and passed to .NET portal server 124.
  • the objects may be passed by reference or by value.
  • .NET Portal Service 140 uses interoperability framework 126 to facilitate communications between J2EE portal server 122 and .NET portal server 124.
  • Ja.NET may be used to implement interoperability framework 126.
  • .NET Portal Service 140 uses a Ja.NET proxy 302 of the public .NET object of .NET portal server 124. This proxy is a Java Class that has the same signature as the entry-point object of .NET portal server 124.
  • Ja.NET proxies use Ja.NET mechanism to pass the .NET portal snippet request from J2EE portal server 122 to .NET portal server 124.
  • the mechanism uses a TCP server. Other types of communication channels may also be used.
  • a Response Proxy object 304 is also created and passed to .NET portal server 124 as part of the mechanism. As described below, Response Proxy object 304 is used for returning the results of the request from .NET portal server 124 to J2EE portal server 122.
  • .NET portal server 124 determines a specific .NET framework code to be executed based upon information contained in the .NET portal snippet request.
  • a .NET framework code is determined to be executed.
  • a .NET framework API is used to run the selected ASP.NET page.
  • an US server is not needed for running the ASP.NET page, instead an ASP.NET Process 306 is used.
  • the .NET code of the .NET portal snippet is kept in the portal (Java) repository
  • the .NET Portal server when the .NET Portal server is requested to run the code it is retrieved from the Java Portal.
  • the .NET Portal server identifies that it does not have the updated code, it asks the Java Portal server (via the interoperability framework for the portal snippet's code).
  • An additional mechanism is used to update the .NET Portal server on any update of the portal snippet's code in the Portal repository.
  • the results of the execution are returned by .NET portal server 124 to .NET Portal Service 140 of J2EE portal server 122 using Response Proxy object 304 that was sent earlier.
  • the response may include HTML and headers.
  • Interoperability framework 126 is used to facilitate communication of the response from .NET portal server 124 to J2EE portal server 122.
  • Ja.Net is used for the communication.
  • the response proxy then dispatches the response data to the corresponding PRT APIs.
  • PRT 136 may add additional information to the response received via .NET Portal Service 140.
  • the additional information may include data relevant to the .NET portal snippet such as JScripts, cascading style sheets (CSS) files, etc.
  • the response is then communicated to client computer 104 via web server 132.
  • Content received in the .NET portal snippet response may then be displayed in a location allocated to the .NET portal snippet on a page viewed by the user.
  • the .NET portal snippet request received by J2EE portal server 122 may also contain calls to portal services such as System landscape, User management, look & feel, etc. In this instance, additional processing steps may be performed in addition to the processing described above for Fig. 3.
  • .NET portal server 124 When .NET portal server 124 processes such a request and runs the appropriate ASP.NET page (or appropriate .NET framework code), it may use Ja.NET proxies that represent Java objects. These proxies may be reference proxies and thus any call to these proxies is executed on J2EE portal server 122 using J2EE server .NET mechanism. The code (logic) runs on the Java portal server using standard portal services and the results of the methods are returned to .NET portal server 124. The client code runs on a .NET platform.
  • J2EE portal server 122 If the request received by J2EE portal server 122 is for a Java portal snippet, then processing to satisfy the request is performed by J2EE portal server 122 and .NET portal server 124 is not used.
  • FIGs. 4A, 4B, 4C, 4D, 4E, and 4F show examples of deployment models that may be used.
  • a J2EE portal server and .NET portal server may reside on the same physical machine, such as a MS Windows machine. Each server may have its own repository and configuration.
  • a J2EE portal server and a .NET portal server are installed on different machines.
  • the J2EE portal servers may be installed on a UNIX machine and the .NET portal servers may be installed on a Windows machine.
  • the set of machines on which J2EE portal servers are installed may form a J2EE portal cluster.
  • the set of machines on which .NET portal servers are installed may form a .NET portal cluster.
  • each J2EE portal server may be configured to work with a particular .NET portal server.
  • servers of different versions may be deployed at the same time.
  • a particular version of J2EE portal server may be configured to work with a particular version of .NET portal server.
  • J2EE portal servers and .NET portal servers may also be used.
  • a single J2EE portal server may work with two .NET portal servers (.NET1 and .NET2).
  • the J2EE portal server and the two .NET portal servers are installed on the same machine.
  • the servers are installed on different machines.
  • a dispatcher may be installed on the J2EE portal server to implement the model depicted in Figs. 4C and 4D.
  • the dispatcher may be configured to determine a .NET portal server to use from the available .NET portal servers.
  • the dispatcher may prevent marshalling between application domains on the .NET side.
  • test portal snippets may be run on a "development" .NET portal server (e.g., .NETl) and released portal snippets may be run on a "production" .NET portal server (e.g., .NET2).
  • development e.g., .NETl
  • production e.g., .NET2
  • J2EE portal server instances may work with the same .NET portal server as shown in Figs. 4E and 4F.
  • the J2EE portal server instances may use the same repository but with different configurations.
  • the two J2EE portal servers J2EE#1 and J2EE#2
  • the .NET portal servers are installed on the same machine.
  • the J2EE portal servers are installed on one machine and the .NET portal server is installed on a different machine.
  • J2EE portal server 122 provides a common point for receiving both Java portal snippets requests and .NET portal snippet requests. Accordingly, from the viewpoint of the browser application, J2EE portal server 122 acts a central point for accessing portal services. .NET portal snippet requests are processed by J2EE portal server 122 and .NET portal server 124 working in conjunction. Execution of .NET portal snippet requests does not require the use of an IIS server or any other server external to the portal.
  • Embodiments of the present invention thus allow portal smppets developed in a .NET language to run within a Java-based portal such as the SAP Portal.
  • .NET portal snippets can use portal APIs and services that were developed in Java as though they were developed in .NET. .NET conventions and languages (e.g., C#, C++, Visual Basic, ASP.NET, VB.NET, J#, etc.) of writing web pages can be used to write portal snippets.
  • .NET developers can easily develop portal snippets using their .NET skills.
  • .NET and Windows components e.g., COM objects
  • Embodiments of the present invention thus give users that are not Java developers the ability to develop portal snippets (content) for a Java-based Portal such as the SAP Portal.
  • embodiments of the present invention enable portal snippets developed using a language supported by a first framework to be executed in a portal based upon a second framework that is different from the first framework.
  • the portal is able to execute portal snippets developed using languages from different frameworks in an integrated manner.

Abstract

L'invention concerne des techniques permettant à une application ou un composant développé selon une première spécification de plate-forme d'utiliser des services fournis par une application en cours d'exécution sur une seconde plate-forme différente de la première plate-forme. L'invention se rapporte à une architecture de portail permettant d'exécuter des bouts de code de portail développés selon différentes spécifications de plate-forme. Un portail basé sur la plate-forme J2EE est conçu pour exécuter des bouts de code de portail développés au moyen d'un langage Java pour une plate-forme Java, et pour permettre la prise en charge et l'exécution de bouts de code de portail développés au moyen d'un langage pris en charge par une autre plate-forme, telle que la plate-forme .NET.
EP05731562A 2004-05-21 2005-04-04 Plate-forme d'execution de portail Ceased EP1751657A1 (fr)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US85146204A 2004-05-21 2004-05-21
US10/851,696 US7716640B2 (en) 2004-05-21 2004-05-21 Techniques for developing portal snippets using an integrated development environment (IDE)
US10/851,469 US7406510B1 (en) 2004-05-21 2004-05-21 Techniques for accessing portal components
US10/853,024 US7681202B2 (en) 2004-05-21 2004-05-21 Portal runtime framework
PCT/EP2005/003530 WO2005114389A1 (fr) 2004-05-21 2005-04-04 Plate-forme d'execution de portail

Publications (1)

Publication Number Publication Date
EP1751657A1 true EP1751657A1 (fr) 2007-02-14

Family

ID=35058083

Family Applications (2)

Application Number Title Priority Date Filing Date
EP05729994A Ceased EP1751656A1 (fr) 2004-05-21 2005-04-04 Techniques de developpement de bouts de codes de portail au moyen d'un environnement de developpement integre (ide)
EP05731562A Ceased EP1751657A1 (fr) 2004-05-21 2005-04-04 Plate-forme d'execution de portail

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP05729994A Ceased EP1751656A1 (fr) 2004-05-21 2005-04-04 Techniques de developpement de bouts de codes de portail au moyen d'un environnement de developpement integre (ide)

Country Status (2)

Country Link
EP (2) EP1751656A1 (fr)
WO (2) WO2005114388A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7406510B1 (en) 2004-05-21 2008-07-29 Sap Portals Israel Ltd. Techniques for accessing portal components
US7681202B2 (en) 2004-05-21 2010-03-16 Sap Portals Israel Ltd. Portal runtime framework
US7716640B2 (en) 2004-05-21 2010-05-11 Sap Portals Israel Ltd. Techniques for developing portal snippets using an integrated development environment (IDE)
US8407309B1 (en) 2004-12-22 2013-03-26 Sap Ag Techniques for specifying and determining property information for portal entities using attributes
MX2015013209A (es) 2013-03-15 2016-04-15 Beulah Works Llc Sistema de captura y descubrimiento de conocimiento.

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5732270A (en) * 1994-09-15 1998-03-24 Visual Edge Software Limited System and method for providing interoperability among heterogeneous object systems
US7213236B2 (en) * 2001-11-30 2007-05-01 Intrinsyc Software International, Inc. Method of bridging between .Net and Java

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2005114389A1 *

Also Published As

Publication number Publication date
WO2005114389A1 (fr) 2005-12-01
WO2005114388A1 (fr) 2005-12-01
EP1751656A1 (fr) 2007-02-14

Similar Documents

Publication Publication Date Title
US8578333B2 (en) Method and system for client-side user interface enhancement to enable application integration and portalisation
US7849437B2 (en) Object oriented web application framework
US7707563B2 (en) System and method for network-based computing
US6496850B1 (en) Clean-up of orphaned server contexts
US6636242B2 (en) View configurer in a presentation services patterns environment
US6477665B1 (en) System, method, and article of manufacture for environment services patterns in a netcentic environment
US6438594B1 (en) Delivering service to a client via a locally addressable interface
US6950850B1 (en) System and method for dynamic runtime partitioning of model-view-controller applications
US6606660B1 (en) Stream-based communication in a communication services patterns environment
US6529948B1 (en) Multi-object fetch component
US6549949B1 (en) Fixed format stream in a communication services patterns environment
US6742015B1 (en) Base services patterns in a netcentric environment
US6715145B1 (en) Processing pipeline in a base services pattern environment
US6615253B1 (en) Efficient server side data retrieval for execution of client side applications
US7716640B2 (en) Techniques for developing portal snippets using an integrated development environment (IDE)
US20060064422A1 (en) Data sharing system, method and software tool
US20070214420A1 (en) Systems and methods for providing a portal including multiple windows
WO2001016734A2 (fr) Systeme, procede et article de fabrication destines a un flux d'autodescripteurs dans un environnement de modeles de services de communication
WO2001016668A2 (fr) Systeme, procede et article pour groupe d'elements mandataires (proxy) rafraichissables dans un environnement a configurations de services de communication
WO2001016706A2 (fr) Systeme, procede et article de production destines a une table de reponse d'exception dans des configurations de services d'environnement
WO2001016733A2 (fr) Systeme, procede et article manufacture pour module de mise en lots des requetes dans un environnement caracterise par des services transactionnels
JP2002049484A (ja) クライアント側ユーザインタフェース要素を処理するサーバ側制御オブジェクト
WO2001016705A2 (fr) Systeme, procede et article de fabrication destines a la recherche fragmentaire dans un environnement de modeles de services d'informations
US7681202B2 (en) Portal runtime framework
WO2001016724A2 (fr) Systeme, procede et dispositif pour module d'habillage existant dans un environnement de schemas de services de communication

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20061123

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE FR GB

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE FR GB

17Q First examination report despatched

Effective date: 20081127

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20121217