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
