Hi, Please note that we will be using the existing database and backend models currently available in API Manager. These models are common for both Store and Publisher. In the REST API layer, we are going to use separate DTO models (which maps with a common model in the backend) for store and publisher.
Thanks. On Thu, Oct 15, 2015 at 9:43 PM, Dhanuka Ranasinghe <dhan...@wso2.com> wrote: > AFAIU, It would be great to have common data model (entity model) for DAO > layer but separate data models for Service Layer (DTOs). It would be easy > to maintain having two separate layers for separate concerns. > > *Dhanuka Ranasinghe* > > Associate TechLead > WSO2 Inc. ; http://wso2.com > lean . enterprise . middleware > > phone : +94 715381915 > > On Thu, Oct 15, 2015 at 6:57 PM, Frank Leymann <fr...@wso2.com> wrote: > >> Hi Sanjeewa, >> >> I assume Store and Publisher share the same database although they will >> offer different APIs, correct? In that case, a common data model is the >> preferred way. >> >> >> Best regards, >> Frank >> >> 2015-10-14 8:25 GMT+02:00 Sanjeewa Malalgoda <sanje...@wso2.com>: >> >>> Thanks Frank ,Amila, Harshana, Jo, Dhanuka for your valuable inputs. >>> So it seems all are agree on having 2 different APIs/web services for >>> store and publisher. >>> >>> @Frank,Jo, actually store and publisher should return tow different data >>> associated with APIs. >>> But if need we can have common data model and fill only required fields >>> in service layer. >>> As example API model contains both back end url and gateway url. But >>> store will return object only with gateway url while publisher returns back >>> end url. >>> Since we all agreed on two different services(store and publisher APIs) >>> shall we conclude on data model as well. >>> Do we need to have common model shared with both store,publisher and >>> refine parameters at service layer implementation? Or have two different >>> data models? >>> >>> @Amila, yes core implementation and internal data representation will >>> not change due to this. >>> Only change is REST API implementation. And all duplicates will exist >>> only in REST API layer. >>> >>> Thanks, >>> sanjeewa. >>> >>> >>> >>> >>> On Wed, Oct 14, 2015 at 7:10 AM, Amila De Silva <ami...@wso2.com> wrote: >>> >>>> Hi Sanjeewa, >>>> >>>> On Tue, Oct 13, 2015 at 10:46 PM, Sanjeewa Malalgoda <sanje...@wso2.com >>>> > wrote: >>>> >>>>> Hi All, >>>>> API Manager team planned to add complete REST API support for API >>>>> Management operations available in product. >>>>> Since initial implementation is done we are thinking about next steps >>>>> of REST service. >>>>> In this mail we need to discuss about separating API Manager store and >>>>> publisher operations. >>>>> >>>>> *Improvement* >>>>> In current REST API is developed as single web application. >>>>> It will be deployed in API Management server and it can perform both >>>>> store/ publisher operations. >>>>> But so far we had clear separation between API store and >>>>> publisher(Publisher to create/manage APIs and store to manage >>>>> subscriptions >>>>> etc). >>>>> With new REST API we need to do something similar to manage same >>>>> behavior. >>>>> This will be important if we deploy API Manager in fully distributed >>>>> deployment. In that case API store will be deployed in DMZ and we >>>>> shouldn't >>>>> allow publisher operations from that(API create publish should not >>>>> possible >>>>> from outside). >>>>> To have this kind of separation we may need 2 web applications or >>>>> single web application with 2 contexts. >>>>> >>>>> *Suggested solutions* >>>>> 01. Deploy API Manager store and publisher as 2 separate applications. >>>>> Then we will have 2 applications named api#am#store#v1.war and >>>>> api#am#publisher#v1.war. >>>>> These 2 applications will be deployed in contexts >>>>> api/am/store/v1 and api/am/publisher/v1. >>>>> If we deploy store profile we can remove publisher web service >>>>> and if its publisher we can remove store web service. >>>>> >>>>> 02. Have single Applications(web service) which register 2 sub >>>>> contexts. >>>>> We can define mapped classes according to each context(here >>>>> contexts are api/am/store/v1 and api/am/publisher/v1 ). >>>>> We can add service beans(service beans like apis, applications, >>>>> tags etc) on top of these two base contexts. >>>>> If we deploy store profile we need to disable service bean group >>>>> for publisher. To do this we need to edit beans.xml and redeploy .war >>>>> file. >>>>> >>>>> If we go for first approach we will have 2 applications and it do not >>>>> require web application modifications. >>>>> >>>>> *Challenges* >>>>> When we implement 2 different services for API store and publisher >>>>> there will be some duplicates. >>>>> As example we can consider following >>>>> /apis GET in publisher will return complete API details with back end >>>>> urls etc. >>>>> But /apis GET in store will return us only detail required for store >>>>> functionality(in this case back end user will not present in response >>>>> instead it will have gateway API URL). >>>>> Same applies for tiers as well(we can edit tiers in publisher but in >>>>> store we can see available tier name list when we subscribe to API). >>>>> So we need to carefully separate these functionalities. >>>>> >>>> >>>> If I understood correctly, difference in object models will only come >>>> into effect when creating the output/accepting inputs at the REST API >>>> layer. But when performing a core operation (persisting an API or >>>> retrieving it, publishing an API etc...), the App specific model will be >>>> converted to a single format (a domain specific model). >>>> For example, the API model used in Publisher REST API, will have more >>>> fields than the one used in Store REST API. So outputs when called a GET on >>>> /publisher/apis/{apiId} and a GET on /store/apis/{apiId} will be >>>> different. But from the point where the API is retrieved from the >>>> database/registry, to the point where it's handed over to REST API, the API >>>> will be represented using one model. >>>> >>>> So AFAIU even there are duplicates, those duplicates will only exist at >>>> the REST API layer. Core operations won't get duplicated. >>>> >>>> Even from a security point of view, it's good to have two different >>>> models (since it minimises the risk of exposing unwanted information >>>> Publicly, for example revealing backend endpoints at Store App) +1 for the >>>> keeping two Apps, which uses two different models. >>>> >>>>> >>>>> If we go for 2 different applications sometimes we may need 2 >>>>> different api.yaml files to maintain operation isolation. >>>>> Main reason for that is API object return from publisher API may >>>>> different from API object return from store API. >>>>> So there will be 2 models for API object based on service >>>>> type(store/publisher). >>>>> Or other option is maintain single data model and fill required data >>>>> based on used service(if its publisher back end URL parameter will present >>>>> with value but if its store then back end URLs will not be there). >>>>> We need to discuss this and come to conclusion. >>>>> >>>>> I'm sure we need to focus on this when we implement ES REST API. >>>>> Appreciate your suggestions and comments on this. >>>>> >>>>> Thanks, >>>>> sanjeewa. >>>>> >>>>> -- >>>>> >>>>> *Sanjeewa Malalgoda* >>>>> WSO2 Inc. >>>>> Mobile : +94713068779 >>>>> >>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Amila De Silva* >>>> >>>> WSO2 Inc. >>>> mobile :(+94) 775119302 >>>> >>>> >>> >>> >>> -- >>> >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +94713068779 >>> >>> <http://sanjeewamalalgoda.blogspot.com/>blog >>> :http://sanjeewamalalgoda.blogspot.com/ >>> <http://sanjeewamalalgoda.blogspot.com/> >>> >>> >>> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Best Regards, *Thilini Cooray* Software Engineer Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194> E-mail : thili...@wso2.com WSO2 Inc. www.wso2.com lean.enterprise.middleware
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
