Re: [Architecture] [APIM] Admin REST API to check user role existence

[Frank Leymann]

Sure, Meruja, that's what 412 is all about - but I didn't see documented
that we support conditional requests, and what the semantics in our case
will be: that's why I am asking.

Best regards,
Frank




Am Di., 26. Mai 2020 um 06:56 Uhr schrieb Meruja Selvamanikkam <
mer...@wso2.com>:

> Dear Frank,
>
> We return 412 when the preconditions fail.
> The number of request headers that can be used to apply conditions to a
> request:
>
> If-Match
> If-Modified-Since
> If-None-Match
> If-Range
> If-Unmodified-Since
>
> Since my request does not contains the stated headers, there won't be 412.  
> Thanks for pointing me to clarify and correct my understanding.
>
>  412:
>   description: |
> Precondition Failed.
> The request has not been performed because one of the 
> preconditions is not met.
>   schema:
> $ref: '#/definitions/Error'
> This should be removed from the response.
>
> Thanks & Regards,
> *S.Meruja* |Software Engineer | WSO2 Inc.
> (m) +94779650506 | Email: mer...@wso2.com
> Linkedin:   https://www.linkedin.com/in/meruja
> <https://www.google.com/url?q=https://www.linkedin.com/in/meruja>
> Medium: https://medium.com/@meruja
> <http://wso2.com/signature>
>
>
> On Mon, May 25, 2020 at 10:23 PM Frank Leymann  wrote:
>
>> Dear Meruja,
>>
>> when would we return a 412?
>>
>> Best regards,
>> Frank
>>
>>
>>
>>
>> Am Fr., 22. Mai 2020 um 15:42 Uhr schrieb Meruja Selvamanikkam <
>> mer...@wso2.com>:
>>
>>> Hi all,
>>>
>>> We are in the process of implementing an API to get the scope list of a
>>> particular user.
>>> Following will be the notations of the new API:
>>> *GET  api/am/admin/v1/settings/scopes?userId=*
>>>
>>> Please find the swagger definition below:
>>>
>>>  /settings/scopes:
>>> #-
>>> # Retrieve scope settings
>>> #-
>>> get:
>>>   security:
>>> - OAuth2Security:
>>> - apim:admin_settings
>>>   x-wso2-curl: "curl -k -H \"Authorization: Bearer
>>> ae4eae22-3f65-387b-a171-d37eaa366fa8\" -X POST \"
>>> https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48
>>> <https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-4877-a323-57f6ce2ed79b%5C>
>>> ""
>>>   x-wso2-request: |
>>> GET
>>> https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48
>>> <https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-4877-a323-57f6ce2ed79b>
>>> Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
>>>   x-wso2-response: "HTTP/1.1 200 OK"
>>>   summary: Retrieve scopes for a particular user
>>>   description: |
>>> This operation will return the scope list of particular user
>>> In order to get it, we need to pass the userId as a query
>>> parameter
>>>   parameters:
>>> - name: userId
>>>   in: query
>>>   type: string
>>>   required: true
>>>   tags:
>>> - Settings
>>>   responses:
>>> 200:
>>>   description: |
>>> OK.
>>> Scopes for a particular user retrieved successfully.
>>> 400:
>>>   description: |
>>> Bad Request.
>>> Invalid request or validation error
>>>   schema:
>>> $ref: '#/definitions/Error'
>>> 404:
>>>   description: |
>>> Not Found.
>>> Requested user does not exist.
>>>   schema:
>>> $ref: '#/definitions/Error'
>>> 412:
>>>   description: |
>>> Precondition Failed.
>>> The request has not been performed because one of the
>>> preconditions is not met.
>>>   schema:
>>> $ref: '#/definitions/Error'
>>>
>>> Highly appreciate your thoughts and suggestions.
>>>
>>> Thanks & Regards,
>>> *S.Meruja* |Software Engineer | WSO2 Inc.
>>> (m) +94779650506 | Email: mer...@wso2.com
>>> Linkedin:   https://www.linkedin.com

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Frank Leymann]

Dear Meruja,

when would we return a 412?

Best regards,
Frank




Am Fr., 22. Mai 2020 um 15:42 Uhr schrieb Meruja Selvamanikkam <
mer...@wso2.com>:

> Hi all,
>
> We are in the process of implementing an API to get the scope list of a
> particular user.
> Following will be the notations of the new API:
> *GET  api/am/admin/v1/settings/scopes?userId=*
>
> Please find the swagger definition below:
>
>  /settings/scopes:
> #-
> # Retrieve scope settings
> #-
> get:
>   security:
> - OAuth2Security:
> - apim:admin_settings
>   x-wso2-curl: "curl -k -H \"Authorization: Bearer
> ae4eae22-3f65-387b-a171-d37eaa366fa8\" -X POST \"
> https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48
> 
> ""
>   x-wso2-request: |
> GET
> https://localhost:9443/api/am/admin/v1/settings/scopes?userId=890a4f4d-09eb-48
> 
> Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
>   x-wso2-response: "HTTP/1.1 200 OK"
>   summary: Retrieve scopes for a particular user
>   description: |
> This operation will return the scope list of particular user
> In order to get it, we need to pass the userId as a query parameter
>   parameters:
> - name: userId
>   in: query
>   type: string
>   required: true
>   tags:
> - Settings
>   responses:
> 200:
>   description: |
> OK.
> Scopes for a particular user retrieved successfully.
> 400:
>   description: |
> Bad Request.
> Invalid request or validation error
>   schema:
> $ref: '#/definitions/Error'
> 404:
>   description: |
> Not Found.
> Requested user does not exist.
>   schema:
> $ref: '#/definitions/Error'
> 412:
>   description: |
> Precondition Failed.
> The request has not been performed because one of the
> preconditions is not met.
>   schema:
> $ref: '#/definitions/Error'
>
> Highly appreciate your thoughts and suggestions.
>
> Thanks & Regards,
> *S.Meruja* |Software Engineer | WSO2 Inc.
> (m) +94779650506 | Email: mer...@wso2.com
> Linkedin:   https://www.linkedin.com/in/meruja
> 
> Medium: https://medium.com/@meruja
> 
>
>
> On Mon, May 11, 2020 at 9:37 PM Meruja Selvamanikkam 
> wrote:
>
>>  Hi all,
>>
>> Thank you for your suggestions
>>
>> I have a few concerns regarding validating the subscriber permissions of
>>> the input application owner using the default subscriber role(Internal
>>> subscriber). Since the REST API and portal access are based on the
>>> scope-role mapping which is maintained in tenant-conf.json, a subscriber
>>> user does not necessarily have the *Internal/subscriber* role. If a new
>>> role mapping to app management, subscriptions related scopes has been
>>> introduced with custom roles, then the validation should be done against
>>> those roles as well.
>>>
>>
>> I agree with you. For previous versions, we have a default subscriber
>> role in the configuration file and checked role-based permission for a
>> particular feature. From 3.1.0 onwards, we have a scope-role mapping.
>> In this case, we cannot validate the user role.
>>
>> Hence, we should be validating whether any of the roles assigned to that
>>> particular user has bare scope based minimum access to API subscriptions,
>>> app management resources. So the validation should be based on the
>>> role-scope mapping.
>>>
>>> ie: If the user's role 'roleA' has role-scope mappings for 'apim:subscribe'
>>> and 'apim:app_manage' scopes, then that particular user is eligible as
>>> a new owner of a given application.
>>> WDYT?
>>>
>> Yes, we need to validate against the scope.
>>
>>
>> Thanks & Regards,
>> *S.Meruja* |Software Engineer | WSO2 Inc.
>> (m) +94779650506 | Email: mer...@wso2.com
>> Linkedin:   https://www.linkedin.com/in/meruja
>> 
>> Medium: https://medium.com/@meruja
>> 
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
___
Architecture mailing list
Architecture@wso2.org

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Frank Leymann]

Dear Malintha,

my responses below

Best regards,
Frank




Am Mi., 6. Mai 2020 um 08:40 Uhr schrieb Malintha Amarasinghe <
malint...@wso2.com>:

> Dear Frank,
>
> Thank you for looking into this.
>

It is my pleasure :-)


>
> On Tue, May 5, 2020 at 1:48 PM Frank Leymann  wrote:
>
>> Dear Meruja,
>>
>> the URI of the second API (i.e.  /me/roles/{roleName}) is really
>> debatable: the intent of the */me* part of the URI seems to be to
>> identify the logged-in user, and to me, such a user is a resource.
>>
> I may be a little bit deviating from the original question.
>

Let me add to the above:  a URI, e.g. /me, always points to a single, a
unique resource. Thus, /me would point to exactly one person - we can't use
/me as an abstraction for all users implicitly picking the one who is
currently in the context (i.e. logged-in), that would counter the concept
of a URI as an identifier.

If we use a resource like /me, if we consider we do GET for that, we'll get
> the "me" resource which will return the logged in user details: eg:
> {
>"uid": "malintha"
>"fullName": "Malintha Amarasinghe"
>"mobile: "..",
>"roles" : [
>{
>   "name" : "Internal/subscriber",
>   "type": "Internal"
>}, {
>{
>   "name" : "app-manager",
>   "type": "Primary"
>}
>],
>...
> }
>
> In the above resource, I was under the impression that we consider "roles"
> as a sub-resource of /me. For example: if we did a GET for /me/roles we
> could return:
> {
> "count" : 2,
> "list": [
>{
>   "name" : "Internal/subscriber",
>   "type": "Internal"
>}, {
>{
>   "name" : "app-manager",
>   "type": "Primary"
>}
>]
> }
>
> I think /me/roles/{roleName} may not make sense here because we could just
> do /roles/{roleName} to get the role details.
>

Just using  /roles/{roleName} would return the details of the specified
role itself, without any reference to the logged-in user, i.e. the context
has to contain the user itself.


> Instead, I was under impression that we can use  /me/roles?{roleName} to
> check if a particular role is available to the logged-in user.
>

...and, yes, you are absolutely right, "role" is a query parameter, i.e.
.../roles?{roleName} is the correct syntax (I left out the /me part by will
;-)).


>
> Would the above approaches be wrong? If so, if I need to get the roles of
> a particular user, should I only use an approach like /roles?{UserID}?
>

/roles?{UserId} will work too, but it would return all roles of the
specified user.

>
>
> I.e I assume that a user is represented in APIM as a resource (but I
>> didn't check the current API), or has a unique UserID - correct?
>>
>
> Yes, that is correct. But here, if we only need to represent the logged-in
> user, would it be ok if we have a resource /me (which represents a single
> resource for /users/)?. In that case, that doesn't take
> username as an input and we don't need to validate whether the user has
> provided his username instead of providing a different one.
>

As argued above, a URI is not abstract, i.e. it can not point to different
resources (users in this case).  Even worse, if multiple users use the API
at the same time, the "/me" URI would identify (!) different users at the
same time: which shows that it's no longer an identifier.


>
>
>> Thus, the URI of the API should be something like
>> .../users/{UserID}?{roleName}  or  /roles/{roleName}?{UserID}.
>>
>
> In this case, are we adding a filter for /users/{UserID} resource?
>

Yes, the query parameter ?{UserID} would act as a filter


> Which means if we did a GET /users/malintha?roleName=subscriber, should we
> give a 404 or 204?
>

Yes, we'll return a 404 if  GET .../users/{UserID}?{roleName}  did not find
the roleName specified for the UserID.  But should more specific, returning

   - a 403 Forbidden if the user is not allowed to issue this request (e.g.
   because User_1 wants to check the role of User_2 - but I don't know whether
   this is in sope of our application semantics)
   - a 401 Unauthorized if the user has to authenticate him/herself, or
   when authentication failed. But I am not sure whether this may happen
   because of the "security" header, i.e. whether this has been verified
   before.


> Can you kindly elaborate on this?
> I am sorry about asking

Re: [Architecture] [APIM] Admin REST API to check user role existence

[Frank Leymann]

Dear Meruja,

the URI of the second API (i.e.  /me/roles/{roleName}) is really debatable:
the intent of the */me* part of the URI seems to be to identify the
logged-in user, and to me, such a user is a resource. I.e I assume that a
user is represented in APIM as a resource (but I didn't check the current
API), or has a unique UserID - correct?

Thus, the URI of the API should be something like
.../users/{UserID}?{roleName}  or  /roles/{roleName}?{UserID}.

Best regards,
Frank




Am Di., 5. Mai 2020 um 06:17 Uhr schrieb Meruja Selvamanikkam <
mer...@wso2.com>:

> Hi All,
>
> We are planning to add a REST API endpoint to APIM 3.2.0 Admin Rest APIs
> and the intention is to check the existence of a particular role name (
> Internal/subscriber) when transferring ownership of an application to a
> user. We have similar API in the publisher to check the availability of
> the role[1].
> We have to decide the OAuth2 scope which functionalities are used by Admin
> .
>
> The swagger definition for the new endpoint would be as follows:
>
> ##
> # The Role Name Existence
> ##
>   /roles/{roleName}:
> #-
> # The role name existence check resource
> #-
> head:
>   security:
> - OAuth2Security:
> - apim:
>   summary:
> Check given role name already exists
>   description:
> Using this operation, to check whether given role already exists
>   parameters:
> - $ref : '#/parameters/roleName'
>   responses:
> 200:
>   description:
> OK.
> Requested role name is returned.
> 404:
>   description:
> Not Found.
> Requested role name does not exist.
>
> ##
> # The Role Name Existence for the logged-in user
> ##
>   /me/roles/{roleName}:
> #-
> # Validate role against a user
> #-
> head:
>   security:
> - OAuth2Security:
> - apim:
>   summary:
> Validate whether the logged-in user has the given role
>   description:
> Using this operation, logged-in user can check whether he has given 
> role.
>   parameters:
> - $ref : '#/parameters/roleName'
>   responses:
> 200:
>   description:
> OK.
> Logged-in user has the role.
> 404:
>   description:
> Not Found.
> Logged-in user does not have the role.
>
> Appreciate any feedback on this and correct me if I am wrong.
>
> [1] - [APIM-3.0] Publisher rest API to check a role name existence
>
> Thanks & Regards,
> *S.Meruja* |Software Engineer | WSO2 Inc.
> (m) +94779650506 | Email: mer...@wso2.com
> Linkedin:   https://www.linkedin.com/in/meruja
> 
> Medium: https://medium.com/@meruja
> 
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] REST API for Application Template Management

[Frank Leymann]

Dear Pamoda,


   - Why do you need both, limitWithoutDefaultQueryParam as well
   as limitQueryParam?  Won't limitQueryParam do what we need?  (same question
   for other parameters like offset etc)
   - Parameters like sortByQueryParam is not supported in the current
   version (according to the Swagger file). What response do we return if such
   a parameter is passed in the query string: "400 Bad Request" or "501 Not
   Implemented"?  Wouldn't it be more convenient for an API user (or reviewer)
   to not document parameters that are not (yet) supported?
   - POST /applications has a JSON document as payload.
   In contrast, POST /applications/import supports an XML file, which is
   passed as a binary file in the payload
  - Is this a Base64 encoded binara?  If YES, we should say so.
  Otherwise: I don't understand :-)
  - If XML is still important for us, why doesn't POST /applications
  not support XML as payload too?

So, the underlying observation is that it seems to be strange (to me) to
invent an *import* API for creating new application from XML documents,
while a new application is created based on a JSON document via a different
API. The semantics of the APIs is the same, only the representation of the
payload is different...  Can't we combine the two APIs supporting different
types of payloads?


   - PUT /applications/import is used to *substitute* an application that
   has been provided by means of an XML document before. But an application
   that has been created based on a JSON document can be (partially) updated
   via PATCH /applications/{applicationId}. Again, the representation of the
   resource determines how it can be manipulated. This seems to be strange (to
   me) and not consistent with the REST paradigm.
   - Is there any documentation about the semantics of the PATCH model (ie.
   what is the language I use to specify what is updated; what if some updates
   can be applied, some others not [i.e. is there any notion of "atomicity" of
   updates])?

Thanks!

Best regards,
Frank




Am Mi., 1. Apr. 2020 um 16:25 Uhr schrieb Pamoda Wimalasiri :

> Hi all,
>
> We have introduced a set of new REST APIs for managing the application
> templates. These new application template management APIs are added as an
> improvement to the Application Management API. With these APIs, the
> frequently used application configurations can be saved as a template so
> that they can be reused when creating a new application.
>
> Following new endpoints are added for Application Template Management.
>
>- *GET  */applications/templates
>   - Retrieve all the application templates created for a tenant.
>- *POST*  /applications/templates
>   - Create a new application template
>- *GET */applications/templates/{template-id}
>   - Get the application template information when given the template
>   id
>- *PUT*  /applications/templates/{template-id}
>   - Update an application template when given with the template id
>- *DELETE*/applications/templates/{template-id}
>   - Delete the application template with the given template id
>
> The swagger definition of these API can be found here
> 
> .[1]
>
> Application Template Management service is implemented using the Template
> Manager OSGi services. The implementation details related to the
> Application Template Management API can be found here
> 
> [2].
>
> [1]
> https://app.swaggerhub.com/apis/pamoda/wso-2_identity_server_application_management_rest_api/v1#/Application%20Templates
> [2]
> https://github.com/wso2/identity-api-server/commit/d47979934d852cd47d44f8ece1129da1b8e0f328
>
> Thanks,
> Pamoda
> --
> *Pamoda Wimalasiri | *Senior Software Engineer | WSO2 Inc.
> (m) +94713705814 | (w) +94112145345 | (e) pam...@wso2.com
>
> 
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM][IS 5.10.0] REST APIs For Identity Provider Management

[Frank Leymann]

Hi Sathya,

you support PATCH for the
resource /identity-providers/{identity-provider-id}  but for none of the
other resources: any reason for this?  Don't get me wrong, the less we
support PATCH the better ;-)

Best regards,
Frank




Am Sa., 2. Nov. 2019 um 06:24 Uhr schrieb Sathya Bandara :

> Hi all,
>
> WSO2 Identity Server currently supports IDP related operations using SOAP
> APIs. I'm currently working on introducing a REST API layer for IDP
> management in 5.10.0. Please find the API definition in [1].
>
> The internal implementation for the above APIs will use the
> IdentityProviderManager[2] OSGi service. As per the team discussions, we
> have introduced the following framework level changes to support RESTful
> operations for the IDPs.
>
>- Introduce UUID, Image URL to identity provider model.
>- Change DDL of IDP table to store UUID and Image URL.
>- Introduce Regex, Options and SubProperties to Property model.
>- Introduce OSGi methods and DAO layer methods to do IDP operations
>with resource ID (UUID).
>- Listeners for IDP operations based on resource ID.
>
> [1] https://app.swaggerhub.com/apis/emswbandara/IAM_IDP/0.1.0
>
> Highly appreciate your valuable suggestions.
>
> Thanks,
> Sathya
> --
> Sathya Bandara
> Senior Software Engineer
> Blog: https://medium.com/@technospace
> WSO2 Inc. http://wso2.com
> Mobile: (+94) 715 360 421
>
> <+94%2071%20411%205032>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM-3.0] Store REST API to get all active tenants

[Frank Leymann]

Hi Dushan,  I can't find the complete Swagger file. Would you please
provide a link?  Thanks!

Best regards,
Frank




Am Mo., 12. Aug. 2019 um 16:22 Uhr schrieb Dushan Silva :

> Hi all,
> As per above suggestions i have updated the swagger. I have added state as
> a query param. @Malintha Amarasinghe  I have set the
> state param required as false, so by default if no parameter is passed we
> can return the active tenants and if someone requires to do it he can pass
> the parameter? WDYT ?
>
> Additionally I have added *pagination *for Tenant List resource (which is
> an existing definition).
>
> *##*
>>
>> *# The tenant resource APIs*
>>
>> *##*
>>
>> *'/tenants':*
>>
>>   *#*
>>
>> *  # Retrieve all active tenants*
>>
>> *  #*
>>
>>   *get:*
>>
>> *security:*
>>
>>   - *OAuth2Security:*
>>
>>   - []
>>
>> *x-wso2-curl: *""
>>
>> *x-wso2-request: *|
>>
>>   GET https://localhost:9443/api/am/store/v1.0/tenants/active-tenats
>>
>>   Authorization: Bearer ae4eae22-3f65-387b-a171-d37eaa366fa8
>>
>> *x-wso2-response: *""
>>
>> *summary: *|
>>
>>   Get all active tenants names
>>
>> *description: *|
>>
>>   This operation is to retrieve all active tenants
>>
>> *parameters:*
>>
>>   - *name: *state
>>
>> *description: *|
>>
>>   The state represents the current state of the tenant
>>
>>
>>   Supported states are [ active, inactive]
>>
>>
>> *in: *query
>>
>> *type: *string
>>
>> *required: *false
>>
>> *enum:*
>>
>>   - active
>>
>>   - inactive
>>
>> *tags:*
>>
>>   - active tenants
>>
>> *responses:*
>>
>> *  200:*
>>
>> *description: *|
>>
>>   OK.
>>
>>   Tenant names returned.
>>
>> *headers:*
>>
>> *  Content-Type:*
>>
>> *description: *|
>>
>>   The content type of the body.
>>
>> *type: *string
>>
>> *schema:*
>>
>> *  type: *'#/definitions/TenantList'
>>
>>   *404:*
>>
>> *description: *|
>>
>>   Not Found.
>>
>>   Requested application does not exist.
>>
>> *schema:*
>>
>> *  $ref: *'#/definitions/Error'
>>
>>   *406:*
>>
>> *description: *|
>>
>>   Not Acceptable.
>>
>>   The requested media type is not supported
>>
>> *schema:*
>>
>> *  $ref: *'#/definitions/Error'
>>
>
>
>> *#-*
>> *# The Tenant resource*
>> *#-*
>> *Tenant :**title: *Tenant
>>
>> *properties:*
>> *  description:**type: *string
>> *domain: *tenant domain
>> *example: *"wso2.com"
>>
>> *status:**type: *string
>> *description: *current status of the tenant active/inactive
>> *example: *"active"
>>
>>
>> *#-*
>> *# The Tenant List resource*
>> *#-*
>> *TenantList :**title: *Tenant list
>>
>> *properties:*
>> *  count:**type: *integer
>> *description: *|
>>   Number of tenants returned.
>> *example: *1
>>
>> *list:**type: *array
>>
>> *items:**  $ref: *'#/definitions/Tenant'
>>
>> *pagination:**$ref: *'#/definitions/Pagination'
>
>
>
>  Thanks
>
> On Mon, Aug 12, 2019 at 6:59 PM Malintha Amarasinghe 
> wrote:
>
>> As Sanjeewa pointed out, I also think we should support pagination
>> related parameters; eg: "count", "limit", "offset", "next", "previous",
>> "total"; where the total is the number of total "active" tenants in the
>> system.
>>
>>
>> On Mon, Aug 12, 2019 at 6:54 PM Malintha Amarasinghe 
>> wrote:
>>
>>>
>>>
>>> On Mon, Aug 12, 2019 at 6:38 PM Malintha Amarasinghe 
>>> wrote:
>>>


 On Mon, Aug 12, 2019 at 6:17 PM Nuwan Dias  wrote:

> Ideally we would need to support getting all tenants. But for now I
> think its ok to support the active state only. Using the query param to
> pass in the state gives us the flexibility to support other (inactive)
> states in the future.
>
> I also think at this moment we do not need to support retrieving
 inactive tenants. We can think of state = "active" as default and simply
 omit the active param (i.e: I think we do not even need to support state
 param unless we support inactive tenants because the only state we support
 is "active"). Then GET /tenants will give all the active tenants.


> Regarding the other tenant specific APIs, I don't see a need to
> support them right now unless we have a business requirement to do so.
>
 +1


> On 

Re: [Architecture] [APIM][Monetization] Monetization Model For WSO2 API Manager

[Frank Leymann]

Would a discount pricing model make sense? E.g. after x requests you get a
discount of y%?

And what about adding a QoS aspect: if x requests failed within y duration,
you get a discount of z% for D duration?

Best regards,
Frank




Am Mi., 15. Mai 2019 um 08:21 Uhr schrieb Chamin Dias :

> Hi all,
>
> Based on the recent discussions we had, we will be going to implement the
> following features from the products POV. Intention of this email is to
> give an update on some of the important points.
>
> *A) Model : Charge a fixed price for a given time*
>
> *1. What we need in the product : *
> Ability to define the fixed price, frequency and duration for a tier
> Eg : $25 (price) per 1 (frequency) month (duration)
>
> Note : This can be extended as "one time payment" if needed. That means,
> if we specify something like, "$25 (price) per 100 (frequency) years
> (duration)" - it will charge $25 per 100 years. Practically a subscription
> won't last that much of time so this can be considered as one time payment
> for a tier.
>
> *2. What we need in the billing engine : *
> Ability to define pricing plans with parameters (price, frequency and
> duration)
>
> *3. Benefit / User experience : *
> Admins will define tiers with using the dashboard.
> API providers can attach a tier with fixed price (for a given time).
> Subscribers will pay a fixed amount (per week, month - specified in the
> tier).
>
>
> *B) Model : Pay as you use*
>
> *1. What we need in the product : *
> i) Ability to define the price per request
> ii). Aggregate usage daily (via a scheduled / manual task)
>
> *2. What we need in the billing engine :*
> Ability to define pricing plans with 'pay as you use' mode and aggregate
> or set usage and charge subscribers for the usage.
>
> *3. Benefit / User experience : *
> API providers can attach a tier with 'pay as you use' type. Then, usage
> will be aggregated daily / or set for each subscriber. At the end of each
> month, subscriber will be charged for the aggregated usage.
> API provider will be able to see the revenue from each user of their API.
>
> Thanks.
>
> On Mon, Apr 8, 2019 at 3:10 PM Chamin Dias  wrote:
>
>> Hi Cyril,
>>
>> As for the initial implementation, we plan to provide this integration
>> with stripe but eventually we hope to provide necessary interfaces to
>> extend. For now, we focus on delivering a workable solution (APIM + Stripe)
>> for a normal usage based billing scenario.
>>
>> Thanks.
>>
>> On Fri, Apr 5, 2019 at 3:53 PM Silmy Hasan  wrote:
>>
>>> Hi Rukshan,
>>>
>>> Please my answer to your concern below
>>>
>>> *I think we can reuse the existing data. Even though we define recording
>>> policy, all the possible data is stored in the analytics DBs regardless of
>>> the recording policy. So we should be able to correlate this recording
>>> policy with stat data and filter out required data from the Billing engine.*
>>>
>>> As discussed offline , I dont think that we can use only the existing
>>> data without modifying or creating a new Aggregation. If we assume we
>>> define the recording policy based on the response code , we do not store
>>> the response code anywhere in Request count Aggregation. So providing the
>>> successful count based on the response code is impossible without altering
>>> or creating a new aggregation.
>>>
>>> but we can decide whether we are going to add this to an existing
>>> aggregation or create a new one.  If we try to  add the above policy to the
>>> existing aggregations we will have to modify the queries that read the data
>>> from the aggregation to populate graphs.  Also we will always have to
>>> modify the queries  , whenever there is a change in the policy (based on
>>> some user requirement). Also it will compel to store the above data
>>> irrelevant of whether the monetization is enabled or not , hence i believe
>>> creating a separate aggregation(create tables internally) can ease lot of
>>> things in future
>>>
>>> Thanks,
>>> Silmy.
>>>
>>>
>>>
>>> On Fri, Apr 5, 2019 at 2:51 PM Rukshan Premathunga 
>>> wrote:
>>>


 On Fri, Apr 5, 2019 at 2:46 PM Silmy Hasan  wrote:

> Hi Bhathiya,
>
> Please find my answers for your concerns,
>
> *I think we can do this check at the time they enable monetization for
> an API*.
> +1
>
> *Why do we need separate tables here? Can't we use the existing stats
> data here?*
> We need a separate table here because we check whether the response
> for a particular request is delivered successfully based on some set
> policy, before taking it as a count to bill. But in the current stats 
> there
> is no such a check when we aggregate the request count and all of them are
> simply added to the count through API Request count Aggregation. So if we
> try to add this also to the same aggregation as a new column then it will
> create a separation among the request count aggregated and will have to
> modify the 

Re: [Architecture] HoneyPot APIs for API Manager - New Feature of APIM product

[Frank Leymann]

OK - an attacker is characterized by being an anonymus.  What if somebody
registers regularly, then turns into an attacker?  This happens quite
often, e.g. if an employee is fired or feels treated badly, and he wants to
damage his employer. Then, the attacker is not anonymus - we might be able
to use some machine learning algorithms to finde that out - e.g.
classification.

Best regards,
Frank




Am Mo., 13. Mai 2019 um 08:44 Uhr schrieb Nadee Poornima :

> Hi Frank,
>
> Sure, you get information *about* the attacker from such headers. But how
>> do we *detect* (!) an attack - also from headers?  Or do you have a
>> catalogue of IP addresses that are allowed to use the API (then, detection
>> would be simple)...
>>
>>
> In here we have deployed an API in GW but that doesn't see in Publisher or
> Store UI. Then once arrived a hacker, they could able to see this API also
> (as a service) and they will try to invoke that API also. Then that
> invocation will detect by us an anonymous invocation and provide an alert
> to system admins. That's how to detect anonymous users arrived in APIM.
>
> Thank you & regards,
> Nadee
>
> On Sat, May 11, 2019 at 5:35 PM Frank Leymann  wrote:
>
>> Sure, you get information *about* the attacker from such headers. But
>> how do we *detect* (!) an attack - also from headers?  Or do you have a
>> catalogue of IP addresses that are allowed to use the API (then, detection
>> would be simple)...
>>
>>
>> Best regards,
>> Frank
>>
>>
>>
>>
>> Am Fr., 10. Mai 2019 um 07:37 Uhr schrieb Nadee Poornima > >:
>>
>>> Hi Frank,
>>>
>>> In deed: very nice idea, valuable feature!  Which attributes should be
>>>> used to detect an attack?
>>>>
>>>
>>> Thank you very much for the feedback.
>>>
>>> In here, if anyone invokes this Honeypot API, it will detect as an
>>> anonymous attack. We are getting the headers (IP, if have access tokens) in
>>> order to identify the attacker. Currently, we are implementing to detect
>>> and alert this to the system admin. We hope to implement the blocking part
>>> also in future time.
>>>
>>> Thank you & regards,
>>> Nadee
>>>
>>>
>>> On Thu, May 9, 2019 at 10:47 PM Frank Leymann  wrote:
>>>
>>>> In deed: very nice idea, valuable feature!  Which attributes should be
>>>> used to detect an attack?
>>>>
>>>> Best regards,
>>>> Frank
>>>>
>>>>
>>>>
>>>>
>>>> Am Do., 9. Mai 2019 um 11:09 Uhr schrieb Sanjeewa Malalgoda <
>>>> sanje...@wso2.com>:
>>>>
>>>>> Tracing and logging problematic API calls definitely add value to
>>>>> product. This is kind of alerting mechanism. But we should not stop from
>>>>> there. We can go one step ahead and block calls with similar attributes. 
>>>>> We
>>>>> can block API calls temporary based on the API context, application id,
>>>>> user and IP address. Then users who accessed honeypot APIs will not be 
>>>>> able
>>>>> to use other APIs.
>>>>>
>>>>> Blocking condition related updates we can put into topic from traffic
>>>>> manager. So we can use same mechanism here as well.
>>>>>
>>>>> Thanks,
>>>>> sanjeewa.
>>>>>
>>>>> On Thu, May 9, 2019 at 12:18 PM Nadee Poornima 
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> If published APIs in the store, they could invoke by the Hackers by
>>>>>> scanning the open ports of a system. Therefore in order to prevent such
>>>>>> attacks, the user needs to use different tools or mechanism. The
>>>>>> Honeypots[1] is such a system, user can use in their environment to 
>>>>>> detect
>>>>>> such anonymous attacks.
>>>>>>
>>>>>> Instead of using such out of box tools or mechanism, we are trying to
>>>>>> implement a mechanism to detect such anonymous invocation of APIs within
>>>>>> the APIM product.
>>>>>>
>>>>>> *The suggested Approach:*
>>>>>> There is a deployed API in the gateway(not showing the API in
>>>>>> publisher or store), once invoked that API by an anonymous user, it will
>>>>>> identify it as anonymous invocation

Re: [Architecture] HoneyPot APIs for API Manager - New Feature of APIM product

[Frank Leymann]

Sure, you get information *about* the attacker from such headers. But how
do we *detect* (!) an attack - also from headers?  Or do you have a
catalogue of IP addresses that are allowed to use the API (then, detection
would be simple)...


Best regards,
Frank




Am Fr., 10. Mai 2019 um 07:37 Uhr schrieb Nadee Poornima :

> Hi Frank,
>
> In deed: very nice idea, valuable feature!  Which attributes should be
>> used to detect an attack?
>>
>
> Thank you very much for the feedback.
>
> In here, if anyone invokes this Honeypot API, it will detect as an
> anonymous attack. We are getting the headers (IP, if have access tokens) in
> order to identify the attacker. Currently, we are implementing to detect
> and alert this to the system admin. We hope to implement the blocking part
> also in future time.
>
> Thank you & regards,
> Nadee
>
>
> On Thu, May 9, 2019 at 10:47 PM Frank Leymann  wrote:
>
>> In deed: very nice idea, valuable feature!  Which attributes should be
>> used to detect an attack?
>>
>> Best regards,
>> Frank
>>
>>
>>
>>
>> Am Do., 9. Mai 2019 um 11:09 Uhr schrieb Sanjeewa Malalgoda <
>> sanje...@wso2.com>:
>>
>>> Tracing and logging problematic API calls definitely add value to
>>> product. This is kind of alerting mechanism. But we should not stop from
>>> there. We can go one step ahead and block calls with similar attributes. We
>>> can block API calls temporary based on the API context, application id,
>>> user and IP address. Then users who accessed honeypot APIs will not be able
>>> to use other APIs.
>>>
>>> Blocking condition related updates we can put into topic from traffic
>>> manager. So we can use same mechanism here as well.
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Thu, May 9, 2019 at 12:18 PM Nadee Poornima  wrote:
>>>
>>>> Hi All,
>>>>
>>>> If published APIs in the store, they could invoke by the Hackers by
>>>> scanning the open ports of a system. Therefore in order to prevent such
>>>> attacks, the user needs to use different tools or mechanism. The
>>>> Honeypots[1] is such a system, user can use in their environment to detect
>>>> such anonymous attacks.
>>>>
>>>> Instead of using such out of box tools or mechanism, we are trying to
>>>> implement a mechanism to detect such anonymous invocation of APIs within
>>>> the APIM product.
>>>>
>>>> *The suggested Approach:*
>>>> There is a deployed API in the gateway(not showing the API in publisher
>>>> or store), once invoked that API by an anonymous user, it will identify it
>>>> as anonymous invocation and trigger an Alert (send an email) to admin user
>>>> of the system. Request Data will publish to the Trafic Manager and they
>>>> will persist to DB as well.
>>>> Those invocations will appear as a list in the Admin portal and admin
>>>> user could remove or persist them through the UI after reviewing them.
>>>> Further, we will implement an Admin UI part to configure that Alert(like
>>>> configuring email).
>>>>
>>>> [image: HoneyPotAPIAlertApproach.png]
>>>>
>>>> [1]. https://blog.rapid7.com/2016/12/06/introduction-to-honeypots/
>>>>
>>>> Thank you and regards,
>>>> *Nadee Poornima*
>>>> Software Engineer - Support Team | WSO2
>>>>
>>>> Email : nad...@wso2.com
>>>> Mobile : +94713441341
>>>> MyBlog: https://medium.com/nadees-tech-stories
>>>>
>>>> <https://wso2.com/signature>
>>>>
>>>
>>>
>>> --
>>> *Sanjeewa Malalgoda*
>>> Software Architect | Associate Director, Engineering - WSO2 Inc.
>>> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
>>> <http://sanjeewamalalgoda.blogspot.com>, Medium
>>> <https://medium.com/@sanjeewa190>
>>>
>>> GET INTEGRATION AGILE <https://wso2.com/signature>
>>> Integration Agility for Digitally Driven Business
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>
> --
> *Nadee Poornima*
> Software Engineer - Support Team | WSO2
>
> Email : nad...@wso2.com
> Mobile : +94713441341
> MyBlog: https://medium.com/nadees-tech-stories
>
> <https://wso2.com/signature>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] HoneyPot APIs for API Manager - New Feature of APIM product

[Frank Leymann]

In deed: very nice idea, valuable feature!  Which attributes should be used
to detect an attack?

Best regards,
Frank




Am Do., 9. Mai 2019 um 11:09 Uhr schrieb Sanjeewa Malalgoda <
sanje...@wso2.com>:

> Tracing and logging problematic API calls definitely add value to product.
> This is kind of alerting mechanism. But we should not stop from there. We
> can go one step ahead and block calls with similar attributes. We can block
> API calls temporary based on the API context, application id, user and IP
> address. Then users who accessed honeypot APIs will not be able to use
> other APIs.
>
> Blocking condition related updates we can put into topic from traffic
> manager. So we can use same mechanism here as well.
>
> Thanks,
> sanjeewa.
>
> On Thu, May 9, 2019 at 12:18 PM Nadee Poornima  wrote:
>
>> Hi All,
>>
>> If published APIs in the store, they could invoke by the Hackers by
>> scanning the open ports of a system. Therefore in order to prevent such
>> attacks, the user needs to use different tools or mechanism. The
>> Honeypots[1] is such a system, user can use in their environment to detect
>> such anonymous attacks.
>>
>> Instead of using such out of box tools or mechanism, we are trying to
>> implement a mechanism to detect such anonymous invocation of APIs within
>> the APIM product.
>>
>> *The suggested Approach:*
>> There is a deployed API in the gateway(not showing the API in publisher
>> or store), once invoked that API by an anonymous user, it will identify it
>> as anonymous invocation and trigger an Alert (send an email) to admin user
>> of the system. Request Data will publish to the Trafic Manager and they
>> will persist to DB as well.
>> Those invocations will appear as a list in the Admin portal and admin
>> user could remove or persist them through the UI after reviewing them.
>> Further, we will implement an Admin UI part to configure that Alert(like
>> configuring email).
>>
>> [image: HoneyPotAPIAlertApproach.png]
>>
>> [1]. https://blog.rapid7.com/2016/12/06/introduction-to-honeypots/
>>
>> Thank you and regards,
>> *Nadee Poornima*
>> Software Engineer - Support Team | WSO2
>>
>> Email : nad...@wso2.com
>> Mobile : +94713441341
>> MyBlog: https://medium.com/nadees-tech-stories
>>
>> 
>>
>
>
> --
> *Sanjeewa Malalgoda*
> Software Architect | Associate Director, Engineering - WSO2 Inc.
> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
> , Medium
> 
>
> GET INTEGRATION AGILE 
> Integration Agility for Digitally Driven Business
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Introduce API Product Concept

[Frank Leymann]

+1 ,   this is a useful feature (although we may invent another name for a
group of APIs, because a single API today is subject to monetization, i.e.
a "product").

Generalizing Chathura's question:  do non-functional properties defined at
the collection level (throttlling, security, pricing,...) override the
corresponding properties at the "member-API" level?  Can such properties
defined both, at the level of the whole collection as well as at the level
of individual members?

Best regards,
Frank




Am Di., 9. Apr. 2019 um 10:50 Uhr schrieb Chathura Ekanayake <
chath...@wso2.com>:

> Hi Sachini,
>
> Grouping APIs as mentioned is an useful feature. Few comments inline..
>
> On Tue, Apr 2, 2019 at 2:25 PM Sachini De Silva  wrote:
>
>> Hi all,
>>
>> We are planning to introduce API product concept to API Manager.
>>
>> An API product is basically a bundle of APIs/ API resources that is made
>> available to users to subscribe and consume. API product creator can attach
>> a throttling policy and other metadata to the API product. The collection
>> of APIs/resources in the product are such that they address a specific
>> business use case.
>>
>> For example, I have 3 APIs as below. And I need to bundle API A and B
>> together, attach a higher throttling limit and make it available for paid
>> customers. And bundle API B, C together with a lower throttling limit and
>> make it available for free use.
>>
>
> How does API product level throttling work with API/resource level
> throttling? Does it override API/resource level throttling? Or does the
> most restrictive policy apply?
>
>
>>
>> [image: image.png]
>>
>> Below is how we are planning to implement this feature on APIM.
>>
>> 1. When a user creates an API product a new scope(without any role
>> assigned) will be created and attached to all the api resources he/she is
>> allowing for that API product.
>> 2. Then a user can subscribe to the api product and in order to get a
>> token for the API product, he/she has to pass the scope details along with
>> the token request.
>> 3. So that the request can be identified as coming through the API
>> product and handled accordingly.
>>
>> The reason for using this scope based approach is to avoid creating a new
>> gateway resource for the APIs in the product. In above, the requests will
>> be directed to the existing APIs deployed in the gateway and the request
>> will be distinguished as coming from an API product by using the scope
>> attached to the access token.
>>
>> Following are several concerns we identified and appreciate your thoughts
>> and suggestions on them.
>>
>> * At the moment an API resource can’t be assigned multiple scopes. - we
>> are currently looking into this.
>>
>
> So when getting a token does the user has to specify the API product scope
> and the resource scope (if any)?
>
>
>> * We are planning to introduce a new API product throttling level. At the
>> moment we are further looking into throttling and analytics for API
>> products.
>>
>> * With regard to UI aspects, we will be adding a new section in API
>> publisher UI to create and modify API products. And in store, we will be
>> adding a new section to view and subscribe to API products.
>>
>> Thanks,
>> Sachini
>> --
>>
>> *Sachini De Silva*
>> Software Engineer - WSO2
>>
>> Email : sachi...@wso2.com
>> Mobile : +94714765495
>>
>> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Intern Project] Graphical view for Exchanges, Bindings and Queues of MB4

[Frank Leymann]

Dear Ishara,

I don't quite get want you want to achieve: a set of icons that represent
the AMQP artifacts, and use them in the Ballerina modeling tool?  Or do you
want to graphically render a message flow, that is realized based on AMQP?

Best regards,
Frank




Am Do., 24. Jan. 2019 um 15:13 Uhr schrieb Ishara Amali :

> Hi all,
>
> Please find my project description as below.
>
> The project is “Graphical view for Exchanges, Bindings, and Queues of MB4”.
>
> Project Description
>
> The WSO2 Message broker is a lightweight, cloud-native message brokering
> server. It uses AMQP 0-9-1 as the messaging protocol. AMQP protocol has
> exchanges, bindings, and queues as building blocks. The broker core is
> written in a way to represent these components. Messages flowing through
> WSO2 Message broker are routed through these components. The Current WSO2
> ballerina message broker does not have the capability to visualize the AMQP
> model. The project is about developing a web UI to visualize this model in
> message broker by using the APIs already exposed by the MB runtime.
>
> The scope of the project
>
>
> Implement a read-only web-based UI to visualize exchanges, queues,
> bindings, and their relationships. This UI project is independent of the
> message broker which can be pointed to a running broker instance and get
> information.
>
> Extensions to the project,
>
> 1.Login with OAuth
>
> 2.Ability to define new queues and exchanges
>
> Approach
>
> ReactJS and Material-UI framework is used to design the web UIs and Axios
> library is used to send HTTP requests to the message broker.
>
> Timeline
>
> month 1 - understanding JMS 1.1 and AMQP 0.9.1 specifications,
> understanding message broker code.
>
> month 2 - understanding message broker APIs, user story writing and
> designing user interfaces
>
> month 3- learning ReactJS, Material-UI, Axios and starting project
> Implementation
>
> month 4- project implementation
>
>
> Thank you,
>
> Best Regards,
>
> --
> *Ishara Malaviarachchi*
>
> *Software engineering intern*
> *WSO2  (University of Kelaniya)*
> mobile : *+94766327745*  | email :*isha...@wso2.com
>  *
>
>
>
> [image: http://wso2.com/signature]
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Solution Design : Support for HTTP2 on the Microgateway

[Frank Leymann]

Hi Varuni,

thanks a lot!  Do read it correct that HTTP2 has worse response time than
HTTP?  Although many people claim the opposite...

Best regards,
Frank




Am Sa., 12. Jan. 2019 um 03:55 Uhr schrieb Varuni Punchihewa <
varu...@wso2.com>:

> Hi Frank,
>
> Here the server is written in Ballerina and you can find the Ballerina
> performance summary in,
> [1]
> https://github.com/ballerina-platform/ballerina-lang/blob/master/performance/benchmarks/summary.md
>
> Best Regards,
>
> *Varuni Punchihewa*
> Software Engineer - Intern | *WSO2*
> *Tel:* +94 71 699 5861
> <http://wso2.com/signature>
>
>
> On Fri, Dec 21, 2018 at 4:59 PM Frank Leymann  wrote:
>
>> +1 - I am eager to see this :-)
>>
>> Are we running a performance comparison between HTTP 1.1 and HTTP/2?
>>
>> Best regards,
>> Frank
>>
>>
>>
>>
>> Am Fr., 21. Dez. 2018 um 05:25 Uhr schrieb Nuwan Dias :
>>
>>>
>>>
>>> On Thu, Dec 20, 2018 at 5:10 PM Sanjeewa Malalgoda 
>>> wrote:
>>>
>>>> Can you create document explaining this feature in detail with possible
>>>> user scenarios. It would be great if we can have some test artifacts as
>>>> well.
>>>>
>>>
>>> +1. Let's create a GDoc and share please.
>>>
>>>>
>>>> Thanks,
>>>> sanjeewa.
>>>>
>>>> On Thu, Dec 20, 2018 at 3:38 PM Varuni Punchihewa 
>>>> wrote:
>>>>
>>>>> Hi Sanjeewa,
>>>>>
>>>>> There's no effect to ballerina filters from setting the http version
>>>>> to 2.0. But the connection established via the client and the microgateway
>>>>> and microgateway with the backend would be more efficient and fast due to
>>>>> the features like header compression, it's full multiplexed nature etc.
>>>>> Furthermore, we won't be using the server push feature in the microgateway
>>>>> since there's no much use cases of it with the microgateway.
>>>>>
>>>>> Thank you
>>>>> Best Regards,
>>>>>
>>>>> *Varuni Punchihewa*
>>>>> Intern - Software Engineering | *WSO2*
>>>>> *Tel:* +94 71 699 5861
>>>>> <http://wso2.com/signature>
>>>>>
>>>>>
>>>>> On Fri, Oct 26, 2018 at 12:05 PM Sanjeewa Malalgoda 
>>>>> wrote:
>>>>>
>>>>>> Can you please explain how are we planning to go ahead with this
>>>>>> feature? Even now with ballerina we can create http2 client endpoint or
>>>>>> server endpoint with http2 follows.
>>>>>> If we do same now how will it work with existing filters?
>>>>>>
>>>>>> endpoint http:Listener testEP {
>>>>>> port: 9095,
>>>>>> httpVersion: "2.0"
>>>>>> };
>>>>>>
>>>>>> Thanks,
>>>>>> sanjeewa.
>>>>>>
>>>>>> On Sat, Oct 6, 2018 at 5:13 PM Varuni Punchihewa 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi all!
>>>>>>> Please find my project description and the design as below.
>>>>>>>
>>>>>>> *Project description*
>>>>>>>
>>>>>>> The WSO2 API Microgateway currently supports only http and https as
>>>>>>> the incoming and outgoing transport protocols. This project is for 
>>>>>>> enabling
>>>>>>> it to support HTTP2 for both incoming and outgoing message flows. We 
>>>>>>> need
>>>>>>> to evaluate the use of OAuth2.0, and rate limiting capabilities on the
>>>>>>> current Microgateway and see how this impacts the move to HTTP2.
>>>>>>>
>>>>>>> *Solution Design*
>>>>>>>
>>>>>>>- Supporting the messages received by the microgateway from the
>>>>>>>clients, by both HTTP/1.1 and HTTP/2.0 protocols
>>>>>>>- All the communication that happen between the Microgateway and
>>>>>>>the Back end service will support HTTP/2.0 (The maximum version 
>>>>>>> supported
>>>>>>>is set to 2.0. In case if it supports only 1.1, then it will be 
>>>>>>> backward
>>>>>>>compatible to 1.1 and would no

Re: [Architecture] Solution Design : Support for HTTP2 on the Microgateway

[Frank Leymann]

+1 - I am eager to see this :-)

Are we running a performance comparison between HTTP 1.1 and HTTP/2?

Best regards,
Frank




Am Fr., 21. Dez. 2018 um 05:25 Uhr schrieb Nuwan Dias :

>
>
> On Thu, Dec 20, 2018 at 5:10 PM Sanjeewa Malalgoda 
> wrote:
>
>> Can you create document explaining this feature in detail with possible
>> user scenarios. It would be great if we can have some test artifacts as
>> well.
>>
>
> +1. Let's create a GDoc and share please.
>
>>
>> Thanks,
>> sanjeewa.
>>
>> On Thu, Dec 20, 2018 at 3:38 PM Varuni Punchihewa 
>> wrote:
>>
>>> Hi Sanjeewa,
>>>
>>> There's no effect to ballerina filters from setting the http version to
>>> 2.0. But the connection established via the client and the microgateway and
>>> microgateway with the backend would be more efficient and fast due to the
>>> features like header compression, it's full multiplexed nature etc.
>>> Furthermore, we won't be using the server push feature in the microgateway
>>> since there's no much use cases of it with the microgateway.
>>>
>>> Thank you
>>> Best Regards,
>>>
>>> *Varuni Punchihewa*
>>> Intern - Software Engineering | *WSO2*
>>> *Tel:* +94 71 699 5861
>>> 
>>>
>>>
>>> On Fri, Oct 26, 2018 at 12:05 PM Sanjeewa Malalgoda 
>>> wrote:
>>>
 Can you please explain how are we planning to go ahead with this
 feature? Even now with ballerina we can create http2 client endpoint or
 server endpoint with http2 follows.
 If we do same now how will it work with existing filters?

 endpoint http:Listener testEP {
 port: 9095,
 httpVersion: "2.0"
 };

 Thanks,
 sanjeewa.

 On Sat, Oct 6, 2018 at 5:13 PM Varuni Punchihewa 
 wrote:

> Hi all!
> Please find my project description and the design as below.
>
> *Project description*
>
> The WSO2 API Microgateway currently supports only http and https as
> the incoming and outgoing transport protocols. This project is for 
> enabling
> it to support HTTP2 for both incoming and outgoing message flows. We need
> to evaluate the use of OAuth2.0, and rate limiting capabilities on the
> current Microgateway and see how this impacts the move to HTTP2.
>
> *Solution Design*
>
>- Supporting the messages received by the microgateway from the
>clients, by both HTTP/1.1 and HTTP/2.0 protocols
>- All the communication that happen between the Microgateway and
>the Back end service will support HTTP/2.0 (The maximum version 
> supported
>is set to 2.0. In case if it supports only 1.1, then it will be 
> backward
>compatible to 1.1 and would not be a problem to communications)
>
> Best Regards,
>
> *Varuni Punchihewa*
> Intern - Software Engineering | *WSO2*
>
> *Tel:* +94 71 699 5861
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


 --
 *Sanjeewa Malalgoda*
 Software Architect | Associate Director, Engineering - WSO2 Inc.
 (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
 , Medium
 

 GET INTEGRATION AGILE 
 Integration Agility for Digitally Driven Business
 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

>>>
>>
>> --
>> *Sanjeewa Malalgoda*
>> Software Architect | Associate Director, Engineering - WSO2 Inc.
>> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
>> , Medium
>> 
>>
>> GET INTEGRATION AGILE 
>> Integration Agility for Digitally Driven Business
>>
>
>
> --
> *Nuwan Dias* | Director | WSO2 Inc.
> (m) +94 777 775 729 | (e) nuw...@wso2.com
> [image: Signature.jpg]
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] REST API versioning - which version to mandate in the URI scheme?

[Frank Leymann]

sion " , 
>>>>>> defaultValue="1.0")@HeaderParam("Minor-Version") String minorVersion
>>>>>>
>>>>>>
>>>>>> 4. In the implementation minorVersion parameter can be used to change 
>>>>>> the implementations conditionally.
>>>>>>
>>>>>> @Override
>>>>>> public Response policiesTierLevelGet(String tierLevel, Integer limit, 
>>>>>> Integer offset, String accept, String ifNoneMatch,
>>>>>>  String minorVersion) throws 
>>>>>> NotFoundException {
>>>>>> // major version implementation
>>>>>>
>>>>>>
>>>>>> if (Integer.parseInt(minorVersion) > 1) {
>>>>>> // new logic
>>>>>> }
>>>>>> return Response.ok().entity(new 
>>>>>> ApiResponseMessage(ApiResponseMessage.OK, "Sucess!")).build();
>>>>>> }
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 8, 2017 at 12:23 PM, Anuruddha Liyanarachchi <
>>>>>> anurudd...@wso2.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> You could offer clients a URI only approach and header approach in
>>>>>>>> parallel like this:
>>>>>>>> /someresource/v1/thisandthat -> default version, always latest
>>>>>>>> greatest minor version within v1, with optional header pointing to 
>>>>>>>> specific
>>>>>>>> version
>>>>>>>> /someresource/v11/thisandthat
>>>>>>>> /someresource/v12/thisandthat
>>>>>>>> /someresource/v2/whatever -> default version
>>>>>>>> /someresource/v21/whatever
>>>>>>>
>>>>>>>
>>>>>>> Supporting multiple version in URL is having different
>>>>>>> implementations under different context paths. Isn't it what we are 
>>>>>>> trying
>>>>>>> to avoid at the first place using custom minor version header?
>>>>>>>
>>>>>>> /someresource/v1/thisandthat -> default version, always latest
>>>>>>>> greatest minor version within v1, with optional header
>>>>>>>
>>>>>>> Shouldn't we support the minimum minor version if the header is not
>>>>>>> specified?
>>>>>>> This way, the client only need to send the header if latest update
>>>>>>> is required.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Anuruddha
>>>>>>>
>>>>>>> On Thu, Nov 17, 2016 at 9:49 PM, Jochen Traunecker <
>>>>>>> jochen.traunec...@googlemail.com> wrote:
>>>>>>>
>>>>>>>> Hi again,
>>>>>>>>
>>>>>>>> Assuming these policies are in place:
>>>>>>>> P1: minor versions guarantee backward compatibility
>>>>>>>> P2: major version can break backward compatibility
>>>>>>>>
>>>>>>>> You could offer clients a URI only approach and header approach in
>>>>>>>> parallel like this:
>>>>>>>>
>>>>>>>> /someresource/v1/thisandthat -> default version, always latest
>>>>>>>> greatest minor version within v1, with optional header pointing to 
>>>>>>>> specific
>>>>>>>> version
>>>>>>>> /someresource/v11/thisandthat
>>>>>>>> /someresource/v12/thisandthat
>>>>>>>> /someresource/v2/whatever -> default version
>>>>>>>> /someresource/v21/whatever
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> Jochen
>>>>>>>>
>>>>>>>> Jochen Traunecker <jochen.traunec...@googlemail.com> schrieb am
>>>>>>>> Do. 17. Nov. 2016 um 16:52:
>>>>>>>>
>>>>>>>>> Hi,,
>>>>>>>>>
>>>>>>>>> From a consumer's perspective there should be no mandatory minor
>>>>>>&g

Re: [Architecture] [APIM][C5] - Definining Endpoint for Resource from Rest API

[Frank Leymann]

Hi Jo,

yes, 400 is correctly used to indicate validation errors of message bodies
of POST requests.

I didn't know about Swaggers Security Scheme Object: great that we are
planning to use it :-)


Best regards,
Frank

2016-12-21 3:53 GMT+01:00 Joseph Fonseka <jos...@wso2.com>:

> Hi All
>
> On Tue, Dec 20, 2016 at 9:48 PM, Frank Leymann <fr...@wso2.com> wrote:
>
>> If an API Resource or endpoint is nothing stand-alone, i.e. if it needs
>> an API Definition and can't live without it, it should be nested under API
>> Definition.  Thus, "+1!
>>
>> Furthermore, I took a look at [1].  In line 167, a HEAD method is
>> defined.  A HEAD on a certain URI returns the very same than a GET except
>> that a HEAD must not (!) return a body.  A HEAD is used to check the HTTP
>> header fields of a given resource without returning the resource itself;
>> also, a HEAD is used to get aware of Authentication requirements in case of
>> PUT/POST before sending large bodies and getting a 401 back. Thus, it is
>> somehow "a stretch" to use HEAD to check conditions like proposed in the
>> API definition.
>>
>
> +1 Also I think we can go without the HEAD method. We can use the same
> APIs listing resource "/apis GET" to search on a given context which is
> already implemented. Benefits would be one less resource to implement and
> maintain.
>
>
>
>> Line 220 says that in case of status code 400 the API attribute specified
>> in the query string of the request does not meet the requirements.  This is
>> not what status code 400 is used for: 400 is returned in case the request
>> was malformed, had syntax errors etc. Thus, the use of 400 as proposed is
>> not standard compliant and should not be realized as is.
>>
>
> @Frank to clarify, It make sense not to issue 400 if the query parameters
> are malformed but can we use 400 if there are validation errors with the
> data submitted with a POST request.
>
>
>>
>> Line 224 says that a certain attribute does not exist in case of a 404
>> status code. Well, status 404 is returned if the whole resource cannot be
>> found. In this case (i.e. client specified a non-existent attibute) the 400
>> status code is appropriate.
>>
>
> +1 In this case if an API with the given context do not exist we can
> return 200 with a empty list ( assuming we are using /apis GET resource ).
>
>
>> Also, I see a couple of user defined headers (x-wso2...).  User defined
>> attributes are not RESTful, but in well-argued cases they are fine.  For
>> example, x-scope is user defined (not a w-wso2-... header?), and it seems
>> to be security related; isn't that somehow covered by bearer authentication
>> that allows to pass a scope parameter?  As you know, I am not really a
>> security expert, thus, you have to educate me :-)  I don't understand the
>> use of x-wso2-curl, x-wso2-request, and x-wso2-response.
>>
>
> @Frank We use those attributes ( ie x-wso2-curl ) to generate API
> documentation and they will not effect API run-time. see [1]. How ever we
> have planed to use swagger security object [2] instead of x-scope ( which
> is there for historical reasons ).
>
> Thanks & Reagrds
> Jo
>
>
> [1] https://docs.wso2.com/display/AM200/apidocs/publisher/
> [2] http://swagger.io/specification/#securityRequirementObject
>
>
>
>
>>
>>
>> Best regards,
>> Frank
>>
>> 2016-12-20 7:08 GMT+01:00 Sanjeewa Malalgoda <sanje...@wso2.com>:
>>
>>> Yes i also think same way. I believe we should add sub resources only if
>>> it has its own life cycles and its own usage even without dependency to
>>> root resource.
>>> But for me endpoints are tightly bound to API unlike other sub
>>> resources. If we consider image like resource then even without API
>>> dependency it has its own mean. Same applies for swagger definition etc.
>>> But IMO sub resources and its attributes are bit different from them and
>>> more like API meta data. WDYT?
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Tue, Dec 20, 2016 at 11:25 AM, Joseph Fonseka <jos...@wso2.com>
>>> wrote:
>>>
>>>> Hi Tharindu
>>>>
>>>> Instead of exposing new API resources can we use API Definition to
>>>> capture those details for example scopes and authentication types are
>>>> already captured in the API Definition ( Swagger ) with vendor extension
>>>> attributes.
>>>>
>>>> In the above case If a client want to update any of the resource valu

Re: [Architecture] [APIM][C5] - Definining Endpoint for Resource from Rest API

[Frank Leymann]

If an API Resource or endpoint is nothing stand-alone, i.e. if it needs an
API Definition and can't live without it, it should be nested under API
Definition.  Thus, "+1!

Furthermore, I took a look at [1].  In line 167, a HEAD method is defined.
A HEAD on a certain URI returns the very same than a GET except that a HEAD
must not (!) return a body.  A HEAD is used to check the HTTP header fields
of a given resource without returning the resource itself; also, a HEAD is
used to get aware of Authentication requirements in case of PUT/POST before
sending large bodies and getting a 401 back. Thus, it is somehow "a
stretch" to use HEAD to check conditions like proposed in the API
definition.

Line 211 says that an attribute status is returned (in case of status code
200): where is it returned?  The body must be empty!

Line 220 says that in case of status code 400 the API attribute specified
in the query string of the request does not meet the requirements.  This is
not what status code 400 is used for: 400 is returned in case the request
was malformed, had syntax errors etc. Thus, the use of 400 as proposed is
not standard compliant and should not be realized as is.

Line 224 says that a certain attribute does not exist in case of a 404
status code. Well, status 404 is returned if the whole resource cannot be
found. In this case (i.e. client specified a non-existent attibute) the 400
status code is appropriate.

Also, I see a couple of user defined headers (x-wso2...).  User defined
attributes are not RESTful, but in well-argued cases they are fine.  For
example, x-scope is user defined (not a w-wso2-... header?), and it seems
to be security related; isn't that somehow covered by bearer authentication
that allows to pass a scope parameter?  As you know, I am not really a
security expert, thus, you have to educate me :-)  I don't understand the
use of x-wso2-curl, x-wso2-request, and x-wso2-response.


Best regards,
Frank

2016-12-20 7:08 GMT+01:00 Sanjeewa Malalgoda :

> Yes i also think same way. I believe we should add sub resources only if
> it has its own life cycles and its own usage even without dependency to
> root resource.
> But for me endpoints are tightly bound to API unlike other sub resources.
> If we consider image like resource then even without API dependency it has
> its own mean. Same applies for swagger definition etc. But IMO sub
> resources and its attributes are bit different from them and more like API
> meta data. WDYT?
>
> Thanks,
> sanjeewa.
>
> On Tue, Dec 20, 2016 at 11:25 AM, Joseph Fonseka  wrote:
>
>> Hi Tharindu
>>
>> Instead of exposing new API resources can we use API Definition to
>> capture those details for example scopes and authentication types are
>> already captured in the API Definition ( Swagger ) with vendor extension
>> attributes.
>>
>> In the above case If a client want to update any of the resource values
>> they can simply submit the updated API Definition.
>>
>> Thanks
>> Jo
>>
>> On Tue, Dec 20, 2016 at 10:39 AM, Tharindu Dharmarathna <
>> tharin...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> We are going to implement REST API to do the following functionality on
>>> C5.
>>>
>>> *Functionality*
>>>
>>> 1. Add API Resource
>>>
>>>1. Endpoint configuration
>>>2. Resource level policy
>>>3. Authentication Type for resource (Any,Application user ,etc.)
>>>4. Scope
>>>
>>> 2. Update API Resource
>>> 3. Delete API Resource
>>> 4. GET API Resource.
>>>
>>> We had concern of following approaches to handle the above resource.
>>>
>>> 1. Handle as element in the API as [1].
>>>
>>> 2. Make SubResource of the API.
>>>
>>>- /apis/{API_ID}/resources - Post (Add resource)
>>>- /apis/{API_ID}/resources/{resourceid} - GET (Get Specific Resource)
>>>- /apis/{API_ID}/resources/{resourceid} - PUT (Update Specific
>>>Resource)
>>>- /apis/{API_ID}/resources/{resourceid} - Delete (Delete Specific
>>>Resource)
>>>- /apis/{API_ID}/resources - GET (Get All Resource according to the
>>>API)
>>>
>>>
>>> In order to handle above resources we are going to give resource in the
>>> API model of rest API as [1].
>>>
>>> [1] - https://github.com/tharindu1st/carbon-apimgt/blob/0d61ece0
>>> 9a4fc1cc24aa4616f63245a57decfe14/components/apimgt/org.wso2.
>>> carbon.apimgt.rest.api.publisher/src/main/resources/publisher-api.yaml
>>>
>>> Please add your suggestions into the above approaches.
>>>
>>> Thanks
>>>
>>> *Tharindu Dharmarathna*Software Engineer
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94779109091 <+94%2077%20910%209091>*
>>>
>>
>>
>>
>> --
>>
>> --
>> *Joseph Fonseka*
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 772 512 430
>> skype: jpfonseka
>>
>> * *
>>
>>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779 <+94%2071%20306%208779>
>
> blog 

Re: [Architecture] NextGen Tooling - Tool Palette

[Frank Leymann]

Hi Imesh,

please allow for a question:  if I draw a diagram, I control the layout if
it and as long as I don't store it I can chance the size of the elements
etc - is that correct?  But once I filed it, I can no longer change the
sizes and I can't change the position of the elements?  Why not, i.e. what
is the technical problem behind it?

I just tried in Camunda editor:  I can change everything and save, open and
change everything and save, open.  and the changes are all preserved as
I made them.   Same is true for Signavio editor (tested just a minute ago
too).

What the tools are doing is, that the corresponding .bpmn filel has two
subdocuments: one subdocument contains all the model elements to represent
the process MODEL (in the  element), and then the rendering
information for each model element including x-y-coordinates, height, width
etc (in the  element).

Thus, it state of the art to preserve the layouting information. I.e. we
shouldn't be weaker than the state of the art.  Finally, you don't need to
introduce a second file but can maintain the layouting info in the same
file - but cleanly separate between the logic of the process model and its
layout info.


Best regards,
Frank

2016-09-04 4:31 GMT+02:00 Imesh Gunaratne <im...@wso2.com>:

> Hi Frank,
>
> On Sat, Sep 3, 2016 at 8:35 PM, Frank Leymann <fr...@wso2.com> wrote:
>
>> Let me even emphasize what Chathura wrote: users will be really annoyed
>> if we don't preserve the layout/rendering of a diagram. It will be a
>> show-stopper for using the tool
>>
>
> Thanks for your feedback! According to the current approach the layout and
> rendering of the diagram will be preserved. The tool will render diagrams
> the same way as the author drew it, for any other user. The only limitation
> user will experience is that, re-positioning and re-sizing of the elements
> will not be possible, those will be controlled by the tool.
>
> If we were to persist positioning and sizing information, we might need to
> introduce a diagram file inaddition to the language file. Do you think we
> need to follow that model?
>
> Thanks
>
>>
>>
>> Best regards,
>> Frank
>>
>> 2016-08-31 6:01 GMT+02:00 Chathura Ekanayake <chath...@wso2.com>:
>>
>>> Hi Susinda / Imesh,
>>>
>>> If positioning information is not stored with the diagram, does it auto
>>> adjust size and positioning of elements based on the length of text
>>> provided as lifeline labels and text on lines connecting lifelines?
>>> Further, are we allowing users to change the order of lifelines?
>>>
>>> I think, although we might not need for sequence diagrams, in general it
>>> may be better to store positioning information with diagrams as auto
>>> layouting can be a complex problem. In addition, users may feel lack of
>>> control over the diagram, if they cannot position elements. For example,
>>> BPMN stores positioning information for each task and sequence in a
>>> separate xml section, which is referred by the corresponding logical
>>> construct when drawing the diagram in a canvas.
>>>
>>> Regards,
>>> Chathura
>>>
>>> On Tue, Aug 30, 2016 at 4:24 PM, Susinda Perera <susi...@wso2.com>
>>> wrote:
>>>
>>>> Hi Imesh
>>>>
>>>> +1 for all other suggestions and comments
>>>> Multiple groups added only to demonstrate the tool-palette features,
>>>> not needed for this editor but may be useful for datamapper editor.
>>>> We need to finalize the icons for the various tools/actions - Hope ESb
>>>> team can give some input
>>>> We will have UX review fix the other UI issues, +1 for go with a theme
>>>> approach (like dark/white)
>>>> I'll do the code refactoring for the name changes and positioning
>>>> issues.
>>>>
>>>> Thanks
>>>> Susinda
>>>>
>>>>
>>>> On Tue, Aug 30, 2016 at 3:35 PM, Imesh Gunaratne <im...@wso2.com>
>>>> wrote:
>>>>
>>>>> Great work Susinda! Few comments below:
>>>>>
>>>>>- I think initially we may not need multiple groups inside the
>>>>>tool palette for sequence diagramming module.
>>>>>- Maybe we can directly use the exact tool palette elements we
>>>>>need; Lifecycles, Mediators, and Arrows.
>>>>>- The term Tool used at Tools.Models.Tool, might not suit well.
>>>>>Shall we call it an Element/Item (a tool palette element/item)?
>>>>>- The images used inside t

Re: [Architecture] NextGen Tooling - Tool Palette

[Frank Leymann]

Let me even emphasize what Chathura wrote: users will be really annoyed if
we don't preserve the layout/rendering of a diagram. It will be a
show-stopper for using the tool


Best regards,
Frank

2016-08-31 6:01 GMT+02:00 Chathura Ekanayake :

> Hi Susinda / Imesh,
>
> If positioning information is not stored with the diagram, does it auto
> adjust size and positioning of elements based on the length of text
> provided as lifeline labels and text on lines connecting lifelines?
> Further, are we allowing users to change the order of lifelines?
>
> I think, although we might not need for sequence diagrams, in general it
> may be better to store positioning information with diagrams as auto
> layouting can be a complex problem. In addition, users may feel lack of
> control over the diagram, if they cannot position elements. For example,
> BPMN stores positioning information for each task and sequence in a
> separate xml section, which is referred by the corresponding logical
> construct when drawing the diagram in a canvas.
>
> Regards,
> Chathura
>
> On Tue, Aug 30, 2016 at 4:24 PM, Susinda Perera  wrote:
>
>> Hi Imesh
>>
>> +1 for all other suggestions and comments
>> Multiple groups added only to demonstrate the tool-palette features, not
>> needed for this editor but may be useful for datamapper editor.
>> We need to finalize the icons for the various tools/actions - Hope ESb
>> team can give some input
>> We will have UX review fix the other UI issues, +1 for go with a theme
>> approach (like dark/white)
>> I'll do the code refactoring for the name changes and positioning issues.
>>
>> Thanks
>> Susinda
>>
>>
>> On Tue, Aug 30, 2016 at 3:35 PM, Imesh Gunaratne  wrote:
>>
>>> Great work Susinda! Few comments below:
>>>
>>>- I think initially we may not need multiple groups inside the tool
>>>palette for sequence diagramming module.
>>>- Maybe we can directly use the exact tool palette elements we need;
>>>Lifecycles, Mediators, and Arrows.
>>>- The term Tool used at Tools.Models.Tool, might not suit well.
>>>Shall we call it an Element/Item (a tool palette element/item)?
>>>- The images used inside the tool palette may need to have
>>>transparent backgrounds.
>>>- Overall, we may also need to consider following:
>>>   - As we do not store positioning data, we may need to do the
>>>   positioning for the user. If so we may not need to provide user to 
>>> change
>>>   the positioning of elements as needed.
>>>   - We might need to update the colours of the elements and the
>>>   tool palette according to a colour scheme.
>>>
>>> Thanks
>>>
>>>
>>> On Tue, Aug 30, 2016 at 1:04 PM, Susinda Perera 
>>> wrote:
>>>
 The same webpage can be seen at here[1]
 [1] - https://wso2-incubator.github.io/js-tooling-framework/sequen
 ce-editor/index.html

 Thanks
 Susinda


 On Tue, Aug 30, 2016 at 11:34 AM, Susinda Perera 
 wrote:

> Hi All
>
> I have started implementing $subject. Figure[1] below is the
> screenshot of the current implementation.
> The implementation pf Tool palette is devided to following models and
> views (considering extendability) and the js code[2] describes the
> connectivity of the modules.
>
> ToolPalette / ToolPaletteView
> --ToolGroupWraper / ToolGroupWraperView
> --ToolGroup / ToolgroupView
>--Tool / ToolView
>
> TODO
> - Implement the drag and drop support
> - Implement the collapse of tool palette
> - Externalize the templates for toolView, toolgroupWrapperView and
> toolPaletteView
>
> Please give your inputs
>
>
>
> [2] -js code
> //create tools
> var calcTool = new Tools.Models.Tool({
> toolId: "tool1",
> toolImage:"images/icon1.png"
> });
>
> var calcTool2 = new Tools.Models.Tool({
> toolId: "tool2",
> toolImage:"images/icon1.png"
> });
>
> //create tool group
> var group = new Tools.Models.ToolGroup();
> group.add(calcTool);
> group.add(calcTool2);
>
> //create tool palette
> var toolPalette = new Tools.Models.ToolPalatte();
> var toolGroupWrapper = new Tools.Models.ToolGroupWrapper({toolGroupName:
> "LifeLines", toolGroup:group});
> toolPalette.add(toolGroupWrapper);
>
> //render the palate View
> var paletteView = new Tools.Views.ToolPalatteView({c
> ollection:toolPalatte});
> paletteView.render();
>
> [1] - screenshot
>
>
>
> ​
>
> --
> *Susinda Perera*
> Software Engineer
> B.Sc.(Eng), M.Sc(Computer Science), AMIE(SL)
> Mobile:(+94)716049075
> Blog: susinda.blogspot.com
> WSO2 Inc. http://wso2.com/
> Tel : 94 11 214 5345 Fax :94 11 2145300
> ​
>



 --
 *Susinda Perera*
 Software Engineer
 

Re: [Architecture] BPMN - Bulk Task Reassignment, Substitution feature

[Frank Leymann]

Great: we are in agreement :-))


Best regards,
Frank

2016-06-20 9:05 GMT+02:00 Vinod Kavinda <vi...@wso2.com>:

> Hi Frank,
> Agreed for the both suggestions.
>
> As Nandika mentioned "Not accepting a change in the substitute" is the
> option we also decided, whenever we have the ability to do so. But there
> are situations that we cannot do this when the cyclic situation arisen due
> to a time event. Theoratically, we don't have anyone to assign this task at
> this point, so it has to go back to Business Administrator as you suggested.
>
> However, in Activiti the corresponding role is "Task Owner". We will have
> to assign to task owner in this situation. One issue is the task owner is
> optional. Only in such a situation(no owner), we will have to make the task
> Claimable/Unreserved.
>
> Regards,
> Vinod
>
> On Mon, Jun 20, 2016 at 10:48 AM, Nandika Jayawardana <nand...@wso2.com>
> wrote:
>
>> Hi Frank,
>>
>> Not accepting a change in the substitute when there is a cyclic situation
>> is the options we decided as well.
>>
>> Regards
>> Nandika
>>
>> On Fri, Jun 17, 2016 at 11:26 PM, Frank Leymann <fr...@wso2.com> wrote:
>>
>>> Hi Vinod,
>>>
>>> Whenever a user changes his/her substitute, we check for a circular
>>> dependency.  This check happens independent of the fact whether substitutes
>>> are defined when the user are created ("modeling time") or when the
>>> substitute of a user is changed during "runtime". Is that your
>>> understanding too?
>>>
>>> If a circular dependency is detected, the request for the new substitute
>>> is not accepted.  And, yes, that's problematic because it may become quite
>>> cumbersome or even impossible to find a possible substitute (i.e. one that
>>> our cycle checker will accept).  For example, in case of n users U1,
>>> U2,...,Un user Ui has substitute Si and Si = U(i+1) with U(n+1)=U1 - we
>>> have a problem. During modeling time their may be time to fix the problem,
>>> but during runtime that may be critical.  Setting the Reserved or
>>> inProgress tasks of the user just defining his new substitute in state
>>> Ready doesn't help because there may be no potential owners who may get
>>> aware about the task.
>>>
>>> For this purpose, the key principle of Human Task is that the engine
>>> must do everything to push tasks to (at least) Reserve status. This is done
>>> by corresponding deadline processing, or by nomination: i.e. the engine
>>> informs the Business Administrator of the task who then assigns the task to
>>> an owner. But this may result in a burden of the Business Administrator in
>>> case he will get many tasks to nominate.
>>>
>>> So, let's discuss. My current preference is to *not accept* a change in
>>> the substitute definition in case a cyclic structure would result.  WDYT?
>>>
>>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> 2016-06-16 3:31 GMT+02:00 Vinod Kavinda <vi...@wso2.com>:
>>>
>>>> Hi Frank,
>>>> Yes, it's when changing the substitute user. We have to use the second
>>>> suggestion also.
>>>>
>>>> In a scenario where substitution starts in a future time(not just after
>>>> changing the substitute user), we do not have the option of rejecting the
>>>> substitution request. In such a scenario, we will have to make his tasks
>>>> unclaimed!
>>>>
>>>> Regards,
>>>> Vinod
>>>> On Jun 16, 2016 2:28 AM, "Frank Leymann" <fr...@wso2.com> wrote:
>>>>
>>>> Hi Vinod,
>>>>
>>>> yes, that's a well-known issue :-)   I suggest to adopt your first
>>>> suggestion, namely checking circular dependencies when a new substitute has
>>>> been specified (I guess that's what you meant - not when adding a new user,
>>>> right?).
>>>>
>>>>
>>>>
>>>> Best regards,
>>>> Frank
>>>>
>>>> 2016-06-15 13:25 GMT+02:00 Vinod Kavinda <vi...@wso2.com>:
>>>>
>>>>> Hi all,
>>>>> I ran into an issue while implementing this.
>>>>>
>>>>> What if we ran into a *circular dependency between user substitutes*?
>>>>> We can't calculate a transitive substitute in this scenario. No one will 
>>>>> be
>>>>> available to take up the tasks of the

Re: [Architecture] BPMN - Bulk Task Reassignment, Substitution feature

[Frank Leymann]

Hi Vinod,

Whenever a user changes his/her substitute, we check for a circular
dependency.  This check happens independent of the fact whether substitutes
are defined when the user are created ("modeling time") or when the
substitute of a user is changed during "runtime". Is that your
understanding too?

If a circular dependency is detected, the request for the new substitute is
not accepted.  And, yes, that's problematic because it may become quite
cumbersome or even impossible to find a possible substitute (i.e. one that
our cycle checker will accept).  For example, in case of n users U1,
U2,...,Un user Ui has substitute Si and Si = U(i+1) with U(n+1)=U1 - we
have a problem. During modeling time their may be time to fix the problem,
but during runtime that may be critical.  Setting the Reserved or
inProgress tasks of the user just defining his new substitute in state
Ready doesn't help because there may be no potential owners who may get
aware about the task.

For this purpose, the key principle of Human Task is that the engine must
do everything to push tasks to (at least) Reserve status. This is done by
corresponding deadline processing, or by nomination: i.e. the engine
informs the Business Administrator of the task who then assigns the task to
an owner. But this may result in a burden of the Business Administrator in
case he will get many tasks to nominate.

So, let's discuss. My current preference is to *not accept* a change in the
substitute definition in case a cyclic structure would result.  WDYT?



Best regards,
Frank

2016-06-16 3:31 GMT+02:00 Vinod Kavinda <vi...@wso2.com>:

> Hi Frank,
> Yes, it's when changing the substitute user. We have to use the second
> suggestion also.
>
> In a scenario where substitution starts in a future time(not just after
> changing the substitute user), we do not have the option of rejecting the
> substitution request. In such a scenario, we will have to make his tasks
> unclaimed!
>
> Regards,
> Vinod
> On Jun 16, 2016 2:28 AM, "Frank Leymann" <fr...@wso2.com> wrote:
>
> Hi Vinod,
>
> yes, that's a well-known issue :-)   I suggest to adopt your first
> suggestion, namely checking circular dependencies when a new substitute has
> been specified (I guess that's what you meant - not when adding a new user,
> right?).
>
>
>
> Best regards,
> Frank
>
> 2016-06-15 13:25 GMT+02:00 Vinod Kavinda <vi...@wso2.com>:
>
>> Hi all,
>> I ran into an issue while implementing this.
>>
>> What if we ran into a *circular dependency between user substitutes*? We
>> can't calculate a transitive substitute in this scenario. No one will be
>> available to take up the tasks of the unavailable user.
>>
>> Here is my suggestion for this:
>>
>> *Circular dependency detected while adding a new user*
>> We abort this user addition and reply back to the user asking for a new
>> substitute.
>>
>> *Circular dependency detected while resolving transitive subs in a
>> scheduled event (Due to a user's substitution starting at this point )*
>>
>> Mark the transitive sub is "UNDEFINED". Future tasks that are assigning
>> to this user will be reverted back as unclaimed tasks (remove the assignee).
>>
>> Any suggestions?
>>
>>
>>
>>
>> On Thu, Jun 9, 2016 at 8:31 AM, Vinod Kavinda <vi...@wso2.com> wrote:
>>
>>> Hi Frank,
>>> Agreed.
>>> I have created Jira [1] to track this improvement after the Human Task
>>> integration with BPMN engine.
>>>
>>> [1] - https://wso2.org/jira/browse/BPS-1043
>>>
>>> Regards,
>>> Vinod
>>>
>>> On Wed, Jun 8, 2016 at 10:03 PM, Nandika Jayawardana <nand...@wso2.com>
>>> wrote:
>>>
>>>> Yes, Once the task engine refactoring is complete, we can integrate our
>>>> own task implementation with activiti . Then we can overcome the current
>>>> limitations of user tasks.
>>>>
>>>> Regards
>>>> Nandika
>>>>
>>>> On Wed, Jun 8, 2016 at 7:18 PM, Milinda Perera <milin...@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Wed, Jun 8, 2016 at 6:49 PM, Frank Leymann <fr...@wso2.com> wrote:
>>>>>
>>>>>> Dear Vinod,
>>>>>>
>>>>>> understood.  My recommendation is that we should argue as long as
>>>>>> possible independent from a certain implementation: if we may decide to
>>>>>> move from Activiti to Camunda, we should have the architecture/design 
>>>>>> right
>>>>>> to port

Re: [Architecture] BPMN - Bulk Task Reassignment, Substitution feature

[Frank Leymann]

Hi Vinod,

yes, that's a well-known issue :-)   I suggest to adopt your first
suggestion, namely checking circular dependencies when a new substitute has
been specified (I guess that's what you meant - not when adding a new user,
right?).



Best regards,
Frank

2016-06-15 13:25 GMT+02:00 Vinod Kavinda <vi...@wso2.com>:

> Hi all,
> I ran into an issue while implementing this.
>
> What if we ran into a *circular dependency between user substitutes*? We
> can't calculate a transitive substitute in this scenario. No one will be
> available to take up the tasks of the unavailable user.
>
> Here is my suggestion for this:
>
> *Circular dependency detected while adding a new user*
> We abort this user addition and reply back to the user asking for a new
> substitute.
>
> *Circular dependency detected while resolving transitive subs in a
> scheduled event (Due to a user's substitution starting at this point )*
>
> Mark the transitive sub is "UNDEFINED". Future tasks that are assigning to
> this user will be reverted back as unclaimed tasks (remove the assignee).
>
> Any suggestions?
>
>
>
>
> On Thu, Jun 9, 2016 at 8:31 AM, Vinod Kavinda <vi...@wso2.com> wrote:
>
>> Hi Frank,
>> Agreed.
>> I have created Jira [1] to track this improvement after the Human Task
>> integration with BPMN engine.
>>
>> [1] - https://wso2.org/jira/browse/BPS-1043
>>
>> Regards,
>> Vinod
>>
>> On Wed, Jun 8, 2016 at 10:03 PM, Nandika Jayawardana <nand...@wso2.com>
>> wrote:
>>
>>> Yes, Once the task engine refactoring is complete, we can integrate our
>>> own task implementation with activiti . Then we can overcome the current
>>> limitations of user tasks.
>>>
>>> Regards
>>> Nandika
>>>
>>> On Wed, Jun 8, 2016 at 7:18 PM, Milinda Perera <milin...@wso2.com>
>>> wrote:
>>>
>>>>
>>>> On Wed, Jun 8, 2016 at 6:49 PM, Frank Leymann <fr...@wso2.com> wrote:
>>>>
>>>>> Dear Vinod,
>>>>>
>>>>> understood.  My recommendation is that we should argue as long as
>>>>> possible independent from a certain implementation: if we may decide to
>>>>> move from Activiti to Camunda, we should have the architecture/design 
>>>>> right
>>>>> to port our implementation with minimal effort. That's why I argue in 
>>>>> terms
>>>>> of the BPMN recommended state model, and when we agree on the principles 
>>>>> we
>>>>> can map it to the underlying engine. Does this sound acceptable?
>>>>>
>>>>> Which brings up the following question:  When we support User Tasks in
>>>>> Activiti, don't we use our HumanTask implementation as User Task as BPMN
>>>>> 2.0 assumes? But we use the simplified implementation that Activiti ships?
>>>>> If we do the latter, what is our strategy of our HumanTask implementation?
>>>>>
>>>>
>>>>
>>>>
>>>>  +1, Soon or Later I think replacing Activiti User Task or introducing
>>>> as a new type of user task, with our WS-HumanTask it the best option.
>>>> AFAIR similar idea is in our future roadmap @Hasitha @Nandika : isn't
>>>> it?
>>>>
>>>> --
>>>> Milinda Perera
>>>> Software Engineer;
>>>> WSO2 Inc. http://wso2.com ,
>>>> Mobile: (+94) 714 115 032
>>>>
>>>>
>>>
>>>
>>> --
>>> Nandika Jayawardana
>>> WSO2 Inc ; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>
>>
>>
>> --
>> Vinod Kavinda
>> Software Engineer
>> *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.*
>> Mobile : +94 (0) 712 415544
>> Blog : http://soatechflicks.blogspot.com/
>>
>>
>
>
> --
> Vinod Kavinda
> Software Engineer
> *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.*
> Mobile : +94 (0) 712 415544
> Blog : http://soatechflicks.blogspot.com/
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] BPMN - Bulk Task Reassignment, Substitution feature

[Frank Leymann]

Dear Vinod,

understood.  My recommendation is that we should argue as long as possible
independent from a certain implementation: if we may decide to move from
Activiti to Camunda, we should have the architecture/design right to port
our implementation with minimal effort. That's why I argue in terms of the
BPMN recommended state model, and when we agree on the principles we can
map it to the underlying engine. Does this sound acceptable?

Which brings up the following question:  When we support User Tasks in
Activiti, don't we use our HumanTask implementation as User Task as BPMN
2.0 assumes? But we use the simplified implementation that Activiti ships?
If we do the latter, what is our strategy of our HumanTask implementation?


Best regards,
Frank

2016-06-08 11:35 GMT+02:00 Vinod Kavinda <vi...@wso2.com>:

> Hi Frank,
> Activiti has not defined states compliant with WS-HumanTask. It has only
> Created, Claimed and Completed states.
>
> Regards,
> Vinod
>
> On Wed, Jun 8, 2016 at 2:52 PM, Frank Leymann <fr...@wso2.com> wrote:
>
>> Dear Vinod,
>>
>> BPMN 2.0 explicitly refers to WS-HumanTask as implementation of a User
>> Task (see pp 166 ff) - although they say that there are many potential
>> different implementations, HumanTask is preferred (...and I co-authored
>> these sections, summarizing the position of the group ;-)). Thus, BPMN 2.0
>> does not refer to any states because its implementation dependent, but each
>> implementation has to define the states - otherwise we run into non-defined
>> situations we are discussion here.  Has Activiti these states defined?
>>
>>
>> Best regards,
>> Frank
>>
>> 2016-06-06 7:41 GMT+02:00 Vinod Kavinda <vi...@wso2.com>:
>>
>>> Please find my comments inline..
>>>
>>>>
>>>>
>>>>> *Task Reassignment at the end of substitution period*
>>>>> When a user that was on vacation come back, we will not assign his
>>>>> past tasks back to himself from his substitute. Since we cannot track the
>>>>> progress of the tasks once it is assigned to a user, this is not 
>>>>> reasonable.
>>>>> We will stop substitution of future tasks at this point.
>>>>>
>>>>
>>>> ​That's not typically what is required.  We should at least reassign
>>>> tasks that are not yet InProgess. ​ But Ready and Reserved tasks should be
>>>> reassigned to the user returned in any case.
>>>>
>>>
>>> Totally agreed to this if it is in a WS-Human task context.
>>>
>>> We are considering User tasks in BPMN here. In Activiti there is no such
>>> notion as task status. There is no such status like "In progress". Once a
>>> task is assigned to someone, we have to assume that he is working on it.
>>> If we automatically reassign tasks to original user, it will be a mess.
>>> (eg: in call centers, user A assign his tasks to B and go out. B is on a
>>> call for a task came from B. While he is on call A comes back, tasks get
>>> reassigned back to him. He will make another call for the same task, since
>>> the task is not completed, complete mix up!!)
>>>
>>> I don't think we should automatically reassign without the assignee
>>> consent. If we really need, we can have a API that a user can retrieve his
>>> own tasks thet were substituted to someone else.
>>>
>>> Vinod Kavinda
>>> Software Engineer
>>> *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.*
>>> Mobile : +94 (0) 712 415544
>>> Blog : http://soatechflicks.blogspot.com/
>>>
>>>
>>
>
>
> --
> Vinod Kavinda
> Software Engineer
> *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.*
> Mobile : +94 (0) 712 415544
> Blog : http://soatechflicks.blogspot.com/
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] BPMN - Bulk Task Reassignment, Substitution feature

[Frank Leymann]

Vinod,

re-assignment must consider the state of the task. In your scenario, the
task that B is working on is inProgress (BPMN / HumanTask terminology =
"active/workedOn" in informal terminology also used in BPMN spec) and will
not (!) be re-assigned. Note that "claimed" means that a human being said
that she will work on it in some near future but that she is not yet
working on it; thus, it can still be re-assigned.



Best regards,
Frank

2016-06-06 7:41 GMT+02:00 Vinod Kavinda :

> Please find my comments inline..
>
>>
>>
>>> *Task Reassignment at the end of substitution period*
>>> When a user that was on vacation come back, we will not assign his past
>>> tasks back to himself from his substitute. Since we cannot track the
>>> progress of the tasks once it is assigned to a user, this is not reasonable.
>>> We will stop substitution of future tasks at this point.
>>>
>>
>> ​That's not typically what is required.  We should at least reassign
>> tasks that are not yet InProgess. ​ But Ready and Reserved tasks should be
>> reassigned to the user returned in any case.
>>
>
> Totally agreed to this if it is in a WS-Human task context.
>
> We are considering User tasks in BPMN here. In Activiti there is no such
> notion as task status. There is no such status like "In progress". Once a
> task is assigned to someone, we have to assume that he is working on it.
> If we automatically reassign tasks to original user, it will be a mess.
> (eg: in call centers, user A assign his tasks to B and go out. B is on a
> call for a task came from B. While he is on call A comes back, tasks get
> reassigned back to him. He will make another call for the same task, since
> the task is not completed, complete mix up!!)
>
> I don't think we should automatically reassign without the assignee
> consent. If we really need, we can have a API that a user can retrieve his
> own tasks thet were substituted to someone else.
>
> Vinod Kavinda
> Software Engineer
> *WSO2 Inc. - lean . enterprise . middleware .*
> Mobile : +94 (0) 712 415544
> Blog : http://soatechflicks.blogspot.com/
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] BPMN - Bulk Task Reassignment, Substitution feature

[Frank Leymann]

Dear Vinod,

BPMN 2.0 explicitly refers to WS-HumanTask as implementation of a User Task
(see pp 166 ff) - although they say that there are many potential different
implementations, HumanTask is preferred (...and I co-authored these
sections, summarizing the position of the group ;-)). Thus, BPMN 2.0 does
not refer to any states because its implementation dependent, but each
implementation has to define the states - otherwise we run into non-defined
situations we are discussion here.  Has Activiti these states defined?


Best regards,
Frank

2016-06-06 7:41 GMT+02:00 Vinod Kavinda :

> Please find my comments inline..
>
>>
>>
>>> *Task Reassignment at the end of substitution period*
>>> When a user that was on vacation come back, we will not assign his past
>>> tasks back to himself from his substitute. Since we cannot track the
>>> progress of the tasks once it is assigned to a user, this is not reasonable.
>>> We will stop substitution of future tasks at this point.
>>>
>>
>> ​That's not typically what is required.  We should at least reassign
>> tasks that are not yet InProgess. ​ But Ready and Reserved tasks should be
>> reassigned to the user returned in any case.
>>
>
> Totally agreed to this if it is in a WS-Human task context.
>
> We are considering User tasks in BPMN here. In Activiti there is no such
> notion as task status. There is no such status like "In progress". Once a
> task is assigned to someone, we have to assume that he is working on it.
> If we automatically reassign tasks to original user, it will be a mess.
> (eg: in call centers, user A assign his tasks to B and go out. B is on a
> call for a task came from B. While he is on call A comes back, tasks get
> reassigned back to him. He will make another call for the same task, since
> the task is not completed, complete mix up!!)
>
> I don't think we should automatically reassign without the assignee
> consent. If we really need, we can have a API that a user can retrieve his
> own tasks thet were substituted to someone else.
>
> Vinod Kavinda
> Software Engineer
> *WSO2 Inc. - lean . enterprise . middleware .*
> Mobile : +94 (0) 712 415544
> Blog : http://soatechflicks.blogspot.com/
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] BPMN - Bulk Task Reassignment, Substitution feature

[Frank Leymann]

I refer to the states defined in the HumanTask spec:
http://docs.oasis-open.org/bpel4people/ws-humantask-1.1-spec-cd-06.pdf
Section 4.10 defines these states - "claimed" is not what the standard
defines because different implementations had slightly different semantics,
thus, we renamed the states and defined their operational semantics...


Best regards,
Frank

2016-06-06 17:55 GMT+02:00 Manuranga Perera :

> There is no such status like "In progress".
>
> Isn't "claiming" a task is equivalent to making "in progress".
>
> In your example of call, I'll first claim and then start the call.
>
> On Mon, Jun 6, 2016 at 11:51 AM, Manuranga Perera  wrote:
>
>> I think as much as possible we have to achieve this with Event-driven
>>> architecture rather than schedulers.
>>>
>> +1
>>
>>> So we can use simple cache mechanism as below
>>
>> While this is possible, I don't see why we are trying to shave off a few
>> milliseconds from the task creation and make the it more complex even
>> sacrificing correctness. Isn't this some premature optimization ?
>>
>> --
>> With regards,
>> *Manu*ranga Perera.
>>
>> phone : 071 7 70 20 50
>> mail : m...@wso2.com
>>
>
>
>
> --
> With regards,
> *Manu*ranga Perera.
>
> phone : 071 7 70 20 50
> mail : m...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] BPMN - Bulk Task Reassignment, Substitution feature

[Frank Leymann]

Fantastic!  Thanks!


Best regards,
Frank

2016-06-02 5:21 GMT+02:00 Vinod Kavinda <vi...@wso2.com>:

> Hi Frank,
> Yes, the determining of users as substitutes will be a transitive process.
>
> Regards,
> Vinod
>
> On Wed, Jun 1, 2016 at 10:48 PM, Frank Leymann <fr...@wso2.com> wrote:
>
>> Hi Vinod,
>>
>> great that you are implementing it!
>>
>> As described in [1], substitution processing is transitive. Your diagram
>> doesn't explicitly depict this transitive processing: are you considering
>> this but the diagram leaves that out for clarity?
>>
>>
>> [1] https://mail.google.com/mail/u/0/#sent/154edd36fb959ac5
>>
>>
>> Best regards,
>> Frank
>>
>> 2016-06-01 11:25 GMT+02:00 Vinod Kavinda <vi...@wso2.com>:
>>
>>> Hi all,
>>>
>>> In BPMN user tasks, if a task assignee became unavailable (eg: on
>>> vacation), assigned tasks are getting delayed and anyone else cannot work
>>> on them either.
>>>
>>> This feature is to provide an API to allow automatically substitute the
>>> user in future tasks and to reassign the existing tasks. Follow the below
>>> diagrams for more details.
>>>
>>> *Upon user unavailable request*
>>>
>>>
>>>
>>>
>>> *​​​*substitute(user, tasks, from, to, substitute) :
>>>
>>>- user - user going to be unavailable
>>>- tasks - optional. list of tasks that should reassign. All tasks
>>>will be reassigned if not provided
>>>- from, to - optional. unavailable period. if not provided, current
>>>timestamp to forever
>>>- substitute - optional. user who tasks getting assigned to. the
>>>already defined user is used if not provided
>>>
>>> updateSubstitute() : update the DB with user unavailability and
>>> substitute user.
>>>
>>> getTaskList(user) : get the tasks with the user as assignee
>>>
>>> delegateTasks() : change assignee to substitute
>>>
>>> scheduleForrevert(from,to) : start a scheduler, to update the DB at the
>>> 'to' and 'from' timestamps.
>>>
>>> *New Task creation*
>>>
>>> All the task creation events will be validated by this listener after
>>> this feature is enabled.
>>>
>>> After the given time period, the database will be updated. After this
>>> point user won't be substituted.
>>>
>>> Please provide your suggestions.
>>>
>>> Regards,
>>> Vinod
>>> ​
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Vinod Kavinda
>>> Software Engineer
>>> *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.*
>>> Mobile : +94 (0) 712 415544
>>> Blog : http://soatechflicks.blogspot.com/
>>>
>>>
>>
>
>
> --
> Vinod Kavinda
> Software Engineer
> *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.*
> Mobile : +94 (0) 712 415544
> Blog : http://soatechflicks.blogspot.com/
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] BPMN - Bulk Task Reassignment, Substitution feature

[Frank Leymann]

Hi Vinod,

great that you are implementing it!

As described in [1], substitution processing is transitive. Your diagram
doesn't explicitly depict this transitive processing: are you considering
this but the diagram leaves that out for clarity?


[1] https://mail.google.com/mail/u/0/#sent/154edd36fb959ac5


Best regards,
Frank

2016-06-01 11:25 GMT+02:00 Vinod Kavinda :

> Hi all,
>
> In BPMN user tasks, if a task assignee became unavailable (eg: on
> vacation), assigned tasks are getting delayed and anyone else cannot work
> on them either.
>
> This feature is to provide an API to allow automatically substitute the
> user in future tasks and to reassign the existing tasks. Follow the below
> diagrams for more details.
>
> *Upon user unavailable request*
>
>
>
>
> *​​​*substitute(user, tasks, from, to, substitute) :
>
>- user - user going to be unavailable
>- tasks - optional. list of tasks that should reassign. All tasks will
>be reassigned if not provided
>- from, to - optional. unavailable period. if not provided, current
>timestamp to forever
>- substitute - optional. user who tasks getting assigned to. the
>already defined user is used if not provided
>
> updateSubstitute() : update the DB with user unavailability and substitute
> user.
>
> getTaskList(user) : get the tasks with the user as assignee
>
> delegateTasks() : change assignee to substitute
>
> scheduleForrevert(from,to) : start a scheduler, to update the DB at the
> 'to' and 'from' timestamps.
>
> *New Task creation*
>
> All the task creation events will be validated by this listener after this
> feature is enabled.
>
> After the given time period, the database will be updated. After this
> point user won't be substituted.
>
> Please provide your suggestions.
>
> Regards,
> Vinod
> ​
>
>
>
>
>
>
> --
> Vinod Kavinda
> Software Engineer
> *WSO2 Inc. - lean . enterprise . middleware .*
> Mobile : +94 (0) 712 415544
> Blog : http://soatechflicks.blogspot.com/
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] RESTFul API for App Manager - Design discussion

[Frank Leymann]

Sanjeewa (or Prabath) may have guidance on this...


Best regards,
Frank

2016-04-27 11:11 GMT+02:00 Thilini Shanika :

> + Frank
>
> On Wed, Apr 27, 2016 at 2:36 PM, Thilini Shanika 
> wrote:
>
>> Hi,
>>
>> We have a little concern regarding the permission check in OAuth secured
>> APIs in APPM.
>>
>> Currently, all the available APIs are attached with relevant OAuth 2
>> scopes, but there are some cases where we cannot manage permissions using
>> scopes only.
>>
>> For example, in application lifecycle change API, we need to check user
>> permissions in different criterias. Required permission to change the
>> lifecycle state of a mobile/webapp depends on the current state.
>>  ie: The users with Internal/creator is allowed to perform the lifecycle
>> action 'Submit for Review' and change the state into 'In-review'. But rest
>> of the lifecycle state changes are allowed for users with
>> 'Internal/publisher'.Below is the API definition.
>>
>> URL :
>> http://localhost:9763/api/appm/publisher/v1.0/apps
>> /{appType}/change-lifecycle
>> HTTP Methos : POST
>> URI Params : appId, action (ie: Submit for Review, Approve,
>> Publish,Reject ..)
>>
>> Thus we cannot achieve this permission check by attaching scopes with the
>> lifecycle change API, since there's a confusion in scope-role mapping.
>> (Current scope mapping is scope-role mapping : 'appm:publish' --> admin,
>> Internal/publisher. But this mapping cannot be applied for 'Submit for
>> Review' state change since its allowed to perform by 'Internal/creator')
>>
>>
>> We have two options to overcome this problem.
>>
>>1. Remove scopes from lifecycle change API and manage permission
>>check in code level
>>2. Avoid using a common api for all lifecycle changes and maintain
>>different API resources for different lifecycle actions which require
>>different permissions. So different scopes can be assigned to each API.
>>
>> What would be the best option? You suggestions and comments are highly
>> appreciated.
>>
>> Thanks
>>
>> On Tue, Apr 26, 2016 at 7:49 PM, Manuranga Perera  wrote:
>>
>>> agreed Gayan.
>>> If we have following, it will be clearer. I changed 'apps' to '
>>> installations'
>>>
>>> DELETE http://localhost:9763/api/appm/storeadmin/v1.0/users/
>>> admin/installations/cec2027d-2dd6-4826-97c5-33be4eb83ae1
>>>
>>> On Tue, Apr 26, 2016 at 12:33 AM, Gayan Gunarathne 
>>> wrote:
>>>


 On Mon, Apr 25, 2016 at 6:48 PM, Manuranga Perera 
 wrote:

> DELETE is verb to un-link resources.
> Eg: DELETE /user/starred/manu/product-appm [1] will un-link me form
> appM. But it doesn't mean AppM repo will be deleted.
>

 See the url here. That make sense it deletes the starred with
 manu/product-appm.

 With the rest, if we define the resources named well, that API is
 intuitive and easy to use. If we defined the resources naming poorly, that
 same API can feel awkward and be difficult to use and understand.
 We need to consider http verb with the resource naming when creating
 the rest api.


>
> [1]
> https://developer.github.com/v3/activity/starring/#unstar-a-repository
>
> On Mon, Apr 25, 2016 at 6:55 AM, SajithAR Ariyarathna <
> sajit...@wso2.com> wrote:
>
>> [+ Frank]
>>
>> On Mon, Apr 25, 2016 at 11:49 AM, SajithAR Ariyarathna <
>> sajit...@wso2.com> wrote:
>>
>>> ... "uninstall" is NOT a REST, even though it looks like REST.
>>>
>>> "uninstall" does not looks like REST. It looks like RPC.
>>>
>>> On Mon, Apr 25, 2016 at 10:43 AM, Ruwan Abeykoon 
>>> wrote:
>>>
 I disagree Manu, The point is this is not "DELETE" action on a
 "resource". This is an action to remove a link between two resources. 
 But
 one oth that "Resource" is just a virtual resource(which is not under
 control of the system). So I think having DELETE HTTP verb is wrong in 
 this.

 Cheer,
 Ruwan

 On Mon, Apr 25, 2016 at 10:36 AM, Manuranga Perera 
 wrote:

> I think, even if it's not immediately affected (asynchronous), you
> still have to use the correct HTTP verb.
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --

 *Ruwan Abeykoon*
 *Architect,*
 *WSO2, Inc. http://wso2.com  *
 *lean.enterprise.middleware.*

 email: ruw...@wso2.com

 ___
 Architecture mailing list
 Architecture@wso2.org
 

Re: [Architecture] [Dev] [REST APIs][Analytics] GET request with a payload

[Frank Leymann]

Ah, now I got it! Thanks!


Best regards,
Frank

2016-04-15 19:34 GMT+02:00 Gimantha Bandara <giman...@wso2.com>:

> Hi Frank,
>
> Yes, I saw that and I read the document and it is very helpful. These APIs
> were created and released last year. So we cannot change these APIs until
> we do a major release. Of course the new changes in these REST APIs and new
> REST APIs will be created adhering to those REST API Guidelines.
>
> On Fri, Apr 15, 2016 at 10:54 PM, Frank Leymann <fr...@wso2.com> wrote:
>
>> We built a REST API Guideline document a few weeks ago.  Do you
>> (Gimantha) see that?  Its purpose is to help in designing REST APIs.  If
>> you think it would be helpful for you and your team, we can set up a call
>> on this
>>
>>
>> Best regards,
>> Frank
>>
>> 2016-04-15 16:00 GMT+02:00 Manuranga Perera <m...@wso2.com>:
>>
>>> 1) So {to}, {from}, {start}, {count} are resources ? They are not. How
>>> is this REST?
>>> 2) What are you searching in POST /analytics/search.
>>> tables, drilldown, everything? I can't see that in URL.
>>> 3) is POST /analytics/drilldown creating a drilldown or getting one ?
>>> If it's getting one, this is also wrong, should be get. If creating, why
>>> not PUT?
>>>
>>>
>>>
>>>
>>> On Mon, Apr 4, 2016 at 12:08 AM, Gimantha Bandara <giman...@wso2.com>
>>> wrote:
>>>
>>>> Please note that "fields" is changed to "columns" for consistency as in
>>>> APIs, "columns" is used.
>>>>
>>>> On Mon, Apr 4, 2016 at 9:08 AM, Gimantha Bandara <giman...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Thank you for your suggestions! We are going to use GET with the query
>>>>> parameter "columns" to get the records filtered by a time range. So when
>>>>> only a selected set of columns/fields are needed, Following format can be
>>>>> used.
>>>>>
>>>>> *Get the records within a specific time range.*
>>>>>
>>>>> GET
>>>>> /analytics/tables/{tableName}/{to}/{from}/{start}/{count}?fields=field1,field2,field3
>>>>>
>>>>> *Drilldown and Search APIs*
>>>>>
>>>>> Additional JSON element will be added as following
>>>>>
>>>>> POST /analytics/drilldown or POST /analytics/search
>>>>>
>>>>> {
>>>>>   "tableName" : ,
>>>>>
>>>>>
>>>>>   "fields: ["field1", field2", field3"]
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 24, 2016 at 2:59 PM, Lahiru Sandaruwan <lahi...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> POST for filterings is not an issue for special cases, as document
>>>>>> also clearly confirms.
>>>>>>
>>>>>> However, I think the decision has to be made on practical use cases.
>>>>>> This use case doesn't looks like a complex one. As Ayoma mention, it is a
>>>>>> good idea to implement two filters to include and exclude.
>>>>>>
>>>>>> Considering the practical use, if url length is not a problem(i.e.
>>>>>> practically user will not have a requirement to use around 400 columns 
>>>>>> per
>>>>>> search, if we average word length to 5), we should go for GET.
>>>>>>
>>>>>> Otherwise, we can go for POST.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> On Thu, Mar 24, 2016 at 9:01 AM, Sachith Withana <sach...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Gimantha,
>>>>>>>
>>>>>>> I think the point made by Udara is valid.
>>>>>>> Anyways if the user wants to get a selected number of columns, the
>>>>>>> chances are it won't exceed the url limit.
>>>>>>> ( due to the that number being low).
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Sachith
>>>>>>>
>>>>>>> On Thu, Mar 24, 2016 at 2:21 PM, Gimantha Bandara <giman..

Re: [Architecture] [Dev] [REST APIs][Analytics] GET request with a payload

[Frank Leymann]

We built a REST API Guideline document a few weeks ago.  Do you (Gimantha)
see that?  Its purpose is to help in designing REST APIs.  If you think it
would be helpful for you and your team, we can set up a call on this


Best regards,
Frank

2016-04-15 16:00 GMT+02:00 Manuranga Perera :

> 1) So {to}, {from}, {start}, {count} are resources ? They are not. How is
> this REST?
> 2) What are you searching in POST /analytics/search.
> tables, drilldown, everything? I can't see that in URL.
> 3) is POST /analytics/drilldown creating a drilldown or getting one ? If
> it's getting one, this is also wrong, should be get. If creating, why not
> PUT?
>
>
>
>
> On Mon, Apr 4, 2016 at 12:08 AM, Gimantha Bandara 
> wrote:
>
>> Please note that "fields" is changed to "columns" for consistency as in
>> APIs, "columns" is used.
>>
>> On Mon, Apr 4, 2016 at 9:08 AM, Gimantha Bandara 
>> wrote:
>>
>>> Hi all,
>>>
>>> Thank you for your suggestions! We are going to use GET with the query
>>> parameter "columns" to get the records filtered by a time range. So when
>>> only a selected set of columns/fields are needed, Following format can be
>>> used.
>>>
>>> *Get the records within a specific time range.*
>>>
>>> GET
>>> /analytics/tables/{tableName}/{to}/{from}/{start}/{count}?fields=field1,field2,field3
>>>
>>> *Drilldown and Search APIs*
>>>
>>> Additional JSON element will be added as following
>>>
>>> POST /analytics/drilldown or POST /analytics/search
>>>
>>> {
>>>   "tableName" : ,
>>>
>>>
>>>   "fields: ["field1", field2", field3"]
>>> }
>>>
>>>
>>>
>>>
>>> On Thu, Mar 24, 2016 at 2:59 PM, Lahiru Sandaruwan 
>>> wrote:
>>>
 Hi all,

 POST for filterings is not an issue for special cases, as document also
 clearly confirms.

 However, I think the decision has to be made on practical use cases.
 This use case doesn't looks like a complex one. As Ayoma mention, it is a
 good idea to implement two filters to include and exclude.

 Considering the practical use, if url length is not a problem(i.e.
 practically user will not have a requirement to use around 400 columns per
 search, if we average word length to 5), we should go for GET.

 Otherwise, we can go for POST.

 Thanks.

 On Thu, Mar 24, 2016 at 9:01 AM, Sachith Withana 
 wrote:

> Hi Gimantha,
>
> I think the point made by Udara is valid.
> Anyways if the user wants to get a selected number of columns, the
> chances are it won't exceed the url limit.
> ( due to the that number being low).
>
> Thanks,
> Sachith
>
> On Thu, Mar 24, 2016 at 2:21 PM, Gimantha Bandara 
> wrote:
>
>> Hi Sanjeewa,
>>
>> Thank you for the guidelines doc. The exact problem is discussed in
>> 10.2 in the above document. We will be filtering the record values in 
>> each
>> records by providing the required columns, so only those column values 
>> will
>> be returned with each record. According to the document the POST can be
>> used either for updating/creating a resource or for initializing a
>> processing function. In our case we will be simply retrieving records but
>> need to provide a filter for the record values. So from users 
>> perspective,
>> it will be doing some processing and returning filtered records.
>>
>> We can actually implement the following url, but we cannot exactly
>> say if it will exceed the url length limit.
>> GET /analytics/tables/{tableName}?columns=column1,column2]
>>
>> Or we can implement something like below,
>>
>> POST /analytics/tables/tableName/
>>
>> {
>>   from:
>>   to:
>>   start:
>>   count:
>>   columns :[c1,c2,c3]
>> }
>>
>> or
>>
>> POST /analytics/
>>
>> {
>>   tableName :
>>   from:
>>   to:
>>   start:
>>   count:
>>   columns :[c1,c2,c3]
>> }
>>
>> Considering the url length limit, I think the second option is
>> better. WDYT?
>>
>> On Thu, Mar 24, 2016 at 12:33 PM, Sanjeewa Malalgoda <
>> sanje...@wso2.com> wrote:
>>
>>> Hi Gimantha,
>>> Did you refer REST API guidelines document attached in this mail[1]
>>> in architecture mailing list.
>>> When we develop REST APIs please follow that document and if you see
>>> anything missed there please let us know.
>>>
>>> [1][Architecture] REST API Guidelines
>>>
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>> On Wed, Mar 23, 2016 at 8:01 PM, Gimantha Bandara >> > wrote:
>>>
 Hi all,


 We have a REST API in DAS to retrieve records in a specific table.
 It supports GET method with the following url format.

 

Re: [Architecture] [C5] Artifact deployment coordination support for C5

[Frank Leymann]

Sorry for jumping in so late in the thread:  is technology like HEAT/HOT
(OpenStack) or TOSCA (OASIS) too encompassing? I am happy to provide on
overview of their features...

I am not suggesting to use the corresponding implementations (they have
their pros/cons) but we may learn from the concepts behind them.


Best regards,
Frank

2016-04-14 12:06 GMT+02:00 Imesh Gunaratne :

>
>
> On Thu, Apr 14, 2016 at 1:35 AM, Manuranga Perera  wrote:
>
>> If an existing artifact needs to be updated or new artifacts needs to be
>>> added a new container image needs to be created.
>>
>> In this case, why can't we ask from Kub how many pods with new artifact
>> has been spun up? Why does this have to be updated at carbon kernel level
>> via JMS?
>>
>
> Carbon may not handle the rollout but it will need to inform an external
> entity the status of the deployed artifacts. K8S will only know about the
> container image that was used for the deployment, it will have no
> information on the artifacts deployed in the Carbon server.
>
>>
>>
>> On Thu, Apr 7, 2016 at 2:38 PM, Imesh Gunaratne  wrote:
>>
>>>
>>>
>>> On Thu, Apr 7, 2016 at 11:53 PM, Imesh Gunaratne  wrote:
>>>

 Hi Ruwan,

 On Thu, Mar 31, 2016 at 3:07 PM, Ruwan Abeykoon 
 wrote:

> Hi All,
> Do we really want artifact deployment coordination in C5?
> What is preventing us to build the new image with the new version of
> artifacts and let the k8s take care of deployment?
>

 You are absolutely correct! We may not do artifact synchronization in
 C5 rather artifacts will get packaged into the containers.

>>>
>>> I'm sorry C5 will also support none containerized deployments (VM,
>>> physical machines), still artifact synchronization will not be handled by
>>> Carbon.
>>>
>>> On Wed, Apr 6, 2016 at 8:03 PM, Akila Ravihansa Perera <
>>> raviha...@wso2.com> wrote:


 I've few concerns regarding artifact deployment coordination
  - Artifact versioning support. This is important to ensure consistency
 across a cluster

>>>
>>> Indded, but it may not relate to this feature I guess.
>>>
>>>
  - REST API to query the status. I'd rather go ahead with a REST API
 before a JMS based implementation. IMO it's much simpler and easy to use.

>>>
>>> A REST API might be needed in a different context, may be in a central
>>> monitoring server. In this context the design is to let servers publish
>>> their status to a central server. Otherwise it might not be feasible for a
>>> client to talk to each and every server and prepare the aggregated view.
>>>
>>>
  - Why don't we provide a REST API to deploy artifacts rather than
 copying files (whenever applicable)? We can immediately notify the client
 (via HTTP response status) whether artifact deployment was successful.

>>>
>>> Might not be needed for container based deployments.
>>>
>>> Thanks
>>>
>>>
 This feature is for monitoring the deployment status of the artifacts.
 If an existing artifact needs to be updated or new artifacts needs to be
 added a new container image needs to be created. Then a rollout should be
 triggerred (depending on the container cluster management system used).

 Thanks

>
> Cheers,
> Ruwan
>
> On Wed, Mar 30, 2016 at 2:54 PM, Isuru Haththotuwa 
> wrote:
>
>> Hi Kasun,
>>
>> On Wed, Mar 23, 2016 at 10:45 AM, KasunG Gajasinghe 
>> wrote:
>>
>>> Hi,
>>>
>>> Given several issues we discovered with automatic artifact
>>> synchronization with DepSync in C4, we have discussed how to approach 
>>> this
>>> problem in C5.
>>>
>>> We are thinking of not doing the automated artifact synchronization
>>> in C5. Rather, users should use their own mechanism to synchronize the
>>> artifacts across a cluster. Common approaches are RSync as a cron job 
>>> and
>>> shell scripts.
>>>
>>> But, it is vital to know the artifact deployment status of the nodes
>>> in the entire cluster from a central place. For that, we are providing 
>>> this
>>> deployment coordination feature. There will be two ways to use this.
>>>
>>> 1. JMS based publishing - the deployment status will be published by
>>> each node to a jms topic/queue
>>>
>>> 2. Log based publishing - publish the logs by using a syslog
>>> appender [1] or our own custom appender to a central location.
>>>
>> Both are push mechanisms, IMHO we would need an API to check the
>> status of a deployed artifacts on demand, WDYT?
>>
>>>
>>> The log publishing may not be limited to just the deployment
>>> coordination. In a containerized deployment, the carbon products will 
>>> run
>>> in disposable containers. But sometimes, the logs need to be backed 

Re: [Architecture] Circuit Breaker Pattern for MSF4J

[Frank Leymann]

The example about "just bad timing" that Sanjiva has, is a wonderful case
of the "out-of-spec"-errors
that Nygard has in mind.

I think we can abstract this case into issues in systems based on
optimistic concurrency control, i.e.
systems in which you expect concurrency conflicts to occur only rarely, and
if your retry the conflict
is gone. A wonderful use case of the CB pattern.

But what do we recommend for "critical requests" rejected by the CB: should
the client queue them
persistently? Should a robust implementation of a CB queue such requests
and retry them? How does
a client indicate such requests in the latter case, and how to cope with
response a client receives
"out of band" if the CB repeats such a request? etc


Best regards,
Frank

2016-04-03 3:18 GMT+02:00 Sanjiva Weerawarana <sanj...@wso2.com>:

> :-). I think there are two things we should show:
> - one can do circuit breaker (CB) with MSF4J
> - when should you use it
>
> Wrapping of DB calls in Hystrix may indeed be appropriate in some cases,
> but not commonly. Second, at that level its really not about MSF4J at all.
>
> If we show a sample that's a service invoking another service or some
> random Java code invoking a service using CB then that's better IMO. We
> should mention when it is indeed appropriate to use as a fancy try catch.
>
> For example, in the registry code we have scenarios where there can be
> transient DB issues because of concurrent access. Should we use CB there to
> make that code more resilient? Almost always the transaction "failure" in
> those cases is a temporary issue and a non-issue ... just bad timing.
>
> If we can make our code better with CB we absolutely MUST do it. The key
> is to provide guidance on when its appropriate to do it!
>
> Sanjiva.
>
> On Sat, Apr 2, 2016 at 8:24 AM, Afkham Azeez <az...@wso2.com> wrote:
>
>> Well one of your responses indicated that the the blogpost suggests
>> wrapping all DB calls in circuit breakers, and Frank's response indicated
>> that it is suggesting wrapping all calls to external systems in circuit
>> breakers.  If it can confuse such brilliant minds, I guess it could mislead
>> an average developer. That blogpost was on how to implement the pattern in
>> the context of MSF4J using Hystrix, and I think it should have been
>> preceded with a blogpost introducing the pattern & explaining where it is
>> applicable. Sorry for the confusion again. I will work on a separate post.
>>
>> Thanks
>> Azeez
>>
>> On Fri, Apr 1, 2016 at 11:59 PM, Sanjiva Weerawarana <sanj...@wso2.com>
>> wrote:
>>
>>> Azeez, asking questions and asking to understand what the purpose of
>>> some code is not a criticism.
>>>
>>> Of course there should be a sample! I only asked about it because to me
>>> a client side sample made more sense - and then it went into a discussion
>>> of when this should be used etc..
>>>
>>> I would not only put the blog back but also use the opportunity to
>>> explain to "lazy developers" when and where one should use a
>>> circuitbreaker. That's 1000x more valuable than just the code on how to do
>>> it.
>>>
>>> Sanjiva.
>>>
>>> On Thu, Mar 31, 2016 at 8:00 PM, Afkham Azeez <az...@wso2.com> wrote:
>>>
>>>> The blog post has been removed. Sorry for all the confusion. This was
>>>> only done as part of the agreement we had during last week's meeting to
>>>> demonstrate certain features such as Spring support, JPA support, support
>>>> for patterns etc. in order to help developers understand how to implement
>>>> certain stuff with MSF4J. Our target community of MSF4J is primarily
>>>> developers, and developers like to refer to sample code segments in order
>>>> to proceed with implementing their solutions. We lazy developers love to
>>>> Google search for code segments, e.g. JDBC connection example, and then
>>>> copy, paste and modify those segments. What I have been trying to do with
>>>> the series of blogposts is to make available such code segments developers
>>>> could readily use. Since this post and mail thread has generated a lot of
>>>> negative feeling and confusion, I think it is better to get rid of this
>>>> controversial blog post.
>>>>
>>>> Thanks
>>>> Azeez
>>>>
>>>> On Thu, Mar 31, 2016 at 6:54 PM, Afkham Azeez <az...@wso2.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 31, 2016 at 5:03 PM, Fr

Re: [Architecture] Circuit Breaker Pattern for MSF4J

[Frank Leymann]

Yes, all the stability patterns (that Nygard describes, the circuit breaker
being just one of them)
is not associated with microservices, but applies to all distributed
applications. In fact, Nygard's
book has been published in 2007, lng before the microservice discussion
came up ;-)

Applying these patterns to each and any invocation would be a complete
misuse. And it will very likely
result in performance hits...  The circuit breaker pattern, for example, is
recommended to be applied
to "out-of-spec errors", i.e. errors that you don't cover in the spec
(because the errors are too unlikely ;-))
of the invoked function or in the spec of the program making the call (aka
client). Often, these are errors
that never happen during testing unless you really set up a badly behaving
test environment. And it has
impact on the design/implementation of the circuit breaker itself (or
clients), for example "critical work"
not accepted by the circuit breaker has be queued (by the client? by the
circuit breaker?) for later use
(automatic replay?).

Thus, using one of the stability patterns is a (architecture/design)
decision with implications on other
components architecture/design.

Documenting a sample use of the circuit breaker pattern should also discuss
these ramifications.


Best regards,
Frank

2016-03-31 9:12 GMT+02:00 Sanjiva Weerawarana :

> Agreed. However I had understood that the circuit breaker pattern was
> advocated primarily for service clients in MSA (and of course it has
> nothing do with being micro).
>
> The general story of better failure handling applies to all code and is of
> course not MSA specific.
>
> Anyway .. Sample is fine.
> On Mar 31, 2016 9:19 AM, "Afkham Azeez"  wrote:
>
>>
>>
>> On Thu, Mar 31, 2016 at 9:04 AM, Sanjiva Weerawarana 
>> wrote:
>>
>>> That's why I said "fancy try catch" :-).
>>>
>>> However, are you SERIOUSLY saying that we for example should be wrapping
>>> all our DB access code in this stuff? If not who exactly should be doing
>>> this? What are the perf implications?
>>>
>>
>> No I am not saying that. However, there will be use cases where people
>> want to use this pattern and this is a simplified sample that demonstrates
>> how to use this pattern. In Nygards book about how an SQL statement
>> execution failure resulted in an entire checking in system in an airline
>> failing because the failure propagated is a good example of uncontrolled
>> failure propagation (Release It, Chapter 2: Case study: The exception that
>> grounded an airline, for those of you who have the book). So my example was
>> somewhat inspired by that case study and is highly simplified.
>>
>> If a sample is too complicated, people get lost in the implementation
>> details rather than seeing how the core concept or pattern is implemented.
>> I certainly can implement another sample which demonstrates client->service
>> or service->service calls, it certainly would add more code but the core
>> concept demonstrated would be the same.
>>
>>
>>
>>>
>>> Of course wrapping remote service calls in this stuff makes sense -
>>> great way to adjust to transient issues. In that case the overhead is
>>> heavily masked by the latency - I'm not so convinced that is the case for
>>> transactional JDBC calls but maybe it is. In that case WE must use it
>>> internally.
>>>
>>> Sanjiva.
>>>
>>> On Thu, Mar 31, 2016 at 8:53 AM, Afkham Azeez  wrote:
>>>
 Equating these fault tolerance patterns to Java 8 Optional or
 try-catch, is a highly oversimplified view. What Hystrix and these patterns
 provides is a framework for building fault tolerant systems. Something that
 is useful in the toolkit of an architect & developer.

 On Thu, Mar 31, 2016 at 8:36 AM, Sanjiva Weerawarana 
 wrote:

> This is almost kinda like that stupid new Java8 thing of "we removed
> null by wrapping it in a fancy object" ;-).
>
> On Thu, Mar 31, 2016 at 8:32 AM, Sanjiva Weerawarana  > wrote:
>
>> So this is not what I expected the real use case to be ... this is
>> basically a fancy try catch.
>>
>> Don't we want to show a client side example?
>>
>> On Thu, Mar 31, 2016 at 6:28 AM, Afkham Azeez  wrote:
>>
>>> Timeout is related to the actual operation taking more time than
>>> anticipated. In such a case, without waiting indefinitely, the operation
>>> times out and the fallback of the Hystrix command will be invoked. The
>>> circuit will be open for a fixed period of time configured by
>>> https://github.com/Netflix/Hystrix/wiki/Configuration#circuitBreaker.sleepWindowInMilliseconds
>>>
>>> On Thu, Mar 31, 2016 at 2:53 AM, Harshan Liyanage 
>>> wrote:
>>>
 Hi Azeez,

 Does this timeout in open state occurs in exponentially (first
 timeout in 10 secs, 

Re: [Architecture] Data Isolation level for Data from APIM and IoT? Tenant vs. User

[Frank Leymann]

Sorry for jumping into the discussion late (or even too late).  I try to
understand the discussion by drawing analogies to DBMS - maybe that's wrong
and I miss the point... If I am right, what you decided in the meeting is
fully in line with what DBMS are doing :-)

In Srinath's summary, list item (2): The API then actually will be in
charge of implementing access control. Because the API needs to decide who
can see which data. Writing an API accessing data is like writing a SQL
program accessing a database. Then, we are asking an SQL program to
implement access control by itself, isn't it? This is cumbersome, and
likely each product has to implement very similar mechanisms.

In Srinath's summary, list item (1): This sounds like established practice
in DBMS. When a SQL programmer writes a program, she must have all the
access control rights to access the DBMS. The final program is than subject
to access control mechanism w.r.t. to the users of the program: whoever is
allowed to use the program somehow inherits the access writes of the
programmer (but only in context of this program). When identifying the SQL
programmer with the tenant (or tenant admin), this is what (1) of the
summary decided, correct?

>From Srinath's summary: "*Also this means, we will not support users
providing their own analytics queries. Only tenant admins  can provide
their own queries.*"  Again, identifying tenant admins with SQL
programmers, that's exactly the paradigm.


Best regards,
Frank

2016-03-31 10:32 GMT+02:00 Srinath Perera :

> We had a meeting. Participants: Sanjiva, Sumedha, NuwanD, Prabath, Srinath
> (Prabath please list others joined from Trace)
>
> Problem: Bob writes a API and publish it API manager. Then Alice
> subscribes to the API and write an mobile APP. Charlie uses the mobile App,
> which results in an API call. We need to track the API calls via DAS. And
> when Bob, Alice, and possibly Charlie come to the dashboard server, they
> should possibly see the transaction from their view.
>
> Challenge is that now there is no clear user in the above transaction.
> Rather there is three. So we cannot handle this generically at the DAS
> level via a user concept. Hence, the API manager needs to put the right
> information when it publish data to DAS and show data only to relevant
> parties when it showing and exposing data.
>
>
> Solution
>
> [image: SecuirtyLayers.png]
>
>1. We will keep DAS in the current state with support for tenants
>without support for users. It is aware about tenant and provide full
>isolation between tenant. However, it does not aware about users.
>2. Each product will write an extended receiver and DAL layer as, that
>will build an API catered for their use cases. This API will support login
>via OAuth tokens. Since they know the fields in the  tables that has user
>data init, then can filter the data based on the user.
>3. We will run the extended DAL layers and receivers in DAS, and they
>will talk to DAL as an OSGI call.
>4. Above layers will assume that users have access to OAuth token. In
>APIM use cases, APIM can issue tokens, and in IoT use cases, APIM that runs
>in the IoT server can issue tokens.
>
>
> Also this means, we will not support users providing their own analytics
> queries. Only tenant admins  can provide their own queries.
> As decided in the earlier meeting,  We need APIM and IOT Server to be able
> to publish events as "system user", but ask DAS to place data under Ann's (
> related user) account.
>
> Please add anything I missed.
>
> --Srinath
>
>
>
>
> On Tue, Mar 29, 2016 at 11:53 AM, Srinath Perera  wrote:
> >
> > I have scheduled a meeting tomorrow to discuss this.
> >
> > --Srinath
> >
> > On Tue, Mar 29, 2016 at 11:44 AM, Sachith Withana 
> wrote:
> >>
> >> Hi all,
> >>
> >> I do believe it would be of great value to incorporate user level data
> isolation for DAS.
> >>
> >> Having said that though, it wouldn't be practical to provide a complete
> permission platform to DAS that would suffice all the requirements of APIM
> and IOT.
> >>
> >> IMO, we should provide some features that would help individual
> products build their own permission platform that caters to their
> requirements.
> >>
> >> Thanks,
> >> Sachith
> >>
> >> On Tue, Mar 29, 2016 at 10:38 AM, Nuwan Dias  wrote:
> >>>
> >>> Please ignore my reply. It was intended for another thread :)
> >>>
> >>> On Mon, Mar 28, 2016 at 4:26 PM, Nuwan Dias  wrote:
> 
>  Having to publish a single event after collecting all possible data
> records from the server would be good in terms of scalability aspects of
> the DAS/Analytics platform. However I see that it introduces new challenges
> for which we would need solutions.
> 
>  1. How to guarantee a event is always published to DAS? In the case
> of API Manager, a request has multiple exit points. Such as 

Re: [Architecture] Session Affinity Alternatives

[Frank Leymann]

Hi Srinath,

I am not at all arguing in favor of session replication or session
persistence either.

I think in many situation it's fine that a client fails when a session
dropped and the client has to reconnect explicitly - this is option A.

Otherwise (as a second option B), "state transfer" is to be used.  And this
can be achieved by (i) including the full session state in the message
(REST-style), or (ii) including only the session id in the message and hold
the full state in a DB (which is used for session restore if server
affinity has been lost).

Option B.(ii) has quite a bunch of disadvantages: a DB is involved with
obvious performance impact; garbage collection of sessions no longer
needed; DBMS as single point-of-failure;



Best regards,
Frank

2016-03-18 7:08 GMT+01:00 Srinath Perera <srin...@wso2.com>:

> Hi Frank,
>
> Proposal is when the session parameter has changed, framework (e.g.
> Servelt runtime, or MSS framework) will write the update to the disk
> asynchronsly.
>
> Since we are a middleware platform, impact of losing a session depends on
> the kind of the application end user is running.
>
> However, AFAIK session replication or pressitance that is in WSO2 AS was
> rarely used. ( Azeez, please correct me if I am wrong).
>
> --Srinath
>
> On Thu, Mar 17, 2016 at 11:42 PM, Frank Leymann <fr...@wso2.com> wrote:
>
>> Sorry for jumping in late in the discussion
>>
>> Session affinity in general is bad (scalability, HA) - I guess that's
>> what we all agree on.  But in certain scenarios, sticky sessions may be
>> fine.  Thus, what is the underlying scenario in the case we discuss?
>>
>> As far as I understand, persisting session state requires the application
>> to be aware of this. Or is the proposal that provide an environment that
>> reconstructs the session state on behalf of the application?  As Srinath
>> points out we are loosing data if a session aborts and the application is
>> not a transaction: is that critical in our scenario?
>>
>>
>> Best regards,
>> Frank
>>
>> 2016-03-17 10:21 GMT+01:00 Srinath Perera <srin...@wso2.com>:
>>
>>> Let's not do session replication. It is very hard to make it work IMO.
>>>
>>> I would like to propose a variation to Azeez's version.
>>>
>>> We can do local session + session affinity + asynchronously save the
>>> session state to a DB
>>>
>>> If a node cannot find the session, it will go and reload session from
>>> the DB. ( This should happen if the node has failed, or we have moved
>>> session away due to high load).
>>>
>>> With this model, there is a chance that you might loose last update to
>>> the session. However, that will be very rare. I would keep "asynchronously
>>> save the session state to a DB" off by default, so user will enable it for
>>> complex scenarios.
>>>
>>> --Srinath
>>>
>>>
>>>
>>> On Sat, Mar 12, 2016 at 6:25 PM, Afkham Azeez <az...@wso2.com> wrote:
>>>
>>>> Of course the simplest solution is similar to what Tomcat does, local
>>>> sessions (no replication) & in a cluster, have session affinity configured
>>>> at the load balancer, so that should be the default. If the node that had
>>>> the session dies, the clients connected to that instance would get errors
>>>> or have to login again. For HA deployments, we would need session
>>>> replication or session persistence.
>>>>
>>>> On Sat, Mar 12, 2016 at 12:58 PM, Sanjiva Weerawarana <sanj...@wso2.com
>>>> > wrote:
>>>>
>>>>> Azeez we cannot have a model where every simple server (cluster)
>>>>> deployment requires Redis.
>>>>>
>>>>> Please indicate what you think the right solution is .. its not clear
>>>>> to me.
>>>>>
>>>>> On Thu, Mar 10, 2016 at 7:34 PM, Afkham Azeez <az...@wso2.com> wrote:
>>>>>
>>>>>> Storing everything as cookies may not work always  and there could be
>>>>>> sensitive runtime data that you don't want to save on the browser. In
>>>>>> addition, when it comes to Java programming models, using the HTTP 
>>>>>> session
>>>>>> to store serializable objects is the natural way of programming. Yes, 
>>>>>> your
>>>>>> solution would work for certain cases, but it doesn't cover all cases.
>>>>>>
>>>>>> On Thu, Mar 10, 2016 at 6:48 PM, Joseph 

Re: [Architecture] Session Affinity Alternatives

[Frank Leymann]

Sorry for jumping in late in the discussion

Session affinity in general is bad (scalability, HA) - I guess that's what
we all agree on.  But in certain scenarios, sticky sessions may be fine.
Thus, what is the underlying scenario in the case we discuss?

As far as I understand, persisting session state requires the application
to be aware of this. Or is the proposal that provide an environment that
reconstructs the session state on behalf of the application?  As Srinath
points out we are loosing data if a session aborts and the application is
not a transaction: is that critical in our scenario?


Best regards,
Frank

2016-03-17 10:21 GMT+01:00 Srinath Perera :

> Let's not do session replication. It is very hard to make it work IMO.
>
> I would like to propose a variation to Azeez's version.
>
> We can do local session + session affinity + asynchronously save the
> session state to a DB
>
> If a node cannot find the session, it will go and reload session from the
> DB. ( This should happen if the node has failed, or we have moved session
> away due to high load).
>
> With this model, there is a chance that you might loose last update to the
> session. However, that will be very rare. I would keep "asynchronously save
> the session state to a DB" off by default, so user will enable it for
> complex scenarios.
>
> --Srinath
>
>
>
> On Sat, Mar 12, 2016 at 6:25 PM, Afkham Azeez  wrote:
>
>> Of course the simplest solution is similar to what Tomcat does, local
>> sessions (no replication) & in a cluster, have session affinity configured
>> at the load balancer, so that should be the default. If the node that had
>> the session dies, the clients connected to that instance would get errors
>> or have to login again. For HA deployments, we would need session
>> replication or session persistence.
>>
>> On Sat, Mar 12, 2016 at 12:58 PM, Sanjiva Weerawarana 
>> wrote:
>>
>>> Azeez we cannot have a model where every simple server (cluster)
>>> deployment requires Redis.
>>>
>>> Please indicate what you think the right solution is .. its not clear to
>>> me.
>>>
>>> On Thu, Mar 10, 2016 at 7:34 PM, Afkham Azeez  wrote:
>>>
 Storing everything as cookies may not work always  and there could be
 sensitive runtime data that you don't want to save on the browser. In
 addition, when it comes to Java programming models, using the HTTP session
 to store serializable objects is the natural way of programming. Yes, your
 solution would work for certain cases, but it doesn't cover all cases.

 On Thu, Mar 10, 2016 at 6:48 PM, Joseph Fonseka 
 wrote:

> I think we should go with 3 to keep things simple.
>
> To solve HA problem ( without session persistence or replication ).
>
> 1. Use SSO to authenticate the user.
> 2. Use the session to store the claims return from IdP. ( Ex user_id,
> roles )
> 3. DO NOT store app specific data on the session instead use cookies,
> local storage in the browser.
> 4. In case the container get terminated and user get redirected to
> another container it will initiate a SSO flow and repopulate a new session
> with user claims. Then the app can continue as normal.
>
> WDYT?
>
> Regards
> Jo
>
>
>
>
>
>
> On Thu, Mar 10, 2016 at 2:21 PM, Lakmal Warusawithana  > wrote:
>
>> My order of preference - 3, 2.
>>
>> For simple deployment, session affinity work fine. But if we want to
>> deploy large distributed deployment with HA, we need to go for option 2.
>>
>> On Thu, Mar 10, 2016 at 10:41 AM, Afkham Azeez 
>> wrote:
>>
>>> I forgot to add earlier our design decision about using Redis to
>>> store sessions; the Kubernetes scheduler may decide to kill & container 
>>> &
>>> start up different instance if its health checks detects problems. So in
>>> such a case, if we had used affinity, the clients connected to that
>>> instance which was killed will lose their session data. So as a best
>>> practice they recommend using an external service with session 
>>> persistence.
>>> Of course this is not the simplest case, so yes, the default should be
>>> local sessions with affinity.
>>>
>>> On Thu, Mar 10, 2016 at 10:23 AM, Afkham Azeez 
>>> wrote:
>>>
 Petstore is #2. We use the Redis service to store the session. For
 an HA deployment such a model is required, but yes, for the simplest 
 case,
 we can have local sessions and then use session affinity capabilities 
 of
 the LB.

 On Thu, Mar 10, 2016 at 10:17 AM, Sanjiva Weerawarana <
 sanj...@wso2.com> wrote:

> Manu, #1 is not a no-session story. What Azeez has done for the
> petstore is a model 

Re: [Architecture] Circuit Breaker Pattern for MSF4J

[Frank Leymann]

I do have a more general question: what justifies the focus on the "circuit
breaker" pattern at all? It is just one patter to solve recurring problems
with stability, i.e. other patterns are there too that are important (e.g.
"timeout" - see Michael Nygard's nice book).

Thus, what are the criteria that guide our decisions in selecting some
patterns for implementations, some others for leaving out?


Best regards,
Frank

2016-03-12 8:26 GMT+01:00 Sanjiva Weerawarana :

> I don't understand what server side circuit breaker means. How does the
> server adjust itself? Where's that bit of logic running?
>
> IMO this is not needed in a container world.
>
> On Fri, Mar 11, 2016 at 4:38 PM, Afkham Azeez  wrote:
>
>> Yes, that is client side circuit breaker. What Aruna is implementing is
>> server side circuit breaker. Yes, we need both.
>>
>> On Fri, Mar 11, 2016 at 4:04 PM, Lakmal Warusawithana 
>> wrote:
>>
>>> Did you looked at [1]
>>>
>>> Netflix Hystrix  is an incredibly
>>> useful library for writing code that invokes remote services. Hystrix times
>>> out calls that exceed the specified threshold. It implements a *circuit
>>> breaker* pattern, which stops the client from waiting needlessly for an
>>> unresponsive service. If the error rate for a service exceeds a specified
>>> threshold, Hystrix trips the circuit breaker and all requests will fail
>>> immediately for a specified period of time. Hystrix lets you define a
>>> fallback action when a request fails, such as reading from a cache or
>>> returning a default value. If you are using the JVM you should definitely
>>> consider using Hystrix.
>>>
>>> [1] https://github.com/Netflix/Hystrix
>>>
>>> On Fri, Mar 11, 2016 at 2:42 PM, Aruna Karunarathna 
>>> wrote:
>>>
 Hi Devs,

 *Scenario*

 The deployed services in a MSF4J may fail to serve the requests due to
 various factors. e.g,
 1. Less resources in the server.
 2. High Load in the server
 3, Some services take more time to respond etc.

 In this kind of a situation, if the server is getting requests though
 there is no resources to serve those requests, and eventually the server
 will get unusable.

 *Solution*

 The Circuit Breaker design pattern can save the server from above
 scenarios, The typical design can be illustrated as in the following
 diagram.


 So as in the above diagram, when number of failures of a particular
 resource exceeds the Max Failure Count, then the state of that resource is
 moved to the open state with a timeout value (Trip Breaker). At this point
 the requests coming to the server is routed back without passing the
 internal to process further.

 After the timeout has reached, the state is moved to Half-Open state,
 and if the consecutive request pass to the server to process (Attempt
 Reset), if success then close the circuit (Reset Breaker), If fail then
 again move the state to the Open with a timeout value (Trip Breaker).

 Any thoughts, suggestions regarding the above approach?

 References
 [1].
 http://www.javaworld.com/article/2824163/application-performance/stability-patterns-applied-in-a-restful-architecture.html?page=2
 [2].
 http://ssagara.blogspot.com/2015/05/timeout-and-circuit-breaker-pattern-in.html
 [3]. https://pragprog.com/book/mnee/release-it


 Regards,
 Aruna
 --

 *Aruna Sujith Karunarathna *
 WSO2, Inc | lean. enterprise. middleware.
 #20, Palm Grove, Colombo 03, Sri Lanka
 Mobile: +94 71 9040362 | Work: +94 112145345
 Email: ar...@wso2.com | Web: www.wso2.com


 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Lakmal Warusawithana
>>> Director - Cloud Architecture; WSO2 Inc.
>>> Mobile : +94714289692
>>> Blog : http://lakmalsview.blogspot.com/
>>>
>>>
>>
>>
>> --
>> *Afkham Azeez*
>> Director of Architecture; WSO2, Inc.; http://wso2.com
>> Member; Apache Software Foundation; http://www.apache.org/
>> * *
>> *email: **az...@wso2.com* 
>> * cell: +94 77 3320919 <%2B94%2077%203320919>blog: *
>> *http://blog.afkham.org* 
>> *twitter: **http://twitter.com/afkham_azeez*
>> 
>> *linked-in: **http://lk.linkedin.com/in/afkhamazeez
>> *
>>
>> *Lean . Enterprise . Middleware*
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, CEO & Chief Architect; WSO2, Inc.;  http://wso2.com/
> email: 

Re: [Architecture] [BPMN] Implementing correlation support for BPMN Rest API

[Frank Leymann]

Thanks a lot, Firzhan, for letting me know!  I think that's the right way
to go :-)


Best regards,
Frank

2015-12-22 14:11 GMT+01:00 Firzhan Naqash :

> Hi Frank,
>
> After having discussion with Nandika, Chathura and Amal, it was decided
> not to support multiple receiving message events in parallel.
>
> Therefore we will be removing the query attribute "*activityId*" from the
> request message.
>
> Regards,
> Firzhan
>
>
> --
> *Firzhan Naqash*
> Senior Software Engineer - Integration Platform Team
> WSO2 Inc. http://wso2.com
>
> email: firz...@wso2.com
> mobile: (+94) 77 9785674 <%28%2B94%29%2071%205247551>*|
> blog: http://firzhanblogger.blogspot.com/
>   *
> *twitter: https://twitter.com/firzhan007
>  | linked-in: 
> **https://www.linkedin.com/in/firzhan
> *
>
> On Mon, Dec 21, 2015 at 7:21 PM, Firzhan Naqash  wrote:
>
>>
>>
>> Hi Frank,
>>
>> Please find my comments inline.
>>
>> The process model you have drawn enables multiple receiving message
>> events in parallel. According to the BPMN 2.0 spec this is not allowed for
>> key-based correlation (i.e. the correlation mechanism similar to BPEL
>> correlation sets); but it is allowed for predicate based correlation (often
>> used in collaborations).  I assume that we are not dealing with
>> collaborations here. Thus, only one of the events/tasks will receive the
>> message - you see mainly two ways in which this is handled by an engine,
>> (i) the engine randomly assigns the message, or (ii) a runtime error
>> occurs. Not sure what our implementation does
>>
>>
>> Yeah. When we enable multiple message receiving events in parallel, BPMN
>> engine will throw an error. But when you provide the activity id ( Unique
>> id that we use in the process definition model to identify an
>> event receiver) along with the message, BPMN engine can determine the event
>> receiver to be executed. On the other hand, if we have only single
>> message receiving event, we don't have to provide the activity id.
>>
>>
>> Why are the correlation-keys not sufficient?  When a process is
>> instantiated it gets tightly coupled with a process model, i.e. a version
>> of a certain process model; and all correlation-keys associated with that
>> instance are coupled with that version.
>>
>>
>> Exactly, we apply the correlation-keys to identify the process instances.
>> But in addition to that clients can use the *processInstanceVariables* 
>> variable
>> to add/update their user-defined/business variables to the process instance
>> during the process instance execution and it's not being used to filter
>> out the process instances.
>>
>>
>> Regards,
>> Firzhan
>>
>>
>>
>>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [BPMN] Implementing correlation support for BPMN Rest API

[Frank Leymann]

The process model you have drawn enables multiple receiving message events
in parallel. According to the BPMN 2.0 spec this is not allowed for
key-based correlation (i.e. the correlation mechanism similar to BPEL
correlation sets); but it is allowed for predicate based correlation (often
used in collaborations).  I assume that we are not dealing with
collaborations here. Thus, only one of the events/tasks will receive the
message - you see mainly two ways in which this is handled by an engine,
(i) the engine randomly assigns the message, or (ii) a runtime error
occurs. Not sure what our implementation does.  But many people (including
me) consider a process model that specifies concurrent consumption of the
same message a severe modeling error...


Why are the correlation-keys not sufficient?  When a process is
instantiated it gets tightly coupled with a process model, i.e. a version
of a certain process model; and all correlation-keys associated with that
instance are coupled with that version. Correlation-keys don't come out of
the blue: the firsts correlation keys used to instantiate the process
instance are "arbitrary" but after that correlation keys "must fit" -
admittedly, the BPMN spec is not precise on it, but BPEL (that is the
template for that) is more precise.

Maybe I am missing the point what we want to achieve, i.e. that we need all
the information Firzhan sketches...


Best regards,
Frank

2015-12-16 5:40 GMT+01:00 Chathura Ekanayake :

>
>
>
>
>>
>>
>> We need to have the process definition id, in case there are multiple
>> versions of the same process definition exists with in the engine. Because
>> of this we are having it as an optional parameter.
>>
>
> I agree with that. But can we make message name optional? We use process
> definition id, activiti id, correlation variables, etc to locate the
> execution. Once an execution is located, I think we need to provide the
> message name when triggering the message event.
>
>
>>
>>
>>
>> On Mon, Dec 14, 2015 at 2:25 PM, Chathura Ekanayake 
>> wrote:
>>
>>> Hi Firzhan,
>>>
>>>
>>> *processDefinitionKey/processDefinitionId/messageName* (compulsory)

 Either one relevant property out of three should be specified in the
 request.

>>>
>>> Shouldn't we provide messageName or signalName irrespective of the
>>> availability of process definition key or id. Once we queried an execution,
>>> I think we need either a message name or a signal name to trigger the
>>> receive event. Please check with API.
>>>
>>>
>>>

 *activityId *(optional)

 This property is required when there are more than one receivers
 waiting for the same message/signal in different execution flows.



 ​​
 In the above process flow,  all three or two of the execution flows
 might be waiting for the same message.

 *action *(compulsory)

 actions can be either messageEventRecieved/signalEventRecieved/signal.

 *signalName* (optional)

 If we have any signal related actions, then *signalName* has to be
 specified.


 *variables* (optional)

 This holds the task specific local variables that can be used to query
 and filter the relevant process instances.

 *processInstanceVariables* (optional)

 All the instance variables except correlation variables can be
 mentioned here.


 *correlationVariables* (compulsory)

 All the correlation variables should be mentioned here. By default it
 performs the equal operation of that variables.

 *variables* and *processInstanceVariables *can be used to speed up the
 querying process and the correlation variables should be unique across the
 process instances.

>>>
>>> Correlation variables are the ones used to query the relevant execution.
>>> Process instance variables are used to pass in new data values with the
>>> message. What is the purpose of the first "variables" parameter?
>>>
>>> Regards,
>>> Chathura
>>>
>>>
>>>
>>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] API Manager REST API with tier grouping feature

[Frank Leymann]

Hi Malintha,

sorry for the late response.  A post is used on a collection to add a new
resource to this collection. While /tiers is for sure a collection, the
question is whether /tiers/{tier-level} is a collection too.  Even if it
is, it sounds a bit strange to me to add a tier to a collection that
corresponds to a tier-level.

Instead, I assume that the data model of a tier contains more than just a
tier-level attribute, right?  If tier-level is one of many properties of a
tier, I suggest that we POST to /tier...


Best regards,
Frank

2015-12-01 13:10 GMT+01:00 Malintha Amarasinghe <malint...@wso2.com>:

> Hi Nuwan,
>
> Thanks for the clarification.
>
> Hi Frank,
>
> Yes, would that need to be changed for POST /tiers/{tier-level}? Or shall
> we keep the previous one (/tiers ) only for POST and identify the tier
> level from the request body?
>
> Thanks.
>
>
> On Tue, Dec 1, 2015 at 5:32 PM, Frank Leymann <fr...@wso2.com> wrote:
>
>> Just to double-check:  but we still have a POST /tiers to add a new tier
>> to the collection, right?
>>
>>
>> Best regards,
>> Frank
>>
>> 2015-12-01 11:50 GMT+01:00 Nuwan Dias <nuw...@wso2.com>:
>>
>>> I think the group param should be mandatory. Therefore there will not be
>>> a GET /tiers, but instead a GET /tiers/{level} only.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Tue, Dec 1, 2015 at 3:17 PM, Malintha Amarasinghe <malint...@wso2.com
>>> > wrote:
>>>
>>>> Hi Nuwan, Sanjeewa and Joe,
>>>>
>>>> Thanks a lot for all the suggestions.
>>>>
>>>> I have a small doubt for using the group as part of the path.
>>>>
>>>> Lets say we use GET /tiers/api/{tier-id} to get a single API tier by
>>>> its id (actually Name). Then, are we exposing the resource /tiers alone
>>>> too?  If we do, are we returning the tier groups for GET /tiers? In this
>>>> case, returning tiers will not be appropriate IMO as the immediate
>>>> sub-resource is not a tier, but a tier type. Or can we just make the group
>>>> parameter mandatory?
>>>>
>>>> Thank you.
>>>> Malintha
>>>>
>>>> On Tue, Dec 1, 2015 at 11:54 AM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Dec 1, 2015 at 11:21 AM, Joseph Fonseka <jos...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> IMO if we have multiple tier files a path param would be more
>>>>>> suitable. If we have only one tier file and the group(level) is an
>>>>>> attribute then we could have use a query param.
>>>>>>
>>>>>> Any specific reason to have a tier file for each level ? Rather than
>>>>>> having an attribute to group tiers. Or for each tier specifying 
>>>>>> application,
>>>>>> API and resource level throttling separately.
>>>>>>
>>>>>
>>>>> Having everything on a single file makes the tier definitions very
>>>>> noisy. Having it separately makes it very clean and easy to manage.
>>>>>
>>>>> For example, the API tiers now have attributes related to billing
>>>>> information. These won't make sense for Application level and Resource
>>>>> level tiers. So having them in separate files makes sense IMO. In addition
>>>>> to that having them separately allows us to perform access control for
>>>>> those resources as well.
>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Jo
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Dec 1, 2015 at 10:06 AM, Sanjeewa Malalgoda <
>>>>>> sanje...@wso2.com> wrote:
>>>>>>
>>>>>>> What we agreed last week is let users to fetch tiers based on type,
>>>>>>> It can be either path param like mentioned above or query param
>>>>>>> tiers?tier-level=application.
>>>>>>>
>>>>>>> Existing users will get same set of tiers for application, API and
>>>>>>> resource.
>>>>>>> But new deployments and people who willing to have different levels
>>>>>>> can change them as per requirements.
>>>>>>> Having same names in application, API and resource level with
&g

Re: [Architecture] Forceful queue/topic subscription deletion for Message Broker

[Frank Leymann]

+1
I would even say stronger "...we MUST give a way..."


Best regards,
Frank

2015-12-03 11:01 GMT+01:00 Srinath Perera :

> If the user must go to the node where subscription is made to disconnect
> the subscription, we might need to give a way for a user to find which node
> has what subscriptions.
>
> --Srinath
>
> On Thu, Dec 3, 2015 at 11:36 AM, Ramith Jayasinghe 
> wrote:
>
>> I propose,
>>  1) user cant disconnect consumers in another nodes. ( simplifies the
>> approach).
>>  2) there need to be a permission around it.
>>  3) it could for any subscriber ( may be lets leave out MQTT for a bit)
>> whose misbehaving.
>>
>>
>> On Thu, Dec 3, 2015 at 11:31 AM, Sajini De Silva  wrote:
>>
>>> Hi Hasitha,
>>>
>>> We haven't implemented the MQTT UI yet. Therefore IMO its better not to
>>> implement this feature for MQTT for now. We can consider it when
>>> implementing MQTT UI in our major release. WDYT?
>>>
>>> Thank you,
>>> Sajini
>>>
>>> On Thu, Dec 3, 2015 at 11:19 AM, Hasitha Hiranya 
>>> wrote:
>>>
 Hi,

 There is a feature request that Message Broker should support to
 forcefully disconnect a subscriber. This means, server should be able to
 disconnect misbehaving subscribers. Server has a control over it.

 Steps to do this would be

 1. Find a way to disconnect the socket from mina transport level.
 2. Send a message to Andes core to delete (disconnect) the subscriber.

 At step two the node that is disconnecting  the socket, will broadcast
 a Hazelcast message that this subscriber is closed.

 With above implementation steps, a limitation is introduced as "you can
 only disconnect the subscribers originated to that node only". For example,
 say there is a MB cluster MB1, MB2, MB3. There is sub1 for MB1 and sub2 for
 MB2. You need to go to MB1's web console to disconnect sub1 and MB2's web
 console to disconnect sub2. So cluster aspect is lost there.

 Thus two implementation approaches are there

 1. Forceful disconnection can be done only from the node subscriber is
 connected to.
 2. Forceful disconnection can be done from any node (this is bit
 complex. Involves Hazelcast notifications)

 As our end goal for implementation would option 1 be adequate?
 Or do we need to reach out for option 2 as well?
 Do we need to facilitate this for any subscription type
 (queue/topic/durable topic/shared durable topic) ? What about MQTT
 subscribers?

 Also what are the permissions a user should have to perform this
 action? Are we going to introduce a new permission type?

 Thanks
 --
 *Hasitha Abeykoon*
 Senior Software Engineer; WSO2, Inc.; http://wso2.com
 *cell:* *+94 719363063*
 *blog: **abeykoon.blogspot.com* 


 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Sajini De SIlva
>>> Software Engineer; WSO2 Inc.; http://wso2.com ,
>>> Email: saj...@wso2.com
>>> Blog: http://sajinid.blogspot.com/
>>> Git hub profile: https://github.com/sajinidesilva
>>>
>>> Phone: +94 712797729
>>>
>>>
>>
>>
>> --
>> Ramith Jayasinghe
>> Technical Lead
>> WSO2 Inc., http://wso2.com
>> lean.enterprise.middleware
>>
>> E: ram...@wso2.com
>> P: +94 777542851
>>
>>
>
>
> --
> 
> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
> Site: http://people.apache.org/~hemapani/
> Photos: http://www.flickr.com/photos/hemapani/
> Phone: 0772360902
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] API Manager REST API with tier grouping feature

[Frank Leymann]

Just to double-check:  but we still have a POST /tiers to add a new tier to
the collection, right?


Best regards,
Frank

2015-12-01 11:50 GMT+01:00 Nuwan Dias :

> I think the group param should be mandatory. Therefore there will not be a
> GET /tiers, but instead a GET /tiers/{level} only.
>
> Thanks,
> NuwanD.
>
> On Tue, Dec 1, 2015 at 3:17 PM, Malintha Amarasinghe 
> wrote:
>
>> Hi Nuwan, Sanjeewa and Joe,
>>
>> Thanks a lot for all the suggestions.
>>
>> I have a small doubt for using the group as part of the path.
>>
>> Lets say we use GET /tiers/api/{tier-id} to get a single API tier by its
>> id (actually Name). Then, are we exposing the resource /tiers alone too?
>> If we do, are we returning the tier groups for GET /tiers? In this case,
>> returning tiers will not be appropriate IMO as the immediate sub-resource
>> is not a tier, but a tier type. Or can we just make the group parameter
>> mandatory?
>>
>> Thank you.
>> Malintha
>>
>> On Tue, Dec 1, 2015 at 11:54 AM, Nuwan Dias  wrote:
>>
>>>
>>>
>>> On Tue, Dec 1, 2015 at 11:21 AM, Joseph Fonseka  wrote:
>>>
 IMO if we have multiple tier files a path param would be more suitable.
 If we have only one tier file and the group(level) is an attribute then we
 could have use a query param.

 Any specific reason to have a tier file for each level ? Rather than
 having an attribute to group tiers. Or for each tier specifying 
 application,
 API and resource level throttling separately.

>>>
>>> Having everything on a single file makes the tier definitions very
>>> noisy. Having it separately makes it very clean and easy to manage.
>>>
>>> For example, the API tiers now have attributes related to billing
>>> information. These won't make sense for Application level and Resource
>>> level tiers. So having them in separate files makes sense IMO. In addition
>>> to that having them separately allows us to perform access control for
>>> those resources as well.
>>>

 Thanks
 Jo





 On Tue, Dec 1, 2015 at 10:06 AM, Sanjeewa Malalgoda 
 wrote:

> What we agreed last week is let users to fetch tiers based on type,
> It can be either path param like mentioned above or query param
> tiers?tier-level=application.
>
> Existing users will get same set of tiers for application, API and
> resource.
> But new deployments and people who willing to have different levels
> can change them as per requirements.
> Having same names in application, API and resource level with
> different unit time and count may be bit confusing IMO.
> Still nothing will break as we return requested tier list.
>
> Thanks,
> sanjeewa.
>
>
>
> On Tue, Dec 1, 2015 at 8:41 AM, Nuwan Dias  wrote:
>
>> @Sanjeewa, users migrating from older versions of API Manager will
>> have their tiers duplicated across all levels. And its not wrong for 
>> users
>> to have the same tier across all levels as well. Therefore having 
>> duplicate
>> tier names in different levels is valid scenario.
>>
>> @Jo, yes there's a tier.xml file per group.
>>
>> @Malintha, I think the resource url should be
>> /tiers/{level}/{tier-id}. Ex: GET /tiers/application/Gold.
>>
>> Thanks,
>> NuwanD.
>>
>>
>> On Tue, Dec 1, 2015 at 7:51 AM, Joseph Fonseka 
>> wrote:
>>
>>> Hi Malintha
>>>
>>> Do we have multiple tier.xml files per group ?
>>>
>>> On Tue, Dec 1, 2015 at 7:41 AM, Sanjeewa Malalgoda <
>>> sanje...@wso2.com> wrote:
>>>


 On Mon, Nov 30, 2015 at 11:05 PM, Malintha Amarasinghe <
 malint...@wso2.com> wrote:

> Hi All,
>
> With the new REST API for API Manager we are exposing a resource
> /tiers for retrieving/adding/updating tiers. Additionally we have a 
> sub
> resource /tiers/{tier-id}.
>
> As of now, we have been using tier name as the tier-id. It did not
> give problems as it could be used to identify a tier uniquely as we 
> were
> maintaining a single set of tiers for all types (API, application and
> resources)
>
> With the new tier grouping feature, we have defined tiers per
> app/API and resource separately. We are currently using separate 
> names, but
> still the admin can modify the tiers.xml files and define tiers with 
> same
> name for those types, hence identifying tier from tier name can be
> ambiguous.
>
 Ideally we will not use same set of names across application, api
 and resources. We agreed to use different set of names for each tier 
 types,
 So i think this will not cause any 

Re: [Architecture] Specifying the tenant domain in the request URI for the cross-tenant scenarois in API Manager REST API

[Frank Leymann]

Thanks, Malintha!

I assume we verify that a user is allowed to access resources from a
different tenant domain?


Best regards,
Frank

2015-11-22 18:48 GMT+01:00 Malintha Amarasinghe <malint...@wso2.com>:

> Hi,
>
> Yes we have implemented it in the way Sanjeewa mentioned in the previous
> mail. Due to the complexity and inconsistency (with the requests which does
> not require tenant domain) of having the tenant domain as the part of the
> context, we decided to send it as a query/header parameter. According to
> the current implementation, we have used a header parameter.
>
> A sample request would be as follow:
>
>
>- User "us...@wso2.com" wants to see what are the APIs that are
>available in the tenant cloud.com
>
> *GET* http://127.0.0.1:9764/api/am/store/v1/apis HTTP/1.1
> *X-WSO2-Tenant*: cloud.com
> *Authorization*: *Basic* *Or Bearer token*
>
>
>
> We identify the user's tenant domain from the authorization header. If he
> need to lookup resources of a different tenant domain, he can send it from
> the *X-WSO2-Tenant *header. This is only supported in Store for following
> use cases.
>
> 1. User wants to get all APIs from a different tenant domain.
> 2. User wants to get a specific API from a different tenant domain.
> 3. User wants to see documents of an API which is in a different tenant
> domain.
> 4, User wants to see a specific document of an API which is in a different
> tenant domain.
>
> Thank you.
> Malintha.
>
>
>
> On Sun, Nov 22, 2015 at 9:49 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
> wrote:
>
>> Hi frank,
>> As we discussed during last meeting tenant domain will not be a part of
>> context. So application url remain as it is and current logged tenant will
>> identified using authentication details client send(we start tenant flow
>> based on logged in user).
>> If need we can make tenant name query parameter in url.
>> Requested tenant can be transport header and part of API.
>>
>> I think malintha already implemented this for some resources which
>> requires requested tenant. He may provide more information.
>>
>> Thanks
>> sanjeewa.
>>
>> sent from my phone
>> On Nov 22, 2015 7:14 PM, "Frank Leymann" <fr...@wso2.com> wrote:
>>
>>> Dear all,
>>>
>>> let me try to understand:
>>>
>>> A user (us...@wso2.com) wants to access a resource created by a certain
>>> tenant (cloud.com) - correct?  The tenant created the resource and we
>>> decided to make the tenant-id part of the context of the resource's URL.
>>>
>>> Thus, the user who wants to access the tenant's resource is a parameter
>>> of some sort of (new?) API that requests access to the tenant's resource.
>>>
>>> This (new?) API would look something like this:
>>>
>>> //{tenant}//=us...@wso2.com
>>>
>>> Does it make sense or did I miss the discussion?
>>>
>>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> 2015-11-17 16:16 GMT+01:00 Sanjeewa Malalgoda <sanje...@wso2.com>:
>>>
>>>> If we think this very carefully requested tenant domain should be part
>>>> of the API.
>>>> Let me explain it,
>>>> We have API and that behave in some manner according to provided
>>>> parameters and inputs.
>>>> In this particular scenario, we are passing completely different data
>>>> set and get different results.
>>>> So cant we take this as user input for API? If we added that as
>>>> parameter then it will be part of API(non mandatory parameter).
>>>>
>>>> Or else we may need to have ability of setting custom fields in carbon
>>>> context as that can be accessible across all places of started flow.
>>>> But according to current implementation we cannot place anything in
>>>> carbon context.
>>>> With tenant app sharing concept we need to have logged in tenant and
>>>> requested tenant both in message context to give proper results.
>>>> Shouldn't we have that capability in carbon context?
>>>>
>>>> Thanks,
>>>> sanjeewa.
>>>>
>>>>
>>>>
>>>> On Mon, Nov 16, 2015 at 2:20 PM, Malintha Amarasinghe <
>>>> malint...@wso2.com> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> In API Manager REST API, we will be supporting cross tenant scenarios.
>>>>> Few examples would be like below.
>>>>>
>>>&

Re: [Architecture] Specifying the tenant domain in the request URI for the cross-tenant scenarois in API Manager REST API

[Frank Leymann]

Hi Nuwan,

the fact that most of our customers are not using multi-tenancy is a
convincing argument :-)

However, let me point out that (vendor-specific) header fields have a bunch
of problems. For example, a cache will have to be aware that it has to pass
the X-xyz header back to the origin server in case of freshness validation
(which is what a cache doesn't do out of the box). Also, a load balancer
can't be set up to route requests based on the URL (as in the case the
tenantID would be part of the URL), etc.  Thus, the REST recommendation is
to have tenantIDs in the URL - we need to have arguments available if we
are confronted with these weaknesses in a review.

Finally a question: How do we identify tenants in C5?  Or don't we support
multi-tenancy in C5?


Best regards,
Frank

2015-11-23 5:26 GMT+01:00 Nuwan Dias <nuw...@wso2.com>:

> Hi Frank,
>
> In Summary, there are two main reasons we decided to go against having the
> tenant domain as part of the URI.
>
> 1. Its optional. For people who aren't interested in multi-tenancy ( >
> 75%), there would not be a need to expose this complexity.
>
> 2. With C5, tenancy is going to be container based. Therefore the
> underlying Applications would not (necessarily) have to deal with tenant
> related concepts. So having a tenant domain as part of the URL would not
> make much sense in there.
>
> Thanks,
> NuwanD.
>
> On Sun, Nov 22, 2015 at 11:18 PM, Malintha Amarasinghe <malint...@wso2.com
> > wrote:
>
>> Hi,
>>
>> Yes we have implemented it in the way Sanjeewa mentioned in the previous
>> mail. Due to the complexity and inconsistency (with the requests which does
>> not require tenant domain) of having the tenant domain as the part of the
>> context, we decided to send it as a query/header parameter. According to
>> the current implementation, we have used a header parameter.
>>
>> A sample request would be as follow:
>>
>>
>>- User "us...@wso2.com" wants to see what are the APIs that are
>>available in the tenant cloud.com
>>
>> *GET* http://127.0.0.1:9764/api/am/store/v1/apis HTTP/1.1
>> *X-WSO2-Tenant*: cloud.com
>> *Authorization*: *Basic* *Or Bearer token*
>>
>>
>>
>> We identify the user's tenant domain from the authorization header. If he
>> need to lookup resources of a different tenant domain, he can send it from
>> the *X-WSO2-Tenant *header. This is only supported in Store for
>> following use cases.
>>
>> 1. User wants to get all APIs from a different tenant domain.
>> 2. User wants to get a specific API from a different tenant domain.
>> 3. User wants to see documents of an API which is in a different tenant
>> domain.
>> 4, User wants to see a specific document of an API which is in a
>> different tenant domain.
>>
>> Thank you.
>> Malintha.
>>
>>
>>
>> On Sun, Nov 22, 2015 at 9:49 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
>> wrote:
>>
>>> Hi frank,
>>> As we discussed during last meeting tenant domain will not be a part of
>>> context. So application url remain as it is and current logged tenant will
>>> identified using authentication details client send(we start tenant flow
>>> based on logged in user).
>>> If need we can make tenant name query parameter in url.
>>> Requested tenant can be transport header and part of API.
>>>
>>> I think malintha already implemented this for some resources which
>>> requires requested tenant. He may provide more information.
>>>
>>> Thanks
>>> sanjeewa.
>>>
>>> sent from my phone
>>> On Nov 22, 2015 7:14 PM, "Frank Leymann" <fr...@wso2.com> wrote:
>>>
>>>> Dear all,
>>>>
>>>> let me try to understand:
>>>>
>>>> A user (us...@wso2.com) wants to access a resource created by a
>>>> certain tenant (cloud.com) - correct?  The tenant created the resource
>>>> and we decided to make the tenant-id part of the context of the resource's
>>>> URL.
>>>>
>>>> Thus, the user who wants to access the tenant's resource is a parameter
>>>> of some sort of (new?) API that requests access to the tenant's resource.
>>>>
>>>> This (new?) API would look something like this:
>>>>
>>>> //{tenant}//=us...@wso2.com
>>>>
>>>> Does it make sense or did I miss the discussion?
>>>>
>>>>
>>>>
>>>> Best regards,
>>>> Frank
>>>>
>>>> 2015-11-17 1

Re: [Architecture] Specifying the tenant domain in the request URI for the cross-tenant scenarois in API Manager REST API

[Frank Leymann]

Dear all,

let me try to understand:

A user (us...@wso2.com) wants to access a resource created by a certain
tenant (cloud.com) - correct?  The tenant created the resource and we
decided to make the tenant-id part of the context of the resource's URL.

Thus, the user who wants to access the tenant's resource is a parameter of
some sort of (new?) API that requests access to the tenant's resource.

This (new?) API would look something like this:

//{tenant}//=us...@wso2.com

Does it make sense or did I miss the discussion?



Best regards,
Frank

2015-11-17 16:16 GMT+01:00 Sanjeewa Malalgoda :

> If we think this very carefully requested tenant domain should be part of
> the API.
> Let me explain it,
> We have API and that behave in some manner according to provided
> parameters and inputs.
> In this particular scenario, we are passing completely different data set
> and get different results.
> So cant we take this as user input for API? If we added that as parameter
> then it will be part of API(non mandatory parameter).
>
> Or else we may need to have ability of setting custom fields in carbon
> context as that can be accessible across all places of started flow.
> But according to current implementation we cannot place anything in carbon
> context.
> With tenant app sharing concept we need to have logged in tenant and
> requested tenant both in message context to give proper results.
> Shouldn't we have that capability in carbon context?
>
> Thanks,
> sanjeewa.
>
>
>
> On Mon, Nov 16, 2015 at 2:20 PM, Malintha Amarasinghe 
> wrote:
>
>> Hi All,
>>
>> In API Manager REST API, we will be supporting cross tenant scenarios.
>> Few examples would be like below.
>>
>> 1. us...@wso2.com wants to see the APIs that are available in the tenant
>> store; cloud.com
>> 2. us...@wso2.com wants to see the documents of an API weatherAPI that
>> are available in the tenant store; cloud.com
>>
>> For this requirement we need to pass the "required tenant domain"
>> parameter with the request as the logged in user belongs to is a different
>> tenant. There are several possible ways to specify this.
>>
>> 1. Specify this as a query parameter for every resource this is required
>>
>> ex: GET 
>> http://127.0.0.1:9763/api/am/publisher/v1/apis?*tenantDomain=cloud.com
>> *
>>
>>
>> 2. Specify this as a header parameter
>>
>> 3. Specify this within the URI.
>>
>> a. before the Jax-RS web app context
>>
>> ex: GET http://127.0.0.1:9763/*t/cloud.com *
>> /api/am/publisher/v1/apis
>>
>> b. after the Jax-RS web app context
>>
>> ex: GET http://127.0.0.1:9763/api/am/publisher/v1/*t/cloud.com
>> */apis
>>
>>
>> Regarding these three options, option (3.a) would require the web app to
>> be deployed on each and every tenant. Or otherwise we should manually
>> register contexts in tomcat run-time to match those contexts. Even if we
>> register context manually, this would not be a good solution as the user
>> might expect the web app to be in the tenant space (when he sees the
>> /t/tenant part in the URI) but it is not there actually. Option (3.b) would
>> require the web app to handle the tenant as a resource and every other
>> resource would need to be a sub-resource. And we need to specifically
>> handle for the super tenant which we don't specify the tenant in the URL.
>> For options (1) and (2), we don't need to face such difficulties.
>>
>> Please share your thoughts.
>>
>> Thanks.
>> Malintha
>>
>> --
>> Malintha Amarasinghe
>> Software Engineer
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306
>>
>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
> blog
> :http://sanjeewamalalgoda.blogspot.com/
> 
>
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] API Manager REST API separation for store and publisher.

[Frank Leymann]

A GET on a resource returns *the* resource. All that can vary is its
requested representation (i.e. as JSON, XML,... rendering). I.e. if the GET
in Store and the GET in Publisher return different resources (i.e.
different data structures independent from their rendering) we should have
two different APIs. Thus, I agree with Jo...

Note, that this is a REST purists point of view.  There are examples that
provide viewing mechanisms by specifying which "fields" of a resource
should be retrieved. But this results in problems like caching etc. Thus, I
tend to the purists' approach.


Best regards,
Frank

2015-10-13 19:40 GMT+02:00 Joseph Fonseka :

> IMHO There should be two API definitions for Store and publisher APIs.
> Mainly because even though publisher and store share some resources there
> properties generally will be different e.g. data models, permissions. So
> managing this in one web app will be difficult and hard to maintain.
>
> So +1 for two web apps namely api#am#store#v1.war and
> api#am#publisher#v1.war.
>
> Cheers
> Jo
>
> On Tue, Oct 13, 2015 at 10:46 PM, Sanjeewa Malalgoda 
> wrote:
>
>> Hi All,
>> API Manager team planned to add complete REST API support for API
>> Management operations available in product.
>> Since initial implementation is done we are thinking about next steps of
>> REST service.
>> In this mail we need to discuss about separating API Manager store and
>> publisher operations.
>>
>> *Improvement*
>> In current REST API is developed as single web application.
>> It will be deployed in API Management server and it can perform both
>> store/ publisher operations.
>> But so far we had clear separation between API store and
>> publisher(Publisher to create/manage APIs and store to manage subscriptions
>> etc).
>> With new REST API we need to do something similar to manage same behavior.
>> This will be important if we deploy API Manager in fully distributed
>> deployment. In that case API store will be deployed in DMZ and we shouldn't
>> allow publisher operations from that(API create publish should not possible
>> from outside).
>> To have this kind of separation we may need 2 web applications or single
>> web application with 2 contexts.
>>
>> *Suggested solutions*
>> 01. Deploy API Manager store and publisher as 2 separate applications.
>>   Then we will have 2 applications named api#am#store#v1.war and
>> api#am#publisher#v1.war.
>>   These 2 applications will be deployed in contexts api/am/store/v1
>> and api/am/publisher/v1.
>>   If we deploy store profile we can remove publisher web service and
>> if its publisher we can remove store web service.
>>
>> 02. Have single Applications(web service) which register 2 sub contexts.
>>   We can define mapped classes according to each context(here
>> contexts are api/am/store/v1 and api/am/publisher/v1 ).
>>   We can add service beans(service beans like apis, applications,
>> tags etc) on top of these two base contexts.
>>   If we deploy store profile we need to disable service bean group
>> for publisher. To do this we need to edit beans.xml and redeploy .war file.
>>
>> If we go for first approach we will have 2 applications and it do not
>> require web application modifications.
>>
>> *Challenges*
>> When we implement 2 different services for API store and publisher there
>> will be some duplicates.
>> As example we can consider following
>> /apis GET in publisher will return complete API details with back end
>> urls etc.
>> But /apis GET in store will return us only detail required for store
>> functionality(in this case back end user will not present in response
>> instead it will have gateway API URL).
>> Same applies for tiers as well(we can edit tiers in publisher but in
>> store we can see available tier name list when we subscribe to API).
>> So we need to carefully separate these functionalities.
>>
>> If we go for 2 different applications sometimes we may need 2 different
>> api.yaml files to maintain operation isolation.
>> Main reason for that is API object return from publisher API may
>> different from API object return from store API.
>> So there will be 2 models for API object based on service
>> type(store/publisher).
>> Or other option is maintain single data model and fill required data
>> based on used service(if its publisher back end URL parameter will present
>> with value but if its store then back end URLs will not be there).
>> We need to discuss this and come to conclusion.
>>
>> I'm sure we need to focus on this when we implement ES REST API.
>> Appreciate your suggestions and comments on this.
>>
>> Thanks,
>> sanjeewa.
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779
>>
>> blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> 
>>
>>
>>
>
>
> --
>
> --
> *Joseph Fonseka*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> 

Re: [Architecture] IS Workflow Implementation - Issues in AddUser Workflow

[Frank Leymann]

Thanks, Chamila :-)

And you get the list of people easily from the database table...


Best regards,
Frank

2015-07-22 14:31 GMT+02:00 Chamila Wijayarathna cham...@wso2.com:

 Hi Frank,

 yes, one of the main requirements I am trying to address is handling
 adding duplicate users. Also as I mentioned in my previous mail, we need a
 way so that an admin user can see list of people with those who are still
 in workflows and not accepted.

 Thanks

 On Wed, Jul 22, 2015 at 5:37 PM, Frank Leymann fr...@wso2.com wrote:

 Dear Chamila,

 in summary, you are implementing a pessimistic offline lock, right?
 http://martinfowler.com/eaaCatalog/pessimisticOfflineLock.html


 Best regards,
 Frank

 2015-07-22 7:23 GMT+02:00 Chamila Wijayarathna cham...@wso2.com:

 Hi all,

 Currently we are in the process of implementing Workflow support for
 user operations in IS 5.1.0. Recently we have identified following issue in
 the implementation. For the sake of the conversation let’s focus only on
 workflow support for 'addUser' operation.

 Usually when a user is added to a user store it will go through
 following 3 steps.

1.

UserOperationEventListener.doPreAddUser
2.

UserStoreManager.doAddUser
3.

UserOperationEventListener.doPostAddUser


 Workflow integration for 'addUser' operation is currently implemented as
 follows. We have implemented a UserOperationEventListner in workflow-mgt
 component whose 'doPreAddUser' hook is called when a user is added through
 addUser of the UserStoreManager. Then it will trigger a workflow for this
 task, save the request data and workflow related metadata in a database
 table (not in user store, separate table introduced), and then will return
 false, which will stop the further processing of addUser listeners and the
 operation itself. When the workflow is completed, in its callback method,
 it will again call 'addUser' method of UserStoreManager where this time it
 executes all 3 steps, pre-hooks, operation and post hooks, except for the
 workflow pre-hook. So user will be added to the user store only when the
 workflow is completed.

 We came up with 2 limitations of this approach which needs to be
 addressed.

1.

When a ‘addUser’ workflow is triggered, it should not be possible to
add another user with same userName. Right now we can’t find this out 
 until
the second workflow to be approved, tries to insert the user to the
userstore.
2.

Admin user should be able to see the list of users who are in the
queue to be added once the workflows are approved.


 To overcome these limitations, first we came up with the following
 approach.

 When user is added and workflow is started, he should be added to the
 userStore (so adding new users will be prevented from userStore level and
 list users is also possible as usual). To do this we have to execute
 'doPreAddUser' and 'doAddUser' methods when user is added, but also keep a
 claim saying he is locked or pending, which will prevent modifications or
 authentication for the user. However we need to prevent the post listeners
 from executing because the actual user provisioning is not actually
 completed. E.g. one of the post listeners we have provisions users to
 external Identity Providers, which can’t happen until the workflow is
 approved. Of course we can provision him to external system and in case the
 workflow is rejected we can deprovision the same user in the callback, but
 the drawback is between such time the user will be like a valid user in the
 external system. Then once the workflow is accepted it will unlock user as
 well as execute doPostAddUser which do the outbound provisioning, etc.

 Basically what we need is to be able to control the execution of the
 pre-hooks, operation and post-hooks independently from the rest. But for
 now we can't implement it in this way, since this needs few API changes in
 user core, which is in carbon4-kernel and there won't be a release of
 kernel with API changes before IS 5.1.0 release.

 So we decided to do this in following way.

 User addition will remain the same, i.e. user will not be added the
 userstore until workflow is approved, but using the workflow related
 metadata table we can cater the 2 requirements stated above. That is
 identify the conflicting scenarios, e.g. adding users with same username
 and listing the users that are still under processing.

 The same scenario can be extended to all other user operations as well,
 such as addRole, updateRoleListOfUser, etc.

 Thank You!


 --
 *Chamila Dilshan Wijayarathna,*
 Software Engineer
 Mobile:(+94)788193620
 WSO2 Inc., http://wso2.com/

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] IS Workflow Implementation - Issues in AddUser Workflow

[Frank Leymann]

Dear Chamila,

in summary, you are implementing a pessimistic offline lock, right?
http://martinfowler.com/eaaCatalog/pessimisticOfflineLock.html


Best regards,
Frank

2015-07-22 7:23 GMT+02:00 Chamila Wijayarathna cham...@wso2.com:

 Hi all,

 Currently we are in the process of implementing Workflow support for user
 operations in IS 5.1.0. Recently we have identified following issue in the
 implementation. For the sake of the conversation let’s focus only on
 workflow support for 'addUser' operation.

 Usually when a user is added to a user store it will go through following
 3 steps.

1.

UserOperationEventListener.doPreAddUser
2.

UserStoreManager.doAddUser
3.

UserOperationEventListener.doPostAddUser


 Workflow integration for 'addUser' operation is currently implemented as
 follows. We have implemented a UserOperationEventListner in workflow-mgt
 component whose 'doPreAddUser' hook is called when a user is added through
 addUser of the UserStoreManager. Then it will trigger a workflow for this
 task, save the request data and workflow related metadata in a database
 table (not in user store, separate table introduced), and then will return
 false, which will stop the further processing of addUser listeners and the
 operation itself. When the workflow is completed, in its callback method,
 it will again call 'addUser' method of UserStoreManager where this time it
 executes all 3 steps, pre-hooks, operation and post hooks, except for the
 workflow pre-hook. So user will be added to the user store only when the
 workflow is completed.

 We came up with 2 limitations of this approach which needs to be addressed.

1.

When a ‘addUser’ workflow is triggered, it should not be possible to
add another user with same userName. Right now we can’t find this out until
the second workflow to be approved, tries to insert the user to the
userstore.
2.

Admin user should be able to see the list of users who are in the
queue to be added once the workflows are approved.


 To overcome these limitations, first we came up with the following
 approach.

 When user is added and workflow is started, he should be added to the
 userStore (so adding new users will be prevented from userStore level and
 list users is also possible as usual). To do this we have to execute
 'doPreAddUser' and 'doAddUser' methods when user is added, but also keep a
 claim saying he is locked or pending, which will prevent modifications or
 authentication for the user. However we need to prevent the post listeners
 from executing because the actual user provisioning is not actually
 completed. E.g. one of the post listeners we have provisions users to
 external Identity Providers, which can’t happen until the workflow is
 approved. Of course we can provision him to external system and in case the
 workflow is rejected we can deprovision the same user in the callback, but
 the drawback is between such time the user will be like a valid user in the
 external system. Then once the workflow is accepted it will unlock user as
 well as execute doPostAddUser which do the outbound provisioning, etc.

 Basically what we need is to be able to control the execution of the
 pre-hooks, operation and post-hooks independently from the rest. But for
 now we can't implement it in this way, since this needs few API changes in
 user core, which is in carbon4-kernel and there won't be a release of
 kernel with API changes before IS 5.1.0 release.

 So we decided to do this in following way.

 User addition will remain the same, i.e. user will not be added the
 userstore until workflow is approved, but using the workflow related
 metadata table we can cater the 2 requirements stated above. That is
 identify the conflicting scenarios, e.g. adding users with same username
 and listing the users that are still under processing.

 The same scenario can be extended to all other user operations as well,
 such as addRole, updateRoleListOfUser, etc.

 Thank You!


 --
 *Chamila Dilshan Wijayarathna,*
 Software Engineer
 Mobile:(+94)788193620
 WSO2 Inc., http://wso2.com/

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Workflow Implementation in IS 5.1.0

[Frank Leymann]

Great!  Is our gut feeling that the same is true also in other cases in
which WSO2 products benefit from BPS (e.g. ES)?  That would be good
progress :-)


Best regards,
Frank

2015-07-20 6:15 GMT+02:00 Chathura Ekanayake chath...@wso2.com:

 Hi Frank,


 ​This does not solve the problem of missing data: your selection may skip
 steps that produce data required by the selected steps.


 As discussed with Prabath and IS team, human tasks involved in these
 workflows have the same input and output data. Input data is provided at
 process instance creation (e.g. details of a new user) and output data is
 whether the request is approved or not. Therefore, I think we assume that
 tasks do not depend on outputs of other tasks.

 Regards,
 Chathura



 2015-07-16 8:49 GMT+02:00 Chathura Ekanayake chath...@wso2.com:

 From the implementation point of view, the BPEL workflow executor should
 read the workflow template (which may be stored in the registry) and attach
 template details to BPEL invocation request. So that the BPEL request
 message will look like below:

 body
addUserWorkflowRequest
   template
  step
 namestep1/name
 assignment.../assignment
  /step
  step
 namestep2/name
 assignment.../assignment
  /step
   /template

   userData
  usernamesmith/username
  passwordsmithpass/password
  roles
rolemanager/role
roleinventoryStaff/role
  /roles
   /userData
/addUserWorkflowRequest
 /body

 BPEL workflow decides which tasks to execute by examining the
 template/step/name part and assigns users to corresponding tasks using the
 template/step/assignment part. userData element contains the actual
 payload of the request, which may be used by human tasks to display
 information about the user being added.

 Regards,
 Chathura

 On Thu, Jul 16, 2015 at 12:00 PM, Chathura Ekanayake chath...@wso2.com
 wrote:

 I think we can clarify this further by looking in to user stories. I
 think the user experience of using IS workflows should be something like
 this:

 Scenario A - Associating a workflow with an action (e.g. Add user
 action):
 1) Select the Add user attachment point from the list of published
 attachment points
 2) Select a workflow from the list of registered workflows
 3) Once selected, the selected workflow can be configured to create a
 template (as described in 4 and 5)
 4) User is presented with all available tasks (i.e. steps) in the
 selected workflow
 5) User can exclude certain tasks and assign users/roles to remaining
 tasks
 6) User can specify an activation condition for the workflow

 Scenario B - Performing an action which has an associated workflow
 (e.g. Adding a user):
 1) User fills in the add user form and click Finish
 2) The associated workflow is triggered and relevant users performs
 tasks assigned to them using the BPS human task webapp
 3) Once the workflow completes, it returns the approval status and IS
 decides whether to add the user based on the status

 Scenario C - Registering a workflow:
 1) Deploy the required BPEL archive in BPS
 2) Provide the URL of the BPEL endpoint as a configuration
 3) Specify the list of configurable tasks (this is used for creating
 templates)

 Below are some questions:

 Scenario A:
 Can we specify multiple workflows for the same action?
 Do workflows always return a boolean value (i.e. approved / not
 approved)?

 Scenario B:
 Are we expecting the users to complete tasks (e.g. approval steps)
 using the BPS Human Task web app? Or are we providing an integrated human
 task UI in the IS management console?

 Scenario C:
 Are there any other steps involved in this?
 The list of tasks can also be extracted from the BPEL by locating
 b4p:peopleActivity elements. Then the user can remove certain tasks from
 the configurable tasks list, if those are mandatory.

 Regards,
 Chathura



 On Wed, Jul 15, 2015 at 9:40 PM, Prabath Siriwardena prab...@wso2.com
 wrote:

 Thanks Frank for the suggestion. Yes - it would be great if we can
 make the template generation easy. At the moment as we discussed with
 Chathura, we are creating a parameterized BPEL workflow and  parameters 
 are
 picked from the user through the template (in IS). So the same BPEL
 workflow will find different execution paths based on the template...

 Thanks  regards,
 -Prabath


 On Wed, Jul 15, 2015 at 6:02 AM, Frank Leymann fr...@wso2.com wrote:

 As Chathura describes, workflow templates are not easy to design.
 This is why we discussed some months ago a specialized language to 
 ensure
 that template design is easy.  Another alternative is to consider CMMN
 which has been designed to make skipping more easy...  Maybe that's
 another subject to be discussed when we meet early August in Colombo?


 Best regards,
 Frank

 2015-07-15 6:31 GMT+02:00 Chathura Ekanayake chath...@wso2.com:

 According to the discussion we

Re: [Architecture] Workflow Implementation in IS 5.1.0

[Frank Leymann]

A few comments:

Scenario A:
If I get it right, the workflows are modeled by workflow-skilled users.
I.e. we can assume that they build it in a way that the data dependency by
skipping tasks is avoided, right?  For example, we may provide a best
practices guide to the corresponding modelers.

Scenario B:
The form mentioned in (1) could be the basis for the forms document I
sketched in my last mail on this subject.

Scenario C:
Is it really acceptable for IS users/admins/... to model BPEL workflows?
Do they have the skills? My understanding from our call early this year was
that we need a very simple workflow language (isomorphic to a very small
subset of BPEL or BPMN) for modeling such flows. We should discuss this, or
need to get Isabelle's feedback, respectively.


Best regards,
Frank

2015-07-16 8:30 GMT+02:00 Chathura Ekanayake chath...@wso2.com:

 I think we can clarify this further by looking in to user stories. I think
 the user experience of using IS workflows should be something like this:

 Scenario A - Associating a workflow with an action (e.g. Add user action):
 1) Select the Add user attachment point from the list of published
 attachment points
 2) Select a workflow from the list of registered workflows
 3) Once selected, the selected workflow can be configured to create a
 template (as described in 4 and 5)
 4) User is presented with all available tasks (i.e. steps) in the selected
 workflow
 5) User can exclude certain tasks and assign users/roles to remaining tasks
 6) User can specify an activation condition for the workflow

 Scenario B - Performing an action which has an associated workflow (e.g.
 Adding a user):
 1) User fills in the add user form and click Finish
 2) The associated workflow is triggered and relevant users performs tasks
 assigned to them using the BPS human task webapp
 3) Once the workflow completes, it returns the approval status and IS
 decides whether to add the user based on the status

 Scenario C - Registering a workflow:
 1) Deploy the required BPEL archive in BPS
 2) Provide the URL of the BPEL endpoint as a configuration
 3) Specify the list of configurable tasks (this is used for creating
 templates)

 Below are some questions:

 Scenario A:
 Can we specify multiple workflows for the same action?
 Do workflows always return a boolean value (i.e. approved / not approved)?

 Scenario B:
 Are we expecting the users to complete tasks (e.g. approval steps) using
 the BPS Human Task web app? Or are we providing an integrated human task UI
 in the IS management console?

 Scenario C:
 Are there any other steps involved in this?
 The list of tasks can also be extracted from the BPEL by locating
 b4p:peopleActivity elements. Then the user can remove certain tasks from
 the configurable tasks list, if those are mandatory.

 Regards,
 Chathura



 On Wed, Jul 15, 2015 at 9:40 PM, Prabath Siriwardena prab...@wso2.com
 wrote:

 Thanks Frank for the suggestion. Yes - it would be great if we can make
 the template generation easy. At the moment as we discussed with Chathura,
 we are creating a parameterized BPEL workflow and  parameters are picked
 from the user through the template (in IS). So the same BPEL workflow will
 find different execution paths based on the template...

 Thanks  regards,
 -Prabath


 On Wed, Jul 15, 2015 at 6:02 AM, Frank Leymann fr...@wso2.com wrote:

 As Chathura describes, workflow templates are not easy to design. This
 is why we discussed some months ago a specialized language to ensure that
 template design is easy.  Another alternative is to consider CMMN which has
 been designed to make skipping more easy...  Maybe that's another subject
 to be discussed when we meet early August in Colombo?


 Best regards,
 Frank

 2015-07-15 6:31 GMT+02:00 Chathura Ekanayake chath...@wso2.com:

 According to the discussion we had last week, I think the users
 assigned to tasks (e.g. approvers) as well as workflow steps have to be
 configurable. That means, we can give a workflow covering many steps. Then
 steps required for a particular scenario (and users/roles for those steps)
 can be selected based on the configuration (i.e. workflow template).

 For example a workflow (workflow A) can be:

 Step1 - Step2 - Step3 - Step4

 And a workflow template (for workflow A) can be:
 Step1 : role1 OR user2
 Step3 : role2

 Above template triggers the workflow A by skipping tasks Step2 and
 Step4. Therefore, a concrete workflow can support any template that
 contains subset of its tasks. Then there is a problem if a workflow
 contains conditional branches (i.e. if branches / OR gateways). In that
 case, certain branches may not contain tasks specified in a template.
 Therefore, what a template states is the tasks that can possibly execute.

 The next problem is whether tasks have dependencies on other tasks
 (e.g. output variables of task A can be consumed by task B). In that case
 if task A is skipped workflow may fail. Therefore, either we have to design

Re: [Architecture] Workflow Implementation in IS 5.1.0

[Frank Leymann]

Dear all,

I won't be in Sri Lanka first week of August as originally planned because
of WSO2Con canceled.  Should we set up a call during that week to review
and discuss the next steps?

I would appreciate it!



Best regards,
Frank

2015-07-15 17:29 GMT+02:00 Isabelle Mauny isabe...@wso2.com:

 All,

 I am still not clear on how a customer would add
 A) a workflow template
 B) the corresponding implementation ( in BPEL or something else)

 So yes +1 to review and enhance/standardize across the platform as
 necessary.

 Isabelle.

 On Wednesday, July 15, 2015, Frank Leymann fr...@wso2.com wrote:

 As Chathura describes, workflow templates are not easy to design. This
 is why we discussed some months ago a specialized language to ensure that
 template design is easy.  Another alternative is to consider CMMN which has
 been designed to make skipping more easy...  Maybe that's another subject
 to be discussed when we meet early August in Colombo?


 Best regards,
 Frank

 2015-07-15 6:31 GMT+02:00 Chathura Ekanayake chath...@wso2.com:

 According to the discussion we had last week, I think the users assigned
 to tasks (e.g. approvers) as well as workflow steps have to be
 configurable. That means, we can give a workflow covering many steps. Then
 steps required for a particular scenario (and users/roles for those steps)
 can be selected based on the configuration (i.e. workflow template).

 For example a workflow (workflow A) can be:

 Step1 - Step2 - Step3 - Step4

 And a workflow template (for workflow A) can be:
 Step1 : role1 OR user2
 Step3 : role2

 Above template triggers the workflow A by skipping tasks Step2 and
 Step4. Therefore, a concrete workflow can support any template that
 contains subset of its tasks. Then there is a problem if a workflow
 contains conditional branches (i.e. if branches / OR gateways). In that
 case, certain branches may not contain tasks specified in a template.
 Therefore, what a template states is the tasks that can possibly execute.

 The next problem is whether tasks have dependencies on other tasks (e.g.
 output variables of task A can be consumed by task B). In that case if task
 A is skipped workflow may fail. Therefore, either we have to design
 workflows without having any dependencies among tasks or we should support
 restrictions on workflow templates (e.g. if task B is included then task A
 has to be included).

 Regards,
 Chathura

 On Wed, Jul 15, 2015 at 1:42 AM, Prabath Siriwardena prab...@wso2.com
 wrote:

 BTW yes - lets have a discussion on this again - because this is not
 just IS thing - and can be used by any other product which needs to have
 workflow support..

 Thanks  regards,
 -Prabath

 On Tue, Jul 14, 2015 at 1:07 PM, Prabath Siriwardena prab...@wso2.com
 wrote:

 Hi Suemdha,

 We discussed most of the stuff with the API Manager team before doing
 this.

 At the moment API Manager implementation does not have any of these
 capabilities and most of the time need to write a workflow or modify a
 workflow..

 Thanks  regards,
 -Prabath

 On Tue, Jul 14, 2015 at 1:03 PM, Sumedha Rubasinghe sume...@wso2.com
 wrote:

 Prabath,
 I think this has some overlaps and improvements compared to what we
 have done for API Manager about 2 years ago.
 Let's have a discussion on how to bring best of both worlds.


 On Wed, Jul 15, 2015 at 12:49 AM, Prabath Siriwardena 
 prab...@wso2.com wrote:

 Hi Isabelle,

 As per the offline chat - you talk about *workflow templates *here..

 The *workflow* implementation should be able to interpret the *workflow
 template*.

 Lets take for example the following sample template..

 Step-1 Approvers : role1 OR role2 AND user1
 Step-2 Approvers : role3 OR role4 AND user3

 There can be multiple workflow implementations supporting the above
 - but the catch here is, when you have a concrete workflow 
 implementation
 it should announce which templates are supported by it. That is how the
 underneath framework knows - which templates are supported by which
 workflows.

 Its pointless to have workflow templates in the system without
 having workflow implementations that support them.

 If there is a need to write a workflow template - then that means -
 you are also going to write a workflow that knows how to interpret it.

 Users of the system need not to worrying about mapping templates to
 the implementations (workflows). Since the each workflow announces which
 templates they support - the framework itself can do it.

 From user's point of view - what mostly matters is the workflow
 template (please see the above example). Templates decide what needs to 
 be
 done - and the workflow implementation decides how to do that.

 The user experience is like below.

 What do I need to know ?  I need to associate a workflow for the
 add-user operation.

 User first picks the *Attachment Point - *in this case add_user.

 Now - I need to specify under which conditions I need to execute
 this work flow..

 User fills the *Attachment

Re: [Architecture] Workflow Implementation in IS 5.1.0

[Frank Leymann]

+1

Whatever we come up with, it must be usable across out product set...


Best regards,
Frank

2015-07-14 22:12 GMT+02:00 Prabath Siriwardena prab...@wso2.com:

 BTW yes - lets have a discussion on this again - because this is not just
 IS thing - and can be used by any other product which needs to have
 workflow support..

 Thanks  regards,
 -Prabath

 On Tue, Jul 14, 2015 at 1:07 PM, Prabath Siriwardena prab...@wso2.com
 wrote:

 Hi Suemdha,

 We discussed most of the stuff with the API Manager team before doing
 this.

 At the moment API Manager implementation does not have any of these
 capabilities and most of the time need to write a workflow or modify a
 workflow..

 Thanks  regards,
 -Prabath

 On Tue, Jul 14, 2015 at 1:03 PM, Sumedha Rubasinghe sume...@wso2.com
 wrote:

 Prabath,
 I think this has some overlaps and improvements compared to what we have
 done for API Manager about 2 years ago.
 Let's have a discussion on how to bring best of both worlds.


 On Wed, Jul 15, 2015 at 12:49 AM, Prabath Siriwardena prab...@wso2.com
 wrote:

 Hi Isabelle,

 As per the offline chat - you talk about *workflow templates *here..

 The *workflow* implementation should be able to interpret the *workflow
 template*.

 Lets take for example the following sample template..

 Step-1 Approvers : role1 OR role2 AND user1
 Step-2 Approvers : role3 OR role4 AND user3

 There can be multiple workflow implementations supporting the above -
 but the catch here is, when you have a concrete workflow implementation it
 should announce which templates are supported by it. That is how the
 underneath framework knows - which templates are supported by which
 workflows.

 Its pointless to have workflow templates in the system without having
 workflow implementations that support them.

 If there is a need to write a workflow template - then that means - you
 are also going to write a workflow that knows how to interpret it.

 Users of the system need not to worrying about mapping templates to the
 implementations (workflows). Since the each workflow announces which
 templates they support - the framework itself can do it.

 From user's point of view - what mostly matters is the workflow
 template (please see the above example). Templates decide what needs to be
 done - and the workflow implementation decides how to do that.

 The user experience is like below.

 What do I need to know ?  I need to associate a workflow for the
 add-user operation.

 User first picks the *Attachment Point - *in this case add_user.

 Now - I need to specify under which conditions I need to execute this
 work flow..

 User fills the *Attachment Point Template* - execute this workflow if
 user's email address is from WSO2.

 Now - I need to select what needs to be done during the add user
 operation.

 User picks one of the available *workflow templates* - and fill the
 data required.

 If there are more than one implementations for the picked* workflow
 template *system will present you an option to pick the workflow
 (rather unlikely) if not - system already associates the available workflow
 with the selected workflow template - user has to nothing there.

 Thanks  regards,
 -Prabath












 On Tue, Jul 14, 2015 at 11:36 AM, Isabelle Mauny isabe...@wso2.com
 wrote:

 Prabath,

 Couple of clarifications:
 - If a user ( customer ) adds a template, what would they need to
 write ? The template definition *AND* the implementation (i.e. executor) ?
 i.e other words they have to describe the interface to the workflow itself
 and then implement the workflow in say BPEL ? Or Java ? or whatever ?
 - How does a customer maps between the template and the executor ?
 (i.e. how do parameters defined in template becomes Receive data in BPEL
 for example)

 Thanks,
 Isabelle.

 -
 *Isabelle Mauny*
 VP, Product Management - WSO2, Inc. - http://wso2.com/



 On Tue, Jul 14, 2015 at 6:22 PM, Prabath Siriwardena prab...@wso2.com
  wrote:

 It looks like still there are some confusions regarding IS workflow
 implementation. So, thought of sharing my thoughts on the design - and
 hopefully this be helpful to clear out the doubts.

 AFAIK - the framework for the following is already implemented.

 Basic design principals.

 1. Simplicity. Keep simple things simple and have provisions to add
 more complex stuff
 2. Not coupled into any implementation. No hard coupling to BPEL
 3. Not coupled into WSO2 BPS. (part of 2 as well)
 4. Not specific to IS

 Terminology:

 1. *Workflow* - implementation independent abstract representation
 of the concrete workflow has two parts, *initializer* and the
 *executor*.

 If its BPEL based workflows the initializer can be used to initialize
 the BPEL and deploy it in the corresponding BPEL engine.

 And the executor will execute the workflow in runtime.

 2. *Attachment Point* - you should be able to attach a workflow to
 an *Attachment Point 

Re: [Architecture] Workflow Implementation in IS 5.1.0

[Frank Leymann]

As Chathura describes, workflow templates are not easy to design. This is
why we discussed some months ago a specialized language to ensure that
template design is easy.  Another alternative is to consider CMMN which has
been designed to make skipping more easy...  Maybe that's another subject
to be discussed when we meet early August in Colombo?


Best regards,
Frank

2015-07-15 6:31 GMT+02:00 Chathura Ekanayake chath...@wso2.com:

 According to the discussion we had last week, I think the users assigned
 to tasks (e.g. approvers) as well as workflow steps have to be
 configurable. That means, we can give a workflow covering many steps. Then
 steps required for a particular scenario (and users/roles for those steps)
 can be selected based on the configuration (i.e. workflow template).

 For example a workflow (workflow A) can be:

 Step1 - Step2 - Step3 - Step4

 And a workflow template (for workflow A) can be:
 Step1 : role1 OR user2
 Step3 : role2

 Above template triggers the workflow A by skipping tasks Step2 and Step4.
 Therefore, a concrete workflow can support any template that contains
 subset of its tasks. Then there is a problem if a workflow contains
 conditional branches (i.e. if branches / OR gateways). In that case,
 certain branches may not contain tasks specified in a template. Therefore,
 what a template states is the tasks that can possibly execute.

 The next problem is whether tasks have dependencies on other tasks (e.g.
 output variables of task A can be consumed by task B). In that case if task
 A is skipped workflow may fail. Therefore, either we have to design
 workflows without having any dependencies among tasks or we should support
 restrictions on workflow templates (e.g. if task B is included then task A
 has to be included).

 Regards,
 Chathura

 On Wed, Jul 15, 2015 at 1:42 AM, Prabath Siriwardena prab...@wso2.com
 wrote:

 BTW yes - lets have a discussion on this again - because this is not just
 IS thing - and can be used by any other product which needs to have
 workflow support..

 Thanks  regards,
 -Prabath

 On Tue, Jul 14, 2015 at 1:07 PM, Prabath Siriwardena prab...@wso2.com
 wrote:

 Hi Suemdha,

 We discussed most of the stuff with the API Manager team before doing
 this.

 At the moment API Manager implementation does not have any of these
 capabilities and most of the time need to write a workflow or modify a
 workflow..

 Thanks  regards,
 -Prabath

 On Tue, Jul 14, 2015 at 1:03 PM, Sumedha Rubasinghe sume...@wso2.com
 wrote:

 Prabath,
 I think this has some overlaps and improvements compared to what we
 have done for API Manager about 2 years ago.
 Let's have a discussion on how to bring best of both worlds.


 On Wed, Jul 15, 2015 at 12:49 AM, Prabath Siriwardena prab...@wso2.com
  wrote:

 Hi Isabelle,

 As per the offline chat - you talk about *workflow templates *here..

 The *workflow* implementation should be able to interpret the *workflow
 template*.

 Lets take for example the following sample template..

 Step-1 Approvers : role1 OR role2 AND user1
 Step-2 Approvers : role3 OR role4 AND user3

 There can be multiple workflow implementations supporting the above -
 but the catch here is, when you have a concrete workflow implementation it
 should announce which templates are supported by it. That is how the
 underneath framework knows - which templates are supported by which
 workflows.

 Its pointless to have workflow templates in the system without having
 workflow implementations that support them.

 If there is a need to write a workflow template - then that means -
 you are also going to write a workflow that knows how to interpret it.

 Users of the system need not to worrying about mapping templates to
 the implementations (workflows). Since the each workflow announces which
 templates they support - the framework itself can do it.

 From user's point of view - what mostly matters is the workflow
 template (please see the above example). Templates decide what needs to be
 done - and the workflow implementation decides how to do that.

 The user experience is like below.

 What do I need to know ?  I need to associate a workflow for the
 add-user operation.

 User first picks the *Attachment Point - *in this case add_user.

 Now - I need to specify under which conditions I need to execute this
 work flow..

 User fills the *Attachment Point Template* - execute this workflow if
 user's email address is from WSO2.

 Now - I need to select what needs to be done during the add user
 operation.

 User picks one of the available *workflow templates* - and fill the
 data required.

 If there are more than one implementations for the picked* workflow
 template *system will present you an option to pick the workflow
 (rather unlikely) if not - system already associates the available 
 workflow
 with the selected workflow template - user has to nothing there.

 Thanks  regards,
 -Prabath












 On Tue, Jul 14, 2015 at 11:36 AM, Isabelle Mauny 

Re: [Architecture] Generic workflow executor across the platform

[Frank Leymann]

Dear Pulasthi,

having a way to define simple BPEL processes in a form-based manner would
be great!  Do you have some details on this?


Best regards,
Frank

2015-04-20 8:42 GMT+02:00 Pulasthi Mahawithana pulast...@wso2.com:

 Hi Frank,

 We thought of having a simple form based approach at user end. We will use
 some BPELs as templates and get the inputs from a form to customize it.

 On Sat, Apr 11, 2015 at 8:02 PM, Frank Leymann fr...@wso2.com wrote:

 Hi Pulasthi,

 when you have users without BPEL knowledge in mind, you assume that
 these users have programming skills, correct?  I.e. that they provide the
 workflow process in JavaScript, for example, correct?

 Or do you work on a new very easy-to-use workflow language?


 Best regards,
 Frank

 2015-04-04 14:40 GMT+02:00 Pulasthi Mahawithana pulast...@wso2.com:

 Hi Frank,

 I sent a separate mail[1] with the architecture. Our main objective was
 to provide the workflow support for the events in IS and [1] was designed
 to address that. Furthermore we plan to provide a way to easily configure a
 workflow process and deploy it at BPS (for the users without BPEL
 knowlege). The work for that is in progress and we will update with the
 details soon.

 [1] [Architecture] Generic workflow support

 On Thu, Apr 2, 2015 at 8:31 PM, Frank Leymann fr...@wso2.com wrote:

 Hi Pulasthi, hi Tanja,

 can you provide a consolidated architecture figure, please?  Can you
 also position in your architecture BPS?  I assume the requirements you
 address by your architecture is the ability to create an on-ramp workflow
 for ES, AM,... in a fast way, correct?

 Thanks!


 Best regards,
 Frank

 2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana pulast...@wso2.com:

 Hi Tanya,

 The actual architecture is bit different from the one you mentioned
 here (I'll send a separate mail with details). The executors are
 responsible only for executing workflow in some manner (can be BPEL, Web
 Service or even some java code), and they can be registered as OSGI
 services. The persisting is done by the WorkflowManager before calling the
 executor.

 The WorkflowRequestHandler is the one responsible for creating
 workflow requests for an event, and handling the callback for the same
 event. So, what you said can be achieved at this point by customizing the
 workflow request creation (persist somewhere and provide link in workflow
 request). Since you create asset disabled and enable it after workflow
 completion it will work. However there are some events where we have to
 wait till the workflow completion to perform the actual action. That was
 the reason to persist the request. Also note that all workflow parameters
 are not set to the workflow executor. We can filter out parameters that
 won't be needed at workflow (I will send those details in a separate 
 mail).




 On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma ta...@wso2.com
 wrote:

 Hi Johann and all,

 As per the offline chat with Pulasthi, the executor serialize the
 workflow info and save in the database before calling the bpel service.
 (see the diagram below)


 ​So in our case if we are to use this component, we will have to do a
 network call with all the information for the workflow request (might
 include large files such as images and videos etc as admin needs to 
 approve
 them)
 Also at the call back we have to resend the same info back.

 We thought it would be more convienient and performance friendly, if
 we persist those information at our end and provide an endpoint where the
 admin can access all the information.

 For an example, say asset creation process.
 Once the user fills the asset creation form, we will persist that
 info in a database with a flag so that it won't be visible in the store 
 to
 the other users. And when triggering the workflow we send an endpoint 
 with
 a token and admin can view the created asset info with that endpoint. 
 Admin
 will be redirected to store to display the newly created (pending) asset.
 With that we don't need to worry about sending/rendering images at the
 workflow admin application.

 WDYT?

 Thanks,
 Tanya

 On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma ta...@wso2.com
 wrote:

 Hi Johann,

 Thanks for the response.
 IMO it is better if we can make the WorkflowRequestDAO more generic
 where we can plug any storing mechanism. WDYT?

 Thanks,
 Tanya

 On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby joh...@wso2.com
  wrote:

 Hi Tanya,

 On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma 
 ta...@wso2.com wrote:

 Hi all,

 We are in the process of implementing the workflow support for ES
 and came across the $Subject.
 Although many products have worflow support, seems there is no
 generic component to achieve this.

 The workflow executor for APIM [1] cannot be used platform wide
 since they pass the ApiMgtDAO to execute method in their executor.

 Similar issue is there with the IS workflow executor where they
 preserve the workflow information

Re: [Architecture] Operations Center RestAPI

[Frank Leymann]

Dear Chaya,

I have to apologize for not responding for such a long time...

In case you have a bit more information about your APIs for me, I could
comment more meaningful. E.g. when to use which header, how to structure
URLs etc.

As an initial comment, using PUT to execute commands is not really RESTful:
you should use POST. The reason for this is that PUT is considered
idempotent, i.e. you can perform the same PUT many times, always producing
the same result. I suspect that this is not the case in your scenario, i.e.
if you use the same PUT to execute a command a second time, there is no
guarantee that the command produces exactly the same results than before.
Furthermore, PUT is usually used to update a resource (sometime for
creating a resource).

Also, we (API Man team, ES team, self) are currently discussing versioning.
I suggest that you join this discussion so that we all follow the same
approach for versioning.


Best regards,
Frank

2015-03-18 13:14 GMT+01:00 Chaya Sandamali ch...@wso2.com:

 Dear Frank,

 With OC portal[1] you can view the topology of the cluster .
 (admin/admin). We have currently following URIs with external API.

 GET

- [2] - view all cluster data
- [3] - view details of a specific cluster
- [4] - view all server data of a specific cluster
- [5] - view specific sever details

 PUT

- [6] -execute cluster wide commands
- [7]- execute commands on a specific server


 [1] http://192.168.57.22:9763/sso/login.jag
 [2]
 http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/
 [3]
 http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}
 [4]
 http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/nodes
 [5]
 http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/nodes/{nodes-id}
 [6]
 http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/commands/{command-id}
 [7]
 http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/nodes/{node-id}/commands/{command-id}

 Thank you.

 Regards,
 Chaya

 Chaya Sandamali
 Software Engineering Intern
 WSo2 Inc
 Mobile: +94714905772
 LinkedIn: http://lk.linkedin.com/pub/chaya-sandamali/90/694/a59/

 On Wed, Mar 18, 2015 at 4:48 PM, Frank Leymann fr...@wso2.com wrote:

 Dear Chaya,

 is there a pointer to the REST API?  I would be interested in its URIs,
 HTTP methods used on each URI, header fields supported, status codes
 returned...

 Thanks!


 Best regards,
 Frank

 2015-03-18 9:28 GMT+01:00 Chaya Sandamali ch...@wso2.com:

 Hi all,

 After the last review,we came up with a data model for the API. I have
 attached an initial model of the design and currently the OperationsCenter
 Rest API is implemented with this new model and following are the new
 improvements in internal API part.

 Execute restart command as a cluster wide operation in *round-robin *
 fashion.

- GRACEFUL_RESTART
- FORCE_RESTART

 Execute shut down command on the cluster

- GRACEFUL_SHUTDOWN
- FORCE_SHUTDOWN

 Thank you.

 Regards,
 Chaya

 Chaya Sandamali
 Software Engineering Intern
 WSo2 Inc
 Mobile: +94714905772
 LinkedIn: http://lk.linkedin.com/pub/chaya-sandamali/90/694/a59/




 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Generic workflow support

[Frank Leymann]

Hi Pulasthi,

based on what information will the Workflow Manager decide which Workflow
Executor to use?


Best regards,
Frank

2015-04-04 14:01 GMT+02:00 Pulasthi Mahawithana pulast...@wso2.com:

 Hi,

 Following is the architecture of the workflow support framework. This was
 initially planned for IS, but can be used across the platform.



 ​

 *Workflow Request Handler*
 Build workflow requests and handle the callback requests. This interface
 can be implemented to be used for any event that need to trigger workflows.
 The request will have a uuid, and a set of parameters with their values.
 All these parameters are persisted and will be available at the callback
 handler by the time of response. However the requester can decide which of
 these parameters should be sent to the workflow executor and which should
 not.

 The callback handler will get the same request generated by the request
 builder, along with the status from the executor (approved, rejected or
 custom status). Based on the status the event can be completed or cancelled
 at the callback handler.

 *Workflow Executor*
 Execute the workflow engine and provide the response back along with the
 uuid. One implementation of this will be the BPEL/WS executor and will be
 available by default. However any other java implementation can also be
 used here.

 *WorkflowManager*
 Both RequestHandlers and Executors need to be registered here as OSGI
 services. In addition to that, WorkflowManager will

- Decide which executor should be invoked for each request.
- Persist the requests and maintain their state.
- Receive responses from the executors and forward them to their
respective callbackHandler.


 --
 *Pulasthi Mahawithana*
 Software Engineer
 WSO2 Inc., http://wso2.com/
 Mobile: +94-71-5179022
 Blog: http://blog.pulasthi.org

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Generic workflow executor across the platform

[Frank Leymann]

Hi Pulasthi,

when you have users without BPEL knowledge in mind, you assume that these
users have programming skills, correct?  I.e. that they provide the
workflow process in JavaScript, for example, correct?

Or do you work on a new very easy-to-use workflow language?


Best regards,
Frank

2015-04-04 14:40 GMT+02:00 Pulasthi Mahawithana pulast...@wso2.com:

 Hi Frank,

 I sent a separate mail[1] with the architecture. Our main objective was to
 provide the workflow support for the events in IS and [1] was designed to
 address that. Furthermore we plan to provide a way to easily configure a
 workflow process and deploy it at BPS (for the users without BPEL
 knowlege). The work for that is in progress and we will update with the
 details soon.

 [1] [Architecture] Generic workflow support

 On Thu, Apr 2, 2015 at 8:31 PM, Frank Leymann fr...@wso2.com wrote:

 Hi Pulasthi, hi Tanja,

 can you provide a consolidated architecture figure, please?  Can you also
 position in your architecture BPS?  I assume the requirements you address
 by your architecture is the ability to create an on-ramp workflow for ES,
 AM,... in a fast way, correct?

 Thanks!


 Best regards,
 Frank

 2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana pulast...@wso2.com:

 Hi Tanya,

 The actual architecture is bit different from the one you mentioned here
 (I'll send a separate mail with details). The executors are responsible
 only for executing workflow in some manner (can be BPEL, Web Service or
 even some java code), and they can be registered as OSGI services. The
 persisting is done by the WorkflowManager before calling the executor.

 The WorkflowRequestHandler is the one responsible for creating workflow
 requests for an event, and handling the callback for the same event. So,
 what you said can be achieved at this point by customizing the workflow
 request creation (persist somewhere and provide link in workflow request).
 Since you create asset disabled and enable it after workflow completion it
 will work. However there are some events where we have to wait till the
 workflow completion to perform the actual action. That was the reason to
 persist the request. Also note that all workflow parameters are not set to
 the workflow executor. We can filter out parameters that won't be needed at
 workflow (I will send those details in a separate mail).




 On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma ta...@wso2.com
 wrote:

 Hi Johann and all,

 As per the offline chat with Pulasthi, the executor serialize the
 workflow info and save in the database before calling the bpel service.
 (see the diagram below)


 ​So in our case if we are to use this component, we will have to do a
 network call with all the information for the workflow request (might
 include large files such as images and videos etc as admin needs to approve
 them)
 Also at the call back we have to resend the same info back.

 We thought it would be more convienient and performance friendly, if we
 persist those information at our end and provide an endpoint where the
 admin can access all the information.

 For an example, say asset creation process.
 Once the user fills the asset creation form, we will persist that info
 in a database with a flag so that it won't be visible in the store to the
 other users. And when triggering the workflow we send an endpoint with a
 token and admin can view the created asset info with that endpoint. Admin
 will be redirected to store to display the newly created (pending) asset.
 With that we don't need to worry about sending/rendering images at the
 workflow admin application.

 WDYT?

 Thanks,
 Tanya

 On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma ta...@wso2.com
 wrote:

 Hi Johann,

 Thanks for the response.
 IMO it is better if we can make the WorkflowRequestDAO more generic
 where we can plug any storing mechanism. WDYT?

 Thanks,
 Tanya

 On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby joh...@wso2.com
 wrote:

 Hi Tanya,

 On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma ta...@wso2.com
 wrote:

 Hi all,

 We are in the process of implementing the workflow support for ES
 and came across the $Subject.
 Although many products have worflow support, seems there is no
 generic component to achieve this.

 The workflow executor for APIM [1] cannot be used platform wide
 since they pass the ApiMgtDAO to execute method in their executor.

 Similar issue is there with the IS workflow executor where they
 preserve the workflow information in the identity database [2] (refer
 addWorkflowEntry method)


 The work flow component that was designed for IS was designed with
 the intension of extensibility. The workflow components are not coupled 
 in
 anyway to identity components. If there is anything which is blocking you
 from achieving what you need then we will like to know about it so that 
 we
 can fix our design.


 IMO other products should be able to use their own workflow info
 preservation mechanism.
 Ex

Re: [Architecture] Generic workflow executor across the platform

[Frank Leymann]

Hi Pulasthi, hi Tanja,

can you provide a consolidated architecture figure, please?  Can you also
position in your architecture BPS?  I assume the requirements you address
by your architecture is the ability to create an on-ramp workflow for ES,
AM,... in a fast way, correct?

Thanks!


Best regards,
Frank

2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana pulast...@wso2.com:

 Hi Tanya,

 The actual architecture is bit different from the one you mentioned here
 (I'll send a separate mail with details). The executors are responsible
 only for executing workflow in some manner (can be BPEL, Web Service or
 even some java code), and they can be registered as OSGI services. The
 persisting is done by the WorkflowManager before calling the executor.

 The WorkflowRequestHandler is the one responsible for creating workflow
 requests for an event, and handling the callback for the same event. So,
 what you said can be achieved at this point by customizing the workflow
 request creation (persist somewhere and provide link in workflow request).
 Since you create asset disabled and enable it after workflow completion it
 will work. However there are some events where we have to wait till the
 workflow completion to perform the actual action. That was the reason to
 persist the request. Also note that all workflow parameters are not set to
 the workflow executor. We can filter out parameters that won't be needed at
 workflow (I will send those details in a separate mail).




 On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma ta...@wso2.com
 wrote:

 Hi Johann and all,

 As per the offline chat with Pulasthi, the executor serialize the
 workflow info and save in the database before calling the bpel service.
 (see the diagram below)


 ​So in our case if we are to use this component, we will have to do a
 network call with all the information for the workflow request (might
 include large files such as images and videos etc as admin needs to approve
 them)
 Also at the call back we have to resend the same info back.

 We thought it would be more convienient and performance friendly, if we
 persist those information at our end and provide an endpoint where the
 admin can access all the information.

 For an example, say asset creation process.
 Once the user fills the asset creation form, we will persist that info in
 a database with a flag so that it won't be visible in the store to the
 other users. And when triggering the workflow we send an endpoint with a
 token and admin can view the created asset info with that endpoint. Admin
 will be redirected to store to display the newly created (pending) asset.
 With that we don't need to worry about sending/rendering images at the
 workflow admin application.

 WDYT?

 Thanks,
 Tanya

 On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma ta...@wso2.com
 wrote:

 Hi Johann,

 Thanks for the response.
 IMO it is better if we can make the WorkflowRequestDAO more generic
 where we can plug any storing mechanism. WDYT?

 Thanks,
 Tanya

 On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby joh...@wso2.com
 wrote:

 Hi Tanya,

 On Tue, Mar 31, 2015 at 4:59 PM, Tanya Madurapperuma ta...@wso2.com
 wrote:

 Hi all,

 We are in the process of implementing the workflow support for ES and
 came across the $Subject.
 Although many products have worflow support, seems there is no generic
 component to achieve this.

 The workflow executor for APIM [1] cannot be used platform wide since
 they pass the ApiMgtDAO to execute method in their executor.

 Similar issue is there with the IS workflow executor where they
 preserve the workflow information in the identity database [2] (refer
 addWorkflowEntry method)


 The work flow component that was designed for IS was designed with the
 intension of extensibility. The workflow components are not coupled in
 anyway to identity components. If there is anything which is blocking you
 from achieving what you need then we will like to know about it so that we
 can fix our design.


 IMO other products should be able to use their own workflow info
 preservation mechanism.
 Ex: To store in the registry
To store in a database
 Say in ES, we want to provide workflow support for asset creation.
 Storing asset level info in Identity database doesn't make sense.


 Don't think of it as Identity database. Think of it as a database
 coming from another feature repository. It can be any product like IS. If
 the same workflow component was developed by APIM then it would be AM_
 tables. Apart from the naming convention the functionality is generic and
 extensible. The table naming convention comes from which product team
 develops it, thats all.

 Using Identity database in ES is not wrong. If you are installing IS
 feature you have to install the database scripts also. I know previously
 APIM did the same mistake of copying the identity tables into apim scripts
 and not executing identity scripts. I know how much duplication it made and
 how much 

Re: [Architecture] RFC: RESTFul API for API Manager

[Frank Leymann]

Hi Nirmal,

camel case should not be used because:

   - the domain name (aka host) is not case sensitive by definition,
   - some servers treat the path not as case sensitive

thus, camel case style will be confusing, implying differences in API names
that don't exist. Nevertheless, a couple of vendors use camel style, but
the public critique is that these APIs are designed by Java programmers ;-)

Using underscores is typically seen as problematic, because API URLs are
often rendered in HTML pages (e.g. in documentation; as error descriptions;
in generated pages;...). And the browser will interpret them as links,
thus, rendering them as underlined: the underscore is then hard to read.

As a *consequence*, the general recommendation is to *use hyphens* (-).
 :-)



Best regards,
Frank

2015-04-01 10:34 GMT+02:00 Nirmal Fernando nir...@wso2.com:

 This is very helpful Frank, and as you mentioned these
 controlled-resources are always lead to discussion. Do you have any
 comments on the usage of '-' instead of camel case ?

 On Tue, Mar 31, 2015 at 10:51 PM, Frank Leymann fr...@wso2.com wrote:

 Hi Jo, hi Manu,

 how to cope with actions that cannot be mapped onto the CRUD methods on
 individual resources or collection resources is always a matter of
 discussion and taste when designing REST interfaces.

 A very often used guideline is to use so-called *controller resources*.
 I controller resources represents an application specific operation that
 acts on one or more individual resources or collection resources in an
 atomic manner. The copy-api is such a controller resource.

 There are two ways to design URIs of controller resources. First, you
 append the name of the action to one of the URIs that you atomically want
 to act on, and other parameters follow in the query string; sometimes it is
 random which of the URIs to append the name of the action to - this is why
 I personally don't like this naming scheme. The second design uses the name
 of the action as URI and the query string contains the parameters
 required by the action - this is what I personally prefer because it's
 deterministic and symmetric (but again, it's a matter of taste.  However
 you design the URI you use POST as the http method to interact with the
 controller resource.

 In our concrete case of copy-api the two options are:

 1. /apis/{apiId}/copy-api
 or
 2. /copy-api?{apiID}

 By the way, the similar case is the change-lifecycle controller resource.

 Another reason why I like API design (2) is as follows.  Often you need
 actions on individual resources that don't manipulate (or retrieve) a
 resource. Such actions are designed as resources called *processing
 function resources* or *computing resources*. The standard example is
 verifying a credit card. The design of the URIs of such processing function
 resources always follows number (2).  Because processing functions
 resources never manipulate resources its http method is always GET, by the
 way.

 Finally, controller resources are used from time to time to update parts
 of individual resources.  Http has the PATCH method for this purpose, but
 not all web servers support PATCH. PUT itself will substitute complete
 resources, i.e. updating parts of an individual resource is not intended
 via PUT.  This is why specific controller resources may be used for partial
 updates.




 Best regards,
 Frank

 2015-03-30 19:57 GMT+02:00 Joseph Fonseka jos...@wso2.com:

 Hi Manu

 Copy API will duplicate not just the resource it will duplicate all the
 resources associated to it as well eg. Documents. So re-posting the API
 resource json will not be sufficient in this particular case. But there is
 a possibility of duplicating the associated resources from the client as
 well but IMHO that will complicated the client implementation.

 Nevertheless its a problem that we face how to represent an action as a
 resource.  Currently we have adopted action-resource or attr acted
 upon kind of notation.

 Regards
 Jo


 On Mon, Mar 30, 2015 at 4:49 PM, Manuranga Perera m...@wso2.com wrote:

 Hi Frank,
 I see few endpoints representing actions rather than resources. For
 example POST /apis/{apiId}/copy-api.
 This is an action because there is no resource called copy-api. I
 would rather see it as posting an existing API to the /apis.
 In a HATEOS system we will be posting the href of an existing API to
 /apis endpoint. Since we are not there yet, we can use some json
 representation of the existing API.

 What do you think?

 On Tue, Mar 31, 2015 at 12:03 AM, Joseph Fonseka jos...@wso2.com
 wrote:

 Hi Frank

 Thanks for the feedback. And it is nice to see how we can control
 cashing and concurrency with the additional headers. We will update the
 remaining APIs with the same concepts.

 Please let us know a convenient time for a call to discuss on it
 further.

 Also we will try to document these design decisions and concepts to
 benefit APIs created in the future.

 BTW. The changes were

Re: [Architecture] RFC: RESTFul API for API Manager

[Frank Leymann]

Hi Jo,

is it possible for you to have a call tomorrow, Wednesday, 4/1, 2pm Colombo
time (i.e. 10:30am Germany, daylight-savings-time).  I thing a 30...60
minutes will be suffice. Main purpose would be how to proceed :-)

I find Skype more reliable than Hangouts. Would you mind about a Skype
call?  My SkypeID is frank.leymann

Talk to you then!


Best regards,
Frank

2015-03-30 13:03 GMT+02:00 Joseph Fonseka jos...@wso2.com:

 Hi Frank

 Thanks for the feedback. And it is nice to see how we can control cashing
 and concurrency with the additional headers. We will update the remaining
 APIs with the same concepts.

 Please let us know a convenient time for a call to discuss on it further.

 Also we will try to document these design decisions and concepts to
 benefit APIs created in the future.

 BTW. The changes were pushed to the repo.

 Thanks
 Jo


 [1] http://hevayo.github.io/restful-apim/

 On Sat, Mar 28, 2015 at 12:47 AM, Frank Leymann fr...@wso2.com wrote:

 Hi Jo,

 again, thanks for your work: we'll get a nice RESTful API :-)   In the
 Richardson maturity model we'll get to level 2 (not level 3 because we are
 leaving out HATEOS - which is something that is not used often today in
 practice anyhow).

 I exported the YAML of the API, put it into a Word document and used the
 change tracking feature to comment/modify across the document - please
 find the document attached. (Frank Input - API Manager API -
 2015-03-27.docx)

 All the changes I made to YAML itself is in the separate swagger YAML
 file I attached too.  I used the swagger 2.0 tool to create this YAML, and
 the tool shows no syntax errors... So you may import it into your tool
 without problems. (FL Input API Manager API - 2015-03-27.yaml)

 I worked on the apis of the /apis and /apis/{apiID} resources. Before I
 continue, I suggest that we have a discussion (i.e. a call) to discuss the
 changes/suggestions I made. We need to agree whether this fits into the
 plan for implementing in the next release.

 Looking forward



 Best regards,
 Frank

 2015-03-26 4:52 GMT+01:00 Joseph Fonseka jos...@wso2.com:

 Hi Frank

 What are the headers we should include ?

 1. For the access token header we can define it globally in the security
 definition [1]
 https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#securityDefinitionsObject
 2. Content-type headers are covered by the consumes and produces
 attributes [2]
 https://github.com/hevayo/restful-apim/blob/master/apim.yaml#L18-L19
 3. For post methods we have an option of sending Link header with a
 URL to newly created resource rather than returning newly created resource
 JSON.

 Thanks
 Jo

 [1]
 https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#securityDefinitionsObject

 [2] https://github.com/hevayo/restful-apim/blob/master/apim.yaml#L18-L19

 On Wed, Mar 25, 2015 at 3:51 PM, Frank Leymann fr...@wso2.com wrote:

 Hi Jo,

 nice piece of work!

 What is still needed is a description of the header fields for both,
 the requests and APIs.



 Best regards,
 Frank

 2015-03-24 17:34 GMT+01:00 Joseph Fonseka jos...@wso2.com:

 Hi All

 We are planing to implement a RESTFul API to expose the API Manager
 functionality. This will be a replacement to the currently provided Store
 and Publisher APIs [1]
 https://docs.wso2.com/display/AM180/Publisher+APIs  [2]
 https://docs.wso2.com/display/AM180/Store+APIs.

 Main Motivation.
 1. The current APIs are not RESTful and they do not cover all the
 functionality.
 2. To make it easy to integrate and automate API manager functionality
 with 3rd party systems.
 3. To provide better security with Oauth.
 4. To provide better versioning and documentation with the API.

 As a start we have written a draft version of the API definition which
 you can find here [3] http://hevayo.github.io/restful-apim/.

 Following is a rough implementation plan.
 1. Work on the API Definition, get feed back from users and finalize.
 2. Implementation. ( Architecture , Jax-RS ?)
 3. Adding Security. ( O-auth, scopes ? )
 4. Testing.
 5. Documentation.

 API definition was written with Swagger 2 once completed we can use it
 to generate server stubs, client stubs and documentation.

 Please share your thoughts.

 Thanks
 Jo

 [1] https://docs.wso2.com/display/AM180/Publisher+APIs
 [2] https://docs.wso2.com/display/AM180/Store+APIs
 [3] http://hevayo.github.io/restful-apim/

 --
 *Joseph Fonseka*
  WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: +94 772 512 430
 skype: jpfonseka

 * http://lk.linkedin.com/in/rumeshbandara*





 --

 --
 *Joseph Fonseka*
  WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: +94 772 512 430
 skype: jpfonseka

 * http://lk.linkedin.com/in/rumeshbandara*





 --

 --
 *Joseph Fonseka*
  WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: +94 772 512 430
 skype: jpfonseka

 * http://lk.linkedin.com/in/rumeshbandara

Re: [Architecture] RFC: RESTFul API for API Manager

[Frank Leymann]

Hi Jo, hi Manu,

how to cope with actions that cannot be mapped onto the CRUD methods on
individual resources or collection resources is always a matter of
discussion and taste when designing REST interfaces.

A very often used guideline is to use so-called *controller resources*. I
controller resources represents an application specific operation that acts
on one or more individual resources or collection resources in an atomic
manner. The copy-api is such a controller resource.

There are two ways to design URIs of controller resources. First, you
append the name of the action to one of the URIs that you atomically want
to act on, and other parameters follow in the query string; sometimes it is
random which of the URIs to append the name of the action to - this is why
I personally don't like this naming scheme. The second design uses the name
of the action as URI and the query string contains the parameters
required by the action - this is what I personally prefer because it's
deterministic and symmetric (but again, it's a matter of taste.  However
you design the URI you use POST as the http method to interact with the
controller resource.

In our concrete case of copy-api the two options are:

1. /apis/{apiId}/copy-api
or
2. /copy-api?{apiID}

By the way, the similar case is the change-lifecycle controller resource.

Another reason why I like API design (2) is as follows.  Often you need
actions on individual resources that don't manipulate (or retrieve) a
resource. Such actions are designed as resources called *processing
function resources* or *computing resources*. The standard example is
verifying a credit card. The design of the URIs of such processing function
resources always follows number (2).  Because processing functions
resources never manipulate resources its http method is always GET, by the
way.

Finally, controller resources are used from time to time to update parts of
individual resources.  Http has the PATCH method for this purpose, but not
all web servers support PATCH. PUT itself will substitute complete
resources, i.e. updating parts of an individual resource is not intended
via PUT.  This is why specific controller resources may be used for partial
updates.




Best regards,
Frank

2015-03-30 19:57 GMT+02:00 Joseph Fonseka jos...@wso2.com:

 Hi Manu

 Copy API will duplicate not just the resource it will duplicate all the
 resources associated to it as well eg. Documents. So re-posting the API
 resource json will not be sufficient in this particular case. But there is
 a possibility of duplicating the associated resources from the client as
 well but IMHO that will complicated the client implementation.

 Nevertheless its a problem that we face how to represent an action as a
 resource.  Currently we have adopted action-resource or attr acted
 upon kind of notation.

 Regards
 Jo


 On Mon, Mar 30, 2015 at 4:49 PM, Manuranga Perera m...@wso2.com wrote:

 Hi Frank,
 I see few endpoints representing actions rather than resources. For
 example POST /apis/{apiId}/copy-api.
 This is an action because there is no resource called copy-api. I would
 rather see it as posting an existing API to the /apis.
 In a HATEOS system we will be posting the href of an existing API to
 /apis endpoint. Since we are not there yet, we can use some json
 representation of the existing API.

 What do you think?

 On Tue, Mar 31, 2015 at 12:03 AM, Joseph Fonseka jos...@wso2.com wrote:

 Hi Frank

 Thanks for the feedback. And it is nice to see how we can control
 cashing and concurrency with the additional headers. We will update the
 remaining APIs with the same concepts.

 Please let us know a convenient time for a call to discuss on it
 further.

 Also we will try to document these design decisions and concepts to
 benefit APIs created in the future.

 BTW. The changes were pushed to the repo.

 Thanks
 Jo


 [1] http://hevayo.github.io/restful-apim/

 On Sat, Mar 28, 2015 at 12:47 AM, Frank Leymann fr...@wso2.com wrote:

 Hi Jo,

 again, thanks for your work: we'll get a nice RESTful API :-)   In the
 Richardson maturity model we'll get to level 2 (not level 3 because we are
 leaving out HATEOS - which is something that is not used often today in
 practice anyhow).

 I exported the YAML of the API, put it into a Word document and used
 the change tracking feature to comment/modify across the document -
 please find the document attached. (Frank Input - API Manager API -
 2015-03-27.docx)

 All the changes I made to YAML itself is in the separate swagger YAML
 file I attached too.  I used the swagger 2.0 tool to create this YAML, and
 the tool shows no syntax errors... So you may import it into your tool
 without problems. (FL Input API Manager API - 2015-03-27.yaml)

 I worked on the apis of the /apis and /apis/{apiID} resources. Before I
 continue, I suggest that we have a discussion (i.e. a call) to discuss the
 changes/suggestions I made. We need to agree whether this fits into the
 plan

Re: [Architecture] Operations Center RestAPI

[Frank Leymann]

Hi Nirmal,

I fully agree about naming APIs according to the REST guidelines :-)

Since we are currently in the process of creating a bunch of RESTful APIs,
I suggest to make sure that we have a WSO2-wide naming scheme for the
resources we support to manipulate via our APIs.  Obviously, the following
alternatives come to mind:

   1. The ideal way would be a managed and maintained list of WSO2-wide
   unique names of these resources. And these names would be product
   neutral.  The base URL would be like http://wso2.com/api (to be refined
   depending on how versioning will be done) and then the name of the resource
   will follow (like /clusters).
  - PRO:  nice governance structure for all of our APIs. Consistent
  naming, nice to comprehend by our customers.
  - CON:  we need a process to register APIs within WSO2
   2. I we want a leaner naming mechanism we need some sort of namespace.
   This could be done by using as base URL a template like
   http://wso2.com/api/{product} or http://wso2.com/{product}/api
  - PRO: no need for WSO2-wide unique names of resources; lean process.
  - CON: more complex, sometimes non-natural names, no consistent
  naming - i.e. more difficult to learn/understand by our customers.

Thoughts, comments, opinions are cordially welcome...


Best regards,
Frank

2015-03-18 13:36 GMT+01:00 Nirmal Fernando nir...@wso2.com:

 Hi Chaya,

 Do we really need OCServer/services/oc-server/external/
 http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/ 
 part
 in the URL? In a RESTFull API, every such path element should represent a
 resource and also should be nouns.

 You can use the /api as the root context, it's how GitHub API designed too.

 I suggest /api/clusters instead of /
 OCServer/services/oc-server/external/oc/clusters/
 http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/


 On Wed, Mar 18, 2015 at 5:44 PM, Chaya Sandamali ch...@wso2.com wrote:

 Dear Frank,

 With OC portal[1] you can view the topology of the cluster .
 (admin/admin). We have currently following URIs with external API.

 GET

- [2] - view all cluster data
- [3] - view details of a specific cluster
- [4] - view all server data of a specific cluster
- [5] - view specific sever details

 PUT

- [6] -execute cluster wide commands
- [7]- execute commands on a specific server


 [1] http://192.168.57.22:9763/sso/login.jag
 [2]
 http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/
 [3]
 http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}
 [4]
 http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/nodes
 [5]
 http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/nodes/{nodes-id}
 [6]
 http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/commands/{command-id}
 [7]
 http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/nodes/{node-id}/commands/{command-id}

 Thank you.

 Regards,
 Chaya

 Chaya Sandamali
 Software Engineering Intern
 WSo2 Inc
 Mobile: +94714905772
 LinkedIn: http://lk.linkedin.com/pub/chaya-sandamali/90/694/a59/

 On Wed, Mar 18, 2015 at 4:48 PM, Frank Leymann fr...@wso2.com wrote:

 Dear Chaya,

 is there a pointer to the REST API?  I would be interested in its URIs,
 HTTP methods used on each URI, header fields supported, status codes
 returned...

 Thanks!


 Best regards,
 Frank

 2015-03-18 9:28 GMT+01:00 Chaya Sandamali ch...@wso2.com:

 Hi all,

 After the last review,we came up with a data model for the API. I have
 attached an initial model of the design and currently the OperationsCenter
 Rest API is implemented with this new model and following are the new
 improvements in internal API part.

 Execute restart command as a cluster wide operation in *round-robin *
 fashion.

- GRACEFUL_RESTART
- FORCE_RESTART

 Execute shut down command on the cluster

- GRACEFUL_SHUTDOWN
- FORCE_SHUTDOWN

 Thank you.

 Regards,
 Chaya

 Chaya Sandamali
 Software Engineering Intern
 WSo2 Inc
 Mobile: +94714905772
 LinkedIn: http://lk.linkedin.com/pub/chaya-sandamali/90/694/a59/




 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




 --

 Thanks  regards,
 Nirmal

 Senior Software Engineer- Platform Technologies Team, WSO2 Inc.
 Mobile: +94715779733
 Blog: http://nirmalfdo.blogspot.com/



 ___
 Architecture mailing list

Re: [Architecture] RFC: RESTFul API for API Manager

[Frank Leymann]

Hi Jo,

again, thanks for your work: we'll get a nice RESTful API :-)   In the
Richardson maturity model we'll get to level 2 (not level 3 because we are
leaving out HATEOS - which is something that is not used often today in
practice anyhow).

I exported the YAML of the API, put it into a Word document and used the
change tracking feature to comment/modify across the document - please
find the document attached. (Frank Input - API Manager API -
2015-03-27.docx)

All the changes I made to YAML itself is in the separate swagger YAML file
I attached too.  I used the swagger 2.0 tool to create this YAML, and the
tool shows no syntax errors... So you may import it into your tool without
problems. (FL Input API Manager API - 2015-03-27.yaml)

I worked on the apis of the /apis and /apis/{apiID} resources. Before I
continue, I suggest that we have a discussion (i.e. a call) to discuss the
changes/suggestions I made. We need to agree whether this fits into the
plan for implementing in the next release.

Looking forward



Best regards,
Frank

2015-03-26 4:52 GMT+01:00 Joseph Fonseka jos...@wso2.com:

 Hi Frank

 What are the headers we should include ?

 1. For the access token header we can define it globally in the security
 definition [1]
 https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#securityDefinitionsObject
 2. Content-type headers are covered by the consumes and produces
 attributes [2]
 https://github.com/hevayo/restful-apim/blob/master/apim.yaml#L18-L19
 3. For post methods we have an option of sending Link header with a URL
 to newly created resource rather than returning newly created resource JSON.

 Thanks
 Jo

 [1]
 https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#securityDefinitionsObject

 [2] https://github.com/hevayo/restful-apim/blob/master/apim.yaml#L18-L19

 On Wed, Mar 25, 2015 at 3:51 PM, Frank Leymann fr...@wso2.com wrote:

 Hi Jo,

 nice piece of work!

 What is still needed is a description of the header fields for both, the
 requests and APIs.



 Best regards,
 Frank

 2015-03-24 17:34 GMT+01:00 Joseph Fonseka jos...@wso2.com:

 Hi All

 We are planing to implement a RESTFul API to expose the API Manager
 functionality. This will be a replacement to the currently provided Store
 and Publisher APIs [1]
 https://docs.wso2.com/display/AM180/Publisher+APIs  [2]
 https://docs.wso2.com/display/AM180/Store+APIs.

 Main Motivation.
 1. The current APIs are not RESTful and they do not cover all the
 functionality.
 2. To make it easy to integrate and automate API manager functionality
 with 3rd party systems.
 3. To provide better security with Oauth.
 4. To provide better versioning and documentation with the API.

 As a start we have written a draft version of the API definition which
 you can find here [3] http://hevayo.github.io/restful-apim/.

 Following is a rough implementation plan.
 1. Work on the API Definition, get feed back from users and finalize.
 2. Implementation. ( Architecture , Jax-RS ?)
 3. Adding Security. ( O-auth, scopes ? )
 4. Testing.
 5. Documentation.

 API definition was written with Swagger 2 once completed we can use it
 to generate server stubs, client stubs and documentation.

 Please share your thoughts.

 Thanks
 Jo

 [1] https://docs.wso2.com/display/AM180/Publisher+APIs
 [2] https://docs.wso2.com/display/AM180/Store+APIs
 [3] http://hevayo.github.io/restful-apim/

 --
 *Joseph Fonseka*
  WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: +94 772 512 430
 skype: jpfonseka

 * http://lk.linkedin.com/in/rumeshbandara*





 --

 --
 *Joseph Fonseka*
  WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: +94 772 512 430
 skype: jpfonseka

 * http://lk.linkedin.com/in/rumeshbandara*




Frank Input - API Manager API - 2015-03-27.docx
Description: MS-Word 2007 document


FL Input API Manager API - 2015-03-27.yaml
Description: Binary data
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] RFC: RESTFul API for API Manager

[Frank Leymann]

Hi Jo,

I'll provide my input until Sunday evening...


Best regards,
Frank

2015-03-26 4:52 GMT+01:00 Joseph Fonseka jos...@wso2.com:

 Hi Frank

 What are the headers we should include ?

 1. For the access token header we can define it globally in the security
 definition [1]
 https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#securityDefinitionsObject
 2. Content-type headers are covered by the consumes and produces
 attributes [2]
 https://github.com/hevayo/restful-apim/blob/master/apim.yaml#L18-L19
 3. For post methods we have an option of sending Link header with a URL
 to newly created resource rather than returning newly created resource JSON.

 Thanks
 Jo

 [1]
 https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#securityDefinitionsObject

 [2] https://github.com/hevayo/restful-apim/blob/master/apim.yaml#L18-L19

 On Wed, Mar 25, 2015 at 3:51 PM, Frank Leymann fr...@wso2.com wrote:

 Hi Jo,

 nice piece of work!

 What is still needed is a description of the header fields for both, the
 requests and APIs.



 Best regards,
 Frank

 2015-03-24 17:34 GMT+01:00 Joseph Fonseka jos...@wso2.com:

 Hi All

 We are planing to implement a RESTFul API to expose the API Manager
 functionality. This will be a replacement to the currently provided Store
 and Publisher APIs [1]
 https://docs.wso2.com/display/AM180/Publisher+APIs  [2]
 https://docs.wso2.com/display/AM180/Store+APIs.

 Main Motivation.
 1. The current APIs are not RESTful and they do not cover all the
 functionality.
 2. To make it easy to integrate and automate API manager functionality
 with 3rd party systems.
 3. To provide better security with Oauth.
 4. To provide better versioning and documentation with the API.

 As a start we have written a draft version of the API definition which
 you can find here [3] http://hevayo.github.io/restful-apim/.

 Following is a rough implementation plan.
 1. Work on the API Definition, get feed back from users and finalize.
 2. Implementation. ( Architecture , Jax-RS ?)
 3. Adding Security. ( O-auth, scopes ? )
 4. Testing.
 5. Documentation.

 API definition was written with Swagger 2 once completed we can use it
 to generate server stubs, client stubs and documentation.

 Please share your thoughts.

 Thanks
 Jo

 [1] https://docs.wso2.com/display/AM180/Publisher+APIs
 [2] https://docs.wso2.com/display/AM180/Store+APIs
 [3] http://hevayo.github.io/restful-apim/

 --
 *Joseph Fonseka*
  WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: +94 772 512 430
 skype: jpfonseka

 * http://lk.linkedin.com/in/rumeshbandara*





 --

 --
 *Joseph Fonseka*
  WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: +94 772 512 430
 skype: jpfonseka

 * http://lk.linkedin.com/in/rumeshbandara*


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Operations Center RestAPI

[Frank Leymann]

Dear Chaya,

is there a pointer to the REST API?  I would be interested in its URIs,
HTTP methods used on each URI, header fields supported, status codes
returned...

Thanks!


Best regards,
Frank

2015-03-18 9:28 GMT+01:00 Chaya Sandamali ch...@wso2.com:

 Hi all,

 After the last review,we came up with a data model for the API. I have
 attached an initial model of the design and currently the OperationsCenter
 Rest API is implemented with this new model and following are the new
 improvements in internal API part.

 Execute restart command as a cluster wide operation in *round-robin *
 fashion.

- GRACEFUL_RESTART
- FORCE_RESTART

 Execute shut down command on the cluster

- GRACEFUL_SHUTDOWN
- FORCE_SHUTDOWN

 Thank you.

 Regards,
 Chaya

 Chaya Sandamali
 Software Engineering Intern
 WSo2 Inc
 Mobile: +94714905772
 LinkedIn: http://lk.linkedin.com/pub/chaya-sandamali/90/694/a59/




 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Improving Impact Analysis Feature on G-Reg

[Frank Leymann]

Senaka,

multiple relatioships are fine: it doesn't occur very often, and if, more
than two relations are rare.

And, yes, by all means, the ability to toggle particular collections of
relationship types on and off is extremely helpful!  Similarly, the feature
that Isabelle brought up, namely specifying the level of children of a
certain node to view, will help comprehension...

Who will detect policy violations (and: which kind of policies?)?  If
policy violations are automatically detected, corresponding workflows might
be kicked-off to repair the violations. This will significantly contribute
to compliance, an key aspect of governance.


Best regards,
Frank

2015-02-22 20:34 GMT+01:00 Senaka Fernando sen...@wso2.com:

 Hi Frank, Jerad,

 Useful thought on colouring relationships. Frank, I have one question.
 What if multiple relationships coincide between two specific nodes, won't
 that complicate things? I have a feeling that turning relationships on and
 off (as in Jerad's GIF) is a way of visualizing how things connect and how
 deep. WDYT?

 Also, I have another question. Something I spoke about in WSO2Con US 2013,
 :), on G-Reg 5.0.0 was that you can use this view to understand lifecycle
 state, policy violations etc. Didn't see that part being addressed though.
 Jerad, given the things you've done so far, I don't expect this to be an
 impossible task, but how easy would it be to annotate nodes (using colours
 or miniature overlay graphics) to achieve this?

 Put together, these features alone will make G-Reg 10-times more usable
 that where it stands today in terms of Asset Governance.

 Thanks,
 Senaka.

 On Sun, Feb 22, 2015 at 5:00 PM, Frank Leymann fr...@wso2.com wrote:

 HI Jerad,

 thanks, the gif was helpful :-)   Very nice tool!

 Coloring nodes is optional (I would even argue: not needed).  But
 coloring relations will in fact improve comprehension of the user.  See for
 example when you select in your gif a subset of relationship types: it is
 still unclear which relationship types connect the nodes.  I would rank
 relationship coloring much higher than node coloring.



 Best regards,
 Frank

 2015-02-21 6:31 GMT+01:00 Jerad Rutnam je...@wso2.com:

 Hi Frank,

 I get your point. Agree for giving users more flexible features. Yes, we
 were discussing about the coloring nodes, and this was decided to have like
 an optional feature. So it will be an enhance feature for filtering option.
 Which we decided to work on after releasing the tool. :)

 Please find the attached animated .gif image, that will give better idea
 about the tool functions. (Use chrome or better .gif previewer to open -
 since the file is large, it might not work on all the browsers correctly)

 Thanks,
 Jerad
 --
 *Jerad Rutnam*
 *Software Engineer*

 WSO2 Inc.
 lean | enterprise | middleware
 M : +94 77 959 1609 | E : je...@wso2.com | W : www.wso2.com





 --


 *[image: http://wso2.com] http://wso2.comSenaka Fernando*
 Solutions Architect; WSO2 Inc.; http://wso2.com



 *Member; Apache Software Foundation; http://apache.org
 http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1
 408 754 7388 %2B1%20408%20754%207388; ext: 51736*;


 *M: +44 782 741 1966 %2B44%20782%20741%201966Linked-In:
 http://linkedin.com/in/senakafernando
 http://linkedin.com/in/senakafernando*Lean . Enterprise . Middleware

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Improving Impact Analysis Feature on G-Reg

[Frank Leymann]

Good 3D is hard to achieve  ;-)


Best regards,
Frank

2015-02-23 10:55 GMT+01:00 Isabelle Mauny isabe...@wso2.com:

 +1 - The relationship path is very important to highlight.

 Right-click on a node, say Show Relationships , or Show Dependencies - And
 then center the object and highlight the relationships.. Now, I am going to
 complicate this, but… This really calls for 3D :D -  Let the user rotate
 graph ..

 Isabelle.


 -
 *Isabelle Mauny*
 VP, Product Management - WSO2, Inc. - http://wso2.com/


 On Sun, Feb 22, 2015 at 6:00 PM, Frank Leymann fr...@wso2.com wrote:

 HI Jerad,

 thanks, the gif was helpful :-)   Very nice tool!

 Coloring nodes is optional (I would even argue: not needed).  But
 coloring relations will in fact improve comprehension of the user.  See for
 example when you select in your gif a subset of relationship types: it is
 still unclear which relationship types connect the nodes.  I would rank
 relationship coloring much higher than node coloring.



 Best regards,
 Frank

 2015-02-21 6:31 GMT+01:00 Jerad Rutnam je...@wso2.com:

 Hi Frank,

 I get your point. Agree for giving users more flexible features. Yes, we
 were discussing about the coloring nodes, and this was decided to have like
 an optional feature. So it will be an enhance feature for filtering option.
 Which we decided to work on after releasing the tool. :)

 Please find the attached animated .gif image, that will give better idea
 about the tool functions. (Use chrome or better .gif previewer to open -
 since the file is large, it might not work on all the browsers correctly)

 Thanks,
 Jerad
 --
 *Jerad Rutnam*
 *Software Engineer*

 WSO2 Inc.
 lean | enterprise | middleware
 M : +94 77 959 1609 | E : je...@wso2.com | W : www.wso2.com




___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Improving Impact Analysis Feature on G-Reg

[Frank Leymann]

HI Jerad,

thanks, the gif was helpful :-)   Very nice tool!

Coloring nodes is optional (I would even argue: not needed).  But coloring
relations will in fact improve comprehension of the user.  See for example
when you select in your gif a subset of relationship types: it is still
unclear which relationship types connect the nodes.  I would rank
relationship coloring much higher than node coloring.



Best regards,
Frank

2015-02-21 6:31 GMT+01:00 Jerad Rutnam je...@wso2.com:

 Hi Frank,

 I get your point. Agree for giving users more flexible features. Yes, we
 were discussing about the coloring nodes, and this was decided to have like
 an optional feature. So it will be an enhance feature for filtering option.
 Which we decided to work on after releasing the tool. :)

 Please find the attached animated .gif image, that will give better idea
 about the tool functions. (Use chrome or better .gif previewer to open -
 since the file is large, it might not work on all the browsers correctly)

 Thanks,
 Jerad
 --
 *Jerad Rutnam*
 *Software Engineer*

 WSO2 Inc.
 lean | enterprise | middleware
 M : +94 77 959 1609 | E : je...@wso2.com | W : www.wso2.com

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] BAM 3.0 REST APIs for AnalyticsDataService / Indexing / Search

[Frank Leymann]

Hi Gimantha,

it depends on the scenario:  if you want to check existence of resource
it's fine to use a GET on this resource and receive a 404 Not Found.

But the subtlety is that Not Found according to HTTP is statement in
time: you cannot infer that the resource does not exist, all that 404
says is that it cannot be found at this point in time, i.e. it maybe found
later. If your scenario doesn't care about that you are fine.

Furthermore, in case the resource in fact is found, the GET on this
resource will return the complete table. This might not be acceptable if
you only want to get an indicator that the exists. The signal for existence
shouldn't the possibly huge table itself.

Thus, depending on your scenario you may consider a corresponding
function.  By the way, this is completely compliant to the REST style that
foresees such processing function resources.


Best regards,
Frank

2015-02-14 15:01 GMT+01:00 Gimantha Bandara giman...@wso2.com:

 Hi Manuranga,

 Already *GET /analytics/tables/{tableName} *returns 404 if the
 table doesn't exists. So we will not need a separate API. Thanks for your
 feedback.

 On Sat, Feb 14, 2015 at 12:22 PM, Manuranga Perera m...@wso2.com wrote:

 there shouldn't be a separate end point for is-exists

 *GET /analytics/tables/{tableName}* - Will return table informing if it
 exists and if not it should return 404

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




 --
 Gimantha Bandara
 Software Engineer
 WSO2. Inc : http://wso2.com
 Mobile : +94714961919

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Process center- Multiple predecessor/successor support for chevron diagram editor

[Frank Leymann]

Hi Himasha,

thanks for your response!  Especially adding the auto-layout when switching
on/off the proximity annotations will be pretty cool (aka a powerful
feature) of your editor! I will really like it :-)

Your question on my bullet (4):  What you explained is fine - i.e. the
Reset button will only be available before the first save on a new
diagram will be requested.  Which brings up another (minor) question:  once
a diagram is saved can I select more than one phase and/or arrow for
deletion, or do I have to delete one modeling element after the other.
Selection more than one would be fine.

Thanks again!


Best regards,
Frank

2015-01-17 3:46 GMT+01:00 Himasha Guruge himas...@wso2.com:

Hi Frank,

 Please find  below comments/answers regarding the queries.

1. Can we add arrow heads to the lines between the phases (aka
individual chevrons)?  E.g. in later releases we will likely support to
draw directed graphs without inferring the direction of an arrow from its
geometric position. In this sense, the current diagram [1] is a bit
confusing: is ship product a successor/predecessor of check payment
and/or request refund?

 Yes Frank, I think adding arrow heads will make things
 more clear to the user specially in a scenario as you   mentioned. The
 logic used here to derive the predecessor/successor is to check the
 row/column numbers (placement of phases). Therefore it will recognize 'Ship
 product' as a successor of 'check payment' and 'ship product' a predecessor
 of 'request refund'.  Will add arrow heads as requested.

 2. Can we highlight the whole phase (aka individual chevron) the
 properties of which are shown in [2] instead of highlighting the text field?
 Will change it as requested.

  3. What does reset canvas in [3] do?  Erasing all of the
 canvas?  Is this is the case, I assume that a dialog pops
  up asking the user whether he really wants this, correct?

Reset canvas is only found in chevron create page, so that
 the user can clear the canvas if needed. (Delete all elements). Will add a
 dialog popup.


   4. When describing [5], you say that Reset creates a new
 diagram. In this case we should call the button new.And the
 old diagram should automatically stored (or you ask the user what to do
 with the existing diagram).

  Frank this clear canvas option is only given in create phase page. This
 is under the impression that the user wants to remove all elements that he
 drew (before clicking on create to save it ) and re draw a new diagram. So
 do we need to save the old diagram here? If we still need to, we can let
 him save it locally?

   5.In [4], when will the annotation of a phase be shown close to
 it: when I hover over the +, or when I click the +?  Is there a button
 that allows me to display all annotations at once?

Annotations are shown when the user clicks on +  since it
 gives more control to the user. Will include a button to display all
 annotations.

 6. In [4], we should not overlay the phases with their
 annotations. Instead, they should be shown on top, below, left,
  right,... (consistently) of the phase. And, yes, this means that we have
 to auto layout the diagram when theproximity
 annotations are requests, and we have to restore the diagram as modeled
 once display of annotations are  switched off.  Chevron diagrams are often
 presented with proximity annotations, i.e. the cluttering problem that you
 mentioned has to be solved (by automatic layouting,e.g.
 +1 ,will include it .

 Thanks  Regards,
 Himasha

 On Fri, Jan 16, 2015 at 3:54 PM, Frank Leymann fr...@wso2.com wrote:

 Hi Himasha,

 great progress!  Thanks!  :-)))

 A few comments/questions:

1. Can we add arrow heads to the lines between the phases (aka
individual chevrons)?  E.g. in later releases we will likely support to
draw directed graphs without inferring the direction of an arrow from its
geometric position. In this sense, the current diagram [1] is a bit
confusing: is ship product a successor/predecessor of check payment
and/or request refund?
2. Can we highlight the whole phase (aka individual chevron) the
properties of which are shown in [2] instead of highlighting the text 
 field?
3. What does reset canvas in [3] do?  Erasing all of the canvas?
Is this is the case, I assume that a dialog pops up asking the user 
 whether
he really wants this, correct?
4. When describing [5], you say that Reset creates a new diagram.
In this case we should call the button new. And the old diagram should
automatically stored (or you ask the user what to do with the existing
diagram).
5. In [4], when will the annotation of a phase be shown close to it:
when I hover over the +, or when I click the +?  Is there a button 
 that
allows me to display all

Re: [Architecture] Process center- Multiple predecessor/successor support for chevron diagram editor

[Frank Leymann]

Hi Chathura,

yes, I fully agree: that's what I meant :-)  We keep it simple and use
column ordering as default but allow separate arrows to override the
former semantics.

But we need to refine now what the successor relationship means (see next
figure Chevron Relations and Arrows):

   1. Chevrons 1 and 3 succeed chevron 4, but 2 does not succeed 4.
  1. Does that mean that 2 can take place in parallel to 4?
  2. Does that mean that 2 is not required to execute in order to
  perform 4?
  3. Does not mean that 2 is not required to complete (but must be
  performed and may fail) before 4?
   2. Chevron 5 precedes chevron 6, but 5 does not precede 7. Similar as
   before:
   1. Does that mean that 7 may happen even in case 5 (a) did not take
  place; (b) took place but failed?
  2. May 6 take place even if 5 failed?

We need to understand this in order to support the correct refinement in
case the chevrons are substituted by executable process models at the next
level of refinement.  Thus, we have to describe what the semantics is even
if we don't support refinement into executable process models in our first
release


How are arrows considered when a chevron is refined:

   1. If chevron 4 is refined, will the incoming arrows (logically) target
   all chevrons of the first column of the refined diagram?
   2. Or may the modeler decide that only a subset of the chevrons of the
   first column of the refined diagram become target?
   3. May the modeler target the arrows at any chevron of the refined
   diagram or only at chevrons of the first column of the refined diagram?
   4. ...and similar questions for refining chevron 5, but now for the
   source ends of the arrows...

Thus, arrows are very helpful but raise the bar in terms of their
semantics...


Best regards,
Frank

2014-12-12 9:27 GMT+01:00 Chathura Ekanayake chath...@wso2.com:

 Hi Frank,

 Yes, it is better to let users to draw chevron diagrams without arrows
 whenever possible. However, if there is a scenario where only some chevrons
 in a column succeeds a chevron in its previous column, we can let users to
 indicate that using arrows. Therefore, we can support a combination of
 column ordering and arrows to capture predecessor/successor relationships.
 i.e. if arrows are not drawn, all chevrons in a column are in successor
 relationship with all chevrons in its previous column.

 Regards,
 Chathura

 On Thu, Dec 11, 2014 at 11:50 PM, Frank Leymann fr...@wso2.com wrote:

 Hi Himasha,

 very good idea :-)Let me suggest a little variation:

 People modeling Chevron Diagrams are not really used to use arrows to
 connect the individual chevrons to indicate (control or data) flow. The
 flow is defined by the orientation of the diagram (i.e. horizontal or
 vertical). This would imply to avoid arrows as long as possible - but folks
 MAY use arrows if they want e.g. because of clarity and comprehensibility.

 Let's assume a horizontal orientation:  each chevron in a column of your
 grid will be a successor of all chevrons in the immediate preceding column.
 And all chevrons in the same column can be performed in parallel. And all
 chevrons of certain column must be ready before the chevrons of the
 succeeding column can be activated. And, yes, this is not really
 satisfactory because not all chevrons in a certain column have to be
 performed - but that's an inherent imprecision of Chevron Diagrams because
 they don't have an operational semantics (by will ;-)).

 Thus, the Chevron Diagram you draw would be equivalent to the following
 (ChevronRelations):





 Best regards,
 Frank

 2014-12-11 7:45 GMT+01:00 Himasha Guruge himas...@wso2.com:

 Hi All,

 The idea is to support multiple relations for the chevrons in initial
 chevron diagram editor. As the initial step, the editor canvas will include
 a virtual grid [1] where the chevron elements can be dropped into.

 When a chevron is dropped to the canvas most suitable cell location will
 be retrieved by checking the center position of the chevron.  In such a
 scenario where the most suitable cell is already occupied by another
 chevron element, it will be placed in the next most suitable location.
 Once a chevron element is added, it can be swapped between different
 cells as long as they are not already occupied.

 Any suggestion/feedback on building the virtual grid would be
 appreciated.

 [1] chevronEditor_virtualGrid_mockup
 https://docs.google.com/a/wso2.com/drawings/d/1CJwFQrm4FjKSLS23I0iXWZwLg_D4ddramm62c0q3lAw/edit?usp=sharing

 Thanks  Regards,

 Himasha Guruge
 *Software Engineer*
 WS*O2* *Inc.*
 Mobile: +94 777459299
 himas...@wso2.com






Chevron Relations and Arrows.pptx
Description: MS-Powerpoint 2007 presentation
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Process center- Multiple predecessor/successor support for chevron diagram editor

[Frank Leymann]

Hi Himasha,

in case you have an initial version of your code running, I would be glad
to get a brief demo :-)


Best regards,
Frank

2014-12-12 9:44 GMT+01:00 Himasha Guruge himas...@wso2.com:

 Hi Frank,

 Thanks for the suggestion. As Chathura mentioned, will support both
 approaches depending on the scenario.

 Thanks  Regards,
 Himasha

 On Fri, Dec 12, 2014 at 1:57 PM, Chathura Ekanayake chath...@wso2.com
 wrote:

 Hi Frank,

 Yes, it is better to let users to draw chevron diagrams without arrows
 whenever possible. However, if there is a scenario where only some chevrons
 in a column succeeds a chevron in its previous column, we can let users to
 indicate that using arrows. Therefore, we can support a combination of
 column ordering and arrows to capture predecessor/successor relationships.
 i.e. if arrows are not drawn, all chevrons in a column are in successor
 relationship with all chevrons in its previous column.

 Regards,
 Chathura

 On Thu, Dec 11, 2014 at 11:50 PM, Frank Leymann fr...@wso2.com wrote:

 Hi Himasha,

 very good idea :-)Let me suggest a little variation:

 People modeling Chevron Diagrams are not really used to use arrows to
 connect the individual chevrons to indicate (control or data) flow. The
 flow is defined by the orientation of the diagram (i.e. horizontal or
 vertical). This would imply to avoid arrows as long as possible - but folks
 MAY use arrows if they want e.g. because of clarity and comprehensibility.

 Let's assume a horizontal orientation:  each chevron in a column of your
 grid will be a successor of all chevrons in the immediate preceding column.
 And all chevrons in the same column can be performed in parallel. And all
 chevrons of certain column must be ready before the chevrons of the
 succeeding column can be activated. And, yes, this is not really
 satisfactory because not all chevrons in a certain column have to be
 performed - but that's an inherent imprecision of Chevron Diagrams because
 they don't have an operational semantics (by will ;-)).

 Thus, the Chevron Diagram you draw would be equivalent to the following
 (ChevronRelations):





 Best regards,
 Frank

 2014-12-11 7:45 GMT+01:00 Himasha Guruge himas...@wso2.com:

 Hi All,

 The idea is to support multiple relations for the chevrons in initial
 chevron diagram editor. As the initial step, the editor canvas will include
 a virtual grid [1] where the chevron elements can be dropped into.

 When a chevron is dropped to the canvas most suitable cell location
 will be retrieved by checking the center position of the chevron.  In such
 a scenario where the most suitable cell is already occupied by another
 chevron element, it will be placed in the next most suitable location.
 Once a chevron element is added, it can be swapped between different
 cells as long as they are not already occupied.

 Any suggestion/feedback on building the virtual grid would be
 appreciated.

 [1] chevronEditor_virtualGrid_mockup
 https://docs.google.com/a/wso2.com/drawings/d/1CJwFQrm4FjKSLS23I0iXWZwLg_D4ddramm62c0q3lAw/edit?usp=sharing

 Thanks  Regards,

 Himasha Guruge
 *Software Engineer*
 WS*O2* *Inc.*
 Mobile: +94 777459299
 himas...@wso2.com





 --
 Himasha Guruge
 *Software Engineer*
 WS*O2* *Inc.*
 Mobile: +94 777459299
 himas...@wso2.com

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Process center- Multiple predecessor/successor support for chevron diagram editor

[Frank Leymann]

Hi Himasha,

very good idea :-)Let me suggest a little variation:

People modeling Chevron Diagrams are not really used to use arrows to
connect the individual chevrons to indicate (control or data) flow. The
flow is defined by the orientation of the diagram (i.e. horizontal or
vertical). This would imply to avoid arrows as long as possible - but folks
MAY use arrows if they want e.g. because of clarity and comprehensibility.

Let's assume a horizontal orientation:  each chevron in a column of your
grid will be a successor of all chevrons in the immediate preceding column.
And all chevrons in the same column can be performed in parallel. And all
chevrons of certain column must be ready before the chevrons of the
succeeding column can be activated. And, yes, this is not really
satisfactory because not all chevrons in a certain column have to be
performed - but that's an inherent imprecision of Chevron Diagrams because
they don't have an operational semantics (by will ;-)).

Thus, the Chevron Diagram you draw would be equivalent to the following
(ChevronRelations):





Best regards,
Frank

2014-12-11 7:45 GMT+01:00 Himasha Guruge himas...@wso2.com:

 Hi All,

 The idea is to support multiple relations for the chevrons in initial
 chevron diagram editor. As the initial step, the editor canvas will include
 a virtual grid [1] where the chevron elements can be dropped into.

 When a chevron is dropped to the canvas most suitable cell location will
 be retrieved by checking the center position of the chevron.  In such a
 scenario where the most suitable cell is already occupied by another
 chevron element, it will be placed in the next most suitable location.
 Once a chevron element is added, it can be swapped between different cells
 as long as they are not already occupied.

 Any suggestion/feedback on building the virtual grid would be appreciated.

 [1] chevronEditor_virtualGrid_mockup
 https://docs.google.com/a/wso2.com/drawings/d/1CJwFQrm4FjKSLS23I0iXWZwLg_D4ddramm62c0q3lAw/edit?usp=sharing

 Thanks  Regards,

 Himasha Guruge
 *Software Engineer*
 WS*O2* *Inc.*
 Mobile: +94 777459299
 himas...@wso2.com



ChevronRelations.pptx
Description: MS-Powerpoint 2007 presentation
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Process center] Support for executable process models

[Frank Leymann]

Hi Chathura,

​what is the semantics of the deployment URL (second bullet):  is this the
endpoint where a BPEL archive can be deployed? Or is this the URL of an
archive that contains all the artifacts to create a BPEL engine where I can
deploy and execute the BPEL file?  I suspect the first alternative is what
you mean - just double-check.

I don't understand your third bullet:  when you deploy a BPEL archive you
(nearly always) deploy all roles of all partner links. After that an
instance of the process model can be instantiated by any external source by
sending messages to the ports that correspond to initiating activities of
the process model. The same is true in case a BPEL file uses the
BPEL4People extension, i.e. in case some activities are implemented by
human tasks.

Continuing on the Webapp URL (it must be something implementation
specific that we have done at WSO2): A process model may be initiated by
activities that have not user interaction at all (i.e. that is no
peopleActivity activity kicking-off a new instance of the process model).
What is the Webapp URL all about in this case?

Pushing the deploy button is done by non-business-oriented users because
it will require quite some technical information, right? I.e. do we support
in the Process Store corresponding role models to avoid frustration by
business users when pushing the deploy button?

Best regards,
Frank

2014-12-03 12:26 GMT+01:00 Chathura Ekanayake chath...@wso2.com:


 Executable process model is a BPEL or BPMN model, which can be executed in
 a process runtime. We can support executable models in process center as
 follows:

 Executable model contains:
  - Process archive (e.g. BPEL archive)
  - [optional] Deployment URL (e.g. URL of a BPS server)
  - [optional] Webapp URL - This URL points to a web application which can
 be used to create a new process instance and work on human tasks defined in
 the process (i.e. this is the operational UI for the process).

 If a webapp URL is provided, process center provides a Start button
 which simply directs to that URL. For example, employees can search process
 models from the store side and start them if they are executable. If it is
 not provided, the human task web app shipped with BPS can be used to start
 and work on human tasks.

 If a deployment URL is provided, a Deploy button is shown, which deploys
 a process archive in the corresponding BPS server.

 Thoughts...

 Regards,
 Chathura



___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Chevron diagram editor/viewer for the Process Store

[Frank Leymann]

 model.

 [1] chevron_diagram_properties
 https://drive.google.com/a/wso2.com/file/d/0B2gZ09XLMRjKS0czei1OQWtqekU/view?usp=sharing

 [2] individual_chevron_properties
 https://drive.google.com/a/wso2.com/file/d/0B2gZ09XLMRjKcjBaOW5EcUI0Y28/view?usp=sharing

 Thanks  Regards,
 Himasha

 On Sun, Nov 30, 2014 at 10:19 PM, Frank Leymann fr...@wso2.com wrote:

 Hi Himasha,

 please allow for a few questions/comments:


1. create_chevron:
   1. Is the list of properties of a chevron fixed?  Or does add
   properties mean that I can add more properties? I suspect that the 
 list of
   property types of a chevron is pre-defined...
   2. What is the purpose of the Thumbnail?
  - do we support to change the graphical appearance of a
  chevron? Especially supporting to change the color of individual 
 chevrons
  will be helpful in practice.
   3. Do we support multiple predecessors and successors?
   4. Is a value of the Process property a link? If it is only a
   name, what is the scope of its uniqueness (aka namespace)?
   5. Do we support drawing vertical chevron diagrams, i.e. diagrams
   the arrows of which point from top to bottom?
   6. Do we support annotations of individual chevrons that are shown
   on the canvas?
2. list_chevron:
   1. Please call the type Chevron Diagram (instead of just
   Chevron): A chevron is a single arrow in a chevron diagram.
   2. What's the purpose of the Statistics button?
3. edit_chevron:
   1. Can we change Edit Asset into Edit Chevron Diagram?
   2. The properties now contain an owner and a description
   property, i.e. more properties than you show in create_chevron; and the
   process property is now missing:  why?
4. store_view:
   1. Again, I recommend to speak about Chevron Diagrams and not only
   about Chevron.  Btw the same holds for Process Model instead of 
 just
   Process
   2. Showing an individual chevron in ES is not the right
   granularity (just as you don't show individual activities of a process
   model in ES but the complete process model itself).



 Best regards,
 Frank

 2014-11-28 13:09 GMT+01:00 Himasha Guruge himas...@wso2.com:

 Hi All,

 Chevron diagram editor initial requirements are completed, and following
 are few screenshots from publisher/store end of Enterprise Store. Currently
 the chevron asset is created as an extension of ES.

 *publisher: create chevron page - *This page will enable the
 user to draw the related chevron diagram and view the properties added. The
 predecessor/successor fields are read only ,therefore the values will be
 dynamically updated.
 *​*
  create_chevron.png
 https://docs.google.com/a/wso2.com/file/d/0B2gZ09XLMRjKMllDRXc4SlczaGM/edit?usp=drive_web
 *​*

 *publisher: list chevron page - *The created chevrons will be listed in
 this page as below.
 ​
  list_chevron.png
 https://docs.google.com/a/wso2.com/file/d/0B2gZ09XLMRjKMTBpRldNVFRhZ3M/edit?usp=drive_web
 ​
 *publisher: edit chevron page* - This page will enable the user to edit
 any existing properties as well as to update the diagram ( add new chevron
 icons/ change order of existing icons etc)

 ​
  edit_chevron.png
 https://docs.google.com/a/wso2.com/file/d/0B2gZ09XLMRjKT1VXcXNIRExBMDg/edit?usp=drive_web
 ​
 *store end view page - *Once a created chevron is published, it will
 appear in ES(Enterprise Store) store end, and will contain the following
 view. Each chevron in the diagram can be clicked and the relevant
 properties will be displayed.
 ​
  store_view.png
 https://docs.google.com/a/wso2.com/file/d/0B2gZ09XLMRjKNkdHdjJEQ04ydGc/edit?usp=drive_web
 ​
 Thanks  Regards,
 Himasha Guruge

 On Mon, Nov 3, 2014 at 9:36 AM, Himasha Guruge himas...@wso2.com
 wrote:

 Hi Chathura,

 Import functionality noted.

 Thanks  Regards,
 Himasha

 On Mon, Nov 3, 2014 at 9:17 AM, Chathura Ekanayake chath...@wso2.com
 wrote:

 Hi Himasha,


 Current requirements did not include the import functionality of the
 xml document,will discuss with the stakeholders regarding it so that we 
 can
 add it in the future.


 We persist chevron diagrams (logic and formatting) in XML format in
 GReg. So when a persisted chevron is opened we have to read the XML and
 display the corresponding chevron. Therefore, we have to support XML 
 import
 functionality as well.

 Regards,
 Chathura



 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




 --
 Himasha Guruge
 *Software Engineer*
 WS*O2* *Inc.*
 Mobile: +94 777459299
 himas...@wso2.com




 --
 Himasha Guruge
 *Software Engineer*
 WS*O2* *Inc.*
 Mobile: +94 777459299
 himas...@wso2.com





 --
 Himasha Guruge
 *Software Engineer*
 WS*O2* *Inc.*
 Mobile: +94 777459299
 himas...@wso2.com

___
Architecture mailing list
Architecture@wso2.org

Re: [Architecture] [Process center] Support for executable process models

[Frank Leymann]

+1


Best regards,
Frank

2014-12-04 4:40 GMT+01:00 Chathura Ekanayake chath...@wso2.com:

 Hi Chinthana,

 Process center is not used to interact with the BPS runtime or HT runtime.
 Instead, end users use it to search/discover available processes and to
 execute them if possible. If a user wants to execute a process, process
 center delegates it to the associated webapp, which runs separately from
 the process center.

 The idea here is that the process center connects all BPM related
 products/runtimes in to a single platform.

 Regards,
 Chathura

 On Thu, Dec 4, 2014 at 7:20 AM, Srinath Perera srin...@wso2.com wrote:

 +1, we need to make sure terminology and wording matches those scenarios.
 For example it should be Start a Process not Create Instance etc
 (latter is process jargon and user is not interested).

 --Srinath

 On Wed, Dec 3, 2014 at 7:13 PM, Chathura Ekanayake chath...@wso2.com
 wrote:

 Hi Srinath,

 Yes, if a process is already deployed, it can just store the deployment
 URL.

 An example scenario would be:
 An employee wants to claim a travel expense. He logs in to the process
 center deployed in his organization and search for travel expense claim
 processes. This process can be in different formats. If only a textual
 process or a non-executable BPMN is available, he just follows the
 mentioned steps manually. If there is an associated executable model, he
 can click the Start button to initiate an automated process. In that
 case, he will be directed to the associated web app where he (and other
 participants) can provide details via human tasks.

 As a next step, we can associate event streams with such executable
 processes to facilitate runtime analysis. I will initiate another thread on
 that after refining this idea bit more.

 Regards,
 Chathura

 On Wed, Dec 3, 2014 at 5:49 PM, Nandika Jayawardana nand...@wso2.com
 wrote:

 Hi Chathura,

 In this scenario, does the process center discover the process models
 and tasks deployed in BPS or a user manually configure / upload processes
 at process center which are deployed to BPS by a user action ?

 Regards
 NAndika

 On Wed, Dec 3, 2014 at 5:00 PM, Srinath Perera srin...@wso2.com
 wrote:

 Hi Chathura,

 I think one other case is it is deployed already, and we just get a
 URL.

 Also, I think we need to think how above can be useful in real life
 scenario, basically we need to come up with a full story on how above can
 be used.

 --Srinath



 On Wed, Dec 3, 2014 at 4:56 PM, Chathura Ekanayake chath...@wso2.com
 wrote:


 Executable process model is a BPEL or BPMN model, which can be
 executed in a process runtime. We can support executable models in 
 process
 center as follows:

 Executable model contains:
  - Process archive (e.g. BPEL archive)
  - [optional] Deployment URL (e.g. URL of a BPS server)
  - [optional] Webapp URL - This URL points to a web application which
 can be used to create a new process instance and work on human tasks
 defined in the process (i.e. this is the operational UI for the process).

 If a webapp URL is provided, process center provides a Start button
 which simply directs to that URL. For example, employees can search 
 process
 models from the store side and start them if they are executable. If it 
 is
 not provided, the human task web app shipped with BPS can be used to 
 start
 and work on human tasks.

 If a deployment URL is provided, a Deploy button is shown, which
 deploys a process archive in the corresponding BPS server.

 Thoughts...

 Regards,
 Chathura






 --
 
 Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
 Site: http://people.apache.org/~hemapani/
 Photos: http://www.flickr.com/photos/hemapani/
 Phone: 0772360902

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




 --
 Nandika Jayawardana
 Senior Technical Lead
 WSO2 Inc ; http://wso2.com
 lean.enterprise.middleware





 --
 
 Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
 Site: http://people.apache.org/~hemapani/
 Photos: http://www.flickr.com/photos/hemapani/
 Phone: 0772360902



 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Process center] Support for executable process models

[Frank Leymann]

Please add me to the tbd thread on processes and event streams :-)


Best regards,
Frank

2014-12-03 14:43 GMT+01:00 Chathura Ekanayake chath...@wso2.com:

 Hi Srinath,

 Yes, if a process is already deployed, it can just store the deployment
 URL.

 An example scenario would be:
 An employee wants to claim a travel expense. He logs in to the process
 center deployed in his organization and search for travel expense claim
 processes. This process can be in different formats. If only a textual
 process or a non-executable BPMN is available, he just follows the
 mentioned steps manually. If there is an associated executable model, he
 can click the Start button to initiate an automated process. In that
 case, he will be directed to the associated web app where he (and other
 participants) can provide details via human tasks.

 As a next step, we can associate event streams with such executable
 processes to facilitate runtime analysis. I will initiate another thread on
 that after refining this idea bit more.

 Regards,
 Chathura

 On Wed, Dec 3, 2014 at 5:49 PM, Nandika Jayawardana nand...@wso2.com
 wrote:

 Hi Chathura,

 In this scenario, does the process center discover the process models and
 tasks deployed in BPS or a user manually configure / upload processes at
 process center which are deployed to BPS by a user action ?

 Regards
 NAndika

 On Wed, Dec 3, 2014 at 5:00 PM, Srinath Perera srin...@wso2.com wrote:

 Hi Chathura,

 I think one other case is it is deployed already, and we just get a URL.

 Also, I think we need to think how above can be useful in real life
 scenario, basically we need to come up with a full story on how above can
 be used.

 --Srinath



 On Wed, Dec 3, 2014 at 4:56 PM, Chathura Ekanayake chath...@wso2.com
 wrote:


 Executable process model is a BPEL or BPMN model, which can be executed
 in a process runtime. We can support executable models in process center as
 follows:

 Executable model contains:
  - Process archive (e.g. BPEL archive)
  - [optional] Deployment URL (e.g. URL of a BPS server)
  - [optional] Webapp URL - This URL points to a web application which
 can be used to create a new process instance and work on human tasks
 defined in the process (i.e. this is the operational UI for the process).

 If a webapp URL is provided, process center provides a Start button
 which simply directs to that URL. For example, employees can search process
 models from the store side and start them if they are executable. If it is
 not provided, the human task web app shipped with BPS can be used to start
 and work on human tasks.

 If a deployment URL is provided, a Deploy button is shown, which
 deploys a process archive in the corresponding BPS server.

 Thoughts...

 Regards,
 Chathura






 --
 
 Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
 Site: http://people.apache.org/~hemapani/
 Photos: http://www.flickr.com/photos/hemapani/
 Phone: 0772360902

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




 --
 Nandika Jayawardana
 Senior Technical Lead
 WSO2 Inc ; http://wso2.com
 lean.enterprise.middleware



 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Chevron diagram editor/viewer for the Process Store

[Frank Leymann]

Hi Himasha,

please allow for a few questions/comments:


   1. create_chevron:
  1. Is the list of properties of a chevron fixed?  Or does add
  properties mean that I can add more properties? I suspect that
the list of
  property types of a chevron is pre-defined...
  2. What is the purpose of the Thumbnail?
 - do we support to change the graphical appearance of a chevron?
 Especially supporting to change the color of individual
chevrons will be
 helpful in practice.
  3. Do we support multiple predecessors and successors?
  4. Is a value of the Process property a link? If it is only a name,
  what is the scope of its uniqueness (aka namespace)?
  5. Do we support drawing vertical chevron diagrams, i.e. diagrams the
  arrows of which point from top to bottom?
  6. Do we support annotations of individual chevrons that are shown on
  the canvas?
   2. list_chevron:
  1. Please call the type Chevron Diagram (instead of just
  Chevron): A chevron is a single arrow in a chevron diagram.
  2. What's the purpose of the Statistics button?
   3. edit_chevron:
  1. Can we change Edit Asset into Edit Chevron Diagram?
  2. The properties now contain an owner and a description
  property, i.e. more properties than you show in create_chevron; and the
  process property is now missing:  why?
   4. store_view:
  1. Again, I recommend to speak about Chevron Diagrams and not only
  about Chevron.  Btw the same holds for Process Model instead of just
  Process
  2. Showing an individual chevron in ES is not the right granularity
  (just as you don't show individual activities of a process model
in ES but
  the complete process model itself).



Best regards,
Frank

2014-11-28 13:09 GMT+01:00 Himasha Guruge himas...@wso2.com:

 Hi All,

 Chevron diagram editor initial requirements are completed, and following
 are few screenshots from publisher/store end of Enterprise Store. Currently
 the chevron asset is created as an extension of ES.

 *publisher: create chevron page - *This page will enable the user
 to draw the related chevron diagram and view the properties added. The
 predecessor/successor fields are read only ,therefore the values will be
 dynamically updated.
 *​*
  create_chevron.png
 https://docs.google.com/a/wso2.com/file/d/0B2gZ09XLMRjKMllDRXc4SlczaGM/edit?usp=drive_web
 *​*

*publisher: list chevron page - *The created chevrons will be listed in
 this page as below.
 ​
  list_chevron.png
 https://docs.google.com/a/wso2.com/file/d/0B2gZ09XLMRjKMTBpRldNVFRhZ3M/edit?usp=drive_web
 ​
 *publisher: edit chevron page* - This page will enable the user to edit
 any existing properties as well as to update the diagram ( add new chevron
 icons/ change order of existing icons etc)

 ​
  edit_chevron.png
 https://docs.google.com/a/wso2.com/file/d/0B2gZ09XLMRjKT1VXcXNIRExBMDg/edit?usp=drive_web
 ​
 *store end view page - *Once a created chevron is published, it will
 appear in ES(Enterprise Store) store end, and will contain the following
 view. Each chevron in the diagram can be clicked and the relevant
 properties will be displayed.
 ​
  store_view.png
 https://docs.google.com/a/wso2.com/file/d/0B2gZ09XLMRjKNkdHdjJEQ04ydGc/edit?usp=drive_web
 ​
 Thanks  Regards,
 Himasha Guruge

 On Mon, Nov 3, 2014 at 9:36 AM, Himasha Guruge himas...@wso2.com wrote:

 Hi Chathura,

 Import functionality noted.

 Thanks  Regards,
 Himasha

 On Mon, Nov 3, 2014 at 9:17 AM, Chathura Ekanayake chath...@wso2.com
 wrote:

 Hi Himasha,


 Current requirements did not include the import functionality of the
 xml document,will discuss with the stakeholders regarding it so that we can
 add it in the future.


 We persist chevron diagrams (logic and formatting) in XML format in
 GReg. So when a persisted chevron is opened we have to read the XML and
 display the corresponding chevron. Therefore, we have to support XML import
 functionality as well.

 Regards,
 Chathura



 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




 --
 Himasha Guruge
 *Software Engineer*
 WS*O2* *Inc.*
 Mobile: +94 777459299
 himas...@wso2.com




 --
 Himasha Guruge
 *Software Engineer*
 WS*O2* *Inc.*
 Mobile: +94 777459299
 himas...@wso2.com

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] Machine Processable Metadata and GUI Generation

[Frank Leymann]

Here is the link to the technology called OSCL I was mentioning:
http://open-services.net/resources/tutorials/oslc-primer/what-is-oslc/

Best regards,
Frank
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] RFC: Doing Bulk Events Updates to HDFS instead of Cassandra

[Frank Leymann]

Hi Srinath,

I assume the scenarios you intend to support by such file manipulations do
not require typical database functionality like concurrent access,
atomicity of sets of manipulations, random and selective access (aka
queries) etc.. Am I right?


Best regards,
Frank

2014-11-05 3:56 GMT+01:00 Srinath Perera srin...@wso2.com:

 Hi All,

 Following came out of chat with Sanjiva on a scenario involve very large
 number of events coming into BAM.

 Currently we use Cassandra to store the events and number we got out of it
 has not been great and Cassandra need too much attention to get to those
 number.

 With Cassandra (or any DB) we write data as records. We can batch it, but
 still amount of data in one IO operation is small. In comparison,  file
 transfers are much much faster and that is fastest way to get some data
 from A to B.

 So I am proposing to write the events that comes into a local file in the
 Data Receiver, and periodically append them to a HDFS file. We can arrange
 data in a folder by stream and files by timestamp (e.g. 1h data go to a new
 file), so we can selectively pull and process data using Hive. (We can use
 something like https://github.com/OpenHFT/Chronicle-Queue to write data
 to disk).

 If user needs avoid losing any messages at all in case of a disk failure,
 either he can have a SAN or NTFS or can run two replicas of receivers  (we
 should write some code so only one of the receivers will actually put data
 to HDFS).

 Coding wise, this should not be too hard. I am sure this will be factor of
 time faster than Cassandra (of course we need to do a PoC and verify).

 WDYT?

 --Srinath






 --
 
 Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
 Site: http://people.apache.org/~hemapani/
 Photos: http://www.flickr.com/photos/hemapani/
 Phone: 0772360902

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Chevron diagram editor/viewer for the Process Store

[Frank Leymann]

Hi Himasha,

I don't understand what you mean by deriving predecessor/successor
relationships for the entire diagram: does that mean that you derive the
relationships for all chevrons of a diagram at once, i.e. that you apply
your second bullet iteratively?

Will the position on the canvas of each modeling element be part of the XML
document you create?  You want to take a look at BPMN 2.0: they separate
the raw layouting information about a process model from the logic of the
business process model: this allows different layouts for different tools,
for different devices etc..

I also suggest to consider the XML document you create as a step when
exporting the process model. I.e. we should not assume that the XML is the
only representation of the model in the database - correct?

Finally: will you also support to import such an XML file that you create?



Best regards,
Frank

2014-10-30 9:19 GMT+01:00 Himasha Guruge himas...@wso2.com:

 Hi All,

 As per  requirement in visualizing process  associations of Process Store,
 I have taken up the training project in creating a chevron diagram
 editor/view for the Process Store. Similar to pre built textual based
 process extension, this editor will also be build as an extension of
 Enterprise Store, which will be moved to Process Store in the future.

 After discussion with the stakeholders, following functionalities are to
 be supported.

- Create chevron diagrams in drag and drop manner : JSPlumb will be
used for editor based manipulations.
- Derive predecessor/successor relationships from the positioning of
elements.
- Derive predecessor/successor relationships for the entire diagram
process.
- Navigate to associated process models/chevron diagrams from elements
in the current chevron diagram.
- Serialize canvas elements and convert into a specified xml format.

 Taking feedback of the stakeholder meeting into account, the core elements
 and their formatting properties will be specified separately when saving in
 xml format.


 Thanks  Regards,

 Himasha Guruge
 *Software Engineer*
 WS*O2* *Inc.*
 Mobile: +94 777459299
 himas...@wso2.com

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] WSO2 MB Proposed RDBMS Design

[Frank Leymann]

Prabath,

I agree that triggers make comprehending code a bit more difficult. But
triggers are a mechanism to achieve active database features, something
that is very difficult to get without triggers. Thus, I would not say that
they should not be used. I don't understand the statement that triggers are
executed outside of SQL transactions: in case your trigger only makes use
of SQL statements (in contrast to generating effects outside of the DBMS)
the trigger actions are included in the embracing transaction - at least in
DB2, which I am familiar with.

Furthermore, the use of stored procedures can be an excellent means to
avoid network latency by shuffling data between a client and the DBMS.
Thus, it is a means to improve response time, throughput etc.  Also, an SQL
CALL is part of the embracing transaction.  Again, I would not banish the
use of stored procedures at all...



Best regards,
Frank

2014-09-12 10:25 GMT+02:00 Prabath Abeysekera praba...@wso2.com:

 In addition, triggers, usually, are like stored procedures in its context
 and at times, might store some good portion of your business logic within
 the database layer which makes them less visible to someone who's
 evaluating a particular high-level business use-case just by looking at
 some code level implementation. So, they usually go unnoticed, I would say,
 a lot more than it is with a stored procedure. So, IMO, it would be good if
 we can avoid them whenever possible.

 Cheers,
 Prabath

 On Fri, Sep 12, 2014 at 1:21 PM, Asitha Nanayakkara asi...@wso2.com
 wrote:

 According to an offline chat I had with PrabathA SQL triggers should be
 avoided since SQL triggers execute outside SQL transactions.

 On Thu, Jul 24, 2014 at 6:30 PM, Hasitha Hiranya hasit...@wso2.com
 wrote:

 Hi,

 According to mail arch@ Removing Global Queue from MB, maybe we need
 to update this design.
 Better we discuss upfront if so.

 It will bring changes to messageStore interface.

 Thanks


 On Thu, Jul 24, 2014 at 3:04 PM, Asitha Nanayakkara asi...@wso2.com
 wrote:

 With the addition of message expiration feature RDBMS design for
 Metadata in MB needs to be changed.
 Updated design is as follows.




 * ​Design considerations*

- Only a subset of messages comes with message expiration and a
separate thread handles deletion of expired messages.
- Periodically expired message deletion thread queries for a chunk
of expired messages. The subset of messages to go through would be less
when a separated Expiration table is used. However when deleting a 
 message
from Expiration table should trigger a delete of all the messages with 
 the
respective message_id from Metadata table.

 In addition, to update reference count of messages an SQL trigger will
 be created. Is there any performance hit using triggers?




 On Thu, Jul 24, 2014 at 12:06 PM, Asitha Nanayakkara asi...@wso2.com
 wrote:

 With current design in memory message store will be used only in
 single node mode.


 On Wed, Jul 23, 2014 at 11:36 AM, Dhanuka Ranasinghe dhan...@wso2.com
  wrote:

 Also, normally publisher mention whether to persist or not messages
 in message itself (delivery mode). So based on that MB will process
 messages in memory and/or persist to a persistence store. So if it's
 process in memory How do we communicate through the MB cluster?


 http://activemq.apache.org/what-is-the-difference-between-persistent-and-non-persistent-delivery.html


 *Dhanuka Ranasinghe*

 Senior Software Engineer
 WSO2 Inc. ; http://wso2.com
 lean . enterprise . middleware

 phone : +94 715381915


 On Mon, Jul 21, 2014 at 12:36 PM, Dhanuka Ranasinghe 
 dhan...@wso2.com wrote:

 IMO, If we gonna keep huge messages as chunks in memory and insert
 into DB as bulk it will heavily affect on MB heap memory. My suggestion 
 is
 we need to handle this case by case. For example, if it's small 
 messages it
 will be efficient to keep in memory while huge messages it will be
 efficient to insert into DB early as possible and let others to use heap
 memory. For this we will have to make this functionality more 
 configurable
 but again we will have to think about how gonna support fail over 
 (probably
 have to change db schema).

 *Dhanuka Ranasinghe*

 Senior Software Engineer
 WSO2 Inc. ; http://wso2.com
 lean . enterprise . middleware

 phone : +94 715381915


 On Mon, Jul 21, 2014 at 9:00 AM, Asitha Nanayakkara asi...@wso2.com
  wrote:

 We are planning to insert message chunks as batch insert queries.


 On Sat, Jul 19, 2014 at 11:00 AM, Dhanuka Ranasinghe 
 dhan...@wso2.com wrote:

 Are we going to insert whole message or as chunks
 On 18 Jul 2014 18:06, Asitha Nanayakkara asi...@wso2.com
 wrote:

  Hi,

 Following is the RDBMS design for WSO2 MB 3.0.0

 Messages model

 ​Message metadata model


 ​
 Following are the concerns came across in the discussion

 *- Why we use reference counting for message meta data?*

 Reference counting is needed to delete topic messages from the
 

Re: [Architecture] WSO2 MB Proposed RDBMS Design

[Frank Leymann]

This is true in general:  even a simple statement like SELECT behaves a bit
differently in different RDBMS implementations. I.e. minor differences in
SQL statements is not restricted to triggers, however we use RDBMS...


Best regards,
Frank

2014-09-12 10:24 GMT+02:00 Sumedha Rubasinghe sume...@wso2.com:

 If you use triggers, you cannot have a database engine independent design.

 On Fri, Sep 12, 2014 at 1:21 PM, Asitha Nanayakkara asi...@wso2.com
 wrote:

 According to an offline chat I had with PrabathA SQL triggers should be
 avoided since SQL triggers execute outside SQL transactions.

 On Thu, Jul 24, 2014 at 6:30 PM, Hasitha Hiranya hasit...@wso2.com
 wrote:

 Hi,

 According to mail arch@ Removing Global Queue from MB, maybe we need
 to update this design.
 Better we discuss upfront if so.

 It will bring changes to messageStore interface.

 Thanks


 On Thu, Jul 24, 2014 at 3:04 PM, Asitha Nanayakkara asi...@wso2.com
 wrote:

 With the addition of message expiration feature RDBMS design for
 Metadata in MB needs to be changed.
 Updated design is as follows.




 * ​Design considerations*

- Only a subset of messages comes with message expiration and a
separate thread handles deletion of expired messages.
- Periodically expired message deletion thread queries for a chunk
of expired messages. The subset of messages to go through would be less
when a separated Expiration table is used. However when deleting a 
 message
from Expiration table should trigger a delete of all the messages with 
 the
respective message_id from Metadata table.

 In addition, to update reference count of messages an SQL trigger will
 be created. Is there any performance hit using triggers?




 On Thu, Jul 24, 2014 at 12:06 PM, Asitha Nanayakkara asi...@wso2.com
 wrote:

 With current design in memory message store will be used only in
 single node mode.


 On Wed, Jul 23, 2014 at 11:36 AM, Dhanuka Ranasinghe dhan...@wso2.com
  wrote:

 Also, normally publisher mention whether to persist or not messages
 in message itself (delivery mode). So based on that MB will process
 messages in memory and/or persist to a persistence store. So if it's
 process in memory How do we communicate through the MB cluster?


 http://activemq.apache.org/what-is-the-difference-between-persistent-and-non-persistent-delivery.html


 *Dhanuka Ranasinghe*

 Senior Software Engineer
 WSO2 Inc. ; http://wso2.com
 lean . enterprise . middleware

 phone : +94 715381915


 On Mon, Jul 21, 2014 at 12:36 PM, Dhanuka Ranasinghe 
 dhan...@wso2.com wrote:

 IMO, If we gonna keep huge messages as chunks in memory and insert
 into DB as bulk it will heavily affect on MB heap memory. My suggestion 
 is
 we need to handle this case by case. For example, if it's small 
 messages it
 will be efficient to keep in memory while huge messages it will be
 efficient to insert into DB early as possible and let others to use heap
 memory. For this we will have to make this functionality more 
 configurable
 but again we will have to think about how gonna support fail over 
 (probably
 have to change db schema).

 *Dhanuka Ranasinghe*

 Senior Software Engineer
 WSO2 Inc. ; http://wso2.com
 lean . enterprise . middleware

 phone : +94 715381915


 On Mon, Jul 21, 2014 at 9:00 AM, Asitha Nanayakkara asi...@wso2.com
  wrote:

 We are planning to insert message chunks as batch insert queries.


 On Sat, Jul 19, 2014 at 11:00 AM, Dhanuka Ranasinghe 
 dhan...@wso2.com wrote:

 Are we going to insert whole message or as chunks
 On 18 Jul 2014 18:06, Asitha Nanayakkara asi...@wso2.com
 wrote:

  Hi,

 Following is the RDBMS design for WSO2 MB 3.0.0

 Messages model

 ​Message metadata model


 ​
 Following are the concerns came across in the discussion

 *- Why we use reference counting for message meta data?*

 Reference counting is needed to delete topic messages from the
 database reliably in a cluster deployment

 *-​ How to manage a large tables like Messages table?*

 for Messages table use database partitioning

 For Metadata queries there will be no SQL joins, hence even if
 the table would grow large that won't be an issue.

 Inserts and delete operation can be done as batch operations.

 *- Following option to save metadata was rejected due to
 following reasons*



 In the above design MB instance will create Node_Queue tables and
 Topic_Node_Queue
 tables when each node connects to a cluster. This design was
 rejected due to following reasons.
 It's DB admins tasks to create and delete tables. MB should not
 modify schema when joining to the cluster. There will be instances 
 where MB
 users might not have privileges to create tables.

 *- Supporting several SQL implementations.*

 Since we are using simple SQL operations those will not become an
 issue.




 Thanks
 --
 *Asitha Nanayakkara*
 Software Engineer
 WSO2, Inc. http://wso2.com/
 Mob: + 94 77 85 30 682
 ​​

 ___
 Architecture mailing 

Re: [Architecture] WSO2 MB Proposed RDBMS Design

[Frank Leymann]

Sumedha,

sure, I understand:  I also developed products that had to support multiple
RDBMS. But we ended up developing RDBMS specific code for performance
reasons. This of course depends on customer requirements, i.e. as long as
there are no customer complains, you are doing the right things  :-)


Best regards,
Frank

2014-09-14 14:12 GMT+02:00 Sumedha Rubasinghe sume...@wso2.com:

 Frank,
 To make testing and development simple, we try to avoid database specific
 code as much as possible with in Carbon platform. Currently most of the
 products support close to 9 RDBMS engines.

 99% of the SQLs we have in our DAO classes are ANSI compatible.  However
 there are database specific DDLs under product-name/dbscripts folder. But
 these only contain DDLs that creates tables, indexes, triggers for identity
 in a db specific way. We have not used triggers for any other purpose.

 Although stored procedures provide heavy advantages, we have avoided using
 them due to the complexity of managing them for different databases.
  On Sep 14, 2014 4:19 PM, Frank Leymann fr...@wso2.com wrote:

 This is true in general:  even a simple statement like SELECT behaves a
 bit differently in different RDBMS implementations. I.e. minor differences
 in SQL statements is not restricted to triggers, however we use RDBMS...


 Best regards,
 Frank

 2014-09-12 10:24 GMT+02:00 Sumedha Rubasinghe sume...@wso2.com:

 If you use triggers, you cannot have a database engine independent
 design.

 On Fri, Sep 12, 2014 at 1:21 PM, Asitha Nanayakkara asi...@wso2.com
 wrote:

 According to an offline chat I had with PrabathA SQL triggers should be
 avoided since SQL triggers execute outside SQL transactions.

 On Thu, Jul 24, 2014 at 6:30 PM, Hasitha Hiranya hasit...@wso2.com
 wrote:

 Hi,

 According to mail arch@ Removing Global Queue from MB, maybe we
 need to update this design.
 Better we discuss upfront if so.

 It will bring changes to messageStore interface.

 Thanks


 On Thu, Jul 24, 2014 at 3:04 PM, Asitha Nanayakkara asi...@wso2.com
 wrote:

 With the addition of message expiration feature RDBMS design for
 Metadata in MB needs to be changed.
 Updated design is as follows.




 * ​Design considerations*

- Only a subset of messages comes with message expiration and a
separate thread handles deletion of expired messages.
- Periodically expired message deletion thread queries for a
chunk of expired messages. The subset of messages to go through would 
 be
less when a separated Expiration table is used. However when deleting 
 a
message from Expiration table should trigger a delete of all the 
 messages
with the respective message_id from Metadata table.

 In addition, to update reference count of messages an SQL trigger
 will be created. Is there any performance hit using triggers?




 On Thu, Jul 24, 2014 at 12:06 PM, Asitha Nanayakkara asi...@wso2.com
  wrote:

 With current design in memory message store will be used only in
 single node mode.


 On Wed, Jul 23, 2014 at 11:36 AM, Dhanuka Ranasinghe 
 dhan...@wso2.com wrote:

 Also, normally publisher mention whether to persist or not messages
 in message itself (delivery mode). So based on that MB will process
 messages in memory and/or persist to a persistence store. So if it's
 process in memory How do we communicate through the MB cluster?


 http://activemq.apache.org/what-is-the-difference-between-persistent-and-non-persistent-delivery.html


 *Dhanuka Ranasinghe*

 Senior Software Engineer
 WSO2 Inc. ; http://wso2.com
 lean . enterprise . middleware

 phone : +94 715381915


 On Mon, Jul 21, 2014 at 12:36 PM, Dhanuka Ranasinghe 
 dhan...@wso2.com wrote:

 IMO, If we gonna keep huge messages as chunks in memory and insert
 into DB as bulk it will heavily affect on MB heap memory. My 
 suggestion is
 we need to handle this case by case. For example, if it's small 
 messages it
 will be efficient to keep in memory while huge messages it will be
 efficient to insert into DB early as possible and let others to use 
 heap
 memory. For this we will have to make this functionality more 
 configurable
 but again we will have to think about how gonna support fail over 
 (probably
 have to change db schema).

 *Dhanuka Ranasinghe*

 Senior Software Engineer
 WSO2 Inc. ; http://wso2.com
 lean . enterprise . middleware

 phone : +94 715381915


 On Mon, Jul 21, 2014 at 9:00 AM, Asitha Nanayakkara 
 asi...@wso2.com wrote:

 We are planning to insert message chunks as batch insert queries.


 On Sat, Jul 19, 2014 at 11:00 AM, Dhanuka Ranasinghe 
 dhan...@wso2.com wrote:

 Are we going to insert whole message or as chunks
 On 18 Jul 2014 18:06, Asitha Nanayakkara asi...@wso2.com
 wrote:

  Hi,

 Following is the RDBMS design for WSO2 MB 3.0.0

 Messages model

 ​Message metadata model


 ​
 Following are the concerns came across in the discussion

 *- Why we use reference counting for message meta data?*

 Reference counting is needed to delete topic messages

Re: [Architecture] RFC: Could we support Hive executions on top of Hazelcast?

[Frank Leymann]

Hi Srinath,

another minor point that came to me:  Google announced recently the
successor of MapReduce, called Google Cloud Dataflow (
http://googlecloudplatform.blogspot.in/2014/06/reimagining-developer-productivity-and-data-analytics-in-the-cloud-news-from-google-io.html).
Because you are mentioning MapReduce sometimes you may get questions about
Google Cloud Dataflow :-)



Best regards,
Frank


2014-09-05 12:07 GMT+02:00 Srinath Perera srin...@wso2.com:

 Hi Paul,

 I have been playing with it a bit, but have lot of figuring out to do. I
 think we should do Spark anyway in near future.

 --Srinath


 On Fri, Sep 5, 2014 at 2:40 PM, Paul Fremantle p...@wso2.com wrote:

 What about our idea of using the Siddhi language for the long-running map
 reduce side as well?

 Paul


 On 5 September 2014 09:57, Srinath Perera srin...@wso2.com wrote:

 Hi All,

 Hazelcast now also have a MapReduce implementation. May be we can change
 hive so it can also submit jobs to Hazelcast in addition to MapReduce. Then
 users can load lot of data to hazelcast and process them with HiveSQL.

 1. It will enable users to also do in memory computing using Hive SQL
 2. It will enable ad-hoc queries that return fast results over a large
 dataset using HiveSQL

 IMO it will be a pretty tool In-memory computing scenario.

 WDYT?

 --Srinath

 p.s. One concern is when we support Spark, it will also have much
 similar support via .cache() in RDDs. So this might be a redundant feature
 at the time.



 --
 
 Director, Research, WSO2 Inc.
 Visiting Faculty, University of Moratuwa
 Member, Apache Software Foundation
 Research Scientist, Lanka Software Foundation
 Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
 Site: http://people.apache.org/~hemapani/
 Photos: http://www.flickr.com/photos/hemapani/
 Phone: 0772360902




 --
 Paul Fremantle
 CTO and Co-Founder, WSO2
 OASIS WS-RX TC Co-chair, Apache Member

 UK: +44 207 096 0336

 blog: http://pzf.fremantle.org
 twitter.com/pzfreo
 p...@wso2.com

 wso2.com Lean Enterprise Middleware

 Disclaimer: This communication may contain privileged or other
 confidential information and is intended exclusively for the addressee/s.
 If you are not the intended recipient/s, or believe that you may have
 received this communication in error, please reply to the sender indicating
 that fact and delete the copy you received and in addition, you should not
 print, copy, retransmit, disseminate, or otherwise use the information
 contained in this communication. Internet communications cannot be
 guaranteed to be timely, secure, error or virus-free. The sender does not
 accept liability for any errors or omissions.




 --
 
 Director, Research, WSO2 Inc.
 Visiting Faculty, University of Moratuwa
 Member, Apache Software Foundation
 Research Scientist, Lanka Software Foundation
 Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
 Site: http://people.apache.org/~hemapani/
 Photos: http://www.flickr.com/photos/hemapani/
 Phone: 0772360902

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] RFC: Could we support Hive executions on top of Hazelcast?

[Frank Leymann]

Sorry - my comment is on the wrong thread :-(


Best regards,
Frank


2014-09-07 15:26 GMT+02:00 Frank Leymann fr...@wso2.com:

 Hi Srinath,

 another minor point that came to me:  Google announced recently the
 successor of MapReduce, called Google Cloud Dataflow (
 http://googlecloudplatform.blogspot.in/2014/06/reimagining-developer-productivity-and-data-analytics-in-the-cloud-news-from-google-io.html).
 Because you are mentioning MapReduce sometimes you may get questions about
 Google Cloud Dataflow :-)



 Best regards,
 Frank


 2014-09-05 12:07 GMT+02:00 Srinath Perera srin...@wso2.com:

 Hi Paul,

 I have been playing with it a bit, but have lot of figuring out to do. I
 think we should do Spark anyway in near future.

 --Srinath


 On Fri, Sep 5, 2014 at 2:40 PM, Paul Fremantle p...@wso2.com wrote:

 What about our idea of using the Siddhi language for the long-running
 map reduce side as well?

 Paul


 On 5 September 2014 09:57, Srinath Perera srin...@wso2.com wrote:

 Hi All,

 Hazelcast now also have a MapReduce implementation. May be we can
 change hive so it can also submit jobs to Hazelcast in addition to
 MapReduce. Then users can load lot of data to hazelcast and process them
 with HiveSQL.

 1. It will enable users to also do in memory computing using Hive SQL
 2. It will enable ad-hoc queries that return fast results over a large
 dataset using HiveSQL

 IMO it will be a pretty tool In-memory computing scenario.

 WDYT?

 --Srinath

 p.s. One concern is when we support Spark, it will also have much
 similar support via .cache() in RDDs. So this might be a redundant feature
 at the time.



 --
 
 Director, Research, WSO2 Inc.
 Visiting Faculty, University of Moratuwa
 Member, Apache Software Foundation
 Research Scientist, Lanka Software Foundation
 Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
 Site: http://people.apache.org/~hemapani/
 Photos: http://www.flickr.com/photos/hemapani/
 Phone: 0772360902




 --
 Paul Fremantle
 CTO and Co-Founder, WSO2
 OASIS WS-RX TC Co-chair, Apache Member

 UK: +44 207 096 0336

 blog: http://pzf.fremantle.org
 twitter.com/pzfreo
 p...@wso2.com

 wso2.com Lean Enterprise Middleware

 Disclaimer: This communication may contain privileged or other
 confidential information and is intended exclusively for the addressee/s.
 If you are not the intended recipient/s, or believe that you may have
 received this communication in error, please reply to the sender indicating
 that fact and delete the copy you received and in addition, you should not
 print, copy, retransmit, disseminate, or otherwise use the information
 contained in this communication. Internet communications cannot be
 guaranteed to be timely, secure, error or virus-free. The sender does not
 accept liability for any errors or omissions.




 --
 
 Director, Research, WSO2 Inc.
 Visiting Faculty, University of Moratuwa
 Member, Apache Software Foundation
 Research Scientist, Lanka Software Foundation
 Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
 Site: http://people.apache.org/~hemapani/
 Photos: http://www.flickr.com/photos/hemapani/
 Phone: 0772360902

 ___
 Architecture mailing list
 Architecture@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture



___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture