Hi Frank, Sorry for the delay in replying. Somehow missed this.
> ​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. > > Yes, this is the first alternative. i.e. URL of a running BPS engine/cluster where a BPEL or BPMN archive can be deployed. > 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? > A webapp URL is mostly useful when a process has human interactions (i.e. human tasks). In that case usually a web application is developed to view task lists and work on tasks. Webapp URL is the URL of such web application. If a new webapp is not available, it can point to the URL of the builtin human task webapp (which is under development). If a process does not have any human tasks, such web app is not much useful except for providing input values defined in process's WSDL. I think still it is better to have a (built-in) webapp just for starting a non-human centric process than using something like tryit tool in process center (as this is targeted more towards business users). > 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? > Yes, we are planning to support a role based authorization model, which can be used to control such things. Regards, Chathura > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
