Hi Subash, This is regarding the questions you asked about application versions. Current AF versions are not right and needs to be redone in future on what we finalise on Greg. I have documented some thoughts that were on my mind
Application versions can use, - APIs - an association to a API resource - Registry resources and end points - an association to a Registry resource It has, - End point I believe from the meta model you have given above, the following data also belong to the version and not the parent. - List Grammar (XSDs; common to WSDL/WADL both) - List Message Encryption(ssl/ws-security,other) - List Documentation(URLs/inline strings) Note - Just copied over from above mail There must be a set of meta data representing Application and it can have many versions and each versions have types as above. So application has its own set of attributes that almost don't change over the lifecycle. The resource representing the Application is different from the resource representing the version. So in summary IMO, - So when we create an HTTP service as using client-side it doesn't have versions. - If we want a version we should create it using client side code, it has resources(with associations) and property-bag(to store doc links) as above, and it is the responsibility of the client do so thanks, dimuthu [1] https://docs.google.com/a/wso2.com/document/d/1px5Fjutp1WE_K3rkYmO4JUW8GVIftET6mgbby7_Kwis/edit On Wed, Sep 10, 2014 at 9:07 PM, Dimuthu Leelarathne <[email protected]> wrote: > Hi Subash, > > We can use it. But we cannot face the consequences of using it. For > example this would force us to move to 4.3 branch sooner than later. If not > for the demo we won't be looking at this. It would allow us to concentrate > on stabilising AF of 4.2 branch. > > thanks, > dimuthu > > > On Wed, Sep 10, 2014 at 4:59 PM, Subash Chaturanga <[email protected]> > wrote: > >> @Dimuthu, >> You mean you are not using this for next release ? Still if AF does not >> have time at the moment, can you send me link for a particular class/codes >> in AF that use gov api, so that I can provide equivalent code using >> metadata API. Then you guys can test it. >> >> On Wed, Sep 10, 2014 at 12:08 AM, Subash Chaturanga <[email protected]> >> wrote: >> >>> Hi Dimuthu et al, >>> In the attributes you have given for all service types in current AF, I >>> have following questions; >>> >>> What is "Description" ? Is this the service >>> description/document/interface definition (WSDL/WADL) ? or some human >>> readable description ? >>> >>> @Saniva et al; IF there is NO such particular thing specific for HTTP or >>> SOAP, we can maintain one service without having particular sub types and >>> represent all with following attributes; (One disadvantage is anything >>> required in future for a service type in wso2 and that is NOT common, >>> those will have to be managed with the property bag). Advantage is, reduce >>> the # meta models and APIs and having all services in one place. >>> >>> >>> *vnd.wso2.service* >>> >>> Subtype >>> >>> Suffix >>> >>> Parameters >>> >>> Description >>> >>> Content Model >>> >>> Associations >>> >>> * >>> >>> xml/json >>> >>> version (default is “1”) >>> >>> Top level type for all services >>> >>> -String name >>> >>> -String namespace >>> >>> -String owner >>> >>> -String description >>> >>> -String createdDate >>> >>> -List Transport Protocols (http/s,jms,tcp,xmpp) >>> >>> - List Message Format (soap 1.1/1.2,xml) >>> >>> - List Grammar (XSDs; common to WSDL/WADL both) >>> >>> -List Message Encryption(ssl/ws-security,other) >>> >>> - List Documentation(URLs/inline strings) >>> >>> >>> >>> 1..n service versions >>> >>> 1..n contacts >>> >>> >>> >>> *vnd.wso2.version/service* >>> >>> Subtype >>> >>> Suffix >>> >>> Parameters >>> >>> Description >>> >>> Content Model >>> >>> Associations >>> >>> service >>> >>> >>> >>> List<String> Endpoints >>> Object Security (Authentication UT,OAuth etc) ? >>> >>> 1..n endpoints >>> >>> >>> >>> >>> *vnd.wso2.endpoint* >>> >>> Subtype >>> >>> Suffix >>> >>> Parameters >>> >>> Description >>> >>> Content Model >>> >>> Associations >>> >>> * >>> >>> >>> Top level type for all endpoints >>> String URL1..n service versions >>> >>> >>> >>> *vnd.wso2.contact* >>> >>> Subtype >>> >>> Suffix >>> >>> Parameters >>> >>> Description >>> >>> Content Model >>> >>> Associations >>> >>> * >>> >>> >>> Top level type for all contacts >>> >>> - First Name >>> - Last Name >>> - Organization >>> - Address >>> - Country >>> - Email. >>> - Telephone >>> - Mobile >>> - IM - The user's personal e-mail address. >>> - URL - The users site address. >>> >>> >>> 1..n services >>> Contacts will be get generated from the current carbon user store. >>> >>> >>> >>> Shall we finalise service ? Can AF/AM/G-Reg agree on above service ? Is >>> there anything that is lacking/some required attribute ? >>> >>> >>> >>> On Tue, Sep 9, 2014 at 1:03 PM, Dimuthu Leelarathne <[email protected]> >>> wrote: >>> >>>> Hi Subash, >>>> >>>> Thanks. We will not be taking this up yet. >>>> >>>> thanks, >>>> dimuthu >>>> >>>> >>>> On Thu, Sep 4, 2014 at 6:10 PM, Subash Chaturanga <[email protected]> >>>> wrote: >>>> >>>>> Hi, >>>>> Finished the searching with Solr index. I have tested a sample >>>>> complete client code inside Turing G-Reg 4.6.0 governance component. >>>>> @Dimuthu, >>>>> Now this API should be able to used to re build what you have already >>>>> with gov api. I will work on completing my external TODOs left, like >>>>> adding >>>>> unit tests etc. >>>>> >>>>> >>>>> On Mon, Sep 1, 2014 at 9:14 AM, Subash Chaturanga <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> Moving to @architecture. >>>>>> >>>>>> >>>>>> On Fri, Aug 29, 2014 at 3:47 AM, Subash Chaturanga <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> This is to give you a progress update. Now the code is moved to wso2 >>>>>>> -dev repo [1]. And I have completed the implementation except the >>>>>>> search/findAll which have to implement through indexing. Following is >>>>>>> the >>>>>>> client code I used. >>>>>>> >>>>>>> >>>>>>> // You have to set this path ONLY if you are using this api outside >>>>>>> a carbon server runtime. >>>>>>> >>>>>>> Util.setProviderMapFilePath("<path-to-registry.xml>"); >>>>>>> >>>>>>> HTTPServiceVersionV1 bv = new >>>>>>> HTTPServiceVersionV1(registry, "1.0.0"); >>>>>>> >>>>>>> bv.setProperty("foo", "bar"); >>>>>>> >>>>>>> HTTPServiceV1 http1 = new HTTPServiceV1(registry, >>>>>>> "myservice",bv); >>>>>>> >>>>>>> http1.setOwner("serviceOwner"); >>>>>>> >>>>>>> http1.setProperty("createdDate", "12-12-2012"); >>>>>>> >>>>>>> HTTPServiceV1.add(registry, http1); >>>>>>> >>>>>>> HTTPServiceV1 httpServiceV1 = HTTPServiceV1.get(registry, >>>>>>> http1.getUUID()); >>>>>>> >>>>>>> HTTPServiceVersionV1 v2 = >>>>>>> httpServiceV1.newVersion("1.2.0"); >>>>>>> >>>>>>> v2.setProperty("foo", "bar"); >>>>>>> >>>>>>> HTTPServiceVersionV1.add(registry, v2); >>>>>>> >>>>>>> for(HTTPServiceVersionV1 v:httpServiceV1.getVersions()){ >>>>>>> >>>>>>> System.out.println(v.getName()); >>>>>>> >>>>>>> } >>>>>>> >>>>>>> http1.attachLifecycle("SampleLifeCycle"); >>>>>>> >>>>>>> StateMachineLifecycle lc = http1.getLifecycle(); >>>>>>> >>>>>>> StateMachineLifecycle.State s = lc.getCurrentState(); >>>>>>> >>>>>>> lc.transfer("Promote"); >>>>>>> >>>>>>> StateMachineLifecycle.State s1 = lc.getCurrentState(); >>>>>>> >>>>>>> >>>>>>> I have attached the screen shot of the G-Reg 4.6.0 mgt console after >>>>>>> running this client. You can find the associations are created and >>>>>>> lifecycle has attached and promoted to Test status. >>>>>>> >>>>>>> The API always deals with UUIDs from creating associations to CRUD >>>>>>> instances. And the code is in wso2-dev git repo and no need to backport >>>>>>> on >>>>>>> turing, hence AF can build it and put it in to dropins. >>>>>>> >>>>>>> Once finish the searching/getAll we can try replacing a AF code with >>>>>>> this API. Meanwhile we need to finalize the rest of the meta data >>>>>>> @Sanjiva's meta data spec 1.0.0 ;-). Also will arrange a code/API >>>>>>> review >>>>>>> once search is implemented. >>>>>>> >>>>>>> Basic Implementation TODOs; >>>>>>> >>>>>>> - Search >>>>>>> - Add more class/method comments to improve readability. >>>>>>> - Create an ant sample. >>>>>>> - Performance tune >>>>>>> >>>>>>> >>>>>>> [1] - >>>>>>> https://github.com/wso2-dev/carbon-registry/tree/master/components/registry/org.wso2.carbon.registry.metadata >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Aug 22, 2014 at 7:35 PM, Senaka Fernando <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Sanjiva, I added a comment on 2a in FAQ #2, too see whether we can >>>>>>>> find a solution to what Dimuthu mentioned. This is the reason why I >>>>>>>> actually proposed 2a - but that's obviously not the ideal solution >>>>>>>> too. So, >>>>>>>> trying to understand the best compromise here. >>>>>>>> >>>>>>>> Subash, I don't think the get/set property business is a good idea >>>>>>>> at all. If this is an end-to-end API, shouldn't we for example do: >>>>>>>> >>>>>>>> >>>>>>>> HTTPServiceVersionV1 httpV1 = http1.newVersion("1.0.0"); >>>>>>>> EndpointV1 endpoint = new EndpointV1("http://test.rest/stockquote >>>>>>>> "); >>>>>>>> endpoint.setSecured(true); >>>>>>>> httpV1.addEndpoint(endpoint); >>>>>>>> HTTPServiceVersionV1.add(httpV1); >>>>>>>> >>>>>>>> My view is that the API needs to be very expressive so that >>>>>>>> everybody who uses that will generally find it to be comprehensive and >>>>>>>> the >>>>>>>> property option is only if they don't find a way to do what they want. >>>>>>>> >>>>>>>> Also, a very radical question on services and endpoints. I think >>>>>>>> everybody (G-Reg, AppFac and API-M teams) is clear that the >>>>>>>> ServiceVersion >>>>>>>> is what has the lifecycle state. But, I wanted to ask a separate >>>>>>>> question. >>>>>>>> Are we ruling out the possibility of a single service version being in >>>>>>>> multiple environments? If yes, then simply forget this question. If no, >>>>>>>> should we be having a state for the endpoint (i.e. A single service >>>>>>>> version >>>>>>>> with Dev endpoint a QA endpoint and vice versa). If we think we need >>>>>>>> the >>>>>>>> above, should we have a concept of primary endpoint, which is what in >>>>>>>> return deduces what state the service is in (ex:- the primary endpoint >>>>>>>> for >>>>>>>> a service v1 is dev, which means the service is in dev state)? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Senaka. >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Aug 22, 2014 at 2:15 PM, Sanjiva Weerawarana < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> Dimuthu see FAQ #2 in the document. Please suggest alternatives or >>>>>>>>> accept it :-). >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Aug 22, 2014 at 3:36 PM, Dimuthu Leelarathne < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi Subash and all, >>>>>>>>>> >>>>>>>>>> The API look extremely cluttered with V1 appended to all classes. >>>>>>>>>> :( >>>>>>>>>> >>>>>>>>>> thanks, >>>>>>>>>> dimuthu >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Aug 22, 2014 at 9:30 AM, Dimuthu Leelarathne < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi Subash, >>>>>>>>>>> >>>>>>>>>>> I believe this API allows us to create a foo service without a >>>>>>>>>>> version. But that should not be the case. As discussed the instance >>>>>>>>>>> also >>>>>>>>>>> must have a version. So the Create API should change. >>>>>>>>>>> >>>>>>>>>>> thanks, >>>>>>>>>>> dimuthu >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Aug 22, 2014 at 1:05 AM, Subash Chaturanga < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Sanjiva et al, >>>>>>>>>>>> Here is the [1] latest metadata API. In the process of >>>>>>>>>>>> finishing the first cut implementation. Will update soon once I >>>>>>>>>>>> finished >>>>>>>>>>>> it. Please provide your feedback if anything needs to be changed >>>>>>>>>>>> from the >>>>>>>>>>>> API consumer PoV. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> So this is the latest client code; >>>>>>>>>>>> >>>>>>>>>>>> HTTPServiceV1 http1 = new HTTPServiceV1("foo"); >>>>>>>>>>>> http1.setOwner("serviceOwner"); >>>>>>>>>>>> http1.setProperty("createdDate","12-12-2012"); >>>>>>>>>>>> HTTPServiceV1.add(http1); >>>>>>>>>>>> >>>>>>>>>>>> HTTPServiceV1[] services = HTTPServiceV1.getAll(); >>>>>>>>>>>> for(HTTPServiceV1 ht:services){ >>>>>>>>>>>> ht.setProperty("newProp","newValue"); >>>>>>>>>>>> HTTPServiceV1.update(ht); >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>> HTTPServiceVersionV1 httpV1 = http1.newVersion("1.0.0"); >>>>>>>>>>>> httpV1.setEndpointUrl("http://test.rest/stockquote";); >>>>>>>>>>>> httpV1.setProperty("isSecured","true"); >>>>>>>>>>>> HTTPServiceVersionV1.add(httpV1); >>>>>>>>>>>> >>>>>>>>>>>> HTTPServiceVersionV1 v1 = >>>>>>>>>>>> HTTPServiceVersionV1.get(httpV1.getUUID()); >>>>>>>>>>>> HTTPServiceV1.delete(v1.getUUID()); >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> [1] - >>>>>>>>>>>> https://github.com/subash89/carbon-registry/tree/master/components/registry/org.wso2.carbon.registry.metadata >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Aug 18, 2014 at 9:15 AM, Dimuthu Leelarathne < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Please see my comments in line. >>>>>>>>>>>>> >>>>>>>>>>>>> On Sun, Aug 17, 2014 at 3:32 PM, Sanjiva Weerawarana < >>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> [At least Sagara/Dimuthu/Senaka/Frank/Paul please read >>>>>>>>>>>>>> carefully. Lot of subtlety to get right ..] >>>>>>>>>>>>>> >>>>>>>>>>>>>> With media types, we have only 3 simple/direct ways of >>>>>>>>>>>>>> categorizing stuff: >>>>>>>>>>>>>> {type}/{subtype}+{format}. >>>>>>>>>>>>>> There are of course parameters as add-ons but this is the >>>>>>>>>>>>>> primary set. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For services {type} = vnd.wso2.service. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Question is what is subtype? I think we're agreeing WAR is >>>>>>>>>>>>>> not appropriate as that's an implementation format. From a >>>>>>>>>>>>>> service metadata >>>>>>>>>>>>>> perspective, whether its PHP or .Net or Jaggery or whatever is >>>>>>>>>>>>>> not >>>>>>>>>>>>>> important either. JAX-RS and JAX-WS are also really just >>>>>>>>>>>>>> internal things - >>>>>>>>>>>>>> what JAX-RS produces is an HTTP service. What JAX-WS produces is >>>>>>>>>>>>>> a >>>>>>>>>>>>>> SOAP-speaking service which could potentially be exposed in >>>>>>>>>>>>>> multiple access >>>>>>>>>>>>>> channels. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So, it seems to me, what really matters about a service is >>>>>>>>>>>>>> what the access protocol is and what format the messages are to >>>>>>>>>>>>>> be sent. In >>>>>>>>>>>>>> other words: >>>>>>>>>>>>>> >>>>>>>>>>>>>> {subtype} = access protocol: http | smtp | thrift | ... >>>>>>>>>>>>>> {format} = message format: soap | xml | json | txt | binary | >>>>>>>>>>>>>> ... >>>>>>>>>>>>>> >>>>>>>>>>>>>> So how do you represent a SOAP service which is available >>>>>>>>>>>>>> over multiple protocols then? Direct interpretation would say it >>>>>>>>>>>>>> should be >>>>>>>>>>>>>> vnd.wso2.service/*+soap. However that's not a valid media type; >>>>>>>>>>>>>> that's a >>>>>>>>>>>>>> pattern to match against many media types. >>>>>>>>>>>>>> >>>>>>>>>>>>>> We can solve this by considering "soap" as an access protocol >>>>>>>>>>>>>> and model a SOAP service with vnd.wso2.service/soap. The same >>>>>>>>>>>>>> service's >>>>>>>>>>>>>> HTTP specific rendition would be vnd.wso2.service/soap+http. >>>>>>>>>>>>>> This model >>>>>>>>>>>>>> does well for WSDL too - sort of .. WSDL separates the service >>>>>>>>>>>>>> interface >>>>>>>>>>>>>> (portType) from its access information (binding - both transport >>>>>>>>>>>>>> and >>>>>>>>>>>>>> formatting). >>>>>>>>>>>>>> >>>>>>>>>>>>>> So what if we reverse the model and use format as the subtype >>>>>>>>>>>>>> and protocol as the format: >>>>>>>>>>>>>> >>>>>>>>>>>>>> {subtype} = message format: soap | xml | json | txt | binary >>>>>>>>>>>>>> | ... >>>>>>>>>>>>>> {format} = access protocol: http | smtp | thrift >>>>>>>>>>>>>> >>>>>>>>>>>>>> BUT that has its set of problems too .. many services can >>>>>>>>>>>>>> speak both XML and JSON for example. Furthermore, SOAP does not >>>>>>>>>>>>>> imply a >>>>>>>>>>>>>> particular format .. SOAP can be sent over XML or a binary >>>>>>>>>>>>>> serialization of >>>>>>>>>>>>>> XML. Luckily no one uses the latter so lets ignore it. (The use >>>>>>>>>>>>>> of XML vs. >>>>>>>>>>>>>> a binary serialization seems more in the league of content >>>>>>>>>>>>>> transfer >>>>>>>>>>>>>> encoding [1] anyway.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> There's also the aspect of versions of a service to be >>>>>>>>>>>>>> considered. It seems to me its really a version of a service >>>>>>>>>>>>>> that has a >>>>>>>>>>>>>> particular interface, not the service itself (as the interface >>>>>>>>>>>>>> may change >>>>>>>>>>>>>> over time). >>>>>>>>>>>>>> >>>>>>>>>>>>>> *So, in summary, my suggestion is we go with*: >>>>>>>>>>>>>> >>>>>>>>>>>>>> {type} = vnd.wso2.service >>>>>>>>>>>>>> {subtype} = access protocol: soap | http | thift | ... >>>>>>>>>>>>>> {format} = xml | json | text | binary ... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Then, we make sure each service will have at least one >>>>>>>>>>>>>> version: >>>>>>>>>>>>>> >>>>>>>>>>>>>> vnd.wso2.version/service >>>>>>>>>>>>>> >>>>>>>>>>>>>> That could have some standard associations depending on what >>>>>>>>>>>>>> type of service it is a version of. For example, for SOAP >>>>>>>>>>>>>> services it makes >>>>>>>>>>>>>> sense to have a required associated WSDL interface definition >>>>>>>>>>>>>> (portType). >>>>>>>>>>>>>> For HTTP services maybe we can associate with Swagger or WADL >>>>>>>>>>>>>> for interface >>>>>>>>>>>>>> definition. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [NOTE: In App Factory currently bunch of the information is >>>>>>>>>>>>>> at the wrong level w.r.t. to an app and its versions. AF only >>>>>>>>>>>>>> knows about >>>>>>>>>>>>>> versions in terms of Git and for governance. It doesn't keep >>>>>>>>>>>>>> other stuff >>>>>>>>>>>>>> like resources against versions when it really needs to have >>>>>>>>>>>>>> those can >>>>>>>>>>>>>> differ by version easily.] >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Going into this model means we'll be in-sync with ES and >>>>>>>>>>>>> AppManager and in addition and resources will be version >>>>>>>>>>>>> specific. However >>>>>>>>>>>>> then AF story changes drastically - this includes UIs. We'll also >>>>>>>>>>>>> need a >>>>>>>>>>>>> solid story for agile development if we are going for this model. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> If we want the metadata model to capture the >>>>>>>>>>>>>> deployment/implementation model, I suggest we create another top >>>>>>>>>>>>>> level type >>>>>>>>>>>>>> called vnd.wso2.artifact and have subtypes: >>>>>>>>>>>>>> >>>>>>>>>>>>>> vnd.wso2.artifact/war >>>>>>>>>>>>>> vnd.wso2.artifact/war+jaxrs >>>>>>>>>>>>>> vnd.wso2.artifact/war+jaxws >>>>>>>>>>>>>> vnd.wso2.artifact/car >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> +1. This will be useful for AF to make deployment decision and >>>>>>>>>>>>> it can be coupled with the concept of Runtimes, for example >>>>>>>>>>>>> Tomcat, >>>>>>>>>>>>> AppServer and etc ... but that can come later with the multiple >>>>>>>>>>>>> runtime >>>>>>>>>>>>> environment feature. >>>>>>>>>>>>> >>>>>>>>>>>>> thanks, >>>>>>>>>>>>> dimuthu >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> etc.. Then there can be an association or a property to >>>>>>>>>>>>>> capture the artifact type of a particular service. The value of >>>>>>>>>>>>>> that >>>>>>>>>>>>>> association could be the name of the war file for example. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The last part is the endpoint part .. a particular version of >>>>>>>>>>>>>> a service is going to be available at one ore more endpoints. >>>>>>>>>>>>>> Endpoints >>>>>>>>>>>>>> come off servers .. which is part of the model that Senaka and >>>>>>>>>>>>>> G-Reg team >>>>>>>>>>>>>> have planned. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Endpoints are also of course connected to APIs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Subash is going to schedule a discussion to finalize that >>>>>>>>>>>>>> part. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sanjiva. >>>>>>>>>>>>>> [1] >>>>>>>>>>>>>> http://en.wikipedia.org/wiki/MIME#Content-Transfer-Encoding >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Fri, Aug 15, 2014 at 5:29 PM, Dimuthu Leelarathne < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We should be using the name WebApplication for all of these, >>>>>>>>>>>>>>> - PHP >>>>>>>>>>>>>>> - .NET ASP >>>>>>>>>>>>>>> - Jaggery >>>>>>>>>>>>>>> - Java WebApp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In our meta model, it should be as follows. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Parent - Application >>>>>>>>>>>>>>> Child - WebApp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> However, JAX-RS and JAX-WS are services. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> In that sense, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Parent - Service >>>>>>>>>>>>>>> Child - SoapService >>>>>>>>>>>>>>> Child - RESTService >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> For App Factory to proceed the above classes will be enough >>>>>>>>>>>>>>> - WebApp, SOAPService, RESTService. Only 3 meta models are >>>>>>>>>>>>>>> required. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> thanks, >>>>>>>>>>>>>>> dimuthu >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Fri, Aug 15, 2014 at 1:05 PM, Senaka Fernando < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Fri, Aug 15, 2014 at 6:27 AM, Sagara Gunathunga < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Thu, Aug 14, 2014 at 4:34 AM, Dimuthu Leelarathne < >>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi Subash and all, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We want the store the following for the App Factory >>>>>>>>>>>>>>>>>> artefacts. I am not sure whether to fill the parameters >>>>>>>>>>>>>>>>>> section or the >>>>>>>>>>>>>>>>>> Content section of the tables so I decided write inline to >>>>>>>>>>>>>>>>>> the mail. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> For WAR - Name, Key, Owner, Description, Type, >>>>>>>>>>>>>>>>>> Repository Type, EndPoint URL >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I guess you mean application with web pages as WAR, if so >>>>>>>>>>>>>>>>> IMHO it's better to use different name than WAR to avoid >>>>>>>>>>>>>>>>> confusions. WAR >>>>>>>>>>>>>>>>> is not a application type instead it's a deployment unit >>>>>>>>>>>>>>>>> where JAX-WS and >>>>>>>>>>>>>>>>> JAX-RS services also deploy as WAR archives. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> +1 to Sagara. we can all this "WebApplication"? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Senaka. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks ! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> For JAXWS, JAXRS, Data Services, Jaggery and Jaggery >>>>>>>>>>>>>>>>>> parameters would be the following. >>>>>>>>>>>>>>>>>> Name, Key, Owner, Description, Type, Repository Type, >>>>>>>>>>>>>>>>>> Endpoint ( we will need a new feature for this so sending a >>>>>>>>>>>>>>>>>> separate mail >>>>>>>>>>>>>>>>>> on this to architecture) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> thanks, >>>>>>>>>>>>>>>>>> dimuthu >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Wed, Aug 13, 2014 at 7:01 PM, Ruchira Wageesha < >>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi Subash, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> In the attached google doc, I saw that you guys are >>>>>>>>>>>>>>>>>>> going to use versions in class name? If that is the case, >>>>>>>>>>>>>>>>>>> how can we create >>>>>>>>>>>>>>>>>>> Server1.0.0 or Service1.2.0 like classes from Java or do we >>>>>>>>>>>>>>>>>>> assume versions >>>>>>>>>>>>>>>>>>> to be always like v1...vn? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> According to my picture, it should be a different jar >>>>>>>>>>>>>>>>>>> version like in maven/OSGI. i.e. We have the exact >>>>>>>>>>>>>>>>>>> classname for every >>>>>>>>>>>>>>>>>>> version of the same service, but different implementations >>>>>>>>>>>>>>>>>>> in different >>>>>>>>>>>>>>>>>>> jars. It is the model that we follow in Java and why cannot >>>>>>>>>>>>>>>>>>> we continue >>>>>>>>>>>>>>>>>>> that for this as well? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Wed, Aug 13, 2014 at 4:33 AM, Senaka Fernando < >>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi Subash, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Please find comments in-line. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Tue, Aug 12, 2014 at 7:16 PM, Janaka Ranabahu < >>>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hi Subash, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Tue, Aug 12, 2014 at 11:12 PM, Subash Chaturanga < >>>>>>>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>>>>>>>>> We had a meeting on $subject as a continuation on >>>>>>>>>>>>>>>>>>>>>> "Applications in the unified governance model" and >>>>>>>>>>>>>>>>>>>>>> decide what is the >>>>>>>>>>>>>>>>>>>>>> unified governance meta models should be in high level. >>>>>>>>>>>>>>>>>>>>>> And Sanjiva updated >>>>>>>>>>>>>>>>>>>>>> the same doc with todays conclusions in [1]. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Came up with set of high level meta models to start >>>>>>>>>>>>>>>>>>>>>> with compared to what we have already in G-Reg(refer doc >>>>>>>>>>>>>>>>>>>>>> [1]). >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> a. Came up with a meta model java interface to >>>>>>>>>>>>>>>>>>>>>> address the current requirement. There, we will be >>>>>>>>>>>>>>>>>>>>>> creating first class >>>>>>>>>>>>>>>>>>>>>> APIs for identified well known unified governance >>>>>>>>>>>>>>>>>>>>>> metadata models. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> b. Decided some modifications for the media types. >>>>>>>>>>>>>>>>>>>>>> - skip the "application/" for media types and >>>>>>>>>>>>>>>>>>>>>> now it will be something as vnd.wso2.service for >>>>>>>>>>>>>>>>>>>>>> services. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Why? "application" here has nothing to do with services >>>>>>>>>>>>>>>>>>>> and applications that we are talking about. This is the >>>>>>>>>>>>>>>>>>>> standard way of >>>>>>>>>>>>>>>>>>>> writing a vendor specific MIME type (i.e. >>>>>>>>>>>>>>>>>>>> application/vnd.<vendor_name><vendor_specific_portion>). >>>>>>>>>>>>>>>>>>>> Why do we have to >>>>>>>>>>>>>>>>>>>> change this notation? I know that given #2 below, there is >>>>>>>>>>>>>>>>>>>> no reason we >>>>>>>>>>>>>>>>>>>> can't play around with the names of the mediatypes, but if >>>>>>>>>>>>>>>>>>>> this has no >>>>>>>>>>>>>>>>>>>> special intent, I see no point in removing the >>>>>>>>>>>>>>>>>>>> "application/" part though. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> - having version support for media >>>>>>>>>>>>>>>>>>>>>> types.(version will be part of the media type), have not >>>>>>>>>>>>>>>>>>>>>> finalized on how >>>>>>>>>>>>>>>>>>>>>> to add a version string to media type. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> This is fine as we agreed. The MIME processor can >>>>>>>>>>>>>>>>>>>> accept a string after the standard mediatype notation >>>>>>>>>>>>>>>>>>>> (i.e. ";version=x") >>>>>>>>>>>>>>>>>>>> for these specific assets. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> c. Metadata java interfaces will always deal with >>>>>>>>>>>>>>>>>>>>>> UUIDs, but never with paths. >>>>>>>>>>>>>>>>>>>>>> - meta data structure/attribute can get changed >>>>>>>>>>>>>>>>>>>>>> from time to time. Should need a mechanism to support >>>>>>>>>>>>>>>>>>>>>> metadata in old >>>>>>>>>>>>>>>>>>>>>> format as well as in new format (aka different versions >>>>>>>>>>>>>>>>>>>>>> of a media type) in >>>>>>>>>>>>>>>>>>>>>> the same carbon runtime. Hence interface name itself >>>>>>>>>>>>>>>>>>>>>> will have version >>>>>>>>>>>>>>>>>>>>>> information. >>>>>>>>>>>>>>>>>>>>>> i.e media type versions are restricted to have only >>>>>>>>>>>>>>>>>>>>>> majors. i.e for services org.wso2.metadata.ServiceV1 (we >>>>>>>>>>>>>>>>>>>>>> knew this is ugly, >>>>>>>>>>>>>>>>>>>>>> but can't help, but you're mostly welcome for a better >>>>>>>>>>>>>>>>>>>>>> suggestion). >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> This was the way I thought of solving it (during the >>>>>>>>>>>>>>>>>>>> call I was in), "org.wso2.metadata.service.v1.Service". >>>>>>>>>>>>>>>>>>>> But, if it is just >>>>>>>>>>>>>>>>>>>> a single class inside the "org.wso2.metadata.service.v1.*" >>>>>>>>>>>>>>>>>>>> package, there >>>>>>>>>>>>>>>>>>>> is no point in doing that. But, if we plan to have a few >>>>>>>>>>>>>>>>>>>> classes in the >>>>>>>>>>>>>>>>>>>> package, then we probably can do that. Then, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 1. the code is a bit more readable >>>>>>>>>>>>>>>>>>>> 2. there is no possibility of somebody using two >>>>>>>>>>>>>>>>>>>> different versions of the Service class in the code >>>>>>>>>>>>>>>>>>>> that is based on this >>>>>>>>>>>>>>>>>>>> API >>>>>>>>>>>>>>>>>>>> 3. Using OSGi, we can stop exporting the older API >>>>>>>>>>>>>>>>>>>> versions on a later date >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Also, note my comments below on how this works in >>>>>>>>>>>>>>>>>>>> specific situations. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> d. First class version support. >>>>>>>>>>>>>>>>>>>>>> - Create an artifact without a version. >>>>>>>>>>>>>>>>>>>>>> - Then create versions from the artifact >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> e. Apart from these, all CRUD + search; typical >>>>>>>>>>>>>>>>>>>>>> interfaces will be given for each metadata type. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> We did not touch this subject during the discussion >>>>>>>>>>>>>>>>>>>>> but apart from these, I believe we need to introduce >>>>>>>>>>>>>>>>>>>>> methods to perform >>>>>>>>>>>>>>>>>>>>> governance operations in these artifacts. The interface >>>>>>>>>>>>>>>>>>>>> should supports to >>>>>>>>>>>>>>>>>>>>> attach, detach, perform governance >>>>>>>>>>>>>>>>>>>>> operation(promote,demote or any >>>>>>>>>>>>>>>>>>>>> lifecycle event) and get lifecycle state of an artifacts. >>>>>>>>>>>>>>>>>>>>> Right now we have >>>>>>>>>>>>>>>>>>>>> registry API's to do these but IMO, the artifacts should >>>>>>>>>>>>>>>>>>>>> have 1st class >>>>>>>>>>>>>>>>>>>>> support for governance operations. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I have mixed views on this. Does all metadata need to >>>>>>>>>>>>>>>>>>>> be governed? Isn't the metadata API separate from the >>>>>>>>>>>>>>>>>>>> governance around it? >>>>>>>>>>>>>>>>>>>> Wouldn't some governance functionality be limited to >>>>>>>>>>>>>>>>>>>> certain products? If >>>>>>>>>>>>>>>>>>>> so, doesn't it make sense to have the governance of these >>>>>>>>>>>>>>>>>>>> metadata as a >>>>>>>>>>>>>>>>>>>> separate API? i.e. org.wso2.metadata.governance? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Janaka >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Super parent media type will be "vnd.wso2.metadata". >>>>>>>>>>>>>>>>>>>>>> Following is the design for high level service. Refer >>>>>>>>>>>>>>>>>>>>>> doc [1] for more >>>>>>>>>>>>>>>>>>>>>> detailed info. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> vnd.wso2.service __ 1 ____ n vnd.wso2.contact >>>>>>>>>>>>>>>>>>>>>> 1 ____ n >>>>>>>>>>>>>>>>>>>>>> vnd.wso2.version 1 ____ n vnd.wso2.endpoint >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> vnd.wso2.version? or vnd.wso2.version.service? Does any >>>>>>>>>>>>>>>>>>>> version artifact look the same? Note that I specifically >>>>>>>>>>>>>>>>>>>> did not use >>>>>>>>>>>>>>>>>>>> vnd.wso2.service.version for it will break our media-type >>>>>>>>>>>>>>>>>>>> based inheritance >>>>>>>>>>>>>>>>>>>> model. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Also, contacts are loosely coupled. It can be @ service >>>>>>>>>>>>>>>>>>>> level or @ service version level. And, why contact? why >>>>>>>>>>>>>>>>>>>> not vnd.wso2.user? >>>>>>>>>>>>>>>>>>>> vnd.wso2.userprofile? IMHO, a contact is what a service >>>>>>>>>>>>>>>>>>>> has, but when that >>>>>>>>>>>>>>>>>>>> information gets stored in the registry its a >>>>>>>>>>>>>>>>>>>> user-profile, and this should >>>>>>>>>>>>>>>>>>>> directly comply with the WSO2 IS user-profile structure >>>>>>>>>>>>>>>>>>>> (as you have >>>>>>>>>>>>>>>>>>>> mentioned below). In other words, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> public interface Service { >>>>>>>>>>>>>>>>>>>> UserProfile[] getContacts() >>>>>>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> (vnd.wso2.contact will get populated from carbon user >>>>>>>>>>>>>>>>>>>>>> profile and will provide useful information on impact >>>>>>>>>>>>>>>>>>>>>> analysis) >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Targeting Oct WSO2Con, we will be starting with >>>>>>>>>>>>>>>>>>>>>> jax-rs service which is vnd.wso2.metadata > >>>>>>>>>>>>>>>>>>>>>> vnd.wso2.service > >>>>>>>>>>>>>>>>>>>>>> vnd.wso2.service.jax-rs. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Great, and what's the Java package name for this? If >>>>>>>>>>>>>>>>>>>> you take my approach, it will be >>>>>>>>>>>>>>>>>>>> "org.wso2.metadata.service.v1.RESTfulService". Its a >>>>>>>>>>>>>>>>>>>> little ugly, but, I >>>>>>>>>>>>>>>>>>>> expanded the abbreviated name JAX-RS - and the "RS" stands >>>>>>>>>>>>>>>>>>>> for RESTful >>>>>>>>>>>>>>>>>>>> Service and not RESTService. JAX part is redundant since >>>>>>>>>>>>>>>>>>>> this is a Java API. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Immediate action items; >>>>>>>>>>>>>>>>>>>>>> - Need to update the doc [1] and fill the tables >>>>>>>>>>>>>>>>>>>>>> for the defined meta data models and finalize what we >>>>>>>>>>>>>>>>>>>>>> keep/drop >>>>>>>>>>>>>>>>>>>>>> - Finalize the format for Service. >>>>>>>>>>>>>>>>>>>>>> - Finalize the format for JAX-RS. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Please feel free to add your thoughts on adding >>>>>>>>>>>>>>>>>>>>>> anything that seems useful for a >>>>>>>>>>>>>>>>>>>>>> service/JAX-RS/Application in general >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Please add if I had missed anything. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Adding more to Ajith's comments, yet again, if you >>>>>>>>>>>>>>>>>>>> follow the package name model I propose, you can, have >>>>>>>>>>>>>>>>>>>> org.wso2.metadata.common.v1.Endpoint (if endpoint is a >>>>>>>>>>>>>>>>>>>> more generic concept >>>>>>>>>>>>>>>>>>>> than a service for instance) or >>>>>>>>>>>>>>>>>>>> org.wso2.metadata.service.v1.Endpoint (if >>>>>>>>>>>>>>>>>>>> endpoints are only associated with services). Similarly, >>>>>>>>>>>>>>>>>>>> you can have >>>>>>>>>>>>>>>>>>>> org.wso2.metadata.common.v1.Contact or >>>>>>>>>>>>>>>>>>>> org.wso2.metadata.common.v1.User or >>>>>>>>>>>>>>>>>>>> org.wso2.metadata.common.v1.UserProfile. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>> Senaka. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> [1] - >>>>>>>>>>>>>>>>>>>>>> https://docs.google.com/a/wso2.com/document/d/1lqoHru84oCtBXHILNhKyyUdWA0yN05Um4xyfKFIX1_4/edit >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>> /subash >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> *Subash Chaturanga* >>>>>>>>>>>>>>>>>>>>>> Senior Software Engineer & Lead WSO2 Governance >>>>>>>>>>>>>>>>>>>>>> Registry >>>>>>>>>>>>>>>>>>>>>> Platform TG; WSO2 Inc. http://wso2.com >>>>>>>>>>>>>>>>>>>>>> Contact: >>>>>>>>>>>>>>>>>>>>>> email: [email protected] >>>>>>>>>>>>>>>>>>>>>> blog: http://subashsdm.blogspot.com/ >>>>>>>>>>>>>>>>>>>>>> twitter: @subash89 >>>>>>>>>>>>>>>>>>>>>> phone: +9477 2225922 >>>>>>>>>>>>>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> *Janaka Ranabahu* >>>>>>>>>>>>>>>>>>>>> Senior Software Engineer; WSO2 Inc.; http://wso2.com >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> * E-mail: [email protected] <http://wso2.com>**M: **+94 >>>>>>>>>>>>>>>>>>>>> 718370861 <%2B94%20718370861>* >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> *[image: http://wso2.com] <http://wso2.com> Senaka >>>>>>>>>>>>>>>>>>>> Fernando* >>>>>>>>>>>>>>>>>>>> Software Architect; WSO2 Inc.; http://wso2.com >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> * Member; Apache Software Foundation; http://apache.org >>>>>>>>>>>>>>>>>>>> <http://apache.org>E-mail: senaka AT wso2.com >>>>>>>>>>>>>>>>>>>> <http://wso2.com>**P: >>>>>>>>>>>>>>>>>>>> +1 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966> >>>>>>>>>>>>>>>>>>>> Linked-In: http://linkedin.com/in/senakafernando >>>>>>>>>>>>>>>>>>>> <http://linkedin.com/in/senakafernando>* >>>>>>>>>>>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *Ruchira Wageesha**Associate Technical Lead* >>>>>>>>>>>>>>>>>>> *WSO2 Inc. - lean . enterprise . middleware | wso2.com >>>>>>>>>>>>>>>>>>> <http://wso2.com>* >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> *email: [email protected] <[email protected]>, blog: >>>>>>>>>>>>>>>>>>> ruchirawageesha.blogspot.com >>>>>>>>>>>>>>>>>>> <http://ruchirawageesha.blogspot.com>, >>>>>>>>>>>>>>>>>>> mobile: +94 77 5493444 <%2B94%2077%205493444>* >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Dimuthu Leelarathne >>>>>>>>>>>>>>>>>> Architect & Product Lead of App Factory >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> WSO2, Inc. (http://wso2.com) >>>>>>>>>>>>>>>>>> email: [email protected] >>>>>>>>>>>>>>>>>> Mobile : 0773661935 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Sagara Gunathunga >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Senior Technical Lead; WSO2, Inc.; http://wso2.com >>>>>>>>>>>>>>>>> V.P Apache Web Services; http://ws.apache.org/ >>>>>>>>>>>>>>>>> Linkedin; http://www.linkedin.com/in/ssagara >>>>>>>>>>>>>>>>> Blog ; http://ssagara.blogspot.com >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* >>>>>>>>>>>>>>>> Software Architect; WSO2 Inc.; http://wso2.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * Member; Apache Software Foundation; http://apache.org >>>>>>>>>>>>>>>> <http://apache.org>E-mail: senaka AT wso2.com >>>>>>>>>>>>>>>> <http://wso2.com>**P: >>>>>>>>>>>>>>>> +1 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In: >>>>>>>>>>>>>>>> http://linkedin.com/in/senakafernando >>>>>>>>>>>>>>>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise >>>>>>>>>>>>>>>> . Middleware >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Dimuthu Leelarathne >>>>>>>>>>>>>>> Architect & Product Lead of App Factory >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> WSO2, Inc. (http://wso2.com) >>>>>>>>>>>>>>> email: [email protected] >>>>>>>>>>>>>>> Mobile : 0773661935 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Sanjiva Weerawarana, Ph.D. >>>>>>>>>>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >>>>>>>>>>>>>> email: [email protected]; office: (+1 650 745 4499 | +94 11 >>>>>>>>>>>>>> 214 5345) x5700; cell: +94 77 787 6880 | +1 408 466 5099; >>>>>>>>>>>>>> voip: +1 650 265 8311 >>>>>>>>>>>>>> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva >>>>>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Dimuthu Leelarathne >>>>>>>>>>>>> Architect & Product Lead of App Factory >>>>>>>>>>>>> >>>>>>>>>>>>> WSO2, Inc. (http://wso2.com) >>>>>>>>>>>>> email: [email protected] >>>>>>>>>>>>> Mobile : 0773661935 >>>>>>>>>>>>> >>>>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Thanks >>>>>>>>>>>> /subash >>>>>>>>>>>> >>>>>>>>>>>> *Subash Chaturanga* >>>>>>>>>>>> Senior Software Engineer & Lead WSO2 Governance Registry >>>>>>>>>>>> Platform TG; WSO2 Inc. http://wso2.com >>>>>>>>>>>> Contact: >>>>>>>>>>>> email: [email protected] >>>>>>>>>>>> blog: http://subashsdm.blogspot.com/ >>>>>>>>>>>> twitter: @subash89 >>>>>>>>>>>> phone: +9477 2225922 >>>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Dimuthu Leelarathne >>>>>>>>>>> Architect & Product Lead of App Factory >>>>>>>>>>> >>>>>>>>>>> WSO2, Inc. (http://wso2.com) >>>>>>>>>>> email: [email protected] >>>>>>>>>>> Mobile : 0773661935 >>>>>>>>>>> >>>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Dimuthu Leelarathne >>>>>>>>>> Architect & Product Lead of App Factory >>>>>>>>>> >>>>>>>>>> WSO2, Inc. (http://wso2.com) >>>>>>>>>> email: [email protected] >>>>>>>>>> Mobile : 0773661935 >>>>>>>>>> >>>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Sanjiva Weerawarana, Ph.D. >>>>>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >>>>>>>>> email: [email protected]; office: (+1 650 745 4499 | +94 11 214 >>>>>>>>> 5345) x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 >>>>>>>>> 650 265 8311 >>>>>>>>> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva >>>>>>>>> Lean . Enterprise . Middleware >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* >>>>>>>> Software Architect; WSO2 Inc.; http://wso2.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> * Member; Apache Software Foundation; http://apache.org >>>>>>>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: >>>>>>>> +1 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >>>>>>>> >>>>>>>> >>>>>>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In: >>>>>>>> http://linkedin.com/in/senakafernando >>>>>>>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . >>>>>>>> Middleware >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thanks >>>>>>> /subash >>>>>>> >>>>>>> *Subash Chaturanga* >>>>>>> Senior Software Engineer & Lead WSO2 Governance Registry >>>>>>> Platform TG; WSO2 Inc. http://wso2.com >>>>>>> Contact: >>>>>>> email: [email protected] >>>>>>> blog: http://subashsdm.blogspot.com/ >>>>>>> twitter: @subash89 >>>>>>> phone: +9477 2225922 >>>>>>> Lean . Enterprise . Middleware >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Thanks >>>>>> /subash >>>>>> >>>>>> *Subash Chaturanga* >>>>>> Senior Software Engineer & Lead WSO2 Governance Registry >>>>>> Platform TG; WSO2 Inc. http://wso2.com >>>>>> Contact: >>>>>> email: [email protected] >>>>>> blog: http://subashsdm.blogspot.com/ >>>>>> twitter: @subash89 >>>>>> phone: +9477 2225922 >>>>>> Lean . Enterprise . Middleware >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks >>>>> /subash >>>>> >>>>> *Subash Chaturanga* >>>>> Senior Software Engineer & Lead WSO2 Governance Registry >>>>> Platform TG; WSO2 Inc. http://wso2.com >>>>> Contact: >>>>> email: [email protected] >>>>> blog: http://subashsdm.blogspot.com/ >>>>> twitter: @subash89 >>>>> phone: +9477 2225922 >>>>> Lean . Enterprise . Middleware >>>>> >>>> >>>> >>>> >>>> -- >>>> Dimuthu Leelarathne >>>> Architect & Product Lead of App Factory >>>> >>>> WSO2, Inc. (http://wso2.com) >>>> email: [email protected] >>>> Mobile : 0773661935 >>>> >>>> Lean . Enterprise . Middleware >>>> >>> >>> >>> >>> -- >>> Thanks >>> /subash >>> >>> *Subash Chaturanga* >>> Senior Software Engineer & Lead WSO2 Governance Registry >>> Platform TG; WSO2 Inc. http://wso2.com >>> Contact: >>> email: [email protected] >>> blog: http://subashsdm.blogspot.com/ >>> twitter: @subash89 >>> phone: +9477 2225922 >>> Lean . Enterprise . Middleware >>> >> >> >> >> -- >> Thanks >> /subash >> >> *Subash Chaturanga* >> Senior Software Engineer & Lead WSO2 Governance Registry >> Platform TG; WSO2 Inc. http://wso2.com >> Contact: >> email: [email protected] >> blog: http://subashsdm.blogspot.com/ >> twitter: @subash89 >> phone: +9477 2225922 >> Lean . Enterprise . Middleware >> > > > > -- > Dimuthu Leelarathne > Architect & Product Lead of App Factory > > WSO2, Inc. (http://wso2.com) > email: [email protected] > Mobile : 0773661935 > > Lean . Enterprise . Middleware > -- Dimuthu Leelarathne Architect & Product Lead of App Factory WSO2, Inc. (http://wso2.com) email: [email protected] Mobile : 0773661935 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
