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 *and will get executed in runtime when a request hits the >>>>> corresponding *Attachment Point*. >>>>> >>>>> Some examples of *Attachment Points* : add_user, delete_user, >>>>> add_role, add_xacml_policy, update_xacml_policy. >>>>> >>>>> *Attachment Points* - are independent from the *workflow*. >>>>> >>>>> *Attachment Points* are introduced into system via an OSGi service. >>>>> For example user_add, user_update, role_add - all those Attachment Points >>>>> are announced into the system by a UserManagerOperationListner. >>>>> >>>>> *Attachment Points *can be developed and deployed independently. Once >>>>> the system discovers the availability of an *Attachment Point *- it >>>>> will display that to the user - so he can engage and workflow to that >>>>> *Attachment >>>>> Point.* >>>>> >>>>> 3. *Attachment Point Template* >>>>> >>>>> These are coupled to specific* Attachment Points*. For example, the >>>>> *Attachment >>>>> Point Template *- associated with the user_add *Attachment Point* may >>>>> look like following. >>>>> >>>>> *user match : <reg-ex>* >>>>> >>>>> Now the *Attachment Point* will invoke the associated workflow >>>>> executor only if the above criteria is met. >>>>> >>>>> >>>>> 4. *Workflow Template *: These templates should be announced to the >>>>> system along with the *workflow* implementation. This template is >>>>> independent from the *Attachment Point Template*. This tell how to >>>>> configure the workflow. With this approach you can have the same work flow >>>>> - but configured in different ways based on the* Attachment Point*. >>>>> >>>>> Once example could be: >>>>> >>>>> Step-1 Approvers : <role1> OR <role2> AND user1 >>>>> Step-2 Approvers : <role3> OR <role4> AND user3 >>>>> >>>>> likewise... >>>>> >>>>> Okay - so far everything discussed above are related to the core >>>>> framework design. >>>>> >>>>> In IS 5.1.0 we need to have a concrete implementation of followings.. >>>>> >>>>> 1. *Attachment Points*- for all user / role related operations. >>>>> 2. *Attachment Point Templates* - for all user / role related >>>>> operations. >>>>> 3. *Workflow* - initiator and executor for WSO2 BPS BPEL >>>>> implementation - and concrete multi-step approval BPEL workflow. >>>>> 4. *Workflow Templates*: A template for the multi-step approval BPEL >>>>> workflow >>>>> >>>>> Please let me know if you have any doubts or suggestions.. also >>>>> Johann/Pulsathi please verify whether the implementation is done according >>>>> to this. >>>>> >>>>> -- >>>>> Thanks & Regards, >>>>> Prabath >>>>> >>>>> Twitter : @prabath >>>>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>>>> >>>>> Mobile : +1 650 625 7950 >>>>> >>>>> http://blog.facilelogin.com >>>>> http://blog.api-security.org >>>>> >>>> >>>> >>> >>> >>> -- >>> Thanks & Regards, >>> Prabath >>> >>> Twitter : @prabath >>> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena >>> >>> Mobile : +1 650 625 7950 >>> >>> http://blog.facilelogin.com >>> http://blog.api-security.org >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> /sumedha >> m: +94 773017743 >> b : bit.ly/sumedha >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Mobile : +1 650 625 7950 > > http://blog.facilelogin.com > http://blog.api-security.org > -- Thanks & Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://blog.facilelogin.com http://blog.api-security.org
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
