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