The huge demand for ad-hoc and situational enterprise-class applications led to a new kind of Web-based applications, known as enterprise mashups. End users from the business units with no programming skills are empowered to combine and reuse existing company internal and external resources within minutes to new value added applications. In order to handle the growing number of mashable components, we propose a context-aware concept for enterprise mashups that supports users to find relevant components according to their current situation and to compose them automatically. The designed context model which is structured in the three domains agent, computing and environment is implemented in the SAP Research RoofTop Marketplace prototype to demonstrate its applicability and business benefits.
A new trend for software development paradigm, known as enterprise mashups, has
gained momentum in the recent years. They have the potential to bridge the gap
between the automation transaction and peer production world. At the core of the
mashup paradigm are two aspects: First, the empowerment of the end user to cover
ad-hoc and long tail needs by reuse and combination of existing software artefacts;
and second, broad involvement of users based on the peer production concept.
According to Yorchai Benker, who coined the term peer production, “it refers to
production systems that depend on individual action that is self-selected and
decentralized rather hierarchically assigned” [
By means of a business scenario, we motivate the practical challenge: A sales manager (Max Meier) is usually responsible for maintaining knowledge of his company’s products and liaising with customers. Although he has not much technical knowledge and because asking for support from the IT department would cost too much time, he decides to build his own enterprise mashup. Quite fast, he gets confident with the new platform and has success in building his first mashup which combines Customer Data with current Selling Data. Now, he wants to extend his first mashup, but he has no idea what other services would make sense in his context. One option would be to browse in the existing catalogue. But it's hard to find components which best meet his current business needs.
Components which are used by his colleagues from the same department (e.g,. Peter Mustermann) or industry would be also relevant for our sales manager Max. Although adding new mashable components is quite easy, connecting components is the next problem occurring. Often the components have a lot of ports and it's difficult to decide how they can be connected with the correct inport and outport. From the viewpoint of Max, the platform should support him in providing relevant mashable components according to his current context. In addition, after selecting a component, the platform should automatically connect the components.
The goal of this research paper is to fill this gap by designing a concept of how end users can be supported to navigate through the growing enterprise mashup ecosystem in order to adapt their individual working environment according to their context. The general research questions guiding this study are how to model the context space for enterprise mashups as well as how the context information can be organized.
The remainder of this study is organized as follows: After discussing related work in the area of enterprise mashups and context, section three presents the designed context approach. Section four demonstrates the implementation by means of the SAP Research RoofTop Marketplace prototype. A brief evalution and a summary close this present paper.
“An enterprise mashup is a Web-based resource that combines existing resources, be
it content, data or application functionality, from more than one resource by
empowering the actual end users to create individual information centric and
situational applications” [
Resources represent actual contents, data or application functionality. They are encapsulated via well-defined public interfaces (Application Programming Interfaces; i.e., WSDL, RSS, Atom, etc.) allowing the loosely coupling of existing Web-based resources – a major quality of SOA. These resources are created by traditional developers who are familiar with technical development concepts. The layer above contains widgets which provide graphical and simple user interaction mechanism abstracting from the underlying technical resources. The creation of the widgets is done by consultants or key users from the business units who understand the business requirements and know basic development concepts. Finally, the end users from the business units are empowered to combine and configure such visual widgets according to their individual needs, which results in a mashup. According to the motivated scenario in the first section, we focus on the mashup layer in this paper.
Context is an important utilized source of information in interactive computing. In
order to use context efficiently and to build context-aware applications, the term
context needs to be defined. The common aspect of existing definitions [
In order to interpret context and visualize the definition of context, a flexible and
extensible context model is required. As described in the definition of context, an
entity is a person, place, or object. [
This kind of structure includes interrelation between entities that are within one
domain and also interaction between the domains. Another important aspect is that
context information is dynamic by nature. [
Concrete context entities inside those domains can now be expressed as 4-tuples
[
The three examples describe concrete context entities for the agent domain. The first example demonstrates an interaction of entities inside the domain. According to the definition of tuples for context representation, "MaxMeier" represents the entity name, "isColleagueOf" the feature, and "PeterMustermann" the value. Furthermore, this tuple has an internal feature, which means an interaction inside its domain. Because of that, the entity's value must be another entity, in this case "PeterMustermann". The item representing the time is missing in this tuple because it's not necessary to know the exact time of this activity. In contrast to the first example, the other two entities describe an interaction between domains. In the first case, it's the computing domain and in the second case it's the environment domain.
After obtaining the potential context entities, these entities need to be categorized to the three domains agent, environment, and computing. In the terminology of enterprise mashups, the agent domain represents all registered human users, who are eligible to use the enterprise mashup platform. This domain also includes business information like department, industry, country, and position. Due to the fact, that users are using different development platforms for their enterprise mashup applications, the idea of the environment domain is to express where the enterprise mashup is built or executed. Besides execution inside a Customer Relationship Management (CRM) page, the prototype can also be executed inside a sales order environment. What actual widgets are used to build enterprise mashups with a special business purpose is shown by the computing domain. It mainly includes the widgets Country Position and the connection of the in- and outport. The following table summarizes these findings and the categorization of these context entities into the three context domains.
Agent Domain User Industry Department
Industry (i.e. Manufacturing) Specialized division of the large business organization where the user is working at (i.e. Sales Department) Country where the department is located at Status which the user can hpld in his department (i.e. Sales Manager) Computing Domain Enterprise Mashup
Environment Domain Environment
Widgets Visual representation of a resource Identifies the connection point between widgets Purpose that is desired of the enterprise mashup
In contrast to most other typical and traditional applications, which process the input to an according output based on a simple function, context-aware systems need also include and interpret context data to provide relevant information to the user. The process of interpreting raw context data to relevant context information can be described with three context layers. The bottom layer, the Source Data layer is sourced with raw data, like sensed or profiled data. This layer considers every bit of information the system gets and strictly excludes interpretation of data which is done in higher layers. Sensed data is obtained with sensors which provide the physical environment in which the enterprise mashup is executed for example. Profiled data can be for example user's preferences about a special situation. With this source of information, profiled or sensed data, it's possible to generate and build Context Facts related to the situation of the entities. Context facts are defined as something that actually exist and can be verified as true. It interprets the raw information from the Source Data layer to the first meaningful context information the first time. Examples for context facts are "Max Meier is using the Customer Data Mapping mashup", "The Customer Data Mapping mashup is executed in the CRM Start Page", or "Customer Data Mapping mashup uses the Customer Data Widget".
By describing context at a higher level than facts, new situations can be interpreted. Through ordering and weighting with special scores for each context fact, confidence of situations can be achieved. Concerning to the context facts, an example for a situation would be: "Max Meier recommends the widget Google Maps as the best widget for mapping addresses on a map in the CRM Start Page". This example is based on interpretation of the context facts and can be used in order to express context characterized situations and to extract relevant information, like recommended widgets for users building enterprise mashups in the same CRM Start Page.
Most context information is highly dynamic by nature and makes it hard to create and
apply adequate models. In order to provide an adequate model for further practical
exploration, the Context Modeling Language (CML) is applied [
The figure above models context information and types. All necessary context entities are represented by a solid ellipse. The relationship between these entities is defined by roles and an association which is symbolized by connected boxes, one box for each role. Besides trying to visualize the interaction and relationship between the different context entities from table 1, it also includes capturing capabilities for user activities in the form of a fact type that covers historical activities. Besides the historical point of view, user activities also include the used environment, the user’s workplace and as well as the business purpose of the executed and built enterprise mashup. Due to the fact, that each role in the above figure also represents a context fact in form of a relational model, it's possible to easily extract these context facts and use them for the base of the context-aware application.
Context situations are defined in terms of context facts and logical connectives (and,
or, not, exists, forall). They can be unowned, owned by one entity, or owned by
multiple entities. Context-aware systems in ubiquitous computing have the ability to
determine and compute related context for situated behavior (also known as Situated
Computing) [
Each of the three recommendations is represented by a list and has a different focus on the used and processed entities. The first situation contains recommended widgets by colleagues and focuses on the agent domain. Besides the users social network, the users department, industry, country, and the position held by the users are mainly processed in order to generate the list. "Where" the enterprise mashup is built and executed is the main focus for the calculation on the second situation. It considers the different development platforms and mainly recommends different widgets for each environment. The last context situation focuses on the computing domain and considers all widgets which already have been used for the same business purpose.
For each list of the context situation, the widgets need to have a special ordering which should depend on the importance of the widget, as well as how many times the widget has been recently used in enterprise mashups. The widgets quantifier and context related importance is achieved by calculating a scoring function. The scoring considers different parameters, like the users position in the department, the department itself, its industry, country, and as well as the business purpose and the development environment currently used. The following pseudocode tries to state out the main aspect of the used scoring algorithm: For each connection in Context Facts where Widget is involved
Calculate percentage of criteria multiplied with according weight The algorithm tries to consider all connections where the queried widget is involved. For each of those connections, a score is calculated based on the percentage of occurrence in a special context. After that, the list is sorted by that score, in order to have more context-related widgets listed at the top and less context-related widgets at the bottom.
The SAP Research RoofTop Marketplace prototype is an intuitive Web-based application based on AJAX that enables end users to create ad-hoc enterprise-class applications. To demonstrate the applicability of the context model, we have implemented our concept in the SAP Research RoofTop Marketplace prototype. In order to make use of context related information, the RoofTop Marketplace client is linked to a service, called “Lightweight Context Browsing”. This service is responsible to gather and connect important context-related information from the repository which manages all widget or enterprise mashup information.
As motivated in the introduction, the sales manager in our scenario will usually be responsible for maintaining knowledge of his company's products and liaising with customers. Before starting to build the first enterprise mashup, he has to maintain his user profile which includes his business details like the position, the industry, the country, or the department he is currently working at. Quite fast, the sales manager added the Customer Data widget to the design view, to get a list of all customers of his company. However, this step was quite easy, but to extend his enterprise mashup he has not much and detailed knowledge about other widgets which would make sense for his context. Because of that, the sales manager clicks on a little button at the top of the Customer Data widget. This button is available at all widgets. The upcoming popup shows lists of recommended widgets from which the user can choose may it “recommendation by colleagues”, “recommendation by environment”, or “recommendation by business purpose”.
The sales manager is interested in widgets which have been often used by his colleagues in the same department (“recommendation by colleagues”). The presented list of recommended widgets includes “Google News”, “Flickr Photos”, and “Google Maps”. However, these widgets can also be found in the widget catalogue, where they are categorized in different categories. The great benefit of this small presented list is that if the user decides for one of the widgets, it is automatically added to the enterprise mashups. If the user had decided to add the widget from the widget catalogue, he then had the whole responsibility in connecting the widget ports which can also be a nightmare according to the number of the technically focused ports. Instead, if the user decides to add a widget from the lightweight context browsing service presented above, the widget is added to the editor and afterwards connected automatically. This saves time dramatically and assists the end user in a passive manner without dealing of finding and connecting widgets.
The sales manager decided to add the “Google Maps” widget. With one click, the widget is automatically added. Also the outport of the customer data widget is automatically connected to the inport of the “Google Maps” widget. In this case, the “Google Maps” widget is sourced with the address from a customer. As a result, the customers address is automatically displayed on “Google Maps”. The aim of this paper was the design of a model for context-aware enterprise mashups. After defining the main terms related to enterprise mashups and context, we presented a context domain model for enterprise mashups and a layer concept of how the context can be organized. An implementation of the concept in the SAP Research RoofTop Marketplace prototype demonstrated its applicability. By means of a typical business scenario, we evaluated and discussed the first benefits of the solution.
What is still missing is a broader application of the context model in various application domains. Further research will deal with a user evaluation in a field study to measure the benefits. In addition, there is no privacy enforcement in the current concept. The base of the described concept is the mass number of enterprise mashups which has been saved by the users and later processed. However, while saving enterprise mashups the end users agree that their sensitive data is stored and later be used to support others.