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