Service exchange event subscribers management
US1 As business user of my company's applications but also EasySOA Light user, I want to be notified when application A calls application B in order to react when it is called and do additional behaviour (such as an EasySOA Light mashup).
Example 1 : A = Online Shop and its order management, B = CRM and its ContactService
Example 2 : A = Task management ex. Google Calendar or Zimbra, B = Collaborative solution ex. Nuxeo
US1 As business user of my company's application B but also EasySOA Light user, I want to be notified when application B's service BSService is called (by application A, or even others) in order to react when it is called and enrich B with additional behaviour (such as an EasySOA Light mashup)
=>
Example 1 : Schedule a phone call for CRM users to check customer satisfaction about the order (identified by its number)
Example 2 : Delete a document in Zimbra when it's done in Nuxeo. It will synchronize the data states between Zimbra and Nuxeo.
Example 3 : Update tasks's state in google calendar when it's made in Zimbra'one.
US2 As business user of my company's application A ex. Nuxeo calling B ex. Zimbra but also EasySOA Light user, I want to be notified when application A calls application B's BService in order to react when it is called and enrich what A triggers with additional behaviour (such as an EasySOA Light mashup)
Example 1 : We can imagine that we have a web service which role is to receive a call and generate accounting report te same night for the call's sender. When a call is made, an alert can be sent to the secretary who will validate the informations which will be on the report of the call's sender. This operation for be sure of the validity of the report.
Example 2: Another example, in a company two workmates working in the same production process. the first one (Francois) and the second one (Nicolas).Francois need to access to some datas, works on it and after that, he need to discuss with Nicolas who worked with other datas. They should done their work before the meeting. So a way to use EasySOA for resolving this dependency is : When Francois access to the data by a web service's call, an alert is send to Nicolas telling him to be ready because Francois will be ok shortly. This for inform each of them on the state the workmate for impoving productivity.
US3 As a company manager i want to be informed by the EasySOA system when a user try to access to a data. I also want to import in EasySOA my own behavior. The EasySOA system will separe these two tasks in two types. the first type will be the library which represents all the behaviors deployed by default and the other type will be the behaviors added by the users.
business user of my company's application A ex. Nuxeo calling B ex. Zimbra but also EasySOA Light user,
As a EasySOA Light user,
- I want to login in TODO from Nuxeo's Service Use Portal...
- I want to register my EasySOA-known custom behaviour service on an existing service S1, so that it'll trigger its call
- (optional) I want to register my EasySOA-known custom behaviour service on an existing reference (service S1 called by another one S2), so that it'll trigger its call
- I want to unregister...
- I want to list my registered subscriptions
As a EasySOA Light user registering my subscription,
- I want to choose the service (reference) on which to register it among a list / tree / browse it
- and the type of subscription
See also Survey
EasySOA requires a maximum of flexibility so we choose to separe informations like the next schema:
More explications about the schema:
###The tables:
- User's table
It contains the information we need to store about the connected user of the EasySOA system (id, user name …) but something is crucial for keep this schema's coherence. It's the userID. We think first to generate our own userID for manage subscriptions but It was not a good idea because if the same user changes his user name or first name he will not be recognized by our subscription's system and the system will generate him a new ID and he will loose all the subscription he made before. For resolve this problem we will take the userID from the nuxeo session using the “PrincipalUser” class, so we will be sure to know who's really connected.
- Web service's table
This table contains information about web services registered in EasySOA system. We can include: the date time(when the service was registered in the system), an ID, a userID(the id of the user who registered the service in the system), a description of the service and other informations susceptible to be useful.
- Type's table
This table is used for store the different type of subscription. It provide us the possibility to add other subscription type. We can imagine that at the beginning a user can subscribe to be informed when a web service is call more than 10 time a day by EasySOA. This case is represented in EasySOA by one type in this table. So we can use another case like every a user a report is send to a user... This table give us the possibility to add incrementally new functions to the EasySOA users.
- The subscription's table:
This table is the center table. One line of this table must have many information about who's concerned b the subscription? Which kind of subscription does he need? When did he subscribe?... So this table is the principal link of all these tables.
###The associations
- User - Subscription
This association will be used whe the system will check the subscription of the connected user, so it's primordial to know who subscribed from the subscription table.
- Type - Subscription
This association will we use by the system for check which kind of subscription was subscribed by the current user.
- Subscription – Web Service
This link is use by the system to retrieve which web service is concerned by the subscription.
- User - Web Service
This link is used to retrieve who added each web service in the EasySOA system.
The authentication process provided by the monitoring part of EasySOA is a two steps process. The first step is to authenticate the user in our sstem and the second step is to authenticate the user in Nuxeo via Oauth 1 protocol. So when a user try to connect himself in our system, he should enter his login and password in a form, after that he will be redirected to nuxeo authorize url to connect himself with his Nuxeo's account. This operation is crucial to be recognized by the system. This operation will link twice(EasySOA's account and Nuxeo'account) so the current_user should have the same username in both systems otherwise he will get an error:"Use he same user name for both Systems" and will be redirect to our login page.
The next picture represent the Ui flow of the Authentication process. We can see all the steps the user should process to be recognized by both systems.
When we talk about monitoring, EasySOA can be divided in three part: Nuxeo Part, Configuration Part and the Runtime Part.
This part is the part which get the information about the behavior to follow from the Subscription Web Service.
This part build in Ruby On rails allow user to manage their subscriptions. It's the central part of the monitoring system because it interacts with the two other parts. With Nuxeo to connect a user and get information about web services and with the runtime to send a xml flow which discribes what to do to the runtime part.
Nuxeo is the web service provider and also the oauth provider. It only interact with the Configuration Part about services ans autentication.
More about it in the next schema
