Sounds good!

On Thu, Sep 26, 2013 at 9:24 AM, Hasitha Aravinda <[email protected]> wrote:

> Hi Srinath,
>
> We changed only the registration service implementation and others are
> unchanged. Initial decision was to have a one registration service
> (Jax-ws service) for whole BPS cluster. But we have found some
> difficulties to implement it. So in the current architecture,
> registration service is implemented as a carbon admin service and now
> it is per tenant. This approach has resolved security and tenant
> related problems we had.
>
> Other change is we have introduced an option in configuration to skip
> the registration service during the task creation phase. This is not
> compliant with HT 1.1 specification. But this will prevent additional
> overhead of registration service invocation. This is an optimization
> configuration.
>
> Thanks,
> Hasitha.
>
>
> On Thu, Sep 26, 2013 at 7:15 AM, Srinath Perera <[email protected]> wrote:
> > Hi Hasitha,
> >
> > Do we have major changes from what we agree on the last review? do we
> need a
> > new review?
> >
> > --Srinath
> >
> >
> > On Thu, Sep 19, 2013 at 12:07 PM, Hasitha Aravinda <[email protected]>
> wrote:
> >>
> >> Hi all,
> >>
> >> I was working on $subject during past few weeks and have completed its
> >> implementation. This mail will brief its basic
> >> functionalities/configurations and changes have been done to the code
> base.
> >>
> >> Support for HumanTask Coordination.
> >>
> >> B4P module and Task Engine supports following functions,
> >>
> >> Support for Task Coordination : Exit, Skip, Fault  protocol messages
> >> Support for Human Task Context : Using this function, process designer
> can
> >> make a task Skippable, override task priority at run time.
> >>
> >>
> >>
> >> This feature has introduced additional services (i.e Registration
> service,
> >> Task engine protocol handler) to both B4P module and Task engine. These
> >> service are implemented as admin services. Following diagram will
> explain
> >> its overall architecture.
> >>
> >>
> >>
> >> HTCoordinator is an axis2 module, which is engaged with Human Task
> >> Services. It does task registration with Task parent. Protocol Handler
> >> services handle coordination protocol messages ( exit, skip, and fault
> ). We
> >> reuse HumanTask's callback service as the task parent's protocol handler
> >> service.
> >>
> >>
> >> Message exchange scenarios in human task coordination.
> >>
> >> Task Registration with Task Parent.
> >>
> >> 1) People Activity sends a task creation request with both
> ws-coordination
> >> context and task context soap headers. ws-coordination context contains
> the
> >> EPR of the registration service and Task context has override
> attributes of
> >> the task.
> >> 2) The Task creation request is captured by HT coordinator ( the Axis2
> >> module ) and send task registration request to the task parent's
> >> registration service. Task registration request contains EPR of the task
> >> engine's protocol handler service.
> >> 3) Registration service registers the task and persists coordination
> data
> >> in the database. Then it sends back registration response.
> >> 4) Now Task engine creates the task.
> >> 5) Task creation response is sent back to People Activity with task
> >> correlation details.
> >>
> >> On successful Task completion : Task output is sent to the callback
> >> service.
> >> If a task is Skipped by the Task owner: Task engine sends a skip
> protocol
> >> message to the Task parent's protocol handler. Then corresponding people
> >> activity is marked as completed.
> >> If task experience a fault:  Task engine sends a fault protocol message
> to
> >> the Task parent's protocol handler. Then B4P module throw a
> >> nonRecoverableError in the scope enclosing the people activity.
> >> If Process Instance terminated or Completed with Fault: Sends a exit
> >> protocol message to task engine, to exit all human tasks, which are
> >> associated with a particular process instance.
> >>
> >> At the end of last four message exchange scenarios, relevant
> coordination
> >> data are removed from the database.
> >>
> >>
> >> Design Requirement
> >>
> >> Task Parent listens to Life cycle events of process instances, which are
> >> generated by ode engine and uses the instance termination event to send
> Exit
> >> protocol message to task processor for the termination of associated
> task
> >> instances. Therefore enabling instanceLifecycle events is required for a
> >> bpel process which uses b4p extension activity.
> >>
> >>
> >> Configuration and Backward compatibility
> >>
> >> This feature support backward compatibility and configurable using
> >> b4p-coordination-config.xml and humantask.xml.
> >>
> >> Enable HumanTask Coordination: In default configuration, humantask
> >> coordination is disabled. User can enable this feature by setting
> >> <TaskCoordinationEnabled > to true.
> >>
> >> Registration service : This service is compliant with HumanTask 1.1
> >> Specification. However, Task Registration introduces overhead as
> additional
> >> web service invocation is required. So in default configuration Task
> >> Registration and Registration service are disabled.
> >>
> >> Protocol Handler/Registration service authentication: These services are
> >> implemented as wso2 carbon admin services. In order to access these
> >> services, a user needs to be authenticated to the system. In wso2 bps
> Task
> >> coordination, these service are authenticated using a user created in
> BPS
> >> and configured within the config files. These credentials can be secured
> >> (encrypted) using WSO2 secure vault tool.
> >>
> >> Clustered Task Engines: If task engines are clustered, user need to
> >> specify load balancer URL in the above configuration files.
> >>
> >>
> >>
> >> Previous Architecture Discussions:
> >>
> >> [1] Implementing HumanTask Coordination Protocol for BPS
> >> [2] Coordination Support for Human Tasks
> >> [3] Authenticating the Task parent in HumanTask coordination service
> >>
> >>
> >> Thanks,
> >> Hasitha
> >>
> >> --
> >> Hasitha Aravinda,
> >> Software Engineer,
> >> WSO2 Inc.
> >> Email: [email protected]
> >> Mobile: +94 71 8 210 200
> >>
> >> _______________________________________________
> >> Architecture mailing list
> >> [email protected]
> >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
> >>
> >
> >
> >
> > --
> > ============================
> > Srinath Perera, Ph.D.
> >    http://people.apache.org/~hemapani/
> >    http://srinathsview.blogspot.com/
> >
> > _______________________________________________
> > Architecture mailing list
> > [email protected]
> > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
> >
>
>
>
> --
> Hasitha Aravinda,
> Software Engineer,
> WSO2 Inc.
> Email: [email protected]
> Mobile: +94 71 8 210 200
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>



-- 
============================
Srinath Perera, Ph.D.
   http://people.apache.org/~hemapani/
   http://srinathsview.blogspot.com/
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to