Re: [Architecture] RFC: RESTFul API for API Manager
This is very helpful Frank, and as you mentioned these controlled-resources
are always lead to discussion. Do you have any comments on the usage of '-'
instead of camel case ?
On Tue, Mar 31, 2015 at 10:51 PM, Frank Leymann fr...@wso2.com wrote:
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
[Architecture] [Dev] WSO2 Message Broker 3.0.0 Milestone 6 Released !
*WSO2 Message Broker 3.0.0 Milestone 6 Released !* The WSO2 Message Broker team is pleased to announce the 6th milestone release of WSO2 Message Broker (MB) 3.0.0. WSO2 Message Broker (WSO2 MB) 3.0.0 is designed to be a fast, lightweight and user friendly open source distributed message brokering system under the Apache Software License v2.0 http://www.apache.org/licenses/LICENSE-2.0.html. It primarily allows system administrators and developers to easily configure JMS queues and topics which could be used for message routing, message stores and message processors. WSO2 MB is compliant with Advanced Message Queuing Protocol Version 0-9-1, Java Message Service Specification version 1.1 and MQTT protocol version 3.1. WSO2 MB 3.0.0 is developed on top of the revolutionary WSO2 Carbon platform http://wso2.org/projects/carbon (Middleware a' la carte), an OSGi based framework that provides seamless modularity to your SOA via modularization. This release also contains many other new features and a range of optional components (add-ons) that can be installed to customize the behavior of the MB. Further, any existing features of the MB which are not required to your environment can be easily removed using the underlying provisioning framework of Carbon. In a nutshell, WSO2 MB can be fully customized and tailored to meet your exact SOA needs. You can download this distribution from [1]. Release notes for this milestone can be found at [2]. Known issues are listed at [3]. This milestone has mainly focused on bug fixes and performance improvements. How You Can Contribute:Mailing Lists Join our mailing list and correspond with the developers directly. - Developer List : d...@wso2.org | Subscribe | Mail Archive http://wso2.org/mailarchive/carbon-dev/ - User List : StackOverflow.com http://stackoverflow.com/questions/tagged/wso2 Reporting Issues WSO2 encourages you to report issues and your enhancement requests for the WSO2 MB using the public JIRA https://wso2.org/jira/browse/MB. You can also watch how they are resolved, and comment on the progress.. [1] https://svn.wso2.org/repos/wso2/scratch/MB/3.0.0/M6/wso2mb-3.0.0-SNAPSHOT-m6.zip https://www.google.com/url?q=https%3A%2F%2Fsvn.wso2.org%2Frepos%2Fwso2%2Fscratch%2FMB%2F3.0.0%2FM6%2Fwso2mb-3.0.0-SNAPSHOT-m6.zipsa=Dsntz=1usg=AFQjCNEIHTR6d3OKQTJdKaWZfbFZ-tkJnA [2] https://wso2.org/jira/secure/ReleaseNote.jspa?projectId=10200version=11753 https://www.google.com/url?q=https%3A%2F%2Fwso2.org%2Fjira%2Fsecure%2FReleaseNote.jspa%3FprojectId%3D10200%26version%3D11753sa=Dsntz=1usg=AFQjCNFQkFQ4oqkItosd9AekgLdXpMKsWA [3] https://wso2.org/jira/browse/MB#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel https://wso2.org/jira/browse/MB#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel -- Pumudu Ruhunage Associate Software Engineer | WSO2 Inc M: +94 779 664493 | http://wso2.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 All,
Here are my suggestions on this implementation.
When we design rest API for API Management functionality we need to focus
bit on publisher/ store aspects as well. Or we may need to have control at
some point based on the logged in user.
Here is one example:
/apis
GET /apis
API provider should be mandatory field when it comes to publisher context.
API consumer should be mandatory field when it comes to store context.
Or we should be able to retrieve current user by using JWT comes with
request or from access token. Still need to if request comes to store or
publisher context.
And based on current user permissions we may need enable, disable API
add/modification via post, put, delete.
Also for tiers we may have
/tiers
post
/tiers/{tierName}/update-permission
Request body
{
rolePermission: {
access: ,
roles:
}
}
Also for apis/{apiId} PUT need to have response with 409 Conflict as well.
Normally when we update resource with some information it cannot be
accessed due to some reason. So IMO having 409 as well would be helpful(in
addition to 412)
It would be ideal /apis/{apiId}/change-lifecycle success response returns
200 status code as we normally use 201 to indicate that new resource
created.
In this particular case we do update for existing resource state.
We may include additional response code to /apis/{apiId}/documents GET
because we may have 2 situations.
01. API does not exists(We can consider 412 for response code)
02. API exists but documents not available(we can consider 404 as requested
resource is document).
And same should apply to /apis/{apiId}/documents/{documentId} GET as well.
And we need to finalize about security model for this rest API. For that we
may consider few options.
01. Oath2 secured API.
02. Basic auth secured rest API.
03. Other security mechanisms.
My personal opinion is this rest API should be independent from security
protocol.
And our rest API should not rely on any security related information when
in process request.
If we need to verify user is having permission to do some task then we
should not do it in rest API level(api subscriber should not allow to
update API).
Thanks,
sanjeewa.
On Tue, Mar 31, 2015 at 11:07 PM, Joseph Fonseka jos...@wso2.com wrote:
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]
Re: [Architecture] Proposed ESB connector scenario - Integrating Insightly with Mailchimp, CallRail and FreshBooks
Hi All, Please find the methods that will be implemented under following connectors. *Insightly Connector* createContact - Create a new contact. updateContact - Update an existing contact. getContact - Gets a specific contact. listContacts - Gets a list of Contacts. createOpportunity - Create a new opportunity. updateOpportunity - Update an existing opportunity. getOpportunity - Gets a specific opportunity. listOpportunities - Gets a list of opportunities. createProject - Create a new project. updateProject - Update an existing project. getProject - Gets a specific project. listProjects - Gets a list of projects. createNote - Create a new note. updateNote - Update an existing note. getNote - Gets a specific note. listNotes - Gets a list of notes. *Freshbooks Connector (v2.0) * createTimeEntry - Create time entry. updateTimeEntry - Update time entry. getTimeEntry - Get a specific time entry. listTimeEntries - List time entries. Thanks Regards Rasika -- View this message in context: http://wso2-oxygen-tank.10903.n7.nabble.com/Proposed-ESB-connector-scenario-Integrating-Insightly-with-Mailchimp-CallRail-and-FreshBooks-tp115427p115864.html Sent from the WSO2 Architecture mailing list archive at Nabble.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, IMO, creating separate JIRA instances for each tenant is not a feasible option, So regarding the projects that are created in the Jira instance of App Factory, User will have to undergo the limitation that, the tenant name would be appended at the end of project name. Is there any way we can avoid 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 Wed, Apr 1, 2015 at 2:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi Anuruddha, Yeah I understand the issue with appending the tenant domain every time. +1 for the suggestion under 1) Regarding 2) that is when we create a Jira instance, AFAIK, whether we use an on-demand instance for App Factory or a Cloud instance, we would get the same problem of duplicate projects. Unless we create separate Jira Cloud instances for each tenant. WDYT? Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Inc.* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 On Tue, Mar 31, 2015 at 7:37 PM, Anuruddha Premalal anurud...@wso2.com wrote: 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
Re: [Architecture] [App Factory] Jira Integration for WSO2 App Factory
Hi Are there extension points in jira where we can extend authentication mechanism. BTW password is something we don't have. We have only username. Thanks Regards Danushka Fernando Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 On Apr 1, 2015 4:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, I need few other clarifications as well. So far, I have been successful in creating a JIRA project via SOAP only. This SOAP client requires username and password for the Jira instance. So, if we want to allow users to create projects in their JIRA instance, we will have to request for username and password for JIRA instance. Is that okay? We will not store any username or password, but we'll need it to create a SOAP session. WDYT? 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 2:34 PM, Fathima Dilhasha dilha...@wso2.com wrote: The prices for cloud and server instances of JIRA are the same as mentioned in [1] https://www.atlassian.com/software/jira/pricing/?tab=cloud. [1]https://www.atlassian.com/software/jira/pricing/?tab=cloud Thanks. *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 2:31 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, IMO, creating separate JIRA instances for each tenant is not a feasible option, So regarding the projects that are created in the Jira instance of App Factory, User will have to undergo the limitation that, the tenant name would be appended at the end of project name. Is there any way we can avoid 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 Wed, Apr 1, 2015 at 2:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi Anuruddha, Yeah I understand the issue with appending the tenant domain every time. +1 for the suggestion under 1) Regarding 2) that is when we create a Jira instance, AFAIK, whether we use an on-demand instance for App Factory or a Cloud instance, we would get the same problem of duplicate projects. Unless we create separate Jira Cloud instances for each tenant. WDYT? Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Inc.* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 On Tue, Mar 31, 2015 at 7:37 PM, Anuruddha Premalal anurud...@wso2.com wrote: 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
[Architecture] WSO2 ML 1.0.0 Milestone 2 Released
WSO2 ML 1.0.0 Milestone 2 is Released! WSO2 ML team is pleased to announce the 2nd Milestone of WSO2 ML 1.0.0. The distribution is available at [1]. This release includes following features. New features - Initial version of the User Interface ( https://docs.wso2.com/display/ML100/ML+UI+Workflow) - Support analyses execution in an external Spark cluster ( https://docs.wso2.com/display/ML100/Connecting+to+an+External+Apache+Spark+Cluster ) - Support for HDFS storage Pending features - BAM integration - UI - Model comparison, data exploration - ESB - ML mediator - CEP - ML extension Documentation for WSO2 Machine Learner 1.0.0 - M2 - Introduction - https://docs.wso2.com/display/ML100/Introducing+Machine+Learner - Architecture Guide - https://docs.wso2.com/display/ML100/Architecture - REST API guide - https://docs.wso2.com/display/ML100/REST+API+Guide - User Guide - https://docs.wso2.com/display/ML100/User+Guide - ML UI (initial version) Guide - https://docs.wso2.com/display/ML100/ML+UI+Workflow - Sample ML Flows - https://docs.wso2.com/display/ML100/Samples Please report any issues you may find in our JIRA: https://wso2.org/jira/browse/ML GIT tag: https://github.com/wso2/product-ml/releases/tag/1.0.0-m2 [1] *https://github.com/wso2/product-ml/releases/download/1.0.0-m2/wso2ml-1.0.0-SNAPSHOT.zip https://github.com/wso2/product-ml/releases/download/1.0.0-m2/wso2ml-1.0.0-SNAPSHOT.zip* Thanks, -- *CD Athuraliya* Software Engineer WSO2, Inc. lean . enterprise . middleware Mobile: +94 716288847 94716288847 LinkedIn http://lk.linkedin.com/in/cdathuraliya | Twitter https://twitter.com/cdathuraliya | Blog http://cdathuraliya.tumblr.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 Nirmal,
camel case should not be used because:
- the domain name (aka host) is not case sensitive by definition,
- some servers treat the path not as case sensitive
thus, camel case style will be confusing, implying differences in API names
that don't exist. Nevertheless, a couple of vendors use camel style, but
the public critique is that these APIs are designed by Java programmers ;-)
Using underscores is typically seen as problematic, because API URLs are
often rendered in HTML pages (e.g. in documentation; as error descriptions;
in generated pages;...). And the browser will interpret them as links,
thus, rendering them as underlined: the underscore is then hard to read.
As a *consequence*, the general recommendation is to *use hyphens* (-).
:-)
Best regards,
Frank
2015-04-01 10:34 GMT+02:00 Nirmal Fernando nir...@wso2.com:
This is very helpful Frank, and as you mentioned these
controlled-resources are always lead to discussion. Do you have any
comments on the usage of '-' instead of camel case ?
On Tue, Mar 31, 2015 at 10:51 PM, Frank Leymann fr...@wso2.com wrote:
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
Re: [Architecture] [App Factory] Jira Integration for WSO2 App Factory
Hi, I need few other clarifications as well. So far, I have been successful in creating a JIRA project via SOAP only. This SOAP client requires username and password for the Jira instance. So, if we want to allow users to create projects in their JIRA instance, we will have to request for username and password for JIRA instance. Is that okay? We will not store any username or password, but we'll need it to create a SOAP session. WDYT? 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 2:34 PM, Fathima Dilhasha dilha...@wso2.com wrote: The prices for cloud and server instances of JIRA are the same as mentioned in [1] https://www.atlassian.com/software/jira/pricing/?tab=cloud. [1]https://www.atlassian.com/software/jira/pricing/?tab=cloud Thanks. *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 2:31 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, IMO, creating separate JIRA instances for each tenant is not a feasible option, So regarding the projects that are created in the Jira instance of App Factory, User will have to undergo the limitation that, the tenant name would be appended at the end of project name. Is there any way we can avoid 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 Wed, Apr 1, 2015 at 2:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi Anuruddha, Yeah I understand the issue with appending the tenant domain every time. +1 for the suggestion under 1) Regarding 2) that is when we create a Jira instance, AFAIK, whether we use an on-demand instance for App Factory or a Cloud instance, we would get the same problem of duplicate projects. Unless we create separate Jira Cloud instances for each tenant. WDYT? Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Inc.* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 On Tue, Mar 31, 2015 at 7:37 PM, Anuruddha Premalal anurud...@wso2.com wrote: 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
Re: [Architecture] [App Factory] Jira Integration for WSO2 App Factory
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 dilha...@wso2.com*mobile : +94 77 8449321 On Wed, Apr 1, 2015 at 6:07 PM, Danushka Fernando danush...@wso2.com wrote: Hi Are there extension points in jira where we can extend authentication mechanism. BTW password is something we don't have. We have only username. Thanks Regards Danushka Fernando Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 On Apr 1, 2015 4:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, I need few other clarifications as well. So far, I have been successful in creating a JIRA project via SOAP only. This SOAP client requires username and password for the Jira instance. So, if we want to allow users to create projects in their JIRA instance, we will have to request for username and password for JIRA instance. Is that okay? We will not store any username or password, but we'll need it to create a SOAP session. WDYT? 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 2:34 PM, Fathima Dilhasha dilha...@wso2.com wrote: The prices for cloud and server instances of JIRA are the same as mentioned in [1] https://www.atlassian.com/software/jira/pricing/?tab=cloud. [1]https://www.atlassian.com/software/jira/pricing/?tab=cloud Thanks. *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 2:31 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, IMO, creating separate JIRA instances for each tenant is not a feasible option, So regarding the projects that are created in the Jira instance of App Factory, User will have to undergo the limitation that, the tenant name would be appended at the end of project name. Is there any way we can avoid 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 Wed, Apr 1, 2015 at 2:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi Anuruddha, Yeah I understand the issue with appending the tenant domain every time. +1 for the suggestion under 1) Regarding 2) that is when we create a Jira instance, AFAIK, whether we use an on-demand instance for App Factory or a Cloud instance, we would get the same problem of duplicate projects. Unless we create separate Jira Cloud instances for each tenant. WDYT? Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Inc.* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 On Tue, Mar 31, 2015 at 7:37 PM, Anuruddha Premalal anurud...@wso2.com wrote: 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.
Re: [Architecture] RFC: RESTFul API for API Manager
Hi Jo,
Here i have attached updated apim.yaml file with my suggestions.
Lets merge that to latest code.
Thanks,
sanjeewa.
On Wed, Apr 1, 2015 at 1:55 PM, Sanjeewa Malalgoda sanje...@wso2.com
wrote:
Hi All,
Here are my suggestions on this implementation.
When we design rest API for API Management functionality we need to focus
bit on publisher/ store aspects as well. Or we may need to have control at
some point based on the logged in user.
Here is one example:
/apis
GET /apis
API provider should be mandatory field when it comes to publisher context.
API consumer should be mandatory field when it comes to store context.
Or we should be able to retrieve current user by using JWT comes with
request or from access token. Still need to if request comes to store or
publisher context.
And based on current user permissions we may need enable, disable API
add/modification via post, put, delete.
Also for tiers we may have
/tiers
post
/tiers/{tierName}/update-permission
Request body
{
rolePermission: {
access: ,
roles:
}
}
Also for apis/{apiId} PUT need to have response with 409 Conflict as well.
Normally when we update resource with some information it cannot be
accessed due to some reason. So IMO having 409 as well would be helpful(in
addition to 412)
It would be ideal /apis/{apiId}/change-lifecycle success response returns
200 status code as we normally use 201 to indicate that new resource
created.
In this particular case we do update for existing resource state.
We may include additional response code to /apis/{apiId}/documents GET
because we may have 2 situations.
01. API does not exists(We can consider 412 for response code)
02. API exists but documents not available(we can consider 404 as
requested resource is document).
And same should apply to /apis/{apiId}/documents/{documentId} GET as well.
And we need to finalize about security model for this rest API. For that
we may consider few options.
01. Oath2 secured API.
02. Basic auth secured rest API.
03. Other security mechanisms.
My personal opinion is this rest API should be independent from security
protocol.
And our rest API should not rely on any security related information when
in process request.
If we need to verify user is having permission to do some task then we
should not do it in rest API level(api subscriber should not allow to
update API).
Thanks,
sanjeewa.
On Tue, Mar 31, 2015 at 11:07 PM, Joseph Fonseka jos...@wso2.com wrote:
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
Re: [Architecture] [App Factory] Jira Integration for WSO2 App Factory
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 dilha...@wso2.com*mobile : +94 77 8449321 On Wed, Apr 1, 2015 at 6:07 PM, Danushka Fernando danush...@wso2.com wrote: Hi Are there extension points in jira where we can extend authentication mechanism. BTW password is something we don't have. We have only username. Thanks Regards Danushka Fernando Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 On Apr 1, 2015 4:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, I need few other clarifications as well. So far, I have been successful in creating a JIRA project via SOAP only. This SOAP client requires username and password for the Jira instance. So, if we want to allow users to create projects in their JIRA instance, we will have to request for username and password for JIRA instance. Is that okay? We will not store any username or password, but we'll need it to create a SOAP session. WDYT? 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 2:34 PM, Fathima Dilhasha dilha...@wso2.com wrote: The prices for cloud and server instances of JIRA are the same as mentioned in [1] https://www.atlassian.com/software/jira/pricing/?tab=cloud. [1]https://www.atlassian.com/software/jira/pricing/?tab=cloud Thanks. *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 2:31 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, IMO, creating separate JIRA instances for each tenant is not a feasible option, So regarding the projects that are created in the Jira instance of App Factory, User will have to undergo the limitation that, the tenant name would be appended at the end of project name. Is there any way we can avoid 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 Wed, Apr 1, 2015 at 2:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi Anuruddha, Yeah I understand the issue with appending the tenant domain every time. +1 for the suggestion under 1) Regarding 2) that is when we create a Jira instance, AFAIK, whether we use an on-demand instance for App Factory or a Cloud instance, we would get the same problem of duplicate projects. Unless we create separate Jira Cloud instances for each tenant. WDYT? Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Inc.* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 On Tue, Mar 31, 2015 at 7:37 PM, Anuruddha Premalal anurud...@wso2.com wrote: 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]
Re: [Architecture] [Operations Center] OC - Architecture Review Notes
I think we need to correct the diagram. Agents are publish data via thrift and in OC there is a thrift receiver. (not the CEP). These receiving data (we can also store in Cassandra/RDMS ..etc) can used in either BAM or CEP depending on the requirement. On Wed, Apr 1, 2015 at 1:52 PM, Noel Yahan no...@wso2.com wrote: Hi Maninda, According to current architecture CEP only publish data to MB and any other product can subscribe / publish to MB topics and get the data.If we need publish data to BAM we can subscribe to MB topics and get the data.Jax-Rs is for expose MB topics information in RESTful manner.The gadgets are UES gadgets.We use RESTful APIs to display OC data in UES dashboard with gadgets. Thanks. Noel Yahan Software Engineering Intern - WSO2 Mobile : +94 71-647-872-3 Twitter https://twitter.com/noelyahan | LinkedIn http://lk.linkedin.com/pub/noel-yahan/48/186/a9b | Google+ https://plus.google.com/+NoelYahan On Wed, Apr 1, 2015 at 12:25 PM, Maninda Edirisooriya mani...@wso2.com wrote: How does the BAM comes into the picture of new design? Do the OC agents publish to both CEP and BAM, or does the data get published to BAM from MB? It is better if there is some unification among Gadgets in OC with the new dashboard components of new BAM (DAS) as it will be the unified UI we are going to ship with UES AFAIK. So we need to integrate Jax-Rs exposed from MB subscription with the new gadgets supported with DAS. Thanks. *Maninda Edirisooriya* Senior Software Engineer *WSO2, Inc.*lean.enterprise.middleware. *Blog* : http://maninda.blogspot.com/ *E-mail* : mani...@wso2.com *Skype* : @manindae *Twitter* : @maninda On Fri, Mar 27, 2015 at 11:22 PM, Noel Yahan no...@wso2.com wrote: Meeting Notes: Participants: Sameera Jayasoma, Sameera Perera, Kasun, Jayanga, Manoj, Kalpa, Noel, Chanaka, Shashika, Lakmal, Imesh, Kishanthan In this meeting Jayanga explained the current architecture of OC M2 and Lakmal explained Apache Stratos messaging architecture and how Stratos use their agent to publish periodic status, topology, summarized status messages and what are the problems in current OC messaging architecture and how can OC improve, reuse their features and add new features. Current OC architecture - Default communication is the real time communication (Sends periodic server information to OC Jax-Rs web app). - Jax-Rs is exposing a RESTFul API about cluster, server information. - Has a feature to plug any publisher like BAM, MB, CEP. - Use the RESTful API and display different views using UES gadgets. [image: oc current architecture.png] Problems in current architecture - There’s no way to persist real time data other than configure a new BAM data publisher. - If OC goes down dynamic data will be lost, because default real time data is publishing to the Jax-Rs endpoint. - To many requests to OC Jax-Rs - When number of instances will increase, linearly number of request to Jax-Rs will increase. - Server commands (restart, shutdown) are sending through HTTP response message - If something goes wrong in HTTP communication, commands will lost, specially in cluster-wise restart (round robin) New OC architecture [image: oc new archi.png] - This is the new OC messaging architecture according to Apache Stratos Pub-Sub communication. - Real time server data should publish to CEP. - Analyzed/Summarized real time data should publish to MB topics from CEP. - All OC Agents should subscribe to MB topics to get commands and server informations from OC Jax-Rs. - OC Jax-Rs should follow both publishing and subscribing part to sending commands and getting analyzed real time server data from MB. New features that the OC should support - CEP should send alerts (sms, email, etc..) in critical scenario like in server failures etc.. - OC should able to publish lifecycle events to message broker topic and all OC Agents should subscribe to that topic and act according to their events. - Commands should publish to a message broker topic (eg: message notifier topic). - Install AS, MB, CEP features in a single pack with OC and should be able to start with carbon profiling. - OC should able incorporate with WSO2 Private PaaS. Concerns - Decouple the OC agent command handling part, machine level data sending part from current running JVM. - Current OC M2 version handles the commands (restart, shutdown) in same JVM. - Need to decide the implementation of this agent, python or java currently Apache Stratos has the same agent with python implementation and OC M2 version has the java implementation with some feature. - Deploy this agent per
Re: [Architecture] [App Factory] Jira Integration for WSO2 App Factory
/s/pretty/pre Thanks Regards Danushka Fernando Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 From: Danushka Fernando Sent: Wednesday, April 1, 2015 7:30 PM To: architecture 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 mobile : +94 77 8449321 On Wed, Apr 1, 2015 at 6:07 PM, Danushka Fernando danush...@wso2.com wrote: Hi Are there extension points in jira where we can extend authentication mechanism. BTW password is something we don't have. We have only username. Thanks Regards Danushka Fernando Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 On Apr 1, 2015 4:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, I need few other clarifications as well. So far, I have been successful in creating a JIRA project via SOAP only. This SOAP client requires username and password for the Jira instance. So, if we want to allow users to create projects in their JIRA instance, we will have to request for username and password for JIRA instance. Is that okay? We will not store any username or password, but we'll need it to create a SOAP session. WDYT? Thanks. Regards, Dilhasha M.N.F. Dilhasha Software Engineering Intern | WSO2 Inc. email : dilha...@wso2.com mobile : +94 77 8449321 On Wed, Apr 1, 2015 at 2:34 PM, Fathima Dilhasha dilha...@wso2.com wrote: The prices for cloud and server instances of JIRA are the same as mentioned in [1]. [1]https://www.atlassian.com/software/jira/pricing/?tab=cloud Thanks. M.N.F. Dilhasha Software Engineering Intern | WSO2 Inc. email : dilha...@wso2.com mobile : +94 77 8449321 On Wed, Apr 1, 2015 at 2:31 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, IMO, creating separate JIRA instances for each tenant is not a feasible option, So regarding the projects that are created in the Jira instance of App Factory, User will have to undergo the limitation that, the tenant name would be appended at the end of project name. Is there any way we can avoid that? Thanks. Regards, Dilhasha M.N.F. Dilhasha Software Engineering Intern | WSO2 Inc. email : dilha...@wso2.com mobile : +94 77 8449321 On Wed, Apr 1, 2015 at 2:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi Anuruddha, Yeah I understand the issue with appending the tenant domain every time. +1 for the suggestion under 1) Regarding 2) that is when we create a Jira instance, AFAIK, whether we use an on-demand instance for App Factory or a Cloud instance, we would get the same problem of duplicate projects. Unless we create separate Jira Cloud instances for each tenant. WDYT? Thanks. Regards, Dilhasha M.N.F. Dilhasha Software Engineering Intern | WSO2 Inc. email : dilha...@wso2.com mobile : +94 77 8449321 On Tue, Mar 31, 2015 at 7:37 PM, Anuruddha Premalal anurud...@wso2.com wrote: 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
Re: [Architecture] [App Factory] Jira Integration for WSO2 App Factory
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 dilha...@wso2.com*mobile : +94 77 8449321 On Wed, Apr 1, 2015 at 6:07 PM, Danushka Fernando danush...@wso2.com wrote: Hi Are there extension points in jira where we can extend authentication mechanism. BTW password is something we don't have. We have only username. Thanks Regards Danushka Fernando Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 On Apr 1, 2015 4:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, I need few other clarifications as well. So far, I have been successful in creating a JIRA project via SOAP only. This SOAP client requires username and password for the Jira instance. So, if we want to allow users to create projects in their JIRA instance, we will have to request for username and password for JIRA instance. Is that okay? We will not store any username or password, but we'll need it to create a SOAP session. WDYT? 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 2:34 PM, Fathima Dilhasha dilha...@wso2.com wrote: The prices for cloud and server instances of JIRA are the same as mentioned in [1] https://www.atlassian.com/software/jira/pricing/?tab=cloud. [1]https://www.atlassian.com/software/jira/pricing/?tab=cloud Thanks. *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 2:31 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, IMO, creating separate JIRA instances for each tenant is not a feasible option, So regarding the projects that are created in the Jira instance of App Factory, User will have to undergo the limitation that, the tenant name would be appended at the end of project name. Is there any way we can avoid 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 Wed, Apr 1, 2015 at 2:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi Anuruddha, Yeah I understand the issue with appending the tenant domain every time. +1 for the suggestion under 1) Regarding 2) that is when we create a Jira instance, AFAIK, whether we use an on-demand instance for App Factory or a Cloud instance, we would get the same problem of duplicate projects. Unless we create separate Jira Cloud instances for each tenant. WDYT? Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Inc.* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 On Tue, Mar 31, 2015 at 7:37 PM, Anuruddha Premalal anurud...@wso2.com wrote: 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
Re: [Architecture] [App Factory] Jira Integration for WSO2 App Factory
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 dilha...@wso2.com*mobile : +94 77 8449321 On Wed, Apr 1, 2015 at 6:07 PM, Danushka Fernando danush...@wso2.com wrote: Hi Are there extension points in jira where we can extend authentication mechanism. BTW password is something we don't have. We have only username. Thanks Regards Danushka Fernando Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 On Apr 1, 2015 4:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, I need few other clarifications as well. So far, I have been successful in creating a JIRA project via SOAP only. This SOAP client requires username and password for the Jira instance. So, if we want to allow users to create projects in their JIRA instance, we will have to request for username and password for JIRA instance. Is that okay? We will not store any username or password, but we'll need it to create a SOAP session. WDYT? 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 2:34 PM, Fathima Dilhasha dilha...@wso2.com wrote: The prices for cloud and server instances of JIRA are the same as mentioned in [1] https://www.atlassian.com/software/jira/pricing/?tab=cloud. [1]https://www.atlassian.com/software/jira/pricing/?tab=cloud Thanks. *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 2:31 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, IMO, creating separate JIRA instances for each tenant is not a feasible option, So regarding the projects that are created in the Jira instance of App Factory, User will have to undergo the limitation that, the tenant name would be appended at the end of project name. Is there any way we can avoid 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 Wed, Apr 1, 2015 at 2:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi Anuruddha, Yeah I understand the issue with appending the tenant domain every time. +1 for the suggestion under 1) Regarding 2) that is when we create a Jira instance, AFAIK, whether we use an on-demand instance for App Factory or a Cloud instance, we would get the same problem of duplicate projects. Unless we create separate Jira Cloud instances for each tenant. WDYT? Thanks. Regards, Dilhasha
Re: [Architecture] [App Factory] Jira Integration for WSO2 App Factory
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 dilha...@wso2.com*mobile : +94 77 8449321 On Wed, Apr 1, 2015 at 6:07 PM, Danushka Fernando danush...@wso2.com wrote: Hi Are there extension points in jira where we can extend authentication mechanism. BTW password is something we don't have. We have only username. Thanks Regards Danushka Fernando Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 On Apr 1, 2015 4:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, I need few other clarifications as well. So far, I have been successful in creating a JIRA project via SOAP only. This SOAP client requires username and password for the Jira instance. So, if we want to allow users to create projects in their JIRA instance, we will have to request for username and password for JIRA instance. Is that okay? We will not store any username or password, but we'll need it to create a SOAP session. WDYT? 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 2:34 PM, Fathima Dilhasha dilha...@wso2.com wrote: The prices for cloud and server instances of JIRA are the same as mentioned in [1] https://www.atlassian.com/software/jira/pricing/?tab=cloud. [1]https://www.atlassian.com/software/jira/pricing/?tab=cloud Thanks. *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 2:31 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi, IMO, creating separate JIRA instances for each tenant is not a feasible option, So regarding the projects that are created in the Jira instance of App Factory, User will have to undergo the limitation that, the tenant name would be appended at the end of project name. Is there any way we can avoid 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 Wed, Apr 1, 2015 at 2:25 PM, Fathima Dilhasha dilha...@wso2.com wrote: Hi Anuruddha, Yeah I understand the issue with appending the tenant domain every time. +1 for the suggestion under 1) Regarding 2) that is when we create a Jira instance, AFAIK, whether we use an on-demand instance for App Factory or a Cloud instance, we would get the same problem of duplicate projects. Unless we create separate Jira Cloud instances for each tenant. WDYT? Thanks. Regards, Dilhasha *M.N.F. Dilhasha* Software Engineering Intern | *WSO2 Inc.* email : *dilha...@wso2.com dilha...@wso2.com*mobile : +94 77 8449321 On Tue, Mar 31, 2015 at 7:37 PM, Anuruddha Premalal anurud...@wso2.com wrote:
[Architecture] [G-Reg] Lifecycle transition view improvements in G-Reg publisher
Hi,
In current g-reg we have the option of giving a transition UI for the
lifecycle transition in the management console. This UI is used to take the
user inputs for the executor logic.
To incorporate this feature into the publisher view, we have come up with
the proposal of embedding a set of new elements in the LC definition. This
will be parsed from the publisher side and it will display a rendered page
for user inputs. To enable this we will modify the scxml.xsd and the user
will have to set the input parameters as follows:
data name=transitionExecution
execution forEvent=Promote
class=org.wso2.carbon.governance.registry.extensions.executors.ServiceVersionExecutor
*form*
* input name=approver type=text/*
* input name=comment
type=text-area/*
*/form*
parameter name=currentEnvironment
value=/_system/governance/trunk/{@resourcePath}/{@version}/{@resourceName}/
parameter name=targetEnvironment
value=/_system/governance/branches/testing/{@resourcePath}/{@version}/{@resourceName}/
parameter name=service.mediatype
value=application/vnd.wso2-service+xml/
parameter name=wsdl.mediatype
value=application/wsdl+xml/
parameter name=endpoint.mediatype
value=application/vnd.wso2.endpoint/
/execution
/data
Appreciate any feedback about this approach.
Thanks!
Isuruwan
--
Isuruwan Herath
Technical Lead
Contact: +94 776 273 296
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
