Hi Subash,
Thanks. We will not be taking this up yet.
thanks,
dimuthu
On Thu, Sep 4, 2014 at 6:10 PM, Subash Chaturanga <sub...@wso2.com> 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 <sub...@wso2.com> wrote:
>
>> Hi,
>> Moving to @architecture.
>>
>>
>> On Fri, Aug 29, 2014 at 3:47 AM, Subash Chaturanga <sub...@wso2.com>
>> 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 <sen...@wso2.com>
>>> 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 <sanj...@wso2.com>
>>>> 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 <
>>>>> dimut...@wso2.com> 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 <
>>>>>> dimut...@wso2.com> 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 <sub...@wso2.com>
>>>>>>> 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 <
>>>>>>>> dimut...@wso2.com> wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Please see my comments in line.
>>>>>>>>>
>>>>>>>>> On Sun, Aug 17, 2014 at 3:32 PM, Sanjiva Weerawarana <
>>>>>>>>> sanj...@wso2.com> 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 <
>>>>>>>>>> dimut...@wso2.com> 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 <
>>>>>>>>>>> sen...@wso2.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Aug 15, 2014 at 6:27 AM, Sagara Gunathunga <
>>>>>>>>>>>> sag...@wso2.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Aug 14, 2014 at 4:34 AM, Dimuthu Leelarathne <
>>>>>>>>>>>>> dimut...@wso2.com> 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 <
>>>>>>>>>>>>>> ruch...@wso2.com> 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 <
>>>>>>>>>>>>>>> sen...@wso2.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Subash,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Please find comments in-line.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Tue, Aug 12, 2014 at 7:16 PM, Janaka Ranabahu <
>>>>>>>>>>>>>>>> jan...@wso2.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Subash,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Tue, Aug 12, 2014 at 11:12 PM, Subash Chaturanga <
>>>>>>>>>>>>>>>>> sub...@wso2.com> 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: sub...@wso2.com
>>>>>>>>>>>>>>>>>> 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: jan...@wso2.com <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: ruch...@wso2.com <ruch...@wso2.com>, 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: dimut...@wso2.com
>>>>>>>>>>>>>> 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: dimut...@wso2.com
>>>>>>>>>>> Mobile : 0773661935
>>>>>>>>>>>
>>>>>>>>>>> Lean . Enterprise . Middleware
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Sanjiva Weerawarana, Ph.D.
>>>>>>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
>>>>>>>>>> email: sanj...@wso2.com; 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: dimut...@wso2.com
>>>>>>>>> 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: sub...@wso2.com
>>>>>>>> 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: dimut...@wso2.com
>>>>>>> Mobile : 0773661935
>>>>>>>
>>>>>>> Lean . Enterprise . Middleware
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Dimuthu Leelarathne
>>>>>> Architect & Product Lead of App Factory
>>>>>>
>>>>>> WSO2, Inc. (http://wso2.com)
>>>>>> email: dimut...@wso2.com
>>>>>> Mobile : 0773661935
>>>>>>
>>>>>> Lean . Enterprise . Middleware
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sanjiva Weerawarana, Ph.D.
>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
>>>>> email: sanj...@wso2.com; 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: sub...@wso2.com
>>> 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: sub...@wso2.com
>> 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: sub...@wso2.com
> 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: dimut...@wso2.com
Mobile : 0773661935
Lean . Enterprise . Middleware
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
