Another thing is, should we also work on exposing admin services on one listener (probably over https) and other user api's on different listener? May be we need to bring in some changes to MSF4J core to support this via OSGi level service properties and listener id's.
On Thu, May 5, 2016 at 2:17 PM, Afkham Azeez <[email protected]> wrote: > In what cases would you require to maintain multiple versions of a > microservice in a product? Or is this related to different versions of the > same product? If it is the second case, it is the responsibility of the > gateway to route to the correct instances and there is no need to maintain > version information on the product runtime side. > > On Thu, May 5, 2016 at 2:12 PM, Sameera Jayasoma <[email protected]> wrote: > >> >> >> On Thu, May 5, 2016 at 12:42 PM, Hasitha Aravinda <[email protected]> >> wrote: >> >>> Some more questions >>> >>> On Thu, May 5, 2016 at 12:30 PM, Sameera Jayasoma <[email protected]> >>> wrote: >>> >>>> I believe its wrong to use the product version to version your micro >>>> services. >>>> >>>> You need to have different version for your microservices. e.g. >>>> starting from 1.0.0. If you don't change any of your microservices you >>>> shouldn't be changing these versions. >>>> >>> >>> According to Rest API guideline, it should be product version. isn't >>> it ? >>> >> >> We cannot change API versions for each and every product release. You >> should change the API version only if you have introduced a change. We are >> following the same approach to version export packages from bundles. >> >> >>> >>> Let's say we are using version from 1.0.0. >>> If we are going to do a modification >>> >>> to a microservice ( let's say foo 1.0) and new version is foo 1.1 Do >>> we need to maintain both versions to provide backward compatibility ? If so >>> we have to maintain two microservices: Foo 1.0 and Foo 1.1, because version >>> is a part of the path in microservice. >>> >> >> I am not sure whether need to maintain the previous versions of micro >> services. Thats something we need to discuss. Also it adds complexity. >> >> If you have introduced any additions to your micro services, then you can >> bump up the minor version number. If you've introduced incompatible >> changes, then you have bump up the major version number. >> >> >> >>> >>> eg: >>> @Path(" >>> /bps/bpmn/v >>> 1 >>> .0/ >>> foo >>> ") >>> , >>> @Path(" >>> /bps/bpmn/v >>> 1 >>> . >>> 1 >>> / >>> foo >>> ") >>> >>> Thanks, >>> Hasitha. >>> >>> >>>> On Thu, May 5, 2016 at 11:02 AM, Himasha Guruge <[email protected]> >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> We have refactored our REST APIs by implementing Microservice >>>>> interface. According to the new REST guideline , we need to maintain the >>>>> URL format like below. For example, >>>>> >>>>> http://localhost:7777/bps/bpmn/v4.0/repository/deployments >>>>> >>>>> How are we going to maintain the product version updates with >>>>> microservices? If we are to maintain the product version with a parameter >>>>> been set from a config file, how can we achieve this? >>>>> >>>>> >>>>> Thanks, >>>>> Himasha Guruge >>>>> *Software Engineer* >>>>> WS*O2* *Inc.* >>>>> Mobile: +94 777459299 >>>>> [email protected] >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Sameera Jayasoma, >>>> Software Architect, >>>> >>>> WSO2, Inc. (http://wso2.com) >>>> email: [email protected] >>>> blog: http://blog.sameera.org >>>> twitter: https://twitter.com/sameerajayasoma >>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>>> Mobile: 0094776364456 >>>> >>>> Lean . Enterprise . Middleware >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> -- >>> Hasitha Aravinda, >>> Senior Software Engineer, >>> WSO2 Inc. >>> Email: [email protected] >>> Mobile : +94 718 210 200 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Sameera Jayasoma, >> Software Architect, >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> blog: http://blog.sameera.org >> twitter: https://twitter.com/sameerajayasoma >> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >> Mobile: 0094776364456 >> >> Lean . Enterprise . Middleware >> >> > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **[email protected]* <[email protected]> > * cell: +94 77 3320919 <%2B94%2077%203320919>blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez* > <http://twitter.com/afkham_azeez> > *linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Kishanthan Thangarajah* Associate Technical Lead, Platform Technologies Team, WSO2, Inc. lean.enterprise.middleware Mobile - +94773426635 Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
