I am sorry, I don't understand your logic and I am +1 with Harshana (HI there !)
This is not about importing and exporting APIs, it's about enabling the automated deployment of API artifacts across multiple environments. That's the target goal- Import and export is a side-effect of that-Let's focus on that first - How the file will be generated underneath is an implementation detail.- We need to create a packaged delivery application, which contains the API defintion, it's meta-data, attached description (WADL, WSDl, etc.) , attached docs (files, URLs.) - If we don't do that, we don't fulfill the requirement of passing a FULL API definition across environments. The CApp *is* the archive- And we need to desing the structure of that CApp. If we do something else, people will have to repackage their APIs when we move to a CApp. I think the priority is to design the contents/structure of that archive. Thanks, Isabelle. ------------------------------------------------------------------------------------- *Isabelle Mauny* VP, Product Management - WSO2, Inc. - http://wso2.com/ On Wed, May 6, 2015 at 10:58 AM, Sanjeewa Malalgoda <[email protected]> wrote: > > > On Wed, May 6, 2015 at 11:30 AM, Harshana Eranga Martin < > [email protected]> wrote: > >> 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. >> > > Actually its not the archive format for APIs. > What they meant was they develop this rest API (for archive APIs) as > jax-rs application and bundled it as WAR file in away that we can deploy in > API Manager server. > Then you will call to that JAX-RS service and request archived APIs and it > will return as .zip file. > You will get that data as multipart form data or any other format. > > >> 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. >> > Yes C-App would be good approach. But adding API is bit complicate process > that and adding sequence, proxy service etc. So i think we can start with > API archive and then later bundle it to C-App, WDYT? > >> >> 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. >>> >> Actually we do not need to export swagger content when we export API. > Swagger is just a definition that we use to import API definition. And in > future we may use different API description languages. > Once we imported it to our platform we need to maintain all data in our > platform. > So IMO we dont need to include swagger json to archive, Instead of that we > should be able to generate swagger based on our API metadata. > And our plan is to make it customizable in future. So if you need to > generate swagger, raml or any other API description base on our metadata > you need to implement interface provided by us. > Lets not bind to single API description language and make this generic as > much as. > > >>> 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. >>>> >>> IMO we don't need to export swagger content. We should be able to > generate swagger or any other API description based on API meta data in > archived API. > Since we do not directly use WADL to import APIs we may need to maintain > WADL as resource of API data. > > Thanks, > sanjeewa. > >> >>>> 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 >> >> > > > -- > > *Sanjeewa Malalgoda* > WSO2 Inc. > Mobile : +94713068779 > > <http://sanjeewamalalgoda.blogspot.com/>blog > :http://sanjeewamalalgoda.blogspot.com/ > <http://sanjeewamalalgoda.blogspot.com/> > > > > _______________________________________________ > 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
