Re: [Architecture] Clarification of Registering a Lean Task Definition
I prefer to make it a configurable option. Since specification does not allow creating task with the same name, lets make it the default behavior. We can give an option from the configuration file to define whether to create a new task. Regards Nandika On Tue, Mar 31, 2015 at 7:13 AM, Hasitha Aravinda hasi...@wso2.com wrote: Hi, [Adding Architecture] According to HT spec we can't have two lean task definition with same name. But we provide versioning for HumanTask, So IMO we can apply same Task versioning rules for LeanTask as well. So If user registers two versions of TODO lean task definitions, first task will be TODO-1 and 2nd will be TODO-2. But only the latest will be active to create new lean tasks. Thanks, Hasitha. On Mon, Mar 30, 2015 at 5:16 PM, Yasima Dewmini yas...@wso2.com wrote: Hi, This is regarding registering a lean task definition. According to the Human Task Specification, if an existing Lean Task exists at the same name as the htd:tLeanTask/@Name, the WSHumanTask Processor should return an htlt:illegalStateFault. But can't it be used with task versioning? Highly appreciate your comments. Thanks. Yasima. -- K.Y.Dewmini Software Engineer Intern mobile: 0713117081 -- Hasitha Aravinda, Software Engineer, WSO2 Inc. Email: hasi...@wso2.com Mobile: +94 71 8 210 200 -- Nandika Jayawardana Senior Technical Lead WSO2 Inc ; http://wso2.com lean.enterprise.middleware ___ 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, What did you mean by user's name ? Is it App owner ? If so +1 Just one clarification. Suppose there are 2 tenants A and B. Both have created applications named 'app1'. So will it be shown in jira as two projects with same name ? Or is it visible only within tenant's scope. What if we append tenant domain to application name and put it as project name. WDYT ? Thanks. On Tue, Mar 31, 2015 at 12:40 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, I have been successful in creating a project in a Jira instance via a SOAP client included in the issue tracking component in App Factory. Now, I have few clarifications regarding this project creation. When we create a Jira project for a specific Application in Appfactory, we have to specify a project name, and a project lead for that project. My suggestion is to use the application name as the project name and add a jira user with that user's name to our Jira instance. WDYT? Is there any better way we can do this? Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Lanka* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Mahesh Chinthaka Vidanagama* | Software Engineer WSO2, Inc | lean. enterprise. middleware. #20, Palm Grove, Colombo 03, Sri Lanka Mobile: +94 71 63 63 083 | Work: +94 112 145 345 Email: mahe...@wso2.com | Web: www.wso2.com ___ 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, Okay, I got it now. So, there is no possibility of having similar named projects in a particular tenant right? If so appending tenant domain to the project name will be the best approach we can take. +1 for that. Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Lanka* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 On Tue, Mar 31, 2015 at 1:36 PM, Manisha Gayathri mani...@wso2.com wrote: On Tue, Mar 31, 2015 at 1:31 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi Mahesh, Yes, what I meant was App owner. Thanks for pointing out the scenario of having two similar named projects. AFAIK, we can not have projects with same name in a single Jira instance. +1 for Appending the App owners name at the end. That would solve that issue. Rather this should be tenant 'domain' of the app owner. If joh...@foo.com creates DummyProj, as the app then the JIRA project name will look like, fooDummyProj Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Lanka* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 On Tue, Mar 31, 2015 at 1:18 PM, Mahesh Chinthaka mahe...@wso2.com wrote: Hi Fathima, What did you mean by user's name ? Is it App owner ? If so +1 Just one clarification. Suppose there are 2 tenants A and B. Both have created applications named 'app1'. So will it be shown in jira as two projects with same name ? Or is it visible only within tenant's scope. What if we append tenant domain to application name and put it as project name. WDYT ? Thanks. On Tue, Mar 31, 2015 at 12:40 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, I have been successful in creating a project in a Jira instance via a SOAP client included in the issue tracking component in App Factory. Now, I have few clarifications regarding this project creation. When we create a Jira project for a specific Application in Appfactory, we have to specify a project name, and a project lead for that project. My suggestion is to use the application name as the project name and add a jira user with that user's name to our Jira instance. WDYT? Is there any better way we can do this? Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Lanka* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Mahesh Chinthaka Vidanagama* | Software Engineer WSO2, Inc | lean. enterprise. middleware. #20, Palm Grove, Colombo 03, Sri Lanka Mobile: +94 71 63 63 083 | Work: +94 112 145 345 Email: mahe...@wso2.com | Web: www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- ~Regards *Manisha Eleperuma* Software Engineer WSO2, Inc.: http://wso2.com lean.enterprise.middleware *blog: http://manisha-eleperuma.blogspot.com/ http://manisha-eleperuma.blogspot.com/* *mobile: +94 71 8279777 %2B94%2071%208279777* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ 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
On Tue, Mar 31, 2015 at 1:31 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi Mahesh, Yes, what I meant was App owner. Thanks for pointing out the scenario of having two similar named projects. AFAIK, we can not have projects with same name in a single Jira instance. +1 for Appending the App owners name at the end. That would solve that issue. Rather this should be tenant 'domain' of the app owner. If joh...@foo.com creates DummyProj, as the app then the JIRA project name will look like, fooDummyProj Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Lanka* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 On Tue, Mar 31, 2015 at 1:18 PM, Mahesh Chinthaka mahe...@wso2.com wrote: Hi Fathima, What did you mean by user's name ? Is it App owner ? If so +1 Just one clarification. Suppose there are 2 tenants A and B. Both have created applications named 'app1'. So will it be shown in jira as two projects with same name ? Or is it visible only within tenant's scope. What if we append tenant domain to application name and put it as project name. WDYT ? Thanks. On Tue, Mar 31, 2015 at 12:40 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, I have been successful in creating a project in a Jira instance via a SOAP client included in the issue tracking component in App Factory. Now, I have few clarifications regarding this project creation. When we create a Jira project for a specific Application in Appfactory, we have to specify a project name, and a project lead for that project. My suggestion is to use the application name as the project name and add a jira user with that user's name to our Jira instance. WDYT? Is there any better way we can do this? Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Lanka* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Mahesh Chinthaka Vidanagama* | Software Engineer WSO2, Inc | lean. enterprise. middleware. #20, Palm Grove, Colombo 03, Sri Lanka Mobile: +94 71 63 63 083 | Work: +94 112 145 345 Email: mahe...@wso2.com | Web: www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- ~Regards *Manisha Eleperuma* Software Engineer WSO2, Inc.: http://wso2.com lean.enterprise.middleware *blog: http://manisha-eleperuma.blogspot.com/ http://manisha-eleperuma.blogspot.com/* *mobile: +94 71 8279777* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Clarification of Registering a Lean Task Definition
On Tue, Mar 31, 2015 at 12:13 PM, Nandika Jayawardana nand...@wso2.com wrote: I prefer to make it a configurable option. Since specification does not allow creating task with the same name, lets make it the default behavior. We can give an option from the configuration file to define whether to create a new task. Yes, Let's make it configurable. Thanks, Hasitha. Regards Nandika On Tue, Mar 31, 2015 at 7:13 AM, Hasitha Aravinda hasi...@wso2.com wrote: Hi, [Adding Architecture] According to HT spec we can't have two lean task definition with same name. But we provide versioning for HumanTask, So IMO we can apply same Task versioning rules for LeanTask as well. So If user registers two versions of TODO lean task definitions, first task will be TODO-1 and 2nd will be TODO-2. But only the latest will be active to create new lean tasks. Thanks, Hasitha. On Mon, Mar 30, 2015 at 5:16 PM, Yasima Dewmini yas...@wso2.com wrote: Hi, This is regarding registering a lean task definition. According to the Human Task Specification, if an existing Lean Task exists at the same name as the htd:tLeanTask/@Name, the WSHumanTask Processor should return an htlt:illegalStateFault. But can't it be used with task versioning? Highly appreciate your comments. Thanks. Yasima. -- K.Y.Dewmini Software Engineer Intern mobile: 0713117081 -- Hasitha Aravinda, Software Engineer, WSO2 Inc. Email: hasi...@wso2.com Mobile: +94 71 8 210 200 -- Nandika Jayawardana Senior Technical Lead WSO2 Inc ; http://wso2.com lean.enterprise.middleware -- Hasitha Aravinda, Software Engineer, WSO2 Inc. Email: hasi...@wso2.com Mobile: +94 71 8 210 200 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Exploded web app deployment for developer studio
Hi all, As per the offline discussion I had with Jasintha, We are taking the approach [1] mentioned in the previous mail. regards Awanthika On Fri, Feb 27, 2015 at 3:01 PM, Awanthika Senarath awanth...@wso2.com wrote: Hi all, On proceeding with the task, there are two sub-tasks as: [1] enable war file deployment to carbon server without being wrapped by car [2] make the war deployment as exploded web app deployment for [1] - Currently we assign a publisher for the project being deployed only considering the server (if carbon server, the publisher is always CAppDeployer) In order to recognize the deployer by project as well (in addition to the server) is it safe to use the project nature? so that we will be recognizing web application projects by org.wso2.developerstudio.eclipse.webapp.project.nature which is a project property. for [2] - We will directly deploy the web application without creating the war file we need to compile the project copy the WebContent resources to the repository/deployment/server/webapps of the carbon server. Appreciate your suggestions on this. regards Awanthika On Thu, Feb 26, 2015 at 11:09 AM, Awanthika Senarath awanth...@wso2.com wrote: on $subject.. AFAIU what we need to do is enable exploded web app deployment when we deploy Developer Studio web applications to WSO2 AS , as similar to normal Dynamic web project deployment done in eclipse to Tomcat (correct me if I am wrong) according to my finding exploded we application deployment means deploying a web application in its extracted format (not the .war compressed version). Is there any other definition? Further, - Currently in Dev Studio if one wants to deploy a web application to AS they have to wrap it in a car file and deploy it as we do not support war deployment to AS via developer studio. (we only support the inherent war deployment to tomcat in eclipse which is already in exploded deployment format) - In order to enable exploded web application deployment we will have to first support direct war file deployment to AS via dev studio and then make it exploded war file deployment.. Appreciate feedback on this! regards Awanhtika On Wed, Feb 25, 2015 at 7:06 PM, Awanthika Senarath awanth...@wso2.com wrote: Yes KasunG :) noted.. this was an ongoing team thread we decided to make public.. content will add up once the discussion goes on, I will add the history with that On Wed, Feb 25, 2015 at 6:22 PM, KasunG Gajasinghe kas...@wso2.com wrote: Hi Awanthika, It seems your mail body is empty. :-) On Wed, Feb 25, 2015 at 6:16 PM, Awanthika Senarath awanth...@wso2.com wrote: Adding Architecture group ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Kasun Gajasinghe*Senior Software Engineer, WSO2 Inc. email: kasung AT spamfree wso2.com linked-in: http://lk.linkedin.com/in/gajasinghe blog: http://kasunbg.org ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Awanthika Senarath Software Engineer, WSO2 Inc. Mobile: +94717681791 -- Awanthika Senarath Software Engineer, WSO2 Inc. Mobile: +94717681791 -- Awanthika Senarath Software Engineer, WSO2 Inc. Mobile: +94717681791 -- Awanthika Senarath Software Engineer, WSO2 Inc. Mobile: +94717681791 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] RFC: RESTFul API for API Manager
Hi Jo,
is it possible for you to have a call tomorrow, Wednesday, 4/1, 2pm Colombo
time (i.e. 10:30am Germany, daylight-savings-time). I thing a 30...60
minutes will be suffice. Main purpose would be how to proceed :-)
I find Skype more reliable than Hangouts. Would you mind about a Skype
call? My SkypeID is frank.leymann
Talk to you then!
Best regards,
Frank
2015-03-30 13:03 GMT+02:00 Joseph Fonseka jos...@wso2.com:
Hi Frank
Thanks for the feedback. And it is nice to see how we can control cashing
and concurrency with the additional headers. We will update the remaining
APIs with the same concepts.
Please let us know a convenient time for a call to discuss on it further.
Also we will try to document these design decisions and concepts to
benefit APIs created in the future.
BTW. The changes were pushed to the repo.
Thanks
Jo
[1] http://hevayo.github.io/restful-apim/
On Sat, Mar 28, 2015 at 12:47 AM, Frank Leymann fr...@wso2.com wrote:
Hi Jo,
again, thanks for your work: we'll get a nice RESTful API :-) In the
Richardson maturity model we'll get to level 2 (not level 3 because we are
leaving out HATEOS - which is something that is not used often today in
practice anyhow).
I exported the YAML of the API, put it into a Word document and used the
change tracking feature to comment/modify across the document - please
find the document attached. (Frank Input - API Manager API -
2015-03-27.docx)
All the changes I made to YAML itself is in the separate swagger YAML
file I attached too. I used the swagger 2.0 tool to create this YAML, and
the tool shows no syntax errors... So you may import it into your tool
without problems. (FL Input API Manager API - 2015-03-27.yaml)
I worked on the apis of the /apis and /apis/{apiID} resources. Before I
continue, I suggest that we have a discussion (i.e. a call) to discuss the
changes/suggestions I made. We need to agree whether this fits into the
plan for implementing in the next release.
Looking forward
Best regards,
Frank
2015-03-26 4:52 GMT+01:00 Joseph Fonseka jos...@wso2.com:
Hi Frank
What are the headers we should include ?
1. For the access token header we can define it globally in the security
definition [1]
https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#securityDefinitionsObject
2. Content-type headers are covered by the consumes and produces
attributes [2]
https://github.com/hevayo/restful-apim/blob/master/apim.yaml#L18-L19
3. For post methods we have an option of sending Link header with a
URL to newly created resource rather than returning newly created resource
JSON.
Thanks
Jo
[1]
https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#securityDefinitionsObject
[2] https://github.com/hevayo/restful-apim/blob/master/apim.yaml#L18-L19
On Wed, Mar 25, 2015 at 3:51 PM, Frank Leymann fr...@wso2.com wrote:
Hi Jo,
nice piece of work!
What is still needed is a description of the header fields for both,
the requests and APIs.
Best regards,
Frank
2015-03-24 17:34 GMT+01:00 Joseph Fonseka jos...@wso2.com:
Hi All
We are planing to implement a RESTFul API to expose the API Manager
functionality. This will be a replacement to the currently provided Store
and Publisher APIs [1]
https://docs.wso2.com/display/AM180/Publisher+APIs [2]
https://docs.wso2.com/display/AM180/Store+APIs.
Main Motivation.
1. The current APIs are not RESTful and they do not cover all the
functionality.
2. To make it easy to integrate and automate API manager functionality
with 3rd party systems.
3. To provide better security with Oauth.
4. To provide better versioning and documentation with the API.
As a start we have written a draft version of the API definition which
you can find here [3] http://hevayo.github.io/restful-apim/.
Following is a rough implementation plan.
1. Work on the API Definition, get feed back from users and finalize.
2. Implementation. ( Architecture , Jax-RS ?)
3. Adding Security. ( O-auth, scopes ? )
4. Testing.
5. Documentation.
API definition was written with Swagger 2 once completed we can use it
to generate server stubs, client stubs and documentation.
Please share your thoughts.
Thanks
Jo
[1] https://docs.wso2.com/display/AM180/Publisher+APIs
[2] https://docs.wso2.com/display/AM180/Store+APIs
[3] http://hevayo.github.io/restful-apim/
--
*Joseph Fonseka*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware
mobile: +94 772 512 430
skype: jpfonseka
* http://lk.linkedin.com/in/rumeshbandara*
--
--
*Joseph Fonseka*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware
mobile: +94 772 512 430
skype: jpfonseka
* http://lk.linkedin.com/in/rumeshbandara*
--
--
*Joseph Fonseka*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware
mobile: +94 772 512 430
skype: jpfonseka
* http://lk.linkedin.com/in/rumeshbandara*
Re: [Architecture] Generic workflow executor across the platform
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 asset level info in Identity database doesn't make sense. Don't think of it as Identity database. Think of it as a database coming from another feature repository. It can be any product like IS. If the same workflow component was developed by APIM then it would be AM_ tables. Apart from the naming convention the functionality is generic and extensible. The table naming convention comes from which product team develops it, thats all. Using Identity database in ES is not wrong. If you are installing IS feature you have to install the database scripts also. I know previously APIM did the same mistake of copying the identity tables into apim scripts and not executing identity scripts. I know how much duplication it made and how much of problems we ran into. I am -1 on that. If you have a strong reason to move away from database, and use registry then we need to think about making the data access layer extensible, which is open for discussion. P.S. I know we haven't sent a mail to architecture regarding the workflow component design. Will do soon. Regards, Johann. Appreciate your feedback. [1] https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/workflow/WorkflowExecutor.java [2] https://github.com/pulasthi7/carbon-identity/blob/feature/workflow-support/components/workflows/org.wso2.carbon.workflow.mgt/src/main/java/org/wso2/carbon/workflow/mgt/dao/WorkflowRequestDAO.java Thanks, Tanya -- Tanya Madurapperuma Software Engineer, WSO2 Inc. : wso2.com Mobile : +94718184439 Blog : http://tanyamadurapperuma.blogspot.com -- Thanks Regards, *Johann Dilantha Nallathamby* Associate Technical Lead Product Lead of WSO2 Identity Server Integration Technologies Team WSO2, Inc. lean.enterprise.middleware Mobile - *+9476950* Blog - *http://nallaa.wordpress.com http://nallaa.wordpress.com* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] RFC: RESTFul API for API Manager
Hi Jo, hi Manu,
how to cope with actions that cannot be mapped onto the CRUD methods on
individual resources or collection resources is always a matter of
discussion and taste when designing REST interfaces.
A very often used guideline is to use so-called *controller resources*. I
controller resources represents an application specific operation that acts
on one or more individual resources or collection resources in an atomic
manner. The copy-api is such a controller resource.
There are two ways to design URIs of controller resources. First, you
append the name of the action to one of the URIs that you atomically want
to act on, and other parameters follow in the query string; sometimes it is
random which of the URIs to append the name of the action to - this is why
I personally don't like this naming scheme. The second design uses the name
of the action as URI and the query string contains the parameters
required by the action - this is what I personally prefer because it's
deterministic and symmetric (but again, it's a matter of taste. However
you design the URI you use POST as the http method to interact with the
controller resource.
In our concrete case of copy-api the two options are:
1. /apis/{apiId}/copy-api
or
2. /copy-api?{apiID}
By the way, the similar case is the change-lifecycle controller resource.
Another reason why I like API design (2) is as follows. Often you need
actions on individual resources that don't manipulate (or retrieve) a
resource. Such actions are designed as resources called *processing
function resources* or *computing resources*. The standard example is
verifying a credit card. The design of the URIs of such processing function
resources always follows number (2). Because processing functions
resources never manipulate resources its http method is always GET, by the
way.
Finally, controller resources are used from time to time to update parts of
individual resources. Http has the PATCH method for this purpose, but not
all web servers support PATCH. PUT itself will substitute complete
resources, i.e. updating parts of an individual resource is not intended
via PUT. This is why specific controller resources may be used for partial
updates.
Best regards,
Frank
2015-03-30 19:57 GMT+02:00 Joseph Fonseka jos...@wso2.com:
Hi Manu
Copy API will duplicate not just the resource it will duplicate all the
resources associated to it as well eg. Documents. So re-posting the API
resource json will not be sufficient in this particular case. But there is
a possibility of duplicating the associated resources from the client as
well but IMHO that will complicated the client implementation.
Nevertheless its a problem that we face how to represent an action as a
resource. Currently we have adopted action-resource or attr acted
upon kind of notation.
Regards
Jo
On Mon, Mar 30, 2015 at 4:49 PM, Manuranga Perera m...@wso2.com wrote:
Hi Frank,
I see few endpoints representing actions rather than resources. For
example POST /apis/{apiId}/copy-api.
This is an action because there is no resource called copy-api. I would
rather see it as posting an existing API to the /apis.
In a HATEOS system we will be posting the href of an existing API to
/apis endpoint. Since we are not there yet, we can use some json
representation of the existing API.
What do you think?
On Tue, Mar 31, 2015 at 12:03 AM, Joseph Fonseka jos...@wso2.com wrote:
Hi Frank
Thanks for the feedback. And it is nice to see how we can control
cashing and concurrency with the additional headers. We will update the
remaining APIs with the same concepts.
Please let us know a convenient time for a call to discuss on it
further.
Also we will try to document these design decisions and concepts to
benefit APIs created in the future.
BTW. The changes were pushed to the repo.
Thanks
Jo
[1] http://hevayo.github.io/restful-apim/
On Sat, Mar 28, 2015 at 12:47 AM, Frank Leymann fr...@wso2.com wrote:
Hi Jo,
again, thanks for your work: we'll get a nice RESTful API :-) In the
Richardson maturity model we'll get to level 2 (not level 3 because we are
leaving out HATEOS - which is something that is not used often today in
practice anyhow).
I exported the YAML of the API, put it into a Word document and used
the change tracking feature to comment/modify across the document -
please find the document attached. (Frank Input - API Manager API -
2015-03-27.docx)
All the changes I made to YAML itself is in the separate swagger YAML
file I attached too. I used the swagger 2.0 tool to create this YAML, and
the tool shows no syntax errors... So you may import it into your tool
without problems. (FL Input API Manager API - 2015-03-27.yaml)
I worked on the apis of the /apis and /apis/{apiID} resources. Before I
continue, I suggest that we have a discussion (i.e. a call) to discuss the
changes/suggestions I made. We need to agree whether this fits into the
plan for
Re: [Architecture] RFC: RESTFul API for API Manager
Hi Frank
Yes 2pm is fine for me, my skype is jpfonseka. Will ask Sanjeewa
Malalgoda to join as well he was working on the ground work for the
implementation.
Thanks Regards
Jo
On Tue, Mar 31, 2015 at 5:03 PM, Frank Leymann fr...@wso2.com wrote:
Hi Jo,
is it possible for you to have a call tomorrow, Wednesday, 4/1, 2pm
Colombo time (i.e. 10:30am Germany, daylight-savings-time). I thing a
30...60 minutes will be suffice. Main purpose would be how to proceed :-)
I find Skype more reliable than Hangouts. Would you mind about a Skype
call? My SkypeID is frank.leymann
Talk to you then!
Best regards,
Frank
2015-03-30 13:03 GMT+02:00 Joseph Fonseka jos...@wso2.com:
Hi Frank
Thanks for the feedback. And it is nice to see how we can control cashing
and concurrency with the additional headers. We will update the remaining
APIs with the same concepts.
Please let us know a convenient time for a call to discuss on it further.
Also we will try to document these design decisions and concepts to
benefit APIs created in the future.
BTW. The changes were pushed to the repo.
Thanks
Jo
[1] http://hevayo.github.io/restful-apim/
On Sat, Mar 28, 2015 at 12:47 AM, Frank Leymann fr...@wso2.com wrote:
Hi Jo,
again, thanks for your work: we'll get a nice RESTful API :-) In the
Richardson maturity model we'll get to level 2 (not level 3 because we are
leaving out HATEOS - which is something that is not used often today in
practice anyhow).
I exported the YAML of the API, put it into a Word document and used the
change tracking feature to comment/modify across the document - please
find the document attached. (Frank Input - API Manager API -
2015-03-27.docx)
All the changes I made to YAML itself is in the separate swagger YAML
file I attached too. I used the swagger 2.0 tool to create this YAML, and
the tool shows no syntax errors... So you may import it into your tool
without problems. (FL Input API Manager API - 2015-03-27.yaml)
I worked on the apis of the /apis and /apis/{apiID} resources. Before I
continue, I suggest that we have a discussion (i.e. a call) to discuss the
changes/suggestions I made. We need to agree whether this fits into the
plan for implementing in the next release.
Looking forward
Best regards,
Frank
2015-03-26 4:52 GMT+01:00 Joseph Fonseka jos...@wso2.com:
Hi Frank
What are the headers we should include ?
1. For the access token header we can define it globally in the
security definition [1]
https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#securityDefinitionsObject
2. Content-type headers are covered by the consumes and produces
attributes [2]
https://github.com/hevayo/restful-apim/blob/master/apim.yaml#L18-L19
3. For post methods we have an option of sending Link header with a
URL to newly created resource rather than returning newly created resource
JSON.
Thanks
Jo
[1]
https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md#securityDefinitionsObject
[2]
https://github.com/hevayo/restful-apim/blob/master/apim.yaml#L18-L19
On Wed, Mar 25, 2015 at 3:51 PM, Frank Leymann fr...@wso2.com wrote:
Hi Jo,
nice piece of work!
What is still needed is a description of the header fields for both,
the requests and APIs.
Best regards,
Frank
2015-03-24 17:34 GMT+01:00 Joseph Fonseka jos...@wso2.com:
Hi All
We are planing to implement a RESTFul API to expose the API Manager
functionality. This will be a replacement to the currently provided Store
and Publisher APIs [1]
https://docs.wso2.com/display/AM180/Publisher+APIs [2]
https://docs.wso2.com/display/AM180/Store+APIs.
Main Motivation.
1. The current APIs are not RESTful and they do not cover all the
functionality.
2. To make it easy to integrate and automate API manager
functionality with 3rd party systems.
3. To provide better security with Oauth.
4. To provide better versioning and documentation with the API.
As a start we have written a draft version of the API definition
which you can find here [3] http://hevayo.github.io/restful-apim/.
Following is a rough implementation plan.
1. Work on the API Definition, get feed back from users and finalize.
2. Implementation. ( Architecture , Jax-RS ?)
3. Adding Security. ( O-auth, scopes ? )
4. Testing.
5. Documentation.
API definition was written with Swagger 2 once completed we can use
it to generate server stubs, client stubs and documentation.
Please share your thoughts.
Thanks
Jo
[1] https://docs.wso2.com/display/AM180/Publisher+APIs
[2] https://docs.wso2.com/display/AM180/Store+APIs
[3] http://hevayo.github.io/restful-apim/
--
*Joseph Fonseka*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware
mobile: +94 772 512 430
skype: jpfonseka
* http://lk.linkedin.com/in/rumeshbandara*
--
--
*Joseph Fonseka*
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware
mobile: +94 772 512 430
skype: jpfonseka
*
Re: [Architecture] [App Factory] Jira Integration for WSO2 App Factory
Hi Fathima, I'm -1 in appending suffixes to project name at all the time. Jira is something we are going to expose to users. IMO we should allow them (at least for users with their own jira cloud) to go with what they wanted as the project name. You have to treat this as two separate scenarios. Jira could be available in the following ways; 1.) Cloud hosted on-demand jira offered by Atlassian. - This is hosted in a multitenant way (instance per customer) . You can read more about Atlassian cloud architecture [1] - In this case you don't actually need to append any suffix to project name. However if two tenants tries to share the same Cloud jira, we have to perform the project name validation and prompt user; there is already an existing project. 2.) AppFactory hosted single jira instance. - This is where we actually face the problem of duplicate project names; And it is because we don't have the containerized deployment for jira. How are we actually going to host jira? is another topic we need to discuss. Are we going to maintain a separate jira for AppFactory or are we going to go with Atlasian jira cloud?. What are the cost factors of each of them?. If we are going with Atlasian cloud we wan't face duplicate project name issue for multiple tenants. [1] https://developer.atlassian.com/static/connect/docs/latest/concepts/cloud-development.html#overview Regards, Anuruddha. On Tue, Mar 31, 2015 at 1:12 AM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, Okay, I got it now. So, there is no possibility of having similar named projects in a particular tenant right? If so appending tenant domain to the project name will be the best approach we can take. +1 for that. Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Lanka* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 On Tue, Mar 31, 2015 at 1:36 PM, Manisha Gayathri mani...@wso2.com wrote: On Tue, Mar 31, 2015 at 1:31 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi Mahesh, Yes, what I meant was App owner. Thanks for pointing out the scenario of having two similar named projects. AFAIK, we can not have projects with same name in a single Jira instance. +1 for Appending the App owners name at the end. That would solve that issue. Rather this should be tenant 'domain' of the app owner. If joh...@foo.com creates DummyProj, as the app then the JIRA project name will look like, fooDummyProj Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Lanka* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 On Tue, Mar 31, 2015 at 1:18 PM, Mahesh Chinthaka mahe...@wso2.com wrote: Hi Fathima, What did you mean by user's name ? Is it App owner ? If so +1 Just one clarification. Suppose there are 2 tenants A and B. Both have created applications named 'app1'. So will it be shown in jira as two projects with same name ? Or is it visible only within tenant's scope. What if we append tenant domain to application name and put it as project name. WDYT ? Thanks. On Tue, Mar 31, 2015 at 12:40 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, I have been successful in creating a project in a Jira instance via a SOAP client included in the issue tracking component in App Factory. Now, I have few clarifications regarding this project creation. When we create a Jira project for a specific Application in Appfactory, we have to specify a project name, and a project lead for that project. My suggestion is to use the application name as the project name and add a jira user with that user's name to our Jira instance. WDYT? Is there any better way we can do this? Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Lanka* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Mahesh Chinthaka Vidanagama* | Software Engineer WSO2, Inc | lean. enterprise. middleware. #20, Palm Grove, Colombo 03, Sri Lanka Mobile: +94 71 63 63 083 | Work: +94 112 145 345 Email: mahe...@wso2.com | Web: www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- ~Regards *Manisha Eleperuma* Software Engineer WSO2, Inc.: http://wso2.com lean.enterprise.middleware *blog: http://manisha-eleperuma.blogspot.com/ http://manisha-eleperuma.blogspot.com/* *mobile: +94 71 8279777 %2B94%2071%208279777* ___ Architecture mailing list Architecture@wso2.org
