@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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
