Hi Chamila, Thanks for pointing this out. I think its better to change the execute api of Executor interface to throw an exception rather than returning a Boolean value. So the custom error message can be passed to the UI as well.
Thanks! Rajith On Fri, Oct 21, 2016 at 10:23 AM, Chamila Adhikarinayake <[email protected]> wrote: > Hi Rajith, > > One of the limitation we saw with the existing executor implementation is > its limitation in throwing the exception ( executor method does not throw > exceptions and only return a boolean) . Are you planning to change it? > Chamila > > On Mon, Oct 10, 2016 at 3:16 PM, Rajith Roshan <[email protected]> wrote: > >> Hi all, >> >> Life cycle is an integral part in any product. Each SOA governance >> related artifacts can have their own life cycle. Capabilities provided in >> order to manage life cycles not only allow you to properly organize your >> assets but also provides many extensibilities (For ex through custom >> executors) >> >> RequirementCurrent API life cycle of API manager completely depends on >> the life cycle implementation provided by the registry. Since we are moving >> away from the registry concept we need a completely new life cycle >> management framework which cater for life cycle management within API >> Manager and should be able to ship with other products which require life >> cycle management. >> >> Proposed SolutionThe basic idea is to completely decouple the life cycle >> framework from the system to which its provide life cycle capabilities. I.e >> the system which uses life cycle will not change the behavior of the life >> cycle framework and only vice versa will be applicable. The framework >> should exist independent of the asset type to which it provides life cycle >> capability >> >> >> >> >> The mapping should be maintained by asset type in order to associate with >> life cycle data. To be more specific in database schema level each asset >> type should update their tables (add extra columns to maintain mapping with >> life cycle data) in order to map life cycle data. >> >> The external systems which uses life cycle service should connect with >> the service in order to have a unique life cycle id which is generated >> by the service. This id should be stored in the external system in order to >> maintain the mapping (Each asset should have its own life cycle id). On the >> other hand life cycle framework will also store this id in order to provide >> all the life cycle related operations for a particular asset. >> >> >> >> Basically, we will be providing a class (ManagedLifecycle) with all the >> required basic operations. Any asset which requires life cycle management >> can extend this class. >> Further this can be extended to support features like check list items as >> well >> Features supported >> >> - >> >> Custom Inputs - User should provide with the capability in order to >> save custom values per each state, which can be passed to executors . >> - Executors - Which are custom classes executed during life cycle >> state change operation >> >> >> Please provide you valuable inputs. >> >> Thanks! >> Rajith >> >> -- >> Rajith Roshan >> Software Engineer, WSO2 Inc. >> Mobile: +94-72-642-8350 <%2B94-71-554-8430> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Regards, > Chamila Adhikarinayake > Software Engineer > WSO2, Inc. > Mobile - +94712346437 > Email - [email protected] > Blog - http://helpfromadhi.blogspot.com/ > -- Rajith Roshan Software Engineer, WSO2 Inc. Mobile: +94-72-642-8350 <%2B94-71-554-8430>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
