Hi Thilini, I think this is a very useful feature for the platform. API Management users are going to benefit from this a lot as we have been facing the issue for long time with multiple environments.
I have few concerns about the implementation though. Please see the comments inline. Thanks and Regards, Harshana -- Harshana Eranga Martin Senior Software Engineer Asian Mobile Banking Web: https://www.commbank.com.au/ <http://wso2.com> ECF Committer: http://www.eclipse.org/ecf/ Blog: http://harshana05.blogspot.com Profile: https://www.google.com/profiles/harshana05 On 6 May 2015 at 11:43, Thilini Cooray <[email protected]> wrote: > Hi, > > *Regarding Isabelle's concerns,* > > a) This feature will be available as a custom application. Therefore we > decided to package this as a WAR. > I think it is not right to export APIs as a WAR file. WAR is already a well known file extension allocated for Web-Apps. It is going to complicate the life of users of both Web-Apps and API Management feature. I also believe as Isabelle suggested exporting the API as an artifact in the C-App would be the best mechanism. This will allow you to implement a new C-App artifact deployer for API manager and introduction of new Artifact type with an artifact structure. This Artifact deployer will understand the artifact metadata structure and knows how to interpret the metadata as well as generation of the metadata and the artifact when someone requests to export from the Publisher App. This would be a clean way to implement the export and import feature. Having the API as an separate entity in the C-App would help the concern of deployment of Sequences as well since Sequences are already an artifact type supported in the Platform. Hence you can export and import the API and Sequence independent of each other using C-App. API will contain the reference to the Sequence in the API artifact and once the C-App deployed, it will deploy the API artifact as well as referenced Sequence. It will allow you to reuse the same sequence across multiple APIs while the Sequence itself can be governed independently of the APIs. Thanks and Regards, Harshana > b) The QoS details will also be stored in the API > c) Swagger file is also inside the meta information. > > *Regarding Srinath's concerns,* > > We are storing meta-information in JSON format. > > We only support Swagger and it will be stored under meta information. > > Regarding sequences and environment specific setup, shall we allow > importing users to add them according to their preference? > > Appreciate your feedback on this. > > Thank you. > Thilini. > > > > > > On Tue, May 5, 2015 at 8:36 AM, Srinath Perera <[email protected]> wrote: > >> Hi Thilini, >> >> What is the format of meta information? we need to discuss that also in >> this thread. >> >> Do we support both Swagger and WADL? if yes Swagger should go in the >> archive and we have to decide where. >> >> Regarding ESB sequences, one option is to export the API without >> sequences and let users add sequences via UI or configurations. ( Same >> approach we took with Services and Axis2 modules years ago.) >> >> --Srinath >> >> On Mon, May 4, 2015 at 3:36 PM, Isabelle Mauny <[email protected]> wrote: >> >>> All, >>> >>> Can you please confirm: >>> a) That the packaging is a CApp (i.e. talks to API Manager deployer). >>> b) Where is the QOS setup stored ( the managed part ) - For backup >>> purposes, it would be great to attach QoS to the API. or do we assume that >>> users will have to attach the QoS part manually (i.e.. after deployment we >>> get an API in CREATE mode). >>> c) Where is the Swagger file describing the API stored ? As part of >>> meta-data ? >>> >>> I don't think sequences themselves should be there, just the link. >>> Sequences are reusable across APIs and must not be deployed as part of the >>> API itself. However, I should be able to package a set of sequences and >>> deploy them to an API Manager (again, as CApp, as we do for the ESB). The >>> sequences themselves can be managed/versioned/ separately. >>> >>> As for the tiers etc, those are dependent setup that must be in place >>> before you import in the target environment - Part of the env preparation. >>> We could create an import/export for that too (it's a simple check.out/ >>> check.in from registry). Same applies to workflows, store definitions, >>> etc. >>> >>> Isabelle. >>> __________________________________________________ >>> >>> >>> *Isabelle Mauny*VP, Product Management; WSO2, Inc.; http://wso2.com/ >>> On Apr 22, 2015, at 4:38 PM, Colin Roy-Ehri <[email protected]> wrote: >>> >>> Hi! >>> >>> I'm really excited about this feature - it will be of great benefit to >>> our customers. >>> >>> I have no improvements to suggest on your implementation plan. >>> >>> One point you might want to work into your tests is to ensure the >>> swagger definitions remain consistent after an import/export. Of >>> particular concern is the swagger YAML definitions available through the >>> publisher. It shouldn't be too hard to code into a test. :) >>> >>> Thanks, >>> Colin >>> >>> Thanks, >>> Colin Roy-Ehri >>> Software Engineer >>> *WSO2, Inc. : wso2.com <http://wso2.com/>* >>> *Mobile* : 812-219-6517 >>> >>> On Wed, Apr 22, 2015 at 7:15 AM, Thilini Cooray <[email protected]> >>> wrote: >>> >>>> Hi all, >>>> >>>> We are in the process of introducing API Export and Import feature for >>>> WSO2 API Manager. >>>> >>>> This feature can be used in scenarios such as moving APIs from staging >>>> to production environment. >>>> >>>> *API Export* >>>> >>>> - This operation mainly sends an archive which consists of all the >>>> required resources for a API to be recreated in another API Manager >>>> instance. >>>> - We have identified following folder structure to be included in >>>> the archive >>>> >>>> <Screen Shot 2015-04-22 at 3.20.47 PM.png> >>>> >>>> >>>> >>>> >>>> *API Import* >>>> >>>> - Import feature accepts an API archive with the above mentioned >>>> structure and create a new API under current provider. >>>> >>>> *Feature Implementation* >>>> >>>> - Generating archive (in API export) and extracting archive (in API >>>> import) can either be done in server or client side >>>> - Currently we are planning to develop a RESTful API for export and >>>> import functionality where archive generation for requested APIs and all >>>> the related functionality are taken place in the server side. >>>> - Decision for server side implementation was mainly made due to >>>> high number of network calls and high possibility of network failures >>>> that >>>> can happen in client side. >>>> - The RESTful service is halfway done. currently it can export and >>>> import meta information only. >>>> - *Export API* method calls >>>> org.wso2.carbon.apimgt.api.APIProvider.getAPI(APIIdentifier) >>>> and transforms received API object to a json file. >>>> - *Import API* method receives json file via RESTful call and >>>> converts the json to an API object. This object is then sent to >>>> org.wso2.carbon.apimgt.api.APIProvider.addAPI(api) method and a >>>> new API will get created. >>>> - Several concerns can arise with this implementation approach >>>> 1. API object can have environment specific details which are >>>> not compatible with the importing environment >>>> 2. There are some customisable attributes such as tiers (Ex : >>>> tiers in exporting environment may not be available in importing >>>> side) >>>> which may not be available on the importing environment >>>> - Therefore we would like to know whether there is a better >>>> approach for implementing this. >>>> >>>> Suggestions and ideas for implementing this export import API feature >>>> is highly welcome. >>>> >>>> Thank you. >>>> >>>> >>>> -- >>>> Best Regards, >>>> >>>> *Thilini Cooray* >>>> Software Engineer >>>> Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194> >>>> E-mail : [email protected] >>>> >>>> WSO2 Inc. www.wso2.com >>>> lean.enterprise.middleware >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> ============================ >> Srinath Perera, Ph.D. >> http://people.apache.org/~hemapani/ >> http://srinathsview.blogspot.com/ >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Best Regards, > > *Thilini Cooray* > Software Engineer > Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194> > E-mail : [email protected] > > WSO2 Inc. www.wso2.com > lean.enterprise.middleware > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
