Re: [Architecture] Workflow Implementation in IS 5.1.0
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
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
+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
[Architecture] WSO2 Message Broker - Slow topic consumers can make broker OOM
Hi, Topic message subscription practically means to be real time. Most brokers handle topic messages in-memory whereas WSO2 Message Broker store each topic message as well to provide clustering support for subscribers (publish to Node1 and subscribe from Node2). Think of a scenario where there are multiple topic subscribers. We do not duplicate the message for each subscriber, rather do reference counting. Message is considered as delivered if all topic consumers sent the ACK to the server. Now, when there is a slow topic consumer, even though all other subscribers ACK the message, as there is no ACK from the slow consumer, we need to keep the message metadata in memory for reference counting. If the situation is kept for millions of messages MB server will go Out of Memory because of the slow consumer. Thus solution to this problem is, duplicate messages per subscriber and put to the database. This solution is not going to scale with subscription count. Also will use many I/O, memory drop messages in the middle. This is not also a good solution if data is mission critical. Give the choice to the user. He can either loose messages or bare the risk of going server Out of Memory. We did a internal discussion and landed on the third option. -- *Hasitha Abeykoon* Senior Software Engineer; WSO2, Inc.; http://wso2.com *cell:* *+94 719363063* *blog: **abeykoon.blogspot.com* http://abeykoon.blogspot.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Potential for using Akka, ReactiveX or RX Java as based for next ESB
Above might be a option instead of using disrupter and trying to build the thread model from ground up. I think it is worth spending couple of days understanding. e.g RxJava https://www.youtube.com/watch?v=8OcCSQS0tug -- 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
Re: [Architecture] [AF] Adding CAR application type to App Factory
Hi Please find my answers inline On Mon, Jul 20, 2015 at 9:40 AM, Jasintha Dasanayake jasin...@wso2.com wrote: If I have understood correctly, there is a maven multimode project and inside that there are registry resource projects , an ESB project and a Capp project right ? so in your project structure graph where is the Capp project ? is it the first application id ? Yes Also what is the type of these * ResourcesCAR project ? are these registry resource projects ? Yes Hope you going to use the existing carbon CAR deployer right ? , if so existing CAR structure shouldn't be changed so it's better to validate that also in the begging Yes that's in the plan. We will have a git hook to validate this. Thanks and Regards /Jasintha On Fri, Jul 17, 2015 at 10:08 PM, Danushka Fernando danush...@wso2.com wrote: Hi All, Currently we are working on a feature that will enable to develop, deploy and manage CAR files via App Factory. As the first part of this I started working on CAR application type and the ESB runtime. In this phase the expectation is to 1. Create an car type multi module application 2. Build and Deploy the correct artifacts 3. Create versions 4. Promote Decided sample project structure would be something similar to following ├── pom.xml ├── applicationID │ └── pom.xml ├── applicationIDApplicationResources │ ├── artifact.xml │ ├── Development │ │ └── EchoServiceEP.xml │ ├── echo.wsdl │ ├── pom.xml │ ├── Production │ │ └── EchoServiceEP.xml │ └── Testing │ └── EchoServiceEP.xml ├── applicationIDDevelopmentResourcesCAR │ └── pom.xml ├── applicationIDProductionResourcesCAR │ └── pom.xml ├── applicationIDSimpleProxy │ ├── artifact.xml │ ├── pom.xml │ └── src │ └── main │ └── synapse-config │ └── proxy-services │ └── applicationIDSimpleProxyService-version.xml └── applicationIDTestingResourcesCAR └── pom.xml Since CAR Projects are built with Maven this is the first time that we are going to introduce an maven multi module application type to App Factory. Tricky parts are the versioning the project and deploy the correct artifacts. We will use extension points provided by AF to achieve these tasks. We are planning to implement an Application Type Processor, an Initial Deployer and a Deployer. Then after the Stratos 4.1.0 upgrade task is done ESB docker cartidges will use to spawn ESB instances. Thanks Regards Danushka Fernando Senior Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Jasintha Dasanayake* *Senior Software EngineerWSO2 Inc. | http://wso2.com http://wso2.com/lean . enterprise . middleware* *mobile :- 0711368118* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture Thanks Regards Danushka Fernando Senior Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Workflow Implementation in IS 5.1.0
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. As mentioned in the previous reply, for the IS use case, there are no data dependencies. However, I agree that we have to think of situations where this does not hold. Scenario B: The form mentioned in (1) could be the basis for the forms document I sketched in my last mail on this subject. Yes. In current IS scenarios, this form is already filled when the process is started. Human tasks only have to state whether to approve or not (and provide comments if necessary). 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. In the proposed approach, BPS ships with some built-in workflows and IT staff may add additional workflows if necessary. What IS users/admins do is configure those workflows by creating templates. However, we identified some problems in this approach during a discussion with IS team. Regards, Chathura 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
Re: [Architecture] Workflow Implementation in IS 5.1.0
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 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
Re: [Architecture] [AF] Adding CAR application type to App Factory
If I have understood correctly, there is a maven multimode project and inside that there are registry resource projects , an ESB project and a Capp project right ? so in your project structure graph where is the Capp project ? is it the first application id ? Also what is the type of these * ResourcesCAR project ? are these registry resource projects ? Hope you going to use the existing carbon CAR deployer right ? , if so existing CAR structure shouldn't be changed so it's better to validate that also in the begging Thanks and Regards /Jasintha On Fri, Jul 17, 2015 at 10:08 PM, Danushka Fernando danush...@wso2.com wrote: Hi All, Currently we are working on a feature that will enable to develop, deploy and manage CAR files via App Factory. As the first part of this I started working on CAR application type and the ESB runtime. In this phase the expectation is to 1. Create an car type multi module application 2. Build and Deploy the correct artifacts 3. Create versions 4. Promote Decided sample project structure would be something similar to following ├── pom.xml ├── applicationID │ └── pom.xml ├── applicationIDApplicationResources │ ├── artifact.xml │ ├── Development │ │ └── EchoServiceEP.xml │ ├── echo.wsdl │ ├── pom.xml │ ├── Production │ │ └── EchoServiceEP.xml │ └── Testing │ └── EchoServiceEP.xml ├── applicationIDDevelopmentResourcesCAR │ └── pom.xml ├── applicationIDProductionResourcesCAR │ └── pom.xml ├── applicationIDSimpleProxy │ ├── artifact.xml │ ├── pom.xml │ └── src │ └── main │ └── synapse-config │ └── proxy-services │ └── applicationIDSimpleProxyService-version.xml └── applicationIDTestingResourcesCAR └── pom.xml Since CAR Projects are built with Maven this is the first time that we are going to introduce an maven multi module application type to App Factory. Tricky parts are the versioning the project and deploy the correct artifacts. We will use extension points provided by AF to achieve these tasks. We are planning to implement an Application Type Processor, an Initial Deployer and a Deployer. Then after the Stratos 4.1.0 upgrade task is done ESB docker cartidges will use to spawn ESB instances. Thanks Regards Danushka Fernando Senior Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Jasintha Dasanayake* *Senior Software EngineerWSO2 Inc. | http://wso2.com http://wso2.com/lean . enterprise . middleware* *mobile :- 0711368118* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
