[Architecture] Service versioning for Carbon admin services
Admin service WSDL fix the contract between the actual service implementation and the client. If you take ServiceProviderRegistration service in IS - then the Service Provider Registration UI is one client - and also App Manager is another client. There can be many clients as well. Right now we cannot version admin services. If we make any changes to the ServiceProviderRegistration service which is to enhance the features in IS - then the released version of App Manager will not work with the latest version of the IS. This is only example. As our platform grows, and as we find many integration scenarios between products - this will become a problem. I think taking a dependency of a particular version of the service will solve this issue. Then IS can ship both the versions of the service. External applications can use old version while the UI component can use the new one. Appreciate any suggestions/thoughts on 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 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Service versioning for Carbon admin services
Hi Prabath, Great idea, This will loosen the dependency between the admin service and the admin service clients. So the admin services can evolve easily, as new features come under a different version tag and existing functionalities are not effected. But we have to have some policies to control that new additions, Those should be only, 1. Improvements 2. New features that aligned with the original purpose of that admin services Otherwise everyone will try to add/improve admin services with different different features and finally endup as totally different 'hybrid' admin service, with bunch of functionality that are not related to each other. And there should be some system to keep version details of admin services. Everyone using those admin services should update to the latest service ASAP. If not we will have to face the very same problem we currently have with bundles. Thanks, Jayanga. ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [App Factory] Jira Integration for WSO2 App Factory
Hi Fathima, Regarding project names, I can see below options based on your document. 1. If the project name is already taken, let user to come up with another project name. 2. Treat applications as jira project components. 3. Append the tenant domain to the project name. If we need to multi tenant the jira, as mentioned in option 3 in document, we can start up new jira cartridge per tenant. If jira instance is provided, and it needs to store multiple tenant projects, we need to choose from above options. thank you. On Fri, Apr 3, 2015 at 10:27 AM, Fathima Dilhasha dilha...@wso2.com wrote: Hi Manjula, Thanks for the feedback. Regarding 1. I agree with you that we can use role based mapping to restrict accessibility to each project. But we will be using the admin user to create apps in the JIRA instance. Given that, I can't still find a way to solve the problem of having similar named projects for two or more tenants. Regarding 2. Are u referring to scenario 3 in the diagram? That is for creating a project in an App Factory defined instance ? If so +1, an admin user can be maintained to do that. Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Inc.* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 On Fri, Apr 3, 2015 at 9:44 AM, Manjula Rathnayake manju...@wso2.com wrote: Hi all, This is regarding using a single JIRA instance for all apps in all tenants. 1. Using the role based access control, we can restrict users seeing other tenant applications. ex: foo tenant users are assigned to foo_role in jira. @Dilhasha, Please have a look at jira role mapping to jira projects. 2. Regarding the login issue, we can use a predefined system user in jira to create projects, assign users on behalf of other users. thank you. On Fri, Apr 3, 2015 at 12:50 AM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, I have specified a flow chart and my suggestions regarding the scenarios in [1]. https://docs.google.com/document/d/1qDRObBh4CLnO755TgyINWAey9c1X3W1BFI-hgkh9rlQ/edit?usp=sharing Please comment and point out any mistakes and suggest any other options we can consider. [1] https://docs.google.com/document/d/1qDRObBh4CLnO755TgyINWAey9c1X3W1BFI-hgkh9rlQ/edit?usp=sharing Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Inc.* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 On Wed, Apr 1, 2015 at 10:38 PM, Anuruddha Premalal anurud...@wso2.com wrote: Hi Punnadi, We cannot store credentials in a configuration file since this is a per application configuration. Regards, Anuruddha. On Wed, Apr 1, 2015 at 9:43 AM, Punnadi Gunarathna punn...@wso2.com wrote: Hi Fathima, Can't we store the credentials in a configuration file, which are required to create the JIRA instance? If that is possible, We can make use of Secure Vault to secure the plain text password. WDYT? On Apr 1, 2015 8:04 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, Okay, now I understand your first question. AFAIK, there is no way to customize authentication behavior, in a way that we can allow to have similar project names for different tenants. We can have groups of users and manage visibility of each project on a single JIRA instance, among users in that instance as specified in [1] https://confluence.atlassian.com/display/Cloud/Managing+project+visibility . What you are suggesting is to map a user in JIRA to a particular tenant in App Factory, is it? [1] https://confluence.atlassian.com/display/Cloud/Managing+project+visibility Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Inc.* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 On Wed, Apr 1, 2015 at 7:56 PM, danush...@wso2.com wrote: /s/pretty/pre Thanks Regards Danushka Fernando Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 *From:* Danushka Fernando danush...@wso2.com *Sent:* Wednesday, April 1, 2015 7:30 PM *To:* architecture architecture@wso2.org I understand that fact. What I was asking is can we customize the authentication behavior. Are there extension points. Any way if there are not you can have a pretty defined user for each tenant same as we do for jenkins. Thanks Regards Danushka Fernando Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 On Apr 1, 2015 7:14 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi danushka, The issue is with how the SOAP API for JIRA works. It requires admin username and password to establish a SOAP session, to create a project via the SOAP API. If we are to create a project on a user specified JIRA instance, the username and password (For that particular JIRA instance) are required. Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Inc.* email : *dilha...@wso2.com
[Architecture] Using renewal/cancel WS-Trust bindings to manage SAML tokens issued by SAML 2.0 Web SSO profile
AFAIK the $subject is not working today. Can we please get that fixed...? This would lead us to many more useful integration patterns... -- 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
Re: [Architecture] Generic workflow executor across the platform
Hi Pulasthi, you mentioned only BPS/BPEL-engine. What about the BPS/BPMN-activiti-engine? Should it not a prefered way to define workflows? best regards Manfred 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: To store in the registry To store in a database Say in ES, we want to provide workflow support for asset creation. Storing
