Re: [Architecture] [APIM] [New Feature] Replacement for NFS to share throttle policies in a multi traffic manager deployment
On Wed, Oct 14, 2020 at 4:03 AM Chamod Samarajeewa wrote: > Hi all, > > In a multiple Traffic Manager(TM) setup of WSO2 APIM, the users have to > use a file-sharing system (NFS) to sync the throttle policies between TM > nodes. This is needed because during a creation/updating/removal of policy, > only a single TM will be called via an Admin service to deploy the > execution plan. In order to maintain the consistency between TM nodes, a > file-sharing mechanism is required in this case. > > To avoid the usage of a file-sharing approach, we are going to introduce a > new approach as below to synchronize the TM nodes. > > [image: throttle-policy-deployer.jpg] > > >- Add a new JMS listener to the TM component to trigger on >POLICY_CREATE, POLICY_UPDATE, POLICY_DELETE events (These events are >already available for the purpose of Gateway functionalities) >- Add/Edit the internal REST APIs to retrieve the policy metadata >(sufficient enough to build the policy using the templates) from the >database >- Move the policy templates to the TM >- Inside the newly added JMS listener, the internal REST APIs will be >called to retrieve the policy metadata and use the policy templates to >build the execution plan. >- Then, the execution plan will be deployed calling the >EventProcessorAdminService directly > > > This should be a good feature to have for TM HA deployments, IMO the approach is pretty much similar to how other event base improvements made at APIM 3.2.0. Anyway a few quick question; 1. What is this internal *REST APIs (Event Hub)*? Is that something to be part of the internal implementation of the APIM admin? or an external component? if Internal EvenHub to be part of (Admin Node), you may have to correct the scope, boundaries to represent this in a way to adhere to the architectural representation. 2. Other than that, I would assume the existing PolicyDeployer configuration (api-manager.xml), maybe deprecate with the internal PolicyDeployer DB references, correct me if I'm wrong! 3. Also, with this change, *it would be mandatory to have DB sharing between the Admin Node and the TM nodes*, isn't it? Or Admin node pushes the policy changes with meta-data and the context to the EventHub (internal representation in memory) then, JMSListners at TM pull this information, what are failover situations? 4. Will there be any potential changes with APIM Admin HA mode? > With the above-mentioned approach, file sharing will no longer be required > between TM nodes since the policy details are pulled from the database and > deployed upon a change to them. > > Please share your thoughts. Thank you. > > Best regards, > Chamod. > > -- > *Chamod Samarajeewa* > Software Engineer - WSO2 > > Email - cha...@wso2.com > Mobile - +94710397382 > > > _______ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Cheers, *Dushan Abeyruwan *| Solutions Architect | WSO2 Inc. (c) 408-987-1348 | (e) dus...@wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Making self-contained access tokens the default in APIM 3.0
the Microgateway to address >>>>> this. The Key Manager will be notifying the gateway cluster through a >>>>> broker when a token has been revoked. And the gateway will no longer be >>>>> treating the particular token as valid upon receiving the notification. >>>>> >>>>> Appreciate your thoughts and suggestions on this. >>>>> >>>> >>>> So we are making it as default to increase the usage of it ? >>>> >>>> Is this would be same for developer token in store (application >>>> tokens)? >>>> What are the default user details which are adding to self-contains >>>> access token ? >>>> >>>> Thanks, >>>> Asela. >>>> >>>> >>>>> >>>>> Thanks, >>>>> NuwanD. >>>>> -- >>>>> *Nuwan Dias* | Director | WSO2 Inc. >>>>> (m) +94 777 775 729 | (e) nuw...@wso2.com >>>>> [image: Signature.jpg] >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>> >>>> >>>> -- >>>> Thanks & Regards, >>>> Asela >>>> >>>> Mobile : +94 777 625 933 >>>> >>>> http://soasecurity.org/ >>>> http://xacmlinfo.org/ >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>> >>> >>> -- >>> *Manjula Rathnayaka* | Senior Technical Lead | WSO2 Inc. >>> (m) +94 77 743 1987 | (w) +94 11 214 5345 | (e) manju...@wso2.com >>> GET INTEGRATION AGILE >>> Integration Agility for Digitally Driven Business >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >> -- >> *Nuwan Dias* | Director | WSO2 Inc. >> (m) +94 777 775 729 | (e) nuw...@wso2.com >> [image: Signature.jpg] >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Dushan Abeyruwan Director - Support WSO2 Certified Solution Engineer Technical Support,Mountain View, USA PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* LinkedIn:*https://www.linkedin.com/in/dushanabeyruwan <https://www.linkedin.com/in/dushanabeyruwan>* Mobile:(001)408-987-1348 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Migration approach for APIM 2.6.0 to 3.0.0
> >>>>>>Pros >>>>>>- >>>>>> >>>>>> Migration story can be done in single step. (Exporting and >>>>>> importing can be done in single command.) >>>>>> - >>>>>> >>>>>> API/Application import-export tool won’t have any effect or >>>>>> change. >>>>>> - >>>>>> >>>>>> Don’t have to manage 2 separate use cases in single tool. >>>>>> - >>>>>> >>>>>>Cons >>>>>>- >>>>>> >>>>>> Will have to develop/maintain a Web app and/or CLI tool from >>>>>> the scratch >>>>>> >>>>>> >>>>>> >>>>>> Importing : >>>>>> >>>>>> >>>>>>- >>>>>> >>>>>>Has to create separate REST APIs for importing 2.6-exported >>>>>>APIs/Applications/other artifacts as 3.0.0 expecting archives in 3.0 >>>>>>specific format. >>>>>> >>>>>> >>>>>> Approach 1 >>>>>> >>>>>>- >>>>>> >>>>>>Change/improve API Import/export CLI tool in 3.0 to support >>>>>>importing 2.6-exported API/application archives. >>>>>> >>>>>> Approach 2 >>>>>> >>>>>>- >>>>>> >>>>>>Develop separate CLI tool from the scratch which will be used for >>>>>>exporting from 2.6 also >>>>>> >>>>>> >>>>>> >>>>>> Other artifacts required to be exported/imported (other than >>>>>> APIs/Applications) >>>>>> >>>>>> >>>>>>- >>>>>> >>>>>>Throttling Policies >>>>>>- >>>>>> >>>>>>Custom API Lifecycles >>>>>>- >>>>>> >>>>>>Workflows >>>>>>- >>>>>> >>>>>>User Role Permissions >>>>>>- >>>>>> >>>>>>Custom sequences (at least for reference -> has to decide >>>>>>regarding this) >>>>>> >>>>>> >>>>>> >>>>>> My perception is that proceeding with Approach 2 under both exporting >>>>>> and importing would be better considering the pros and cons of each. >>>>>> >>>>>> Highly appreciate your thoughts on this. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Samitha >>>>>> >>>>>> >>>>>> -- >>>>>> *Samitha Chathuranga* >>>>>> *Senior Software Engineer*, *WSO2 Inc.* >>>>>> lean.enterprise.middleware >>>>>> Mobile: +94715123761 >>>>>> >>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Nuwan Dias >>>> >>>> Director - WSO2, Inc. http://wso2.com >>>> email : nuw...@wso2.com >>>> Phone : +94 777 775 729 >>>> >>> >>> >>> >>> -- >>> *Samitha Chathuranga* >>> *Senior Software Engineer*, *WSO2 Inc.* >>> lean.enterprise.middleware >>> Mobile: +94715123761 >>> >>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>> >> >> >> -- >> *Samitha Chathuranga* >> *Senior Software Engineer*, *WSO2 Inc.* >> lean.enterprise.middleware >> Mobile: +94715123761 >> >> [image: http://wso2.com/signature] <http://wso2.com/signature> >> > > > -- > *Samitha Chathuranga* > *Senior Software Engineer*, *WSO2 Inc.* > lean.enterprise.middleware > Mobile: +94715123761 > > [image: http://wso2.com/signature] <http://wso2.com/signature> > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan Architect(Associate Director)-Delivery/Support Technical Support,MV PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* LinkedIn:*https://www.linkedin.com/in/dushanabeyruwan <https://www.linkedin.com/in/dushanabeyruwan>* Mobile:(001)408-987-1348 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [IS] SAML SSO Agent for .NET
Hi Chiran, Interesting work, please do come up with a documentation for the implementation you have done (i.e working sample illustration with images, the README.txt for the git project). I need to visualize the complete agent integration stepwise. I had looked the repo. I believe once the agent installed to the .net web application we may need to install the agent.dll then we may need to complete following[1] I used to work with the [2] for some demos, however, just need to understand the differences between the Componentspace [2] vs the agent feature that we are offering [1] http://localhost:49763/ sample/callback"/> [2] https://www.componentspace.com/ Cheers, Dushan On Sun, Jan 21, 2018 at 10:22 PM, Chiran Wijesekara wrote: > Architecture diagram is attached below. It's not showing up in the > original Email due to an issue with the format. > > > On Mon, Jan 22, 2018 at 10:56 AM, Chiran Wijesekara > wrote: > >> >> *Introduction:* >> >> Suppose someone has an ASP.NET web application or else he/she is going >> to create a new one. One of your major concerns would be to provide a >> secure mechanism for handling user authentication and authorization. >> >> With the introduction of this SAML Agent, you can easily incorporate this >> agent into your ASP.NET web application and it will take care of all the >> things related to SAML authentication mechanism. >> >> *Solution Architecture:* >> >> >> *Note: 2,7,8,3 of the above diagram denotes the resolving of the current >> request of interest.* >> >> The above diagram depicts the architecture for the .NET SAML agent. The >> agent is designed in such a way that all the requests that are coming to >> the ASP.NET web application will be directed to the *FilteringHttpModule*. >> This *FilteringHttpModule* is a class that implements the *IHttpModule >> *interface >> (i.e. a custom HTTP handler). And this *FilteringHttpModule* is >> responsible for handling the SAML authentication related request. It will >> call the relevant method of *SAMLManager *class to process the request. >> >> *How to incorporate Agent into a given ASP.NET <http://ASP.NET> web >> application:* >> >> This agent is developed in a way such that it has minimum possible >> dependencies on the ASP.NET web application. Hence, when someone wants >> to incorporate SAML authentication into his/her ASp.NET web app, that could >> be done with a minimum effort. >> >> Following is the list of items to configure SAML Agent for a given >> ASP.NET web application. >> >> The process of incorporating *SAML authentication with wso2 identity >> server* via SAML agent can be explained in few steps as follows. >> >>1. >> >>*Add* - the agent.dll reference to your Asp.NET web application(You >>can get this via NuGet package manager or else from the git repo) >>2. >> >>*Configure* - the mandatory properties in your ASP.NET web >>application’s web.config file. Furthermore, you have to get the .jks from >>the wso2 Identity Server you are using and convert it to a *pkcs* >>using keytool.(Or else use your own pkcs12). Add the .pfx / .p12 to the >>Local Machine Certificate Store. >>3. >> >>*Register* - the “FilteringHttpModule” in your ASP.NET web >>application to handle the requests related to SAML authentication >> mechanism. >>4. >> >>*Set* - your application’s login controls to refer SAML intensive >>segments. That is, suppose you have a login link in your web application. >>All you have to do is set the attribute, href = “/samlsso”. >> >> >> >> Link to the Repo: https://github.com/chirankavin >> da123/saml-sso-agent-DOT-NET >> <https://github.com/chirankavinda123/saml-sso-agent-DOT-NET> >> Any suggestion/recommendation to improve this agent's architecture would >> be much appreciated. >> >> Thank you. >> -- >> *Chiran Wijesekara* >> >> >> *Software Engineering Intern | WSO2*Email: chir...@wso2.com >> Mobile: +94712990173web: www.wso2.com >> >> [image: https://wso2.com/signature] <https://wso2.com/signature> >> > > > > -- > *Chiran Wijesekara* > > > *Software Engineering Intern | WSO2*Email: chir...@wso2.com > Mobile: +94712990173web: www.wso2.com > > [image: https://wso2.com/signature] <https://wso2.com/signature> > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Architect Technical Support,MV PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* LinkedIn:*https://www.linkedin.com/in/dushanabeyruwan <https://www.linkedin.com/in/dushanabeyruwan>* Mobile:(001)408-791-9312 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [RRT] Improving caching based on cache-control and ETag headers
>>>>>>>>> need to be issued with the "If-None-Match" header(with ETag value) >>>>>>>>> and if >>>>>>>>> the requested resource is modified from the last response fetched >>>>>>>>> time, a >>>>>>>>> new modified response will be returned with new ETag. And this new >>>>>>>>> response >>>>>>>>> needs to be cached. If it is not modified, the server returns a "304 >>>>>>>>> Not >>>>>>>>> Modified" response. In that case, the cached response can be reused. >>>>>>>>> >>>>>>>>> Flow: >>>>>>>>> >>>>>>>>>- Cache mediator receives a request. >>>>>>>>>- Check whether a cached response is available for the same >>>>>>>>>request. >>>>>>>>>- If it is available and ETag is present in the cached >>>>>>>>>response, make a request with "If-None-Match" header with the ETag >>>>>>>>> value. >>>>>>>>>- If the server returns "304 Not Modified" response returns >>>>>>>>>the cached response to the user. >>>>>>>>>- If the server returns a new modified response(200 OK >>>>>>>>>response) then cache the newly returned response. >>>>>>>>> >>>>>>>>> >>>>>>>>> *2. Honor "no-cache" and "no-store" header* >>>>>>>>> >>>>>>>>>- If the "no-cache" header is present in the response it >>>>>>>>>indicates that the returned response can’t be used to satisfy a >>>>>>>>> subsequent >>>>>>>>>request to the same URL without first checking with the server if >>>>>>>>> the >>>>>>>>>response has changed. So before responding with the cached >>>>>>>>> response cache >>>>>>>>>mediator should validate the response with ETag. This can be >>>>>>>>> supported >>>>>>>>>through the ETag support. >>>>>>>>>- If the "no-store" header is present in the response, Cache >>>>>>>>>mediator should not cache the returned response. >>>>>>>>> >>>>>>>>> *3. Honor "max-age" cache-control header* >>>>>>>>> If the "max-age" header presents in the response it specifies the >>>>>>>>> maximum time in seconds that the fetched response is allowed to be >>>>>>>>> reused >>>>>>>>> from the time of the request. So the response should be cached and >>>>>>>>> reused >>>>>>>>> within the max-age time limit. So the Cache mediator should honor >>>>>>>>> max-age >>>>>>>>> instead of timeout configuration if it is less than the timeout >>>>>>>>> configuration. >>>>>>>>> >>>>>>>>> 4. *Include an ‘Age’ header with the response* >>>>>>>>> Cache mediator should return the true TTL value of a response >>>>>>>>> without altering the value of the cache-control max-age header >>>>>>>>> returned by >>>>>>>>> the back-end. >>>>>>>>> >>>>>>>>> >>>>>>>>> Flow: >>>>>>>>> >>>>>>>>>- Calculate the TTL using response fetched time and max-age >>>>>>>>>header >>>>>>>>>- Set the Age header to the cached response before returning >>>>>>>>>it to the user. >>>>>>>>> >>>>>>>>> >>>>>>>>> [1]. https://developers.google.com/web/fundamentals/performa >>>>>>>>> nce/optimizing-content-efficiency/http-caching >>>>>>>>> [2]. https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Keerthika. >>>>>>>>> -- >>>>>>>>> >>>>>>>>> Keerthika Mahendralingam >>>>>>>>> Software Engineer >>>>>>>>> Mobile :+94 (0) 776 121144 <+94%2077%20612%201144> >>>>>>>>> keerth...@wso2.com >>>>>>>>> WSO2, Inc. >>>>>>>>> lean . enterprise . middleware >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Shazni Nazeer >>>>>>>> >>>>>>>> Mob : +94 37331 >>>>>>>> LinkedIn : http://lk.linkedin.com/in/shazninazeer >>>>>>>> >>>>>>>> Blogs : >>>>>>>> >>>>>>>> https://medium.com/@mshazninazeer >>>>>>>> http://shazninazeer.blogspot.com >>>>>>>> >>>>>>>> <http://wso2.com/signature> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Keerthika Mahendralingam >>>>>>> Software Engineer >>>>>>> Mobile :+94 (0) 776 121144 <+94%2077%20612%201144> >>>>>>> keerth...@wso2.com >>>>>>> WSO2, Inc. >>>>>>> lean . enterprise . middleware >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Isuru Udana* >>>>>> Senior Technical Lead >>>>>> WSO2 Inc.; http://wso2.com >>>>>> email: isu...@wso2.com cell: +94 77 3791887 <077%20379%201887> >>>>>> blog: http://mytecheye.blogspot.com/ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Sanjeewa Malalgoda* >>>>> WSO2 Inc. >>>>> Mobile : +94713068779 <+94%2071%20306%208779> >>>>> >>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Vijitha Ekanayake >>>> Senior Software Engineer*, *WSO2, Inc.; http://wso2.com/ >>>> Mobile : +94 777 24 73 39 | +94 718 74 44 08 >>>> lean.enterprise.middleware >>>> >>> >>> >>> >>> -- >>> >>> Keerthika Mahendralingam >>> Software Engineer >>> Mobile :+94 (0) 776 121144 <+94%2077%20612%201144> >>> keerth...@wso2.com >>> WSO2, Inc. >>> lean . enterprise . middleware >>> >> >> >> >> -- >> Riyafa Abdul Hameed >> Software Engineer, WSO2 Lanka (Pvt) Ltd <http://wso2.com/> >> >> Email: riy...@wso2.com >> Website: https://riyafa.wordpress.com/ <http://riyafa.wordpress.com/> >> <http://facebook.com/riyafa.ahf> <http://lk.linkedin.com/in/riyafa> >> <http://twitter.com/Riyafa1> >> > > > > -- > > Keerthika Mahendralingam > Software Engineer > Mobile :+94 (0) 776 121144 <+94%2077%20612%201144> > keerth...@wso2.com > WSO2, Inc. > lean . enterprise . middleware > -- Dushan Abeyruwan | Architect Technical Support,MV PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* LinkedIn:*https://www.linkedin.com/in/dushanabeyruwan <https://www.linkedin.com/in/dushanabeyruwan>* Mobile:(001)408-791-9312 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [RRT] XML, JSON, Shema validation threat protectors in APIM 2.1.x
Hi Dimuthu,
Understood, thanks for the prompted response
Cheers,
Dushan
On Tue, Jan 16, 2018 at 5:12 AM, Dimuthu Leelarathne
wrote:
> Hi Dushan,
>
> It is an optional mediator. We haven't touched the core (not a single line)
>
> We will provide the performance results on Monday.
>
> thanks,
> Dimuthu
>
>
> On Mon, Jan 15, 2018 at 10:26 PM, Dushan Abeyruwan
> wrote:
>
>> Hi
>> Pls provide the diff of the changes you have done.
>>
>> @ESB Team / PPT experts, since there are PPT level changes you need keep
>> watch on performance impact, memory blueprint impact, how the heap usage
>> varies per message size since (smallest to the largest) + per how the
>> behavior for complex interaction which has clone/iterators etc etc.
>>
>> Cheers,
>> Dushan
>>
>> On Tue, Jan 9, 2018 at 9:38 AM, Hasunie Adikari wrote:
>>
>>> Hi all,
>>>
>>> As I discussed with Isuru, There are some possible approaches to
>>> overcome the issue.
>>>
>>> 1. Create a new pass through pipe.
>>>- The data will be written to the pipe by a spawned thread and
>>> current thread will be consuming the data and continuing the message flow.
>>> We went through the pipe creation logic and seemed it tightly coupled with
>>> encoding, decoding methodologies so that it can't be
>>> implemented at APIM level.
>>>
>>> 2. Change the synapse level logic to get the ByteArrayInputstream and
>>> write it into the response.
>>>- It can be but have to thoroughly go through and do it carefully
>>> unless the default message flow would be affected.
>>>
>>> 3. Build the message by invoking RelayUtils.buildMessage() at the
>>> validator mediator after successfully parsing all the validators.
>>> - It will be slightly affected the performance but this is the
>>> straightforward solution at this moment.
>>>
>>> I have improved the code by applying the 3rd option as we discussed.
>>> Setting the PassThroughConstants.BUFFERED_INPUT_STREAM has an effect
>>> now onwards since we changed a way that building the message to achieve the
>>> content aware behavior which seeks the
>>> inputream from the axis2 message context instead of the original
>>> inputstream.
>>>
>>>
>>> Regards
>>> Hasunie
>>>
>>>
>>>
>>> On Tue, Jan 9, 2018 at 4:41 PM, Isuru Udana wrote:
>>>
>>>> Hi Hasunie,
>>>>
>>>> As we discussed, setting the PassThroughConstants.BUFFERED_INPUT_STREAM
>>>> has no effect on the flow in this case and Passthough Sender still seek
>>>> content from the original input stream which got empty due to this cloning
>>>> logic. That's the reason for this behaviour.
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>>> On Tue, Jan 9, 2018 at 11:43 AM, Hasunie Adikari
>>>> wrote:
>>>>
>>>>> Hi Isuru,
>>>>>
>>>>> As we discussed, I cloned the input stream by consuming the
>>>>> passthrough pipe as in below.
>>>>>
>>>>>
>>>>> if (pipe != null) {
>>>>> bufferedInputStream = new BufferedInputStream(pipe.getIn
>>>>> putStream());
>>>>>
>>>>> }
>>>>> ByteArrayOutputStream byteArrayOutputStream = new
>>>>> ByteArrayOutputStream();
>>>>> byte[] buffer = new byte[1024];
>>>>> int len;
>>>>> while ((len = bufferedInputStream.read(buffer)) > -1 ) {
>>>>> byteArrayOutputStream.write(buffer, 0, len);
>>>>> }
>>>>> byteArrayOutputStream.flush();
>>>>>
>>>>>
>>>>> InputStream is1 = new ByteArrayInputStream(byteArray
>>>>> OutputStream.toByteArray());
>>>>> InputStream is2 = new ByteArrayInputStream(byteArray
>>>>> OutputStream.toByteArray());
>>>>>
>>>>> consume the clones for the validation and set another clone as a
>>>>> buffereInputstream property in the axis2messagecontext.
>>>>>
>>>>> BufferedInputStream bufferedInputStreamOriginal = new
>>>>> BufferedInputStream(inputStreamOriginal);
>>>>> axis2MC.setProperty(PassThroughConstants.BUFFERED_INPUT_STREAM,
>>>>> bufferedInputStreamOriginal);
>>>>>
>>>>> I'm
Re: [Architecture] [RRT] XML, JSON, Shema validation threat protectors in APIM 2.1.x
Hi
Pls provide the diff of the changes you have done.
@ESB Team / PPT experts, since there are PPT level changes you need keep
watch on performance impact, memory blueprint impact, how the heap usage
varies per message size since (smallest to the largest) + per how the
behavior for complex interaction which has clone/iterators etc etc.
Cheers,
Dushan
On Tue, Jan 9, 2018 at 9:38 AM, Hasunie Adikari wrote:
> Hi all,
>
> As I discussed with Isuru, There are some possible approaches to overcome
> the issue.
>
> 1. Create a new pass through pipe.
>- The data will be written to the pipe by a spawned thread and current
> thread will be consuming the data and continuing the message flow. We went
> through the pipe creation logic and seemed it tightly coupled with
> encoding, decoding methodologies so that it can't be
> implemented at APIM level.
>
> 2. Change the synapse level logic to get the ByteArrayInputstream and
> write it into the response.
>- It can be but have to thoroughly go through and do it carefully
> unless the default message flow would be affected.
>
> 3. Build the message by invoking RelayUtils.buildMessage() at the
> validator mediator after successfully parsing all the validators.
> - It will be slightly affected the performance but this is the
> straightforward solution at this moment.
>
> I have improved the code by applying the 3rd option as we discussed.
> Setting the PassThroughConstants.BUFFERED_INPUT_STREAM has an effect now
> onwards since we changed a way that building the message to achieve the
> content aware behavior which seeks the
> inputream from the axis2 message context instead of the original
> inputstream.
>
>
> Regards
> Hasunie
>
>
>
> On Tue, Jan 9, 2018 at 4:41 PM, Isuru Udana wrote:
>
>> Hi Hasunie,
>>
>> As we discussed, setting the PassThroughConstants.BUFFERED_INPUT_STREAM
>> has no effect on the flow in this case and Passthough Sender still seek
>> content from the original input stream which got empty due to this cloning
>> logic. That's the reason for this behaviour.
>>
>> Thanks.
>>
>>
>>
>> On Tue, Jan 9, 2018 at 11:43 AM, Hasunie Adikari
>> wrote:
>>
>>> Hi Isuru,
>>>
>>> As we discussed, I cloned the input stream by consuming the passthrough
>>> pipe as in below.
>>>
>>>
>>> if (pipe != null) {
>>> bufferedInputStream = new BufferedInputStream(pipe.getIn
>>> putStream());
>>>
>>> }
>>> ByteArrayOutputStream byteArrayOutputStream = new
>>> ByteArrayOutputStream();
>>> byte[] buffer = new byte[1024];
>>> int len;
>>> while ((len = bufferedInputStream.read(buffer)) > -1 ) {
>>> byteArrayOutputStream.write(buffer, 0, len);
>>> }
>>> byteArrayOutputStream.flush();
>>>
>>>
>>> InputStream is1 = new ByteArrayInputStream(byteArray
>>> OutputStream.toByteArray());
>>> InputStream is2 = new ByteArrayInputStream(byteArray
>>> OutputStream.toByteArray());
>>>
>>> consume the clones for the validation and set another clone as a
>>> buffereInputstream property in the axis2messagecontext.
>>>
>>> BufferedInputStream bufferedInputStreamOriginal = new
>>> BufferedInputStream(inputStreamOriginal);
>>> axis2MC.setProperty(PassThroughConstants.BUFFERED_INPUT_STREAM,
>>> bufferedInputStreamOriginal);
>>>
>>> I'm still getting the stream closed issue only for correct the messages
>>> which have been passed through multiple validators. If the validators throw
>>> an exception, the request is getting build and generate the custom response
>>> as expected. It seems like we implemented a way that gets the
>>> inputstream from the passthrough pipe for the content unaware flows.
>>> Unless it uses to get the inputstream from the messagecontext. It was
>>> proven once I attached an empty content aware mediator and test the
>>> same flow. I was able to observe the expected behaviour for the same
>>> implementation with the content aware mediator.
>>>
>>> Do we have a way to define cloned input stream as an original
>>> inputstream in passthrough pipe?
>>>
>>>
>>> Regards
>>> Hasunie
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Jan 3, 2018 at 9:21 AM, Isuru Udana wrote:
>>>
>>>> Hi Dushan,
>>>>
>>>> On Wed, Jan 3, 2018 at 9:06 AM, Dushan Abeyruwan
>>>> wrote:
>&
Re: [Architecture] [RRT] XML, JSON, Shema validation threat protectors in APIM 2.1.x
> works properly. I went through the RelayUtil message builders [2] and It >>> also uses the mark and reset methodology and return InputStream. >>> >>> >>> I observed another issue once the validator throws an exception, the >>> server hanged and didn't get any response and getting timeout issue. I was >>> able to figure it out and Issue occurred while trying to build the request >>> message in Relayutil.buildmessage().But Ideally, If we get an error we >>> don't need the request message anymore. As I discussed offline with the >>> APIM team, I used the *consumeAndDiscardMessage* method to discard the >>> request message from the message context and set *message.builder.invoked >>> *property to *TRUE. *It needs to be set to avoid sending the content in >>> pass-through pipe (request message) as the response. >>> >>> >>> [1] https://docs.wso2.com/display/AM210/Regular+Expression+T >>> hreat+Protection+for+API+Gateway >>> [2] https://github.com/wso2/wso2-synapse/blob/master/modules >>> /transports/core/nhttp/src/main/java/org/apache/synapse/tran >>> sport/passthru/util/RelayUtils.java#L121 >>> >>> >>> Regards >>> Hasunie >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> *Hasunie Adikari* >>> Senior Software Engineer >>> WSO2 Inc.; http://wso2.com >>> lean.enterprise.middleware >>> blog http://hasuniea.blogspot.com | https://medium.com/@Hasunie/ >>> Mobile:+94713095876 <+94%2071%20309%205876> >>> >>> >> >> >> -- >> *Hasunie Adikari* >> Senior Software Engineer >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> blog http://hasuniea.blogspot.com | https://medium.com/@Hasunie/ >> Mobile:+94713095876 <+94%2071%20309%205876> >> >> > > > -- > Vinod Kavinda > Senior Software Engineer > *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.* > Mobile : +94 (0) 712 415544 > Blog : http://soatechflicks.blogspot.com/ > [image: http://wso2.com/signature] > <http://wso2.com/signature> > > -- Dushan Abeyruwan | Architect Technical Support,MV PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* LinkedIn:*https://www.linkedin.com/in/dushanabeyruwan <https://www.linkedin.com/in/dushanabeyruwan>* Mobile:(001)408-791-9312 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] REST API for resending confirmation code in account recovery and self registration scenarios
On Mon, Dec 4, 2017 at 6:54 AM, Indunil Upeksha Rathnayake wrote: > Hi, > > With IS 5.3.0, we have currently provided a Rest API for resending > confirmation code (Refer [1]), which supports only for self signup feature. > So that, we are planning to provide a more generic REST API and a OSGi > service, for resending confirmation code for any scenario. > > > > Following are the scenarios, currently where we are sending confirmation > emails in IS. > >- *Password Reset* - password recovery using email-based notifications >- *Account Confirmation* - email confirmation on user self registration >- *Ask Password* - ask password from user through confirmation email >- *Admin Forced Password Reset*- admin to trigger a password reset for >a given user account >- *Admin Forced Password Reset With OTP* - admin send an email to the >user with a one time password that the user can use to login once to the >account after which, the user will be prompted to set a new password >- *Email Confirmation *- account confirmation through email >notification > > In there, the confirmation emails get expired after a configured time > period in order to make the accounts secure. After the expiration, we may > need to resend the confirmation emails. > > So with this implementation, when we request for resending confirmation > code, previously issued code (even though, it's still not expired), should > get expired and the new confirmation code should considered as active. So > that in any scenario, if a user is requesting to use an expired > confirmation code, we need to redirect the user, to an error page > mentioning of using an expired confirmation link. > > In case of user self registration, if request has made for resending > confirmation link, after a account activation, I think it should be handled > in the self registration API (currently Re-Send button to resend the > confirmation link will be appeared in the login page, when we try to login > to an unverified account). We may not need to consider it, when resending > the confirmation code. WDYT? > So, generally, when resendingm it should verify the user email address isn't that the case case here? genreally, you will not re-send confirmation code for unverified accounts > > > > Other than that, I think we can consider following scenarios as further > improvements. WDYT? > >- In case of a forgery, we may need to expire the confirmation link, >manually before the configured time (without resending the confirmation >link). > > How to filter out the facts? you mean managing UI per inactive confirmation links? then selectivly disabling? Anyway, yeah this looks to be a good initiate to have anyway. > >- >- Currently for resending confirmation email for user self >registration, we have provided support in the login page where user can >request to resend confirmation link (We have not added this to the >documentation, created a doc jira in [2]). In order to resend the >confirmation emails from admin (or user with a required permissions), we >can provide support in management console to : > > +1 > >- select the user(s) to whom need to resend the activation email > > users/s how many users at once? don't you think it may get complicate when user store is large and if the selection get larger > >- select a role, to send confirmation emails to a group of users - > here we may need to automatically skip over users who have already > activated there accounts in case of self registration > > would appropriate to send email to a user group rather a indvidual IMO or may be users who are in certain group as you have specified, that may more praticle (I'm thinking larger user store) > > > > >- > > > > Appreciate your ideas and comments on this. > > [1] https://github.com/wso2-extensions/identity-governance/blob/master/ > components/org.wso2.carbon.identity.user.endpoint/src/ > main/java/org/wso2/carbon/identity/user/endpoint/impl/ > ResendCodeApiServiceImpl.java > [2] https://wso2.org/jira/browse/DOCUMENTATION-7189 > > Thanks and Regards > > -- > Indunil Upeksha Rathnayake > Software Engineer | WSO2 Inc > Emailindu...@wso2.com > Mobile 0772182255 > > -- > You received this message because you are subscribed to the Google Groups > "WSO2 Documentation Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to documentation+unsubscr...@wso2.com. > For more options, visit https://groups.google.com/a/wso2.com/d/optout. > -- Dushan Abeyruwan | Architect Technical Support,MV PMC Member Apache Synpas
Re: [Architecture] Connection Pool Implementation for ESB Kafka and JMS Connectors
Hi Kathees, Yes, there seems to be an obvious improvement. However, when comes to JMS connector,try to design that more generic, I guess that can be done with some customizations of what Hasitha has done. Anyway, please do let me know when JMS genetic connector design planned, we can run through the design of that connector. Have you started to write JMS connector separately ? Cheers, Dushan On Wed, Nov 30, 2016 at 10:39 PM, Kathees Rajendram wrote: > Hi Malaka, > > Yes. Once I compare this performance with other implementations and will > arrange a code review. > > @Malith > I will compare the performance of this custom connection pool > implementation with other implementations as it is mentioned in the mail > thread [1] that Stormpot throughput is highest, will check the > possibility to add in the connector and analyze performance results. > > [1] - "[Architecture] Benchmarks for Object Pool Implementations" > > Thanks, > Kathees > > On Thu, Dec 1, 2016 at 9:29 AM, Malith Jayasinghe > wrote: > >> Hi Kathees, >> >> The underlying implementation of pool can have a significant impact on >> the performance. See the architecture tread "bench marks for object pool >> implementations" >> >> What is reason for going for a custom implementation here? Since this is >> a custom implementation it might be a good idea to do a micro-bench mark of >> the pool and compare its performance with other implementations. >> >> You can also profile the application to find out where the contentions >> etc are and then improve the performance (by narrowing down lock scopes >> etc) >> >> regards >> >> Malith >> >> On Wed, Nov 30, 2016 at 3:26 PM, Malaka Silva wrote: >> >>> Seems like a significant improvement. >>> >>> I guess pool exists per node in cluster? >>> >>> Once completed please arrange a code review. >>> >>> On Wed, Nov 30, 2016 at 12:27 PM, Kathees Rajendram >>> wrote: >>> >>>> Hi, >>>> >>>> I am working on connection pool implementation for Kafka [1] and JMS >>>> [2] connectors. In the existing connectors, connections are created >>>> and closed per message which gives the performance issue. I have improved >>>> the Kafka connector with configurable connection pool parameter. When >>>> publishing the messages, the maximum pool size parameter value can be >>>> changed in the connector configuration. Now the implementation with >>>> connection pool gives better performance. >>>> >>>> The following results are with connection pool implementation. >>>> Average throughput - 4980/s >>>> >>>> >>>> *Threads & Pool Size* *Messages per a Thread* *No of Messages* *A >>>> Message Size(byte)* >>>> *Throughput (/s)* >>>> 10 >>>> 500 5,000 106 3728 >>>> 20 500 10,000 106 4757 >>>> 100 >>>> 2500 250,000 106 5283 >>>> 100 1 1,000,000 106 4920 >>>> >>>> >>>> The following results were without connection pool implementation. >>>> Average throughput - 2767/s >>>> >>>> *Threads* *Messages per a Thread* *No of Messages* *A Message >>>> Size(byte)* >>>> *Throughput (/s)* >>>> 10 500 5,000 106 1590 >>>> 20 500 10,000 106 2251 >>>> 100 250 25,000 106 2940 >>>> 1,000 1500 1,500,000 106 2780 >>>> In my git repo [3], I have committed the connection pool implementation >>>> for Kafka connector. Please give your suggestion. >>>> >>>> [1] - https://wso2.org/jira/browse/ESBCONNECT-122 >>>> [2] - https://wso2.org/jira/browse/ESBCONNECT-142 >>>> [3] - https://github.com/RKathees/esb-connector-kafka/blob/master/ >>>> src/main/java/org/wso2/carbon/connector/KafkaConnectionPoolManager.java >>>> >>>> Thanks, >>>> Kathees >>>> -- >>>> Kathees >>>> Software Engineer, >>>> email: kath...@wso2.com >>>> mobile: +94772596173 <077%20259%206173> >>>> >>> >>> >>> >>> -- >>> >>> Best Regards, >>> >>> Malaka Silva >>> Senior Technical Lead >>> M: +94 777 219 791 <+94%2077%20721%209791> >>> Tel : 94 11 214 5345 >>> Fax :94 11 2145300 >>> Skype : malaka.sampath.silva >>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/
Re: [Architecture] Introducing Secure-Vault support to C5
-vault support to C5. >>>>>> >>>>>> We have done some changes to the way how we configure ciphertool and >>>>>> securevault in C5 compared to C4. Please find the new design details >>>>>> below: >>>>>> >>>>>> There are two configuration files that we maintain for Ciphertool and >>>>>> Securevault: >>>>>> >>>>>> [1]. *secrets.properties* - This file will contains the >>>>>> secret-allias and secrets (encrypted/or plain-text). Act as the >>>>>> file-based >>>>>> secret repository. We define all the passwords/secrets which need to be >>>>>> secured in this file. >>>>>> eg: SecureVault.Keystore.Password=[wso2carbon] >>>>>> Carbon.Security.KeyStore.Password=[somepassword] >>>>>> >>>>>> [2]. *secure-vault.yaml* - This file will have the main >>>>>> configurations (eg: default secret repository implementation, default >>>>>> Callbackhandler implementation etc) >>>>>> eg:carbon.secretProvider: >>>>>> org.wso2.securevault.secret.handler.SecretManagerSecretCallbackHandler >>>>>> keystore.identity.type: JKS >>>>>> keystore.identity.store.password: identity.store.password >>>>>> >>>>>> The CipherTool will be used for creating encrypted values for given >>>>>> plain text secrets in the *secrets**.properties* [1]. >>>>>> >>>>>> If a user need to make a value secure, >>>>>> >>>>>>1. they have to add a unique name (alias) to their carbon >>>>>>configuration element (eg: a value of an element in carbon.yml) >>>>>>2. add the same unique-name along with the plain-text password to >>>>>>the *secrets.properties* file. >>>>>> >>>>>> *Example:* >>>>>> >>>>>> Assume that we need to secure a value "password" under element >>>>>> "Security/Keystore" in Carbon.yml configuration. First we add a unique a >>>>>> alias as the value to the Password as below [3]. Second we add that >>>>>> unique >>>>>> alias with its plain text password to *secrets*.properties file[4]. >>>>>> >>>>>> CipherTool will encrypt the plain-text password and replace the >>>>>> plain-text password with the encrypted value. (In c4 we have added >>>>>> plain-text passwords within square brackets. If not they are identified >>>>>> as >>>>>> encrypted values). >>>>>> >>>>>> When loading the carbon.yml (or any other custom configuration file), >>>>>> we read the secured values using secure-vault service. This secure vault >>>>>> service will either return the password from the *secrets*.properties >>>>>> file if the secret is not encrypted, OR return the encrypted value. >>>>>> >>>>>> [3] >>>>>> >>>>>> >>>>>>id: carbon-kernel #Value to uniquely identify a server >>>>>>name: WSO2 Carbon Kernel#Server Name >>>>>>version: 5.1.0-SNAPSHOT #Server Version >>>>>>tenant: default #Tenant Name >>>>>> >>>>>># Keystore used by this server >>>>>>Security: >>>>>> Keystore >>>>>> Password: Carbon.Security.Keystore.Password >>>>>> >>>>>> >>>>>> ### >>>>>> >>>>>> [4] Carbon.Security.Keystore.Password=[wso2carbon] >>>>>> >>>>>> >>>>>> *New design decisions taken compared to C4 SecureVault >>>>>> implementation:* >>>>>> >>>>>>1. We have removed the usage of cipher-tool.properties file. >>>>>>(This file was used to keep the alias, the location to the >>>>>> configuration >>>>>>file, and the xpath to the secret element in the configuration file). >>>>>>2. We can support any format of configuration file with this >>>>>>model as we only care about the secret-key that we define in the >>>>>>*secrets*.properties file and do not depend on the xpath to find >>>>>>the location of the secret element. >>>>>> >>>>>> Thanks, >>>>>> Nipuni >>>>>> >>>>>> -- >>>>>> Nipuni Perera >>>>>> Software Engineer; WSO2 Inc.; http://wso2.com >>>>>> Email: nip...@wso2.com >>>>>> Git hub profile: https://github.com/nipuni >>>>>> Blog : http://nipunipererablog.blogspot.com/ >>>>>> Mobile: +94 (71) 5626680 >>>>>> <http://wso2.com> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Sameera Jayasoma, >>>>> Software Architect, >>>>> >>>>> WSO2, Inc. (http://wso2.com) >>>>> email: same...@wso2.com >>>>> blog: http://blog.sameera.org >>>>> twitter: https://twitter.com/sameerajayasoma >>>>> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >>>>> Mobile: 0094776364456 >>>>> >>>>> Lean . Enterprise . Middleware >>>>> >>>>> >>>> >>>> Regards, >>>> Nira >>>> -- >>>> >>>> *Niranjan Karunanandham* >>>> Senior Software Engineer - WSO2 Inc. >>>> WSO2 Inc.: http://www.wso2.com >>>> >>> >>> >>> >>> -- >>> With regards, >>> *Manu*ranga Perera. >>> >>> phone : 071 7 70 20 50 >>> mail : m...@wso2.com >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> Srinath Perera, Ph.D. >>http://people.apache.org/~hemapani/ >>http://srinathsview.blogspot.com/ >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Kasun Indrasiri > Software Architect > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > cell: +94 77 556 5206 > Blog : http://kasunpanorama.blogspot.com/ > -- Dushan Abeyruwan | Technical Lead PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* LinkedIn:*https://www.linkedin.com/in/dushanabeyruwan <https://www.linkedin.com/in/dushanabeyruwan>* Mobile:(001)408-791-9312 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Improving error handling at different layers in ESB
>>>> -- >>>>>> >>>>>> Kasun Indrasiri >>>>>> Software Architect >>>>>> WSO2, Inc.; http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> >>>>>> cell: +94 77 556 5206 >>>>>> Blog : http://kasunpanorama.blogspot.com/ >>>>>> >>>>>> ___ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Srinath Perera, Ph.D. >>>>>http://people.apache.org/~hemapani/ >>>>>http://srinathsview.blogspot.com/ >>>>> >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Isuru Udana* >>>> Associate Technical Lead >>>> WSO2 Inc.; http://wso2.com >>>> email: isu...@wso2.com cell: +94 77 3791887 >>>> blog: http://mytecheye.blogspot.com/ >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> >>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera >>> Site: http://home.apache.org/~hemapani/ >>> Photos: http://www.flickr.com/photos/hemapani/ >>> Phone: 0772360902 >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Kasun Indrasiri >> Software Architect >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> cell: +94 77 556 5206 >> Blog : http://kasunpanorama.blogspot.com/ >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Susankha Nirmala > Software Engineer > WSO2, Inc.: http://wso2.com > lean.enterprise.middleware > Mobile : +94 77 593 2146 > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Technical Lead PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* LinkedIn:*https://www.linkedin.com/in/dushanabeyruwan <https://www.linkedin.com/in/dushanabeyruwan>* Mobile:(001)408-791-9312 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Analytics Mediation Event Publishing Mechanism
on >>>>>>>>>> flow are stored in a single row, and the data about the >>>>>>>>>> mediators invoked during the flow are stored in a known column of >>>>>>>>>> each row >>>>>>>>>> (say "data"), as an array (say a json array). When each row is read >>>>>>>>>> in to >>>>>>>>>> spark, this relational provider create separate rows for each of the >>>>>>>>>> element in the array stored in "data" column. I have tested this >>>>>>>>>> with some >>>>>>>>>> mocked data, and works as expected. >>>>>>>>>> >>>>>>>>>> Need to test with the real data/data-formats, and modify the >>>>>>>>>> mapping accordingly. Will update the thread with the details. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Supun >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Feb 2, 2016 at 2:36 AM, Anjana Fernando >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> In a meeting I'd with Kasun and the ESB team, I got to know >>>>>>>>>>> that, for their tracing mechanism, they were instructed to publish >>>>>>>>>>> one >>>>>>>>>>> event for each of the mediator invocations, where, earlier they had >>>>>>>>>>> an >>>>>>>>>>> approach, they publish one event, which encapsulated data of a whole >>>>>>>>>>> execution flow. I would actually like to support the latter >>>>>>>>>>> approach, >>>>>>>>>>> mainly due to performance / resource requirements. And also >>>>>>>>>>> considering the >>>>>>>>>>> fact, this is a feature that could be enabled in production. So >>>>>>>>>>> simply, if >>>>>>>>>>> we do one event per mediator, this does not scale that well. For >>>>>>>>>>> example, >>>>>>>>>>> if the ESB is doing 1k TPS, for a sequence that has 20 mediators, >>>>>>>>>>> that is >>>>>>>>>>> 20k TPS for analytics traffic. Combine that with a possible ESB >>>>>>>>>>> cluster >>>>>>>>>>> hitting a DAS cluster with a single backend database, this maybe >>>>>>>>>>> too many >>>>>>>>>>> rows per second written to the database. Where the main problem >>>>>>>>>>> here is, >>>>>>>>>>> one event is, a single row/record in the backend database in DAS, >>>>>>>>>>> so it may >>>>>>>>>>> come to a state, where the frequency of row creations by events >>>>>>>>>>> coming from >>>>>>>>>>> ESBs cannot be sustained. >>>>>>>>>>> >>>>>>>>>>> If we create a single event from the 20 mediators, then it is >>>>>>>>>>> just 1k TPS for DAS event receivers and the database too, event >>>>>>>>>>> though the >>>>>>>>>>> message size is bigger. It is not necessarily same performance, if >>>>>>>>>>> you >>>>>>>>>>> publish lots of small events to publishing bigger events. >>>>>>>>>>> Throughput wise, >>>>>>>>>>> comparatively bigger events will win (even though if we consider >>>>>>>>>>> that, >>>>>>>>>>> small operations will be batched in transport level etc.. still one >>>>>>>>>>> event = >>>>>>>>>>> one database row). So I would suggest, we try out a single sequence >>>>>>>>>>> flow = >>>>>>>>>>> single event, approach, and from the Spark processing side, we >>>>>>>>>>> consider one >>>>>>>>>>> of these big rows as multiple rows in Spark. I was first thinking, >>>>>>>>>>> if UDFs >>>>>>>>>>> can help in splitting a single column to multiple rows, and that is >>>>>>>>>>> not >>>>>>>>>>> possible, and also, a bit troublesome, considering we have to >>>>>>>>>>> delete the >>>>>>>>>>> original data table after we concerted it using a script, and not >>>>>>>>>>> forgetting, we actually have to schedule and run a separate script >>>>>>>>>>> to do >>>>>>>>>>> this post-processing. So a much cleaner way to do this would be, to >>>>>>>>>>> create >>>>>>>>>>> a new "relation provider" in Spark (which is like a data adapter >>>>>>>>>>> for their >>>>>>>>>>> DataFrames), and in our relation provider, when we are reading >>>>>>>>>>> rows, we >>>>>>>>>>> convert a single row's column to multiple rows and return that for >>>>>>>>>>> processing. So Spark will not know, physically it was a single row >>>>>>>>>>> from the >>>>>>>>>>> data layer, and it can summarize the data and all as usual and >>>>>>>>>>> write to the >>>>>>>>>>> target summary tables. [1] is our existing implementation of Spark >>>>>>>>>>> relation >>>>>>>>>>> provider, which directly maps to our DAS analytics tables, we can >>>>>>>>>>> create >>>>>>>>>>> the new one extending / based on it. So I suggest we try out this >>>>>>>>>>> approach >>>>>>>>>>> and see, if everyone is okay with it. >>>>>>>>>>> >>>>>>>>>>> [1] >>>>>>>>>>> https://github.com/wso2/carbon-analytics/blob/master/components/analytics-processors/org.wso2.carbon.analytics.spark.core/src/main/java/org/wso2/carbon/analytics/spark/core/sources/AnalyticsRelationProvider.java >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Anjana. >>>>>>>>>>> -- >>>>>>>>>>> *Anjana Fernando* >>>>>>>>>>> Senior Technical Lead >>>>>>>>>>> WSO2 Inc. | http://wso2.com >>>>>>>>>>> lean . enterprise . middleware >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>> Google Groups "WSO2 Engineering Group" group. >>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>> it, send an email to engineering-group+unsubscr...@wso2.com. >>>>>>>>>>> For more options, visit >>>>>>>>>>> https://groups.google.com/a/wso2.com/d/optout. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> *Supun Sethunga* >>>>>>>>>> Software Engineer >>>>>>>>>> WSO2, Inc. >>>>>>>>>> http://wso2.com/ >>>>>>>>>> lean | enterprise | middleware >>>>>>>>>> Mobile : +94 716546324 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Supun Sethunga* >>>>>>>>> Software Engineer >>>>>>>>> WSO2, Inc. >>>>>>>>> http://wso2.com/ >>>>>>>>> lean | enterprise | middleware >>>>>>>>> Mobile : +94 716546324 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Kasun Indrasiri >>>>>>>>> Software Architect >>>>>>>>> WSO2, Inc.; http://wso2.com >>>>>>>>> lean.enterprise.middleware >>>>>>>>> >>>>>>>>> cell: +94 77 556 5206 >>>>>>>>> Blog : http://kasunpanorama.blogspot.com/ >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Isuru Udana* >>>>>>>> Associate Technical Lead >>>>>>>> WSO2 Inc.; http://wso2.com >>>>>>>> email: isu...@wso2.com cell: +94 77 3791887 >>>>>>>> blog: http://mytecheye.blogspot.com/ >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Supun Sethunga* >>>>>>> Software Engineer >>>>>>> WSO2, Inc. >>>>>>> http://wso2.com/ >>>>>>> lean | enterprise | middleware >>>>>>> Mobile : +94 716546324 >>>>>>> >>>>>>> ___ >>>>>>> Architecture mailing list >>>>>>> Architecture@wso2.org >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Sinthuja Rajendran* >>>>>> Associate Technical Lead >>>>>> WSO2, Inc.:http://wso2.com >>>>>> >>>>>> Blog: http://sinthu-rajan.blogspot.com/ >>>>>> Mobile: +94774273955 >>>>>> >>>>>> >>>>>> >>>>>> ___ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Supun Sethunga* >>>>> Software Engineer >>>>> WSO2, Inc. >>>>> http://wso2.com/ >>>>> lean | enterprise | middleware >>>>> Mobile : +94 716546324 >>>>> >>>> >>>> >>>> >>>> -- >>>> *Sinthuja Rajendran* >>>> Associate Technical Lead >>>> WSO2, Inc.:http://wso2.com >>>> >>>> Blog: http://sinthu-rajan.blogspot.com/ >>>> Mobile: +94774273955 >>>> >>>> >>>> >>> >>> >>> -- >>> *Sinthuja Rajendran* >>> Associate Technical Lead >>> WSO2, Inc.:http://wso2.com >>> >>> Blog: http://sinthu-rajan.blogspot.com/ >>> Mobile: +94774273955 >>> >>> >>> >> >> >> -- >> *Supun Sethunga* >> Software Engineer >> WSO2, Inc. >> http://wso2.com/ >> lean | enterprise | middleware >> Mobile : +94 716546324 >> > > > > -- > *Supun Sethunga* > Software Engineer > WSO2, Inc. > http://wso2.com/ > lean | enterprise | middleware > Mobile : +94 716546324 > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Technical Lead PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* Mobile:(001)408-791-9312 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] WSO2 ESB 5.0.0 - Milestone 2 Released!
Hi Have seen mediation debugging feature in docs (others audience: please note, doc are still at a draft stage so not visible to public) anyway, is there correspondent DevS version available? On Mon, Feb 15, 2016 at 4:09 AM, Vijitha Ekanayake wrote: > *WSO2 ESB 5.0.0-Milestone 2 Released* > > ESB Team is pleased to announce the WSO2 ESB 5.0.0 - Milestone 2 Release. > It contains following improvement and bug fixes. > > Bug > >- [ESBJAVA-4416 <https://wso2.org/jira/browse/ESBJAVA-4416>] - ESB >Management console shows Invalid product version. >- [ESBJAVA-4417 <https://wso2.org/jira/browse/ESBJAVA-4415>] - ESB >server terminal shows Invalid product version. > > Improvement > >- [ESBJAVA-4415 <https://wso2.org/jira/browse/ESBJAVA-4415>] - SSL >support for MQTT inbound. > > > > The distribution is available to download at [1]. > > [1] > https://svn.wso2.org/repos/wso2/scratch/ESB/packs/5.0.0-Releases/5.0.0-M2/ > > - WSO2 ESB Team - > > -- > Vijitha Ekanayake > Software Engineer*, *WSO2, Inc.; http://wso2.com/ > Mobile : +94 777 24 73 39 | +94 718 74 44 08 > lean.enterprise.middleware > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Technical Lead PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* Mobile:(001)408-791-9312 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [ESB-Connector] EJB Connector
gt;>>>>>>>>>>> connector zip file is increasing (now 65 MB) so is there any >>>>>>>>>>>> limitation for >>>>>>>>>>>> Connector file? or do we have any other solution? >>>>>>>>>>>> >>>>>>>>>>>> On Sat, Oct 24, 2015 at 6:15 PM, Rasika Perera < >>>>>>>>>>>> rasi...@wso2.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Rajjaz, >>>>>>>>>>>>> >>>>>>>>>>>>> i need to know which EJB-Container is mostly used by the >>>>>>>>>>>>>> client? or which is recommended one? because development will be >>>>>>>>>>>>>> based on >>>>>>>>>>>>>> that (later will try Generalized format). >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> All EJB containers implements EJB 2.x/3.0/3.1/3.2 >>>>>>>>>>>>> specifications. Theoretically all should support it. >>>>>>>>>>>>> >>>>>>>>>>>>> You may try the followings; >>>>>>>>>>>>> >>>>>>>>>>>>> Oracle Weblogic[2], IBM Websphere[3], RedHat JBoss[4], Oracle >>>>>>>>>>>>> Glassfish[5]. >>>>>>>>>>>>> >>>>>>>>>>>>> [1] >>>>>>>>>>>>> http://download.oracle.com/otndocs/jcp/ejb-3_2-fr-spec/index.html >>>>>>>>>>>>> [2] >>>>>>>>>>>>> http://www.oracle.com/technetwork/middleware/weblogic/downloads/index.html >>>>>>>>>>>>> [3] >>>>>>>>>>>>> http://www.ibm.com/developerworks/downloads/ws/was/index.html >>>>>>>>>>>>> [4] http://www.jboss.org/products/eap/overview/ >>>>>>>>>>>>> [5] https://glassfish.java.net/download.html >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Oct 7, 2015 at 12:00 PM, Rajjaz Mohammed < >>>>>>>>>>>>> raj...@wso2.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Noted Malaka, >>>>>>>>>>>>>> i need to know which EJB-Container is mostly used by the >>>>>>>>>>>>>> client? or which is recommended one? because development will be >>>>>>>>>>>>>> based on >>>>>>>>>>>>>> that (later will try Generalized format). >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Oct 7, 2015 at 11:55 AM, Malaka Silva < >>>>>>>>>>>>>> mal...@wso2.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Rajjaz, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> We don't need to write a connector for EJB 3.0 since this is >>>>>>>>>>>>>>> already supported with ESB EJB mediator. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> +1 for the connector with EJB 2.1 support. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Oct 7, 2015 at 11:52 AM, Rajjaz Mohammed < >>>>>>>>>>>>>>> raj...@wso2.com> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi All, >>>>>>>>>>>>>>>> For the EJB Connector Development which EJB-Container is >>>>>>>>>>>>>>>> Recommenced ? and Which version? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> as a first step i would like to develop a EJB 3.x connector >>>>>>>>>&
Re: [Architecture] [ESB-Connector] EJB Connector
Hi I guess there are many improvements to be made if you writing connector, and would certainly looking forward to see new design rather what we currently have in EJB mediator [1] (it seems original doc is corrupted) Existing problems - EJB mediator binds with Bean mediator when we need to initialize instances for binding responses or requests for complex object IMV its too much overhead and feels we need to normalize this. - We need to get rid from 'beanstalks' way of communicating via synapse.propertis (it is must) it should be flexible. - Then we must test this with least multiple application servers (Jboss, Glassfish) there are tons of class loader issues (and we had to create split packages to get rid) With all above concerns please do come up with the design we can continue to discuss. [1] http://www.dushantech.com/search?q=ejb Cheers, Dushan On Wed, Sep 16, 2015 at 10:42 AM, Chanaka Fernando wrote: > Hi Rajjaz, > > Well, if you see any issue with the EJB mediator, please report them and > help us to improve the existing mediator. It is not required to repeat the > functionality of the EJB mediator in the new connector which you are going > to develop. Could you elaborate on a use case for this EJB connector? > > On Wed, Sep 16, 2015 at 2:04 PM, Rajjaz Mohammed wrote: > >> >> >> On Wed, Sep 16, 2015 at 2:04 PM, Rajjaz Mohammed wrote: >> >>> Hi All, >>> I have planned to Implement EJB Connector for WSO2 ESB. Currently, EJB >>> mediator supports EJB3 Stateless Session Beans and Stateful Session Beans. >>> Since EJB mediator have some isues EJB Connector will include the >>> Functionality of EJB mediator which calls an external Enterprise JavaBean >>> (EJB) and stores the result in the message payload or in a message context >>> property. >>> >>> This is my Basic Idea so If you have anything to add/change in EJB >>> Connector please add in this Thread. and Connector will be Separate for EJB >>> 2.0 & 3.0. >>> >>> -- >>> Thank you >>> Best Regards >>> >>> *Rajjaz HM* >>> Associate Software Engineer >>> WSO2 Inc. <http://wso2.com/> >>> lean | enterprise | middleware >>> Mobile | +94752833834 >>> Email | raj...@wso2.com >>> LinkedIn | Blogger | WSO2 Profile >>> <http://wso2.com/about/team/mohammer_rajjaz/> >>> >> >> >> >> -- >> Thank you >> Best Regards >> >> *Rajjaz HM* >> Associate Software Engineer >> WSO2 Inc. <http://wso2.com/> >> lean | enterprise | middleware >> Mobile | +94752833834 >> Email | raj...@wso2.com >> LinkedIn | Blogger | WSO2 Profile >> <http://wso2.com/about/team/mohammer_rajjaz/> >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > -- > Chanaka Fernando > Senior Technical Lead > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 773337238 > Blog : http://soatutorials.blogspot.com > LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 > Twitter:https://twitter.com/chanakaudaya > > > > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Technical Lead Technical Support-Bloomington US PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* Mobile:(001)812-391-7441 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Supporting Default Endpoints for API Manager 1.10.0
Hi AFAIK, In-Flow can have any sequence, and its not must to select sequence which has To header, client can define To header any embedded sequence i.e (which can have many possibilities) think from simple scenario to complex scenario where client define complex custom extension. What I would think adding to NuwanD concern, when creating API you should validate the selected sequence (iterate through mediators and see whether it has To header defined) However ,to make this more interesting, I have seen people using service chaining within In or Out Synapse extensions (using callout mediator) guess what, callout mediator can have To header as well, then you need understand which To header used by API it self :) Cheers, Dushan On Tue, Sep 8, 2015 at 3:06 AM, Abimaran Kugathasan wrote: > Hi All, > > Do we need to move the exsting "Message Mediation Policies" [1] which > handles adding in/out/fault sequences into API to Implementation tab from > Manage tab? Or Can we add this Default Endpoint sequence selection only in > the Implementation tab? > > [1]: > > > > On Mon, Sep 7, 2015 at 9:59 PM, Nuwan Dias wrote: > >> One thing to note is that is Destination Based Stats should also work >> properly with dynamic endpoints. Need to keep that in mind when testing. >> Endpoint security should also be tested for both Basic Auth and Digest Auth. >> >> And when a user selects the "Default Endpoint" type, we should mandate >> him to select a custom in-sequence and provide appropriate messages to >> inform him that he should set the "To" header properly. >> >> Thanks, >> NuwanD. >> >> On Mon, Sep 7, 2015 at 2:16 PM, Abimaran Kugathasan >> wrote: >> >>> Hi All, >>> >>> APIM 1.10.0 needs to support Default Endpoint [1] types. To support it, >>> API Publisher needs a way to define Custom Mediation Sequences to assemble >>> endpoint dynamically and import it into APIs. >>> >>> Currently, we can define/add Custom Mediation Sequences through >>> Management Console and, those will appear in the API Publisher's Manage >>> section under 'Message Mediation Policies'. >>> >>> We planned to move this to API Publisher's Implementation page, where >>> API Publisher can import the custom sequence into API when selecting >>> Default Endpoint for API. And, these sequences should run before the send >>> mediator to generate the endpoint dynamically. >>> >>> Please provide your suggestion on this. >>> >>> >>> [1] : https://docs.wso2.com/display/ESB481/Default+Endpoint >>> >>> -- >>> Thanks >>> Abimaran Kugathasan >>> >>> Software Engineer | WSO2 Inc >>> Data & APIs Technologies Team >>> Mobile : +94 773922820 >>> >>> <http://stackoverflow.com/users/515034> >>> <http://lk.linkedin.com/in/abimaran> >>> <http://www.lkabimaran.blogspot.com/> <https://github.com/abimarank> >>> <https://twitter.com/abimaran> >>> >>> >> >> >> -- >> Nuwan Dias >> >> Technical Lead - WSO2, Inc. http://wso2.com >> email : nuw...@wso2.com >> Phone : +94 777 775 729 >> > > > > -- > Thanks > Abimaran Kugathasan > > Software Engineer | WSO2 Inc > Data & APIs Technologies Team > Mobile : +94 773922820 > > <http://stackoverflow.com/users/515034> > <http://lk.linkedin.com/in/abimaran> > <http://www.lkabimaran.blogspot.com/> <https://github.com/abimarank> > <https://twitter.com/abimaran> > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Technical Lead Technical Support-Bloomington US PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* Mobile:(001)812-391-7441 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Implement File Connector for zip file for WSO2 ESB
Hi For the record , please refer [1] [1] https://wso2.org/jira/browse/ESBCONNECT-52 Cheers, Dushan On Mon, Aug 3, 2015 at 1:10 AM, Gayan Gunarathne wrote: > > > On Sun, Aug 2, 2015 at 9:03 PM, Dushan Abeyruwan wrote: > >> Hi Malaka, >> [Adding Gayan G] >> I guess those are nice operations to have but, first we should >> stabilize file-connector existing methods, there has been few issues >> reported which were really blockers, so I guess we should test these while >> covering "Test the existing file connector" (Please check mail I have >> sent to dev list related to this topic), some aren't visible to public >> > > Yeah we can add those existing issues identified during some support > issues to our roadmap. > +1 to have those zip file related operations which seems have lot of use > cases. > > Thanks, > Gayan > >> >> Cheers, >> Dushan >> >> >> On Thu, Jul 30, 2015 at 12:16 PM, Vivekananthan Sivanayagam < >> vivekanant...@wso2.com> wrote: >> >>> Hi Malaka, >>> I will do that one . >>> >>> >>> >>> >>> >>> >>> *Thank youVivekananthan Sivanayagam* >>> >>> *Associate Software Engineer | WSO2* >>> >>> *E:vivekanant...@wso2.com * >>> *M:+94752786138 <%2B94752786138>* >>> >>> On Thu, Jul 30, 2015 at 7:55 PM, Malaka Silva wrote: >>> >>>> Looks good. >>>> >>>> Also include a load testing in your plan. >>>> >>>> On Thu, Jul 30, 2015 at 6:49 PM, Vivekananthan Sivanayagam < >>>> vivekanant...@wso2.com> wrote: >>>> >>>>> Introduction >>>>> >>>>> The File connector >>>>> <https://docs.wso2.org/display/ESB481/Working+with+Connectors> allows >>>>> you to connect to different file systems and perform various operations >>>>> with the file systems. The file connector uses the apache commons VFS I/O >>>>> functionalities to execute operations. >>>>> >>>>> File Connector for Zip folder >>>>> >>>>> >>>>>1. >>>>> >>>>>Reads a zip files. >>>>>2. >>>>> >>>>>Writes files and compress to zip file. >>>>>3. >>>>> >>>>>Unzip file. >>>>> >>>>> >>>>> >>>>> https://docs.google.com/spreadsheets/d/1w3ZgUhhJSpEFQXRYqRm7Zq_acdnpBMhY-u9AKQ5E7uM/edit#gid=0 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *Thank youVivekananthan Sivanayagam* >>>>> >>>>> *Associate Software Engineer | WSO2* >>>>> >>>>> *E:vivekanant...@wso2.com * >>>>> *M:+94752786138 <%2B94752786138>* >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Best Regards, >>>> >>>> Malaka Silva >>>> Senior Tech Lead >>>> M: +94 777 219 791 >>>> Tel : 94 11 214 5345 >>>> Fax :94 11 2145300 >>>> Skype : malaka.sampath.silva >>>> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >>>> Blog : http://mrmalakasilva.blogspot.com/ >>>> >>>> WSO2, Inc. >>>> lean . enterprise . middleware >>>> http://www.wso2.com/ >>>> http://www.wso2.com/about/team/malaka-silva/ >>>> <http://wso2.com/about/team/malaka-silva/> >>>> >>>> Save a tree -Conserve nature & Save the world for your future. Print >>>> this email only if it is absolutely necessary. >>>> >>> >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Dushan Abeyruwan | Technical Lead >> Technical Support-Bloomington US >> PMC Member Apache Synpase >> WSO2 Inc. http://wso2.com/ >> Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* >> Mobile:(001)812-391-7441 >> >> > > > -- > > Gayan Gunarathne > Technical Lead, WSO2 Inc. (http://wso2.com) > Committer & PMC Member, Apache Stratos > email : gay...@wso2.com | mobile : +94 775030545 <%2B94%20766819985> > > > -- Dushan Abeyruwan | Technical Lead Technical Support-Bloomington US PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* Mobile:(001)812-391-7441 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Implement File Connector for zip file for WSO2 ESB
Hi Malaka, [Adding Gayan G] I guess those are nice operations to have but, first we should stabilize file-connector existing methods, there has been few issues reported which were really blockers, so I guess we should test these while covering "Test the existing file connector" (Please check mail I have sent to dev list related to this topic), some aren't visible to public Cheers, Dushan On Thu, Jul 30, 2015 at 12:16 PM, Vivekananthan Sivanayagam < vivekanant...@wso2.com> wrote: > Hi Malaka, > I will do that one . > > > > > > > *Thank youVivekananthan Sivanayagam* > > *Associate Software Engineer | WSO2* > > *E:vivekanant...@wso2.com * > *M:+94752786138 <%2B94752786138>* > > On Thu, Jul 30, 2015 at 7:55 PM, Malaka Silva wrote: > >> Looks good. >> >> Also include a load testing in your plan. >> >> On Thu, Jul 30, 2015 at 6:49 PM, Vivekananthan Sivanayagam < >> vivekanant...@wso2.com> wrote: >> >>> Introduction >>> >>> The File connector >>> <https://docs.wso2.org/display/ESB481/Working+with+Connectors> allows >>> you to connect to different file systems and perform various operations >>> with the file systems. The file connector uses the apache commons VFS I/O >>> functionalities to execute operations. >>> >>> File Connector for Zip folder >>> >>> >>>1. >>> >>>Reads a zip files. >>>2. >>> >>>Writes files and compress to zip file. >>>3. >>> >>>Unzip file. >>> >>> >>> >>> https://docs.google.com/spreadsheets/d/1w3ZgUhhJSpEFQXRYqRm7Zq_acdnpBMhY-u9AKQ5E7uM/edit#gid=0 >>> >>> >>> >>> >>> >>> >>> >>> >>> *Thank youVivekananthan Sivanayagam* >>> >>> *Associate Software Engineer | WSO2* >>> >>> *E:vivekanant...@wso2.com * >>> *M:+94752786138 <%2B94752786138>* >>> >> >> >> >> -- >> >> Best Regards, >> >> Malaka Silva >> Senior Tech Lead >> M: +94 777 219 791 >> Tel : 94 11 214 5345 >> Fax :94 11 2145300 >> Skype : malaka.sampath.silva >> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >> Blog : http://mrmalakasilva.blogspot.com/ >> >> WSO2, Inc. >> lean . enterprise . middleware >> http://www.wso2.com/ >> http://www.wso2.com/about/team/malaka-silva/ >> <http://wso2.com/about/team/malaka-silva/> >> >> Save a tree -Conserve nature & Save the world for your future. Print this >> email only if it is absolutely necessary. >> > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Technical Lead Technical Support-Bloomington US PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* Mobile:(001)812-391-7441 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Deploying an ESB Connector with a cApp?
aka, >>>>>> >>>>>> As you noted, I will test for possible scenarios. >>>>>> >>>>>> Thank you. >>>>>> >>>>>> On Thu, Jul 9, 2015 at 10:10 AM, Malaka Silva >>>>>> wrote: >>>>>> >>>>>>> Hi Shakila, >>>>>>> >>>>>>> Good Progress on this. >>>>>>> >>>>>>> Let's verify some scenario similar to following, >>>>>>> >>>>>>>1. Include more that one connector. >>>>>>>2. Use the connector inside a proxy service, Api and sequence >>>>>>>that are included in the same capp. >>>>>>> >>>>>>> >>>>>>> On Wed, Jul 8, 2015 at 6:23 PM, Shakila Sivagnanarajah < >>>>>>> shak...@wso2.com> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I have done the connector deployment from CApp. >>>>>>>> >>>>>>>> Thank you >>>>>>>> >>>>>>>> On Wed, Jul 8, 2015 at 10:25 AM, Shakila Sivagnanarajah < >>>>>>>> shak...@wso2.com> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Please find the CApp [1]. >>>>>>>>> >>>>>>>>> This is my progress: >>>>>>>>> >>>>>>>>> 1. I added the connector zip in to the CApp as an artifact and >>>>>>>>> specified the artifact type as "zip". >>>>>>>>> 2. As the same way to deploy the artifact, I have implemented a >>>>>>>>> method to deploy the synapse library in [2] (Still testing). >>>>>>>>> 3. I have added some constants in [3]. >>>>>>>>> >>>>>>>>> I am following the way that Dushan noted. Initially I am doing >>>>>>>>> this with a single connector. As the first step, Now I am doing the >>>>>>>>> connector deployment (CAR -- > upload -- > deploy connector). >>>>>>>>> >>>>>>>>> [1] >>>>>>>>> https://drive.google.com/a/wso2.com/file/d/0B3SvJgvWs9I_eWY5UEJhM3pzb0k/view?usp=sharing >>>>>>>>> >>>>>>>>> [2] >>>>>>>>> /components/application-deployers/org.wso2.carbon.application.deployer.synapse/src/main/java/org/wso2/carbon/application/deployer/synapse/SynapseAppDeployer.java >>>>>>>>> >>>>>>>>> [3] >>>>>>>>> /components/application-deployers/org.wso2.carbon.application.deployer.synapse/src/main/java/org/wso2/carbon/application/deployer/synapse/SynapseAppDeployerConstants.java >>>>>>>>> >>>>>>>>> >>>>>>>>> Thank you. >>>>>>>>> >>>>>>>>> On Wed, Jul 8, 2015 at 6:02 AM, Dushan Abeyruwan >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Jul 7, 2015 at 8:07 AM, Jasintha Dasanayake < >>>>>>>>>> jasin...@wso2.com> wrote: >>>>>>>>>> >>>>>>>>>>> @viraj >>>>>>>>>>> >>>>>>>>>>> Shall we enable this in ESB project level , since there is a >>>>>>>>>>> option already in ESB project , that we can improve to pack >>>>>>>>>>> connector into >>>>>>>>>>> capp when adding the ESB project into Capp ? >>>>>>>>>>> >>>>>>>>>> +1 this should be feasible with ESB Project level as its already >>>>>>>>>> there in DevS >>>>>>>>>> >>>>>>>>>> Shashika, could please provide more detail (design and >>>>>>>>>> implementation detail/changes you have done) how you planned to >>>>>>>>>> integrate >>>>>>>>>> this ? >>>>>>>>>>
Re: [Architecture] Deploying an ESB Connector with a cApp?
On Tue, Jul 7, 2015 at 8:07 AM, Jasintha Dasanayake wrote: > @viraj > > Shall we enable this in ESB project level , since there is a option > already in ESB project , that we can improve to pack connector into capp > when adding the ESB project into Capp ? > +1 this should be feasible with ESB Project level as its already there in DevS Shashika, could please provide more detail (design and implementation detail/changes you have done) how you planned to integrate this ? however, please note that we need manage depdenencies correctly CAR -- > upload -- > deploy connector/s --- >[[*critical:* monitor the status of connector deployment]] -- if success ---> execute connector-meta-import --> if success -- > then deploy other synapse-artifacts *guess, the difficulty can be holding synapse artifact deployment till connector's uploaded successfully and import connector meta data, have found solution for this ?* > > Thanks and Regards > /Jasintha > > On Tue, Jul 7, 2015 at 4:33 PM, Shakila Sivagnanarajah > wrote: > >> Hi Kasun, >> >> Since there is no feature in developer studio to import connector zip >> into the CApp, I have manually added the zip in to car. Now I am >> debugging and modifying the code [1]. I think I am going well with the task. >> >> [1] >> https://github.com/wso2/carbon-mediation/blob/master/components/application-deployers/org.wso2.carbon.application.deployer.synapse/src/main/java/org/wso2/carbon/application/deployer/synapse/SynapseAppDeployer.java >> >> Thank you. >> >> On Tue, Jul 7, 2015 at 4:22 PM, Kasun Indrasiri wrote: >> >>> Any progress on this task? >>> >>> On Thu, Jul 2, 2015 at 11:09 PM, Malaka Silva wrote: >>> >>>> Hi All, >>>> >>>> Shakila will be starting to implement this functionality from ESB side. >>>> >>>> @Shakila - Any blockers user this mail thread to discuss. >>>> >>>> On Tue, Jun 30, 2015 at 5:57 PM, Jasintha Dasanayake >>> > wrote: >>>> >>>>> From tooling perspective, this is similar to class mediator deployment >>>>> using Capp , Since Capp class mediator deployment now working fine with >>>>> Capp so this can be done , However this is also kind of sever extension >>>>> so >>>>> we have to educate the users to use this properly. >>>>> >>>>> Thanks and Regards >>>>> /Jasintha >>>>> >>>>> On Tue, Jun 30, 2015 at 5:11 PM, Kasun Indrasiri >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> AFAIR, this was discussed several times. But in the context of ESB as >>>>>> a service, I think this will be quite useful. I don't think we have any >>>>>> technical difficulty in doing this. >>>>>> >>>>>> Use case : >>>>>> - We want to invoke a twitter operation. >>>>>> - Import the twitter connector from connector-store( into DevS) and >>>>>> use the twitter connector operation in our mediation logic. >>>>>> - Now we want to deploy the artifact into ESB but it is required to >>>>>> deploy/enable the connector beforehand. (If the connector is not deployed >>>>>> in the ESB instance, this config deployment will fail.) >>>>>> - If we can include the connector as part of the cApp, then the >>>>>> connector deployment is completely transparent to the users. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> -- >>>>>> Kasun Indrasiri >>>>>> Software Architect >>>>>> WSO2, Inc.; http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> >>>>>> cell: +94 77 556 5206 >>>>>> Blog : http://kasunpanorama.blogspot.com/ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Jasintha Dasanayake* >>>>> >>>>> *Senior Software EngineerWSO2 Inc. | http://wso2.com >>>>> <http://wso2.com/>lean . enterprise . middleware* >>>>> >>>>> >>>>> *mobile :- 0711368118 <0711368118>* >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> Best Regards, >>>> >>>> Malaka Silva >>>> Senior Tech Lead
Re: [Architecture] [ESB] Guaranteed message delivery capability to the MSMP
HI On Tue, Jul 7, 2015 at 11:21 AM, Prabath Ariyarathna wrote: > Hi All, > > We are planning to implement guaranteed message delivery capability to the > MSMP. We can divided current implementation into two basic sections based > on process. > >1. *Message Store:* Message store mainly responsible for producing >messages to the message broker using message store mediator. >2. *Message process*: Message processor picks the messages from the >message store and send to the specified endpoint. > > When we implement a guaranteed message delivery mechanism to the MSMP, we > need to think about both of above scenarios. JMS specification provided us > to two mechanisms(Acknowledgement, Transaction), which can be used to > achieve guaranteed delivery. > In our case message processor(consumer) side guaranteed delivery was > already implemented using acknowledgements. Message processor ACK to the > message store only if message was successfully processed. Message store > removes the message once ACK received by the processor else redeliver the > message, but for the message storing(producer) part, we don’t have any > mechanism implemented to achieve this feature. Main intention of this > implementation is to provide a way to handle guaranteed delivery for the > message storing(producer) part. > > *Problem.* > We don’t have mechanism to handle guaranteed delivery in message > storing(producer) section. This issue can be occurred for following use > cases. > >1. Message was sent to the MB, but didn’t received to the MB side due >to communication failure. >2. Message broker not available when try to store the message. > > > *Solution.* > We can choose either acknowledgement or transaction as a solution of > guaranteed delivery implementation but since JMS 1.1 doesn't support for > the producer acknowledgement, we decided to enable transaction support for > the message storing section to provide guaranteed delivery. Other than the > transactions enable in the message storing process, we planned to add retry > mechanism to avoid scenario like message store is not available when we try > to produce messages. User can define retry count and retry delay in the > configuration of the store mediator. Message retry process is executing If > message broker connection not available or transaction has already > rollbacked. In addition to that features we are planning to add batch > process facility to store mediator to improve performance, while enabling > transactions as the future improvement. > This sounds good however, any design that we could see how to achieve this model, I guess we may have to re-design JMSStore to look-up messages queued in then then dispatch (if connections ENV conditions are positive) or will this retry is based on per message ? I guess Batch process might be the abstract implementation for retry so batch count should be the variable and control post conditions .. > > > Thanks > -- > > *Prabath Ariyarathna* > > *Associate Technical Lead* > > *WSO2, Inc. * > > *lean . enterprise . middleware * > > > *Email: prabat...@wso2.com * > > *Blog: http://prabu-lk.blogspot.com <http://prabu-lk.blogspot.com>* > > *Flicker : https://www.flickr.com/photos/47759189@N08 > <https://www.flickr.com/photos/47759189@N08>* > > *Mobile: +94 77 699 4730 * > > > > > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Technical Lead Technical Support-Bloomington US PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:*http://www.dushantech.com/ <http://www.dushantech.com/>* Mobile:(001)812-391-7441 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [Dev] WSO2 Message Broker 3.0.0 Milestone 7 Released !
Hi Something wrong with milestone release note, should include Improvements done, bug fixes inline rather providing link, please go with standard template we have Please refer other product's milestone releases. Cheers, Dushan On Wed, Apr 22, 2015 at 4:30 AM, Pumudu Ruhunage wrote: > *WSO2 Message Broker 3.0.0 Milestone 7 Released !* > > > The WSO2 Message Broker team is pleased to announce the 7th milestone > release of WSO2 Message Broker (MB) 3.0.0. > > WSO2 Message Broker (WSO2 MB) 3.0.0 is designed to be a fast, lightweight > and user friendly open source distributed message brokering system under > the Apache Software License v2.0 > <http://www.apache.org/licenses/LICENSE-2.0.html>. It primarily allows > system administrators and developers to easily configure JMS queues and > topics which could be used for message routing, message stores and message > processors. > > WSO2 MB is compliant with Advanced Message Queuing Protocol Version 0-9-1, > Java Message Service Specification version 1.1 and MQTT protocol version > 3.1. WSO2 MB 3.0.0 is developed on top of the revolutionary WSO2 Carbon > platform <http://wso2.org/projects/carbon> (Middleware a' la carte), an > OSGi based framework that provides seamless modularity to your SOA via > modularization. This release also contains many other new features and a > range of optional components (add-ons) that can be installed to customize > the behavior of the MB. Further, any existing features of the MB which are > not required to your environment can be easily removed using the underlying > provisioning framework of Carbon. In a nutshell, WSO2 MB can be fully > customized and tailored to meet your exact SOA needs. > > You can download this distribution from [1]. > > Release notes for this milestone can be found at [2]. > > Known issues are listed at [3]. > > This milestone has mainly focused on bug fixes and > performance improvements. > How You Can Contribute:Mailing Lists > > Join our mailing list and correspond with the developers directly. > >- > >Developer List : d...@wso2.org | Subscribe | Mail Archive ><http://wso2.org/mailarchive/carbon-dev/> >- > >User List : StackOverflow.com ><http://stackoverflow.com/questions/tagged/wso2> > > Reporting Issues > > WSO2 encourages you to report issues and your enhancement requests for the > WSO2 > MB using the public JIRA <https://wso2.org/jira/browse/MB>. > > You can also watch how they are resolved, and comment on the progress.. > > > [1] > https://svn.wso2.org/repos/wso2/scratch/MB/3.0.0/M7/wso2mb-3.0.0-SNAPSHOT-m7.zip > <https://www.google.com/url?q=https%3A%2F%2Fsvn.wso2.org%2Frepos%2Fwso2%2Fscratch%2FMB%2F3.0.0%2FM7%2Fwso2mb-3.0.0-SNAPSHOT-m7.zip&sa=D&sntz=1&usg=AFQjCNEj-PKEn-9ZHW0HM2CzMwsR_IyzhQ> > > [2] > https://wso2.org/jira/secure/ReleaseNote.jspa?projectId=10200&version=11766 > <https://www.google.com/url?q=https%3A%2F%2Fwso2.org%2Fjira%2Fsecure%2FReleaseNote.jspa%3FprojectId%3D10200%26version%3D11766&sa=D&sntz=1&usg=AFQjCNH50zjXZAR9qR6UZm5RIphFHqD15A> > > [3] > https://wso2.org/jira/browse/MB#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel > > > -- > Pumudu Ruhunage > Associate Software Engineer | WSO2 Inc > M: +94 779 664493 | http://wso2.com > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Technical Lead Technical Support-Bloomington US PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(001)812-391-7441 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Milestone for GSS connector for ESB
Hi Better if you send more descriptive mail as audience should be able to understand what you gonna do, which API's gonna utilized (your approach) what's the purpose of GSS why we should implement this etc etc, idea of whole these efforts in architecture list not only implement connector... (appreciate, people who will implement connector/s take this as note) Cheers, Dushan On Fri, Feb 27, 2015 at 3:20 AM, Naasheer Ali wrote: > Hi > > Please find the milestone plan for developing GSS connector [1] > > [1.] > GSS V3 Milestone > <https://docs.google.com/a/wso2.com/spreadsheets/d/1naAkCy0RwyXqJa9R-pjo4bvc5EXPoDm7O-cxGO7Yw10/edit?usp=drive_web> > > > Regards, > -- > > *Naasheer Ali* | Associate Software Engineer > > WSO2, Inc |#20, Palm Grove, Colombo 03, Sri Lanka > > Email: naashe...@wso2.com > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Connector Gmail through REST API
Hi Have wrote anything related to sending attachments ? Cheers, Dushan On Sun, Mar 1, 2015 at 6:30 AM, Vanjikumaran Sivajothy wrote: > Hi Sriashalaya, > > As a very first step, please review among with your peers. > > Best Regards, > vanji > > On Fri, Feb 27, 2015 at 6:07 PM, Sriashalya Srivathsan > wrote: > >> Hi Vanji, >> Please find my pull request below. >> https://github.com/wso2/esb-connectors/pull/69 >> >> Thank you, >> >> On Fri, Feb 27, 2015 at 4:27 PM, Vanjikumaran Sivajothy >> wrote: >> >>> Create the connector artifact with the proper name and send the pull >>> request to wso2 git repo! >>> >>> On Fri, Feb 27, 2015 at 4:14 PM, Sriashalya Srivathsan >> > wrote: >>> >>>> Hi All, >>>> I finished my first mile stone of Gmail connector through REST >>>> API.Please find the deliverables below. >>>> >>>>- >>>> >>>> https://docs.google.com/a/wso2.com/spreadsheets/d/1vkcOk9f0OiIvDcxXW-gs_Dq1W6i2zj9deZKs0gpPT-k/edit#gid=0 >>>>- >>>>https://docs.wso2.com/display/CONNECTORS/Gmail+Connector+Through+REST >>>>- >>>> >>>> https://github.com/ashalya/esb-connectors/tree/master/gmailThroughREST/gmail-connector/gmail-connector-1.0.0/org.wso2.carbon.connector >>>> >>>> Thank you, >>>> Regards, >>>> -- >>>> S.Sriashalya, >>>> Associate Software Engineer, >>>> WSO2. >>>> >>> >>> >>> >>> -- >>> Sivajothy Vanjikumaran >>> *Senior Software Engineer* >>> *Integration Technologies Team* >>> *WSO2 Inc. http://wso2.com <http://wso2.com/>* >>> *Mobile:(+94)777219209* >>> [image: Facebook] <https://www.facebook.com/vanjikumaran> [image: >>> Twitter] <https://twitter.com/vanjikumaran> [image: LinkedIn] >>> <http://www.linkedin.com/pub/vanjikumaran-sivajothy/25/b31/293> [image: >>> Blogger] <http://vanjikumaran.blogspot.com/> [image: SlideShare] >>> <http://www.slideshare.net/vanjikumaran> >>> >>> This communication may contain privileged or other >>> confidential information and is intended exclusively for the addressee/s. >>> If you are not the intended recipient/s, or believe that you may >>> have received this communication in error, please reply to the >>> sender indicating that fact and delete the copy you received and in >>> addition, you should not print, copy, re-transmit, disseminate, or >>> otherwise use the information contained in this communication. >>> Internet communications cannot be guaranteed to be timely, secure, error >>> or virus-free. The sender does not accept liability for any errors >>> or omissions >>> >> >> >> >> -- >> S.Sriashalya, >> Associate Software Engineer, >> WSO2. >> > > > > -- > Sivajothy Vanjikumaran > *Senior Software Engineer* > *Integration Technologies Team* > *WSO2 Inc. http://wso2.com <http://wso2.com/>* > *Mobile:(+94)777219209* > [image: Facebook] <https://www.facebook.com/vanjikumaran> [image: Twitter] > <https://twitter.com/vanjikumaran> [image: LinkedIn] > <http://www.linkedin.com/pub/vanjikumaran-sivajothy/25/b31/293> [image: > Blogger] <http://vanjikumaran.blogspot.com/> [image: SlideShare] > <http://www.slideshare.net/vanjikumaran> > > This communication may contain privileged or other > confidential information and is intended exclusively for the addressee/s. > If you are not the intended recipient/s, or believe that you may > have received this communication in error, please reply to the > sender indicating that fact and delete the copy you received and in > addition, you should not print, copy, re-transmit, disseminate, or > otherwise use the information contained in this communication. > Internet communications cannot be guaranteed to be timely, secure, error > or virus-free. The sender does not accept liability for any errors > or omissions > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector : Instagram
Hi Yes, this looks good, please do share the project plan. (sorry for the late reply) cheers, Dushan On Wed, Jun 18, 2014 at 9:27 AM, Aloka Rathnayake < aloka.yasassri...@gmail.com> wrote: > Hi All, > > We have reviewed the operations of the API. Could any one please be kind > enough to review the details of the Instagram connector. > > Thank You. > Best Regards > Aloka > > > > On Mon, Jun 16, 2014 at 3:14 PM, Sampath Amarakoon < > sampathamarak...@gmail.com> wrote: > >> *Introduction* >> The Instagram API allows users to have access to user authentication, >> photos, friend connections, and other elements of the iPhone & Android >> application. >> >> *API* >> Instagram API v1 using the REST [1]. >> >> *Instagram API v1 Connector Summary* >> >>- Connector Name: instagram-connector-1.0.0 >>- Version: 1.0.0 >>- Technology: REST >> >> >> *Authentication* >> OAuth 2.0 protocol will be used for the authentication [2]. >> >> *Operations* >> Below listed methods are the operations that we are going to use from >> API. So, please let me know if you have any concerns on the below listed >> operations. >> >> 1. Users >> >>- getUserInfo -Get basic information about a user >>- getSelfFeed - Get the authenticated user's feed >>- getUserMediaRecent -Get the most recent media published by a user >>- getSelfMediaLiked - Get the authenticated user's list of media >>they've liked. >>- userSearch -Search for a user by name >> >> >> 2. Relationships >> >> >>- getUserFollows -Get the list of users this user follows. >>- getUserFollowedBy -Get the list of users this user is followed by. >>- getSelfRequestedBy -List the users who have requested this user's >>permission to follow. >>- getUserRelationship -Get information about a relationship to >>another user. >>- setUserRelationship -Modify the relationship between the current >>user and the target user. >> >> >> 3. Media >> >> >>- getMediaInfo -Get information about a media object. >>- mediaSearch -Search for media in a given area. (The time span is >>set to 7 days) >>- getMediaPopular -Get a list of what media is most popular at the >>moment >> >> >> 4. Comments >> >> >>- getMediaComment -Get a full list of comments on a media. >>- setMediaComment -Create a comment on a media. >>- deleteMediaComment -Remove a comment >> >> >> 5. Likes >> >> >>- getMediaLike - Get a list of users who have liked this media. >>- setMediaLike - Set a like on this media by the currently >>authenticated user. >>- deleteMediaLike - Remove a like on this media by the currently >>authenticated user. >> >> >> 6. Tags >> >> >>- getTagInfo -Get information about a tag object. >>- getTagRecent -Get a list of recently tagged media. >>- tagSearch -Search for tags by name. >> >> >> 7. Location >> >> >>- getLocationInfo -Get information about a location. >>- getLocationRecent -Get a list of recent media objects from a given >>location. >>- locationSearch -Search for a location by geographic coordinate. >> >> >> 8. Subcription >> >> >>- getSubscriptionRecent -Get recent media from a geography >>subscription that you created. >>- deleteSubscription - Delete recent media from a geography >>subscription that you created. >>- setSubscriptionUser - creates a subscriptions to receive >>notifications when users have registered with your appliction post >> new photos. >>- setSubscriptionTag - creates a subscription to receive >>notifications when a new photo is tagged with tags of your choosing. >> - setSubscriptionLocation - creates a subscription to receive >>notifications when new photos are posted and tagged with a specific >>location. >>- setSubscriptionGeography - creates a subscription to receive >>notifications when new photos are posted in an arbitary geographical >>location as defined by a center point and radius. >> >> >> [1]. http://instagram.com/developer/endpoints >> [2]. http://instagram.com/developer/authentication >> >> >> >> *Thanks & Regards Sampath Amarakoon* >> > > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Milestone Plan- Connector : Foursquare
Hi On Thu, Jun 19, 2014 at 11:40 AM, Asanki Fernando wrote: > Hi Dushan, > > I've sent a new email with the created google doc. Here's the link for > your convenience. > > > https://docs.google.com/spreadsheets/d/1QwZe1bCosrmqHbauotl5MiE3QRGVAR4ggH3JiIA887E/edit?usp=sharing > > > Thank you. > Best Regards, > Asanki Fernando. > Looks good please update status of completed items and pending, and let us know if required any help > > > > On Thu, Jun 19, 2014 at 11:36 AM, Dushan Abeyruwan > wrote: > >> link >> >> >> On Thu, Jun 19, 2014 at 11:31 AM, Asanki Fernando < >> iasankiferna...@gmail.com> wrote: >> >>> Done >>> >>> >>> On Thu, Jun 19, 2014 at 10:53 AM, Dushan Abeyruwan >>> wrote: >>> >>>> Create google doc >>>> >>>> >>>> On Wed, Jun 18, 2014 at 2:25 PM, Asanki Fernando < >>>> iasankiferna...@gmail.com> wrote: >>>> >>>>> Hi All, >>>>> >>>>> This's the milestone plan for the Foursquare connector. >>>>> >>>>> Thank you! >>>>> Best Regards, >>>>> Asanki Fernando. >>>>> MilestonePlan.ods >>>>> <https://docs.google.com/file/d/0B0IpfLVbrrBrY2o2cEtHbm4zcW8/edit?usp=drive_web> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dushan Abeyruwan | Associate Tech Lead >>>> Integration Technologies Team >>>> PMC Member Apache Synpase >>>> WSO2 Inc. http://wso2.com/ >>>> Blog:http://dushansview.blogspot.com/ >>>> Mobile:(0094)713942042 >>>> >>>> >>> >>> >>> -- >>> "Don't go through life, grow through life!!!" >>> >>> IAN Fernando >>> SLIIT >>> >> >> >> >> -- >> Dushan Abeyruwan | Associate Tech Lead >> Integration Technologies Team >> PMC Member Apache Synpase >> WSO2 Inc. http://wso2.com/ >> Blog:http://dushansview.blogspot.com/ >> Mobile:(0094)713942042 >> >> > > > -- > "Don't go through life, grow through life!!!" > > IAN Fernando > SLIIT > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Milestone Plan- Connector : Foursquare
Create google doc On Wed, Jun 18, 2014 at 2:25 PM, Asanki Fernando wrote: > Hi All, > > This's the milestone plan for the Foursquare connector. > > Thank you! > Best Regards, > Asanki Fernando. > MilestonePlan.ods > <https://docs.google.com/file/d/0B0IpfLVbrrBrY2o2cEtHbm4zcW8/edit?usp=drive_web> > > > > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector: Tumblr
Hi I think you do cover all CURD operations related to post blogs (text,photo,queue,link,audio,video,answer) ? How audio/video upload happens ? have you done any background search ? anyway, looks good to me please do share Project plan across Cheers, Dushan On Wed, Jun 18, 2014 at 9:30 PM, Milinda Perera wrote: > Hi All, > > **Introduction** > > Tumblr is microblogging, social networking and content sharing website. > Users are able to reblog, use multimedia (images, videos, sound clips) > > **API** > > Tumblr API [1] <https://www.tumblr.com/docs/en/api/v2> > > **Tumblr Connector Summary** > > • Connector Name: tumblr-connector-1.0.0 > > • Version: 1.0.0 > > • Technology: REST > > **Authentication** > > Supports OAuth 1.0a protocol > > **Selected methods** > > General Blog Methods: > > > getBlogInfo - retrieve general information about the blog (title, > number of posts, and other high-level data) > > getBlogAvatar - retrieve blog's avatar > > getFollowers - retrieve followers of the blog > > > Blog post Methods: > > > getPosts - retrieve posts (can retrieve all posts, specified number > of posts, specific types of posts (text, quote, link, answer, video, audio, > photo, chat), or a post specified by the ID) > > getQueuedPosts - retrieve queued posts > > getDraftPosts - retrieve drafted posts > getSubmissionPost ** - retrieve submission posts > > createPost - create new blog post > > editPost - edit existing blog post > > reblogPost - reblog a blog post > > deletePost - delete blog post > > > User Methods: > > > getUserInfo - retrieve the user's account information that matches > the OAuth credentials submitted with the request > > getUserDashboard - retrieve the dashboard > > getUserLikes - retrieve the liked posts > > getFollowingPosts - retrieve the blogs followed by the user > > follow - follow a blog > > unfollow - unfollow a blog > > like - like blog post > > unlike - unlike blog post > > > TaggedMethods: > > > getTaggedPosts - get posts with a given tag > > > > getSubmissionPost** [2] > <http://staff.tumblr.com/post/138478782/submissions> still unable to > tryout (waiting for approval for the submitted post by moderator) > > > [1] https://www.tumblr.com/docs/en/api/v2 > [2] http://staff.tumblr.com/post/138478782/submissions > > > Thanks, > Milinda > > > > -- > Milinda Perera > Software Engineer; > WSO2 Inc. http://wso2.com , > Mobile: (+94) 714 115 032 > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector:BrainTree
Hi It looks good to me, unless if no obligations to the license (FYI :Shevan please go through and confirm), also during implementation please pay special attention on handling responses (decline codes, and error codes). https://www.braintreepayments.com/docs/java/reference/processor_responses Cheers, dushan On Mon, Jun 16, 2014 at 3:54 PM, Rasika Hettige wrote: > Hi All > > As there are no suggestions, we will consider following as the final method > list for the connector. > > *Transactions* > cloneTransaction - Clone an existing transaction. > createTransaction - Create a Server-To-Server Transaction > getTransaction - Get details of a Transaction > refundTransaction - Refund a completed transaction > searchTransactions - Search through existing transactions > voidTransaction - Void a transaction (cancel). > submitTransactionForSettlement - Submit a transaction for settlement. > > *Customers* > createCustomer - Create a Customer on Server-To-Server > deleteCustomer- Delete a customer > getCustomer - Get customer details > searchCustomers - Search through existing customers > updateCustomer - Update an existing customer > > *Credit Cards* > createCreditCard - Create Credit Card > deleteCreditCard - Delete Credit Card > getCreditCard - Get details of a credit card > searchCreditCards - Search through existing Credit Cards > updateCreditCard - Update Credit Card Details > > *Addresses* > createAddress - Create a new address > deleteAddress - Delete an address > getAddressDetails - Get details of an address > updateAddress - Update address details > > *Plans* > getPlanDetails - Get details of a single pricing plan > > *Add-Ons* > getAddOnDetails - Get details for a single add-on > > *Discounts* > getDiscountDetails - Get details for single discount > > *Merchant Accounts* > createMerchantAccount - Create a new merchant account > getMerchantAccountDetails -Get details of an individual merchant account > updateMerchantAccount -Update a Merchant Account > > *Settlement Batch Summaries* > getSettlementBatchSummary - Get details of settlements on a particular day > > *Subscriptions* > createSubscription - Create Subscription > cancelSubscription - Cancel Subscription > searchSubscriptions - Search Subscriptions > updateSubscription - Update Subscriptions > retrySubscriptionCharge - Retry Subscription charge > getSubscription - Get Subscription Details > > Thanks & Regards > Rasika > > > > -- > View this message in context: > http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-BrainTree-tp98062p98219.html > Sent from the WSO2 Architecture mailing list archive at Nabble.com. > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Bitly API Architecture
Hi Can I know why you can't implement other functions in sub modules - Authentication <http://dev.bitly.com/authentication.html> - Request / Response Formats <http://dev.bitly.com/formats.html> - CORS (Cross Origin Resource Sharing) <http://dev.bitly.com/cors.html> - Rate Limiting <http://dev.bitly.com/rate_limiting.html> - Data APIs <http://dev.bitly.com/data_apis.html> - Links <http://dev.bitly.com/links.html> - Link Metrics <http://dev.bitly.com/link_metrics.html> - User Info/History <http://dev.bitly.com/user_info.html> - User Metrics <http://dev.bitly.com/user_metrics.html> - Bundles <http://dev.bitly.com/bundles.html> - Domains <http://dev.bitly.com/domains.html> - Deprecated <http://dev.bitly.com/deprecated.html> - API Console <http://dev.bitly.com/console.html> list down operations which you are not going to implement and could you brief why ? those are just a REST calls Cheers, Dushan On Wed, Jun 11, 2014 at 2:16 PM, Inoka Suresh Geenath wrote: > Hi All, > > Here we attached our project architecture. Please find attached document & > give any feedback for us. > > Team Members: > >- Inoka Suresh Geenath > - Jayomi Rajapakshe > > > -- > Thanks & Regards, > Inoka Suresh > BSc (Hons) in Computer Science (UCD) > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector: Foursquare
Why we have two mails for same connector? On Thu, Jun 12, 2014 at 6:49 PM, Asanki Fernando wrote: > Hi Malaka, > > Okay. Thanks for the comment. We'll start with the project plan. > > Best Regards, > Asanki > > > On Thu, Jun 12, 2014 at 6:34 PM, Malaka Silva wrote: > >> This looks good >> >> >> On Wed, Jun 11, 2014 at 12:49 AM, Asanki Fernando < >> iasankiferna...@gmail.com> wrote: >> >>> Introduction >>> >>> Foursquare makes apps that help people keep up and meet up with friends, >>> and discover great places. Foursquare is for explorers who want to try out >>> the best spots and like to share the experiences with others. >>> >>> API >>> Foursquare API v2 using REST [1] [2] [3] >>> >>> >>> Foursquare Connector 1.0.0 >>> As the first version main aspect is to having the main CRUD operations >>> and the frequently used foursquare operations using the OAuth >>> authentication. >>> Technology - REST >>> >>> From the provided operations of the Foursquare API [3] below are the >>> selected methods to implement in the Foursquare Connector 1.0.0 >>> >>> *Selected Methods* >>> >>> >>>- Checkins >>> >>> checkinAdd - Allows you to check in to a place. >>> checkinAddComment - Comment on a check-in >>> checkinDeleteComment - Delete a comment on a check-in >>> checkinDetails - Get details of a check-in >>> checkinRecent - Getting a list of recent checkins from >>> friends. >>> >>> >>>- Users >>> >>> userDetails - Returns profile information. >>> userBadges - Returns badges for a given user. >>> userFriendList - Returns friend list of a given user. >>> userMayorships - Returns a user's mayorships. >>> userTips - Returns tips from a user. >>> userApproveFriend - Approve a friend request. >>> userUnfriend - Removes a friend. >>> userUpdate - Update the user's profile photo. >>> userCheckins - Returns a history of checkins for an >>> authenticated user. >>> >>> >>>- Tips >>> >>> tipsAdd - Allows to add a new tip. >>> tipsSearch - Returns a list of tips near the area >>> specified. >>> >>> Above are the selected methods to implement in Foursquare Connector from >>> provided Foursquare API resources [3]. According to the time scope given >>> and as this the 1st version of the Foursquare Connector we've selected the >>> above methods. We've not mentioned the methods that we've not selected >>> since there are lot of methods available in the API. >>> >>> Your suggestions are much appreciated. >>> >>> [1] https://developer.foursquare.com/docs/ >>> [2] https://developer.foursquare.com/start >>> [3] https://apigee.com/resources/foursquare >>> >>> Thanks, >>> Best Regards, >>> Asanki Fernando. >>> >>> >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> Best Regards, >> >> Malaka Silva >> Senior Tech Lead >> M: +94 777 219 791 >> Tel : 94 11 214 5345 >> Fax :94 11 2145300 >> Skype : malaka.sampath.silva >> LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 >> Blog : http://mrmalakasilva.blogspot.com/ >> >> WSO2, Inc. >> lean . enterprise . middleware >> http://www.wso2.com/ >> http://www.wso2.com/about/team/malaka-silva/ >> <http://wso2.com/about/team/malaka-silva/> >> >> Save a tree -Conserve nature & Save the world for your future. Print this >> email only if it is absolutely necessary. >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector:Skype
Hi I am having the same concern, as what Malaka has, I don't think this has a proper use case to go with ESB On Thu, Jun 12, 2014 at 6:00 PM, Malaka Silva wrote: > Hi Jarachanthan, > > I think skype only provides an api just to connect to client running on a > device. > > This connector does not provide any useful use case for an ESB. > > I guess there are better options for you like hubspot. > > http://developers.hubspot.com/docs/endpoints > > Best Regards, > Malaka > > > On Thu, Jun 12, 2014 at 4:22 AM, Jarachanthan Ratnakumar < > ratmin...@hotmail.com> wrote: > >> Hi all, >> To create an Skype connector for ESB, there is no comfortable API >> for that [1]. But there is Skype URI API [2]. >> Currently supporting >> >>- switch focus to client. >>- initiate video >>- audio call >>- instant messaging >> >> These can be done only when the Skype is already installed. So, how can I >> get a solution on creating a Skype connector? >> >> [1] http://www.infoworld.com/t/application-development/ >> microsoft-kills-skype-third-party-tools-the-desktop-230101 >> <http://www.infoworld.com/t/application-development/microsoft-kills-skype-third-party-tools-the-desktop-230101%29.But> >> [2] https://developer.skype.com/skype-uris >> >> Thank you >> R.Jarachanthan >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > Best Regards, > > Malaka Silva > Senior Tech Lead > M: +94 777 219 791 > Tel : 94 11 214 5345 > Fax :94 11 2145300 > Skype : malaka.sampath.silva > LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 > Blog : http://mrmalakasilva.blogspot.com/ > > WSO2, Inc. > lean . enterprise . middleware > http://www.wso2.com/ > http://www.wso2.com/about/team/malaka-silva/ > <http://wso2.com/about/team/malaka-silva/> > > Save a tree -Conserve nature & Save the world for your future. Print this > email only if it is absolutely necessary. > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector:Delicious
Hi Seems, you have covered all the required operations as defined in delicious API, anyway I would really like to see some meaningful samples once you complete these connector (probably in documentation), and please do share the project plan, please make sure you have to write proper integration tests as I discussed during the initial training session. Cheers, Dushan On Wed, Jun 11, 2014 at 2:09 PM, duleepa kasun wrote: > Hi All, > > *Introduction* > > > > *Delicious is a social bookmarking website - the primary use of delicious > is to store your bookmarks online, which allows you to access the same > bookmarks from any computer and add bookmarks from anywhere, too. On > delicious, you can use tags to organize and remember your bookmarks, which > is a much more flexible system than folders. * > > *The API provides read/write access to Delicious bookmarks and tags via an > HTTP-based interface. The RESTful API returns responses in XML.* > > *Delicious Connector Summary* > > > *• Connector Name: delicious-connector-1.0.0* > > *• Version: 1.0.0* > > *• Technology: REST* > Authentication > > Delicious API uses OAuth2 based authentication [1] > > *Posts* > > *postsUpdate — Check to see when a user last posted an item.* > > > > *postsAdd — Add a new bookmark. * > > > > *postsDelete— Delete an existing bookmark. * > > > > *postsGet — Get bookmark for a single date, or fetch specific items. * > > *postsRecent— Fetch recent bookmarks. * > > > > *postsDates — List dates on which bookmarks were posted. * > > > > *postsAll — Fetch all bookmarks by date or index range. * > > > > *postsAllHashes — Fetch a change detection manifest of all items. * > > > > *postsSuggest — Fetch popular, recommended and network tags for a specific > url. * > Tag Bundles > > *tagsBundlesAll — Fetch tag bundles * > > > > *tagsBundlesSet — Assign a set of tags to a bundle* > > *tagsBundlesDelete — Delete a tag bundle * > Tags > > *tagsGet — Fetch all tags. * > > *tagsDelete — Delete a tag from all posts. * > > > > *tagsRename — Rename a tag on all posts. * > > > *Above are the methods that is going to be implemented in the delicious > connector. We have taken all the methods that are supported by the current > delicious *API.[1] > > <https://github.com/SciDevs/delicious-api/tree/master/api> > * <https://github.com/SciDevs/delicious-api/tree/master/api>* > > *[1] https://github.com/SciDevs/delicious-api/tree/master/api > <https://github.com/SciDevs/delicious-api/tree/master/api>* > > > * <https://github.com/SciDevs/delicious-api/tree/master/api>* > Thank you, > Duleepa > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector:BrainTree
Hi Can I know license and terms of JDK it uses ? Cheers, Dushan On Wed, Jun 11, 2014 at 8:06 PM, Rasika Hettige wrote: > *Introduction* > A full stack payments platform for developers to build applications on top > of that. Available in US, Europe, Australia, and Canada, merchants can > accept payments in 130+ currencies. Has 'Venmo Touch' enables one touch > payments to reduce checkout friction. > > *API* > https://www.braintreepayments.com/docs/java/ > > *BrainTree Connector Summary* > • Connector Name: braintree-connector-1.0.0 > • Version: 1.0.0 > • Technology: Java SDK > > *Authentication* > Authentication is based on merchant id, public key and private key > > Methods Selected: > > *Transactions* > cloneTransaction - Clone an existing transaction. > createTransaction - Create a Server-To-Server Transaction > getTransaction - Get details of a Transaction > refundTransaction - Refund a completed transaction > searchTransactions - Search through existing transactions > voidTransaction - Void a transaction (cancel). > submitTransactionForSettlement - Submit a transaction for settlement. > > *Customers* > createCustomer - Create a Customer on Server-To-Server > deleteCustomer- Delete a customer > getCustomer - Get customer details > searchCustomers - Search through existing customers > updateCustomer - Update an existing customer > > *Credit Cards* > createCreditCard - Create Credit Card > deleteCreditCard - Delete Credit Card > getCreditCard - Get details of a credit card > searchCreditCards - Search through existing Credit Cards > updateCreditCard - Update Credit Card Details > > *Addresses* > createAddress - Create a new address > deleteAddress - Delete an address > getAddressDetails - Get details of an address > updateAddress - Update address details > > *Plans* > getPlanDetails - Get details of a single pricing plan > > *Add-Ons* > getAddOnDetails - Get details for a single add-on > > *Discounts* > getDiscountDetails - Get details for single discount > > *Merchant Accounts* > createMerchantAccount - Create a new merchant account > getMerchantAccountDetails -Get details of an individual merchant account > updateMerchantAccount -Update a Merchant Account > > *Settlement Batch Summaries* > getSettlementBatchSummary - Get details of settlements on a particular day > > *Subscriptions* > createSubscription - Create Subscription > cancelSubscription - Cancel Subscription > searchSubscriptions - Search Subscriptions > updateSubscription - Update Subscriptions > retrySubscriptionCharge - Retry Subscription charge > getSubscription - Get Subscription Details > > > Thanks & Regards > Rasika > > > > > > > > > -- > View this message in context: > http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-BrainTree-tp98062.html > Sent from the WSO2 Architecture mailing list archive at Nabble.com. > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector: Foursquare
Hi This looks good time, please do share project plan. Cheers, Dushan On Wed, Jun 11, 2014 at 2:07 PM, Amaaniy Muhammad wrote: > > > Introduction > > Foursquare makes apps that help people keep up and meet up with friends, > and discover great places. Foursquare is for explorers who want to try out > the best spots and like to share the experiences with others. > > API > Foursquare API v2 using REST [1] [2] [3] > > > Foursquare Connector 1.0.0 > As the first version main aspect is to having the main CRUD operations and > the frequently used foursquare operations using the OAuth2 authentication. > Technology - REST > > From the provided operations of the Foursquare API [3] below are the > selected methods to implement in the Foursquare Connector 1.0.0 > > *Selected Methods* > > >- Checkins > > checkinAdd - Allows you to check in to a place. > checkinAddComment - Comment on a check-in > checkinDeleteComment - Delete a comment on a check-in > checkinDetails - Get details of a check-in > checkinRecent - Getting a list of recent checkins from friends. > > >- Users > > userDetails - Returns profile information. > userBadges - Returns badges for a given user. > userFriendList - Returns friend list of a given user. > userMayorships - Returns a user's mayorships. > userTips - Returns tips from a user. > userApproveFriend - Approve a friend request. > userUnfriend - Removes a friend. > userUpdate - Update the user's profile photo. > userCheckins - Returns a history of checkins for an > authenticated user. > > >- Tips > > tipsAdd - Allows to add a new tip. > tipsSearch - Returns a list of tips near the area specified. > > Above are the selected methods to implement in Foursquare Connector from > provided Foursquare API resources [3]. According to the time scope given > and as this the 1st version of the Foursquare Connector we've selected the > above methods. > We've not mentioned the methods that we've not selected since there are > lot of methods available in the API. > > > Your suggestions are much appreciated. > > [1] https://developer.foursquare.com/docs/ > [2] https://developer.foursquare.com/start > [3] https://apigee.com/resources/foursquare > > > Thanks, > Best Regards, > Amaaniy M. > > > > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector:Wordpress
Hi Looks good since it has very generic REST APIs, so complexity should be less anyway Notifications,Batch seems not complex shall we include them as well? anyway please do share the project plan before startup Cheers, Dushan On Wed, Jun 11, 2014 at 11:36 AM, Asinsala Ratnayake wrote: > Hi All, > > > Introduction > WordPress is a free and open source blogging tool and a content management > system (CMS) based on PHP and MySQL. It is the most popular blogging system > in use on the Web. > > API > Wordpress REST API [1] > > Wordpress Connector Summary > • Connector Name: wordpress-connector-1.0.0 > • Version: 1.0.0 > • Technology: REST > > Authentication > Wordpress API uses OAuth2 based authentication [2] > > Selected methods: > >- Users >- listUsers -List the users of the blog > > >- Sites >- getSiteInfo -Retrieve Information about a site/domain > > >- Posts >- createPost -Create a new post > - updatePost -Edit a post > - deletePost - Delete a post > - getPost -Returns a single post > - getPosts -Returns matching posts, by default this will return all > the posts > - getPostbySlug -Returns a single post by the slug (slug is the > name used for the post in URL) > - likePost - Like a post > - listLikes - Returns a list of likes for a post > > >- Comments >- createComment - Create a comment on a post > - getComments - Returns recent comment for a particular post > - getRecentComments - Returns recent comments > - editComment - Edit a single comment > - deleteComment - Delete a single comment > > - >- Taxonomy > - getCategories - Returns a list of site categories > - createCategory - Create a new category > - editCategory - Edit a category > - deleteCategory - Delete a category > - getTags - Returns a list of site tags > - createTags - Create a new tag > - editTag - Edit a tag > - deleteTags - Delete a tag > > >- Follow >- getFollowers - List a site's followers in reverse chronological order > - followBlog - Follow the specified blog > - unfollowBlog - Unfollow the specified blog > > >- Reader >- getFollowingBlogPosts - Returns the list of posts from the blogs > followed by the user > - subscribeTag - Subscribe to a new tag > - unsubscribeTag - Unsubscribe from a tag > > >- Stats >- getStats - Get a site's stats > - getVisitorsCount - View visitor counts for a site > - getViewsByCountry - View a site's views by country > - getSearchTerms - View search terms used to find the site > > > > Methods not selected: > Above mentioned are the selected methods for the version 1.0.0. The > methods which are not selected are not listed here since there are quit a > lot of methods available in the API > > [1] https://developer.wordpress.com/docs/api > <https://developer.wordpress.com/docs/api> > [2] https://developer.wordpress.com/docs/oauth2 > <https://developer.wordpress.com/docs/oauth2> > > > > > > *Thanks & Regards Asinsala * > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector:Gooddata
Hi Based on the API ,seems it offers more functionalists, Refer, Project Model, Generate MAQL for Project Model,Execute and Validate Project Model, any reason why we have decided to drop methods it has ? Anyway have you guys conducted a survey on which methods are most significant IMO by looking at these there more methods we need implement rather what you have suggested. Cheers, Dushan On Fri, May 23, 2014 at 7:11 PM, Rasika Hettige wrote: > *Introduction* > > GoodData is a business intelligence platform. It helps users and companies > to store, combine, analyze and visualize information. > > > *API (REST)* > http://docs.gooddata.apiary.io/ > > *GoodData Connector Summary* > • Connector Name: gooddata-connector-1.0.0 > • Version: 1.0.0 > • Technology: REST > > *Authentication* > Using the login API resource, a username and password are authenticated and > Super Secure Token (SST) is returned if the authentication is valid. Using > this SST, a Temporary Token (TT) is then returned which is subjected to > expire. > > *Methods* > > createLogin - Use to log into the API. > getAuthenticationToken - Get the authentication token on this resource. > createProjectModel - Execute MAQL DDL Scripts for data model management. > getTaskStatus - Retrieve the asynchronous task status. > uploadData - Upload data using this method. > getUploadStatus - Get the upload status. > getDataset - Get the status of data uploads for specific dataset. > listReports - Use this method to list all Reports in given Project > creatReport - You need to create Report Definition using this resource. > saveReport - Save a created Report. > executeReport - Use this method to execute selected Report. > listProcesses - List Processes in a project. > createProcessWithMultipart - Create new data loading process with one > single > multipart http request. > listProcessExecution - List Processes of the given User in all Projects. > executeProcess - Execute a Process. > > Thanks & Regards > Rasika > > > > -- > View this message in context: > http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-Gooddata-tp97207.html > Sent from the WSO2 Architecture mailing list archive at Nabble.com. > _______ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB semantics
Hi On Fri, Apr 4, 2014 at 12:07 PM, Paul Fremantle wrote: > I've been discussing the ESB semantics with the cloud tooling team and we > had a very interesting thought process yesterday. > > The first starting point is that I think we can simplify away from the > in/out/fault sequence model. > > The new call and respond mediators mean that any API or Proxy can be > defined by a single sequence that calls other sequences and then moves on, > and finally responds (or not). > > This model (which has been discussed before) makes service chaining much > simpler. > Yes, IMO this will simplify service chaining, and it was well discussed during the initial architectural discussion when connector framework was designing. > > Having described this model we then started describing the rest of the > semantics to the tools guys and Tyler made a very interesting pair of > observations. > The first observation was why separate sequence and template. A template > is just a sequence with parameters, and a sequence is just a template with > zero parameters. (I'm ignoring endpoint templates etc for the moment, but > maybe the same applies to them?) > Yes, template is a sort of a sequence,but idea is template it self is a kind of function IMO, a user can utilize them as skeleton and also template it self has a functional scope, so it brings cleaner approach and improve the re-usability, for the same reason we need a separation from sequences from re-usable functions then, that's how templates came in to the picture. The second was that the proxy/api/tasks are all ways of kicking off a > sequence. Of course if you have multiple sequences/targets/etc in a proxy, > then its not like a task. But if you have a single sequence, with the > target service(s) as a parameter(s) then it is very similar to a task. So > his suggestion is that we create a meta concept of > "orchestrators"/"actuators"/"activators". We didn't decide on a name for > these but I personally like activators. > > In other words there are basically just two types of things: sequences > (which do stuff) and activators (which activate sequences). > Would like a more detail discussion on this. > > Paul > > -- > Paul Fremantle > CTO and Co-Founder, WSO2 > OASIS WS-RX TC Co-chair, Apache Member > > UK: +44 207 096 0336 > US: +1 646 595 7614 > > blog: http://pzf.fremantle.org > twitter.com/pzfreo > p...@wso2.com > > wso2.com Lean Enterprise Middleware > > Disclaimer: This communication may contain privileged or other > confidential information and is intended exclusively for the addressee/s. > If you are not the intended recipient/s, or believe that you may have > received this communication in error, please reply to the sender indicating > that fact and delete the copy you received and in addition, you should not > print, copy, retransmit, disseminate, or otherwise use the information > contained in this communication. Internet communications cannot be > guaranteed to be timely, secure, error or virus-free. The sender does not > accept liability for any errors or omissions. > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Inbound Endpoint support for ESB
t;>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> The inbound endpoint will be a new construct in ESB which goes at the >>>>>> top level as with proxy services, APIs etc. >>>>>> >>>>>> I have completed the initial work related to inbound EP and >>>>>> implemented a basic JMS inbound EP. Also I've verified the functionality >>>>>> in >>>>>> super tenant and tenant mode as well. >>>>>> Ravi is working on getting the end to end scenario working for JMS >>>>>> Inbound EP. >>>>>> >>>>>> Please review the design and share your thoughts. >>>>>> >>>>>> Thanks, >>>>>> Kasun >>>>>> >>>>>> -- >>>>>> Kasun Indrasiri >>>>>> Software Architect >>>>>> WSO2, Inc.; http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> >>>>>> cell: +94 77 556 5206 >>>>>> Blog : http://kasunpanorama.blogspot.com/ >>>>>> >>>>>> ___ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Jeewantha Dharmaparakrama >>>>> Software Engineer; WSO2, Inc.; http://wso2.com/ >>>>> Phone : (+94) 774726790 >>>>> Skype : prasad.jeewantha >>>>> LinkedIn : http://www.linkedin.com/in/jeewanthad >>>>> Twitter: https://twitter.com/jeewamp >>>>> Blog: http://jeewanthad.blogspot.com/ >>>>> >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Paul Fremantle >>>> CTO and Co-Founder, WSO2 >>>> OASIS WS-RX TC Co-chair, Apache Member >>>> >>>> UK: +44 207 096 0336 >>>> US: +1 646 595 7614 >>>> >>>> blog: http://pzf.fremantle.org >>>> twitter.com/pzfreo >>>> p...@wso2.com >>>> >>>> wso2.com Lean Enterprise Middleware >>>> >>>> Disclaimer: This communication may contain privileged or other >>>> confidential information and is intended exclusively for the addressee/s. >>>> If you are not the intended recipient/s, or believe that you may have >>>> received this communication in error, please reply to the sender indicating >>>> that fact and delete the copy you received and in addition, you should not >>>> print, copy, retransmit, disseminate, or otherwise use the information >>>> contained in this communication. Internet communications cannot be >>>> guaranteed to be timely, secure, error or virus-free. The sender does not >>>> accept liability for any errors or omissions. >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Pamod Sylvester * >>> * Software Engineer * >>> Integration Technologies Team, WSO2 Inc.; http://wso2.com >>> email: pa...@wso2.com cell: +94 77 7779495 >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Ravi Undupitiya* >> Software Engineer; WSO2 Inc.; http://wso2.com >> >> >> *E-mail: r...@wso2.com <http://wso2.com>**M: **+94 772 930 712 >> <%2B94%C2%A0772%20930%20712>* >> >> Lean . Enterprise . Middleware >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > Best Regards, > > Malaka Silva > Senior Tech Lead > M: +94 777 219 791 > Tel : 94 11 214 5345 > Fax :94 11 2145300 > Skype : malaka.sampath.silva > LinkedIn : http://www.linkedin.com/pub/malaka-silva/6/33/77 > Blog : http://mrmalakasilva.blogspot.com/ > > WSO2, Inc. > lean . enterprise . middleware > http://www.wso2.com/ > http://www.wso2.com/about/team/malaka-silva/<http://wso2.com/about/team/malaka-silva/> > > Save a tree -Conserve nature & Save the world for your future. Print this > email only if it is absolutely necessary. > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector: Flickr
Hi Yes, As Samisa suggested you should include security mechanism; For flicker you need to obtain API_KEY for further access. Ideally you should include followings [1] to your implementation, anyway please do come up with proper method names you can't have (.) embed methods implemented within connector which violate the rules of connector operations. [1] auth - *flickr.auth.checkToken <https://www.flickr.com/services/api/flickr.auth.checkToken.html>* - *flickr.auth.getFrob <https://www.flickr.com/services/api/flickr.auth.getFrob.html>* - *flickr.auth.getFullToken <https://www.flickr.com/services/api/flickr.auth.getFullToken.html>* - *flickr.auth.getToken <https://www.flickr.com/services/api/flickr.auth.getToken.html>* auth.oauth - *flickr.auth.oauth.checkToken <https://www.flickr.com/services/api/flickr.auth.oauth.checkToken.html>* - *flickr.auth.oauth.getAccessToken <https://www.flickr.com/services/api/flickr.auth.oauth.getAccessToken.html>* Cheers, Dushan On Thu, Mar 20, 2014 at 4:35 PM, Samisa Abeysinghe wrote: > What is the security mechanism? > > Thanks, > Samisa... > > > Samisa Abeysinghe > > Vice President Developer Evangelism > > WSO2 Inc. > http://wso2.com > > > > On Thu, Mar 20, 2014 at 3:58 PM, Nalin Chandraratne wrote: > >> *Introduction* >> The Flickr API is a powerful way to interact with Flickr accounts. With >> the API, you can read almost all the data associated with pictures and >> sets. You can also upload pictures through the API and change/add picture >> information. >> >> *Connector Summery* >> Name : Flickr >> API Version : 1.0 >> Technology : REST with ESB templates. >> API url : https://www.flickr.com/services/api/ >> >> *Selected Method List* >> The API provides *200+ methods*. Out of those methods we have selected >> the following methods to be implemented in the first round, within the >> given time frame. >> >> photos >> >>- *flickr.photos.addTags >><https://www.flickr.com/services/api/flickr.photos.addTags.html>* >>- *flickr.photos.delete >><https://www.flickr.com/services/api/flickr.photos.delete.html>* >>- *flickr.photos.getCounts >><https://www.flickr.com/services/api/flickr.photos.getCounts.html>* >>- *flickr.photos.getExif >><https://www.flickr.com/services/api/flickr.photos.getExif.html>* >>- *flickr.photos.getFavorites >><https://www.flickr.com/services/api/flickr.photos.getFavorites.html>* >>- *flickr.photos.getInfo >><https://www.flickr.com/services/api/flickr.photos.getInfo.html>* >>- *flickr.photos.getNotInSet >><https://www.flickr.com/services/api/flickr.photos.getNotInSet.html>* >>- *flickr.photos.getPerms >><https://www.flickr.com/services/api/flickr.photos.getPerms.html>* >>- *flickr.photos.getRecent >><https://www.flickr.com/services/api/flickr.photos.getRecent.html>* >>- *flickr.photos.getSizes >><https://www.flickr.com/services/api/flickr.photos.getSizes.html>* >>- *flickr.photos.removeTag >><https://www.flickr.com/services/api/flickr.photos.removeTag.html>* >>- *flickr.photos.search >><https://www.flickr.com/services/api/flickr.photos.search.html>* >>- *flickr.photos.setContentType >><https://www.flickr.com/services/api/flickr.photos.setContentType.html>* >>- *flickr.photos.setDates >><https://www.flickr.com/services/api/flickr.photos.setDates.html>* >>- *flickr.photos.setMeta >><https://www.flickr.com/services/api/flickr.photos.setMeta.html>* >>- *flickr.photos.setTags >><https://www.flickr.com/services/api/flickr.photos.setTags.html>* >> >> photos.comments >> >>- *flickr.photos.comments.addComment >> >> <https://www.flickr.com/services/api/flickr.photos.comments.addComment.html>* >>- *flickr.photos.comments.deleteComment >> >> <https://www.flickr.com/services/api/flickr.photos.comments.deleteComment.html>* >>- *flickr.photos.comments.editComment >> >> <https://www.flickr.com/services/api/flickr.photos.comments.editComment.html>* >>- *flickr.photos.comments.getList >><https://www.flickr.com/services/api/flickr.photos.comments.getList.html>* >>- *flickr.photos.comments.getRecentForContacts >> >> <https://www.flickr.com/services/api/flickr.photos.comments.getRecentForContacts.html>* >> >> test >> >>- *fl
Re: [Architecture] Connector:Google Tasks
Hi Looks good, anyway how is OAuth working ? Better follow up Google Drive connector implementation instead. Cheers, Dushan On Thu, Mar 20, 2014 at 2:48 PM, Madhawa Bandara wrote: > Yes. > > > On Thu, Mar 20, 2014 at 2:41 PM, Samisa Abeysinghe wrote: > >> And use ESB templates? >> >> Thanks, >> Samisa... >> >> >> Samisa Abeysinghe >> >> Vice President Developer Evangelism >> >> WSO2 Inc. >> http://wso2.com >> >> >> >> On Thu, Mar 20, 2014 at 2:39 PM, Madhawa Bandara wrote: >> >>> Hi, >>> I will be using Google Tasks REST API. >>> >>> >>> On Thu, Mar 20, 2014 at 2:36 PM, Samisa Abeysinghe wrote: >>> >>>> What is the implementation technology you are going to use? In other >>>> words, how do you plan to invoke the APIs? >>>> >>>> Thanks, >>>> Samisa... >>>> >>>> >>>> Samisa Abeysinghe >>>> >>>> Vice President Developer Evangelism >>>> >>>> WSO2 Inc. >>>> http://wso2.com >>>> >>>> >>>> >>>> On Thu, Mar 20, 2014 at 2:25 PM, Madhawa Bandara wrote: >>>> >>>>> *Introduction* >>>>> The Google Tasks API provides developers a set of API endpoints for >>>>> searching, reading, and updating Google Tasks content and metadata. >>>>> >>>>> *Google Tasks Connector Summery* >>>>> * Connector Name: GoogleTasks >>>>> * API Version: v1 >>>>> * Technology: REST >>>>> * API Url: >>>>> https://developers.google.com/google-apps/tasks/<https://api.surveymonkey.net/> >>>>> >>>>> Selected Methods (14) for version 1.0.0 >>>>> >>>>> Methods for the Tasklist operations: >>>>> >>>>> *list*- Returns all the authenticated user's task lists. >>>>> *get*- Returns the authenticated user's specified task list. >>>>> *insert*- Creates a new task list and adds it to the authenticated >>>>> user's task lists. >>>>> *update*- Updates the authenticated user's specified task list. >>>>> *delete*- Deletes the authenticated user's specified task list. >>>>> *patch*- Updates the authenticated user's specified task list. This >>>>> method supports patch semantics. >>>>> >>>>> Methods for the Tasks operations: >>>>> >>>>> *list*- Returns all tasks in the specified task list. >>>>> *get*- Returns the specified task. >>>>> *insert*- Creates a new task on the specified task list. >>>>> *update*- Updates the specified task. >>>>> *delete*- Deletes the specified task from the task list. >>>>> *clear*- Clears all completed tasks from the specified task list. The >>>>> affected tasks will be marked as 'hidden' and no longer be returned by >>>>> default when retrieving all tasks for a task list. >>>>> *move*- Moves the specified task to another position in the task >>>>> list. This can include putting it as a child task under a new parent >>>>> and/or >>>>> move it to a different position among its sibling tasks. >>>>> *patch*- Updates the specified task. This method supports patch >>>>> semantics. >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> *Madhawa Bandara* >>>>> Software Engineer >>>>> WSO2, Inc. >>>>> lean.enterprise.middleware >>>>> >>>>> Mobile - *+94777487726* >>>>> >>>> >>>> >>> >>> >>> -- >>> Regards, >>> >>> *Madhawa Bandara* >>> Software Engineer >>> WSO2, Inc. >>> lean.enterprise.middleware >>> >>> Mobile - *+94777487726* >>> >> >> > > > -- > Regards, > > *Madhawa Bandara* > Software Engineer > WSO2, Inc. > lean.enterprise.middleware > > Mobile - *+94777487726* > -- Dushan Abeyruwan | Associate Tech Lead Integration Technologies Team PMC Member Apache Synpase WSO2 Inc. http://wso2.com/ Blog:http://dushansview.blogspot.com/ Mobile:(0094)713942042 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Connector:SurveyMonkey
Hi
Can't we find a better approach of getting access-token, this has to be
automated (better approach is to use OAuth 2.0 flow) implemented within
the connector rather passing access?
[1] https://developer.surveymonkey.com/mashery/guide_oauth
Cheers,
Dushan
On Fri, Mar 14, 2014 at 8:02 PM, indika prasad wrote:
> *Introduction*
> SurveyMonkey is the world's leading provider of web-based survey solutions,
> helping people gather the insights they need to make more informed
> decisions.
>
> *SurveyMonkey Connector Summery*
> * Connector Name: SurveyMonkey
> * API Version: v2
> * Technology: REST
> * API Url: https://api.surveymonkey.net
>
>
> *Authentication*
>oauth2 access token use to access the API [0] method.
>
> Selected Methods (8) for version 1.0.0
>
> *getSurveyList *- Retrieves a paged list of survey user's
> account.
> *getSurveyDetails *- Retrieve a given survey's metadata.
> *getCollectorList *- Retrieves a paged list of collectors for a
> survey in a
> user's account.
> *getRespondentList *- Retrieves a paged list of respondents for a
> given
> survey and optionally collector
> *getResponses *- Takes a list of respondent ids and returns the
> responses
> that correlate to them. To be used with 'getSurveyDetails'
> *getResponseCounts *- Returns how many respondents have started
> and/or
> completed the survey for the given collector
> *getUserDetails *- Returns basic information about the logged-in
> user
> *init *- Config operation
>
> /Note:
> All API requests return HTTP 200 (OK) with a JSON payload that includes a
> status key containing one of the following codes. [1]
> 0 Success
> 1 Not Authenticated
> 2 Invalid User Credentials
> 3 Invalid Request
> 4 Unknown User
> 5 System Error
>
>Example Response:
> {
> "data": {
> "completed": 10,
> "started": 1
> },
> "status": 0
> }/
>
> [0] https://developer.surveymonkey.com/mashery/authentication
> [1] https://developer.surveymonkey.com/mashery/requests_responses
>
> Thanks
> Indika Kularathne
>
>
>
>
> --
> View this message in context:
> http://wso2-oxygen-tank.10903.n7.nabble.com/Connector-SurveyMonkey-tp93510.html
> Sent from the WSO2 Architecture mailing list archive at Nabble.com.
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
--
Dushan Abeyruwan | Associate Tech Lead
Integration Technologies Team
PMC Member Apache Synpase
WSO2 Inc. http://wso2.com/
Blog:http://dushansview.blogspot.com/
Mobile:(0094)713942042
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] connector versioning
>>>>>>>> There are some cloud APIs which only maintains one version ( like >>>>>>>> twitter ). In those cases we don't have to have versions because in a >>>>>>>> given >>>>>>>> time there will be only one version. >>>>>>>> >>>>>>>> For cases like jira, we have to have different versions as jira >>>>>>>> 3,4,5 has completely different APIs. >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 14, 2013 at 11:55 AM, Manuranga Perera >>>>>>>> wrote: >>>>>>>> >>>>>>>>> isn't updating form one version to another of same connector a >>>>>>>>> common use cause (as opposed to using multiple versions)? >>>>>>>>> if so naming it like "sdfc_2.0" would not be ideal for migration. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> With regards, >>>>>>>>> *Manu*ranga Perera. >>>>>>>>> >>>>>>>>> >>>>>>>>> ___ >>>>>>>>> Architecture mailing list >>>>>>>>> Architecture@wso2.org >>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Miyuru Wanninayaka >>>>>>>> >>>>>>>> Technical Lead >>>>>>>> WSO2 Inc. : http://wso2.com >>>>>>>> >>>>>>>> Mobile : +94 77 209 9788 >>>>>>>> Blog : http://miyurudw.blogspot.com >>>>>>>> Flickr : http://www.flickr.com/photos/miyuru_daminda >>>>>>>> >>>>>>>> ___ >>>>>>>> Architecture mailing list >>>>>>>> Architecture@wso2.org >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Piyum Fernando >>>>>>> Software Engineer >>>>>>> >>>>>>> Mobile: +94 77 22 93 880 >>>>>>> Home: +94 31 22 75 715 >>>>>>> >>>>>>> ___ >>>>>>> Architecture mailing list >>>>>>> Architecture@wso2.org >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> -- >>>>>> Pulasthi Supun >>>>>> Software Engineer; WSO2 Inc.; http://wso2.com, >>>>>> Email: pulas...@wso2.com >>>>>> Mobile: +94 (71) 9258281 >>>>>> Blog : http://pulasthisupun.blogspot.com/ >>>>>> Git hub profile: https://github.com/pulasthi >>>>>> >>>>>> ___ >>>>>> Architecture mailing list >>>>>> Architecture@wso2.org >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> With regards, >>>>> *Manu*ranga Perera. >>>>> >>>>> phone : 071 7 70 20 50 >>>>> mail : m...@wso2.com >>>>> >>>>> ___ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Afkham Azeez* >>>> Director of Architecture; WSO2, Inc.; http://wso2.com >>>> Member; Apache Software Foundation; http://www.apache.org/ >>>> * <http://www.apache.org/>** >>>> email: **az...@wso2.com* * cell: +94 77 3320919 >>>> blog: **http://blog.afkham.org* <http://blog.afkham.org>* >>>> twitter: >>>> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >>>> * >>>> linked-in: **http://lk.linkedin.com/in/afkhamazeez* >>>> >>>> * >>>> * >>>> *Lean . Enterprise . Middleware* >>>> >>>> ___ >>>> Architecture mailing list >>>> Architecture@wso2.org >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Sanjiva Weerawarana, Ph.D. >>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ >>> email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880| +1 >>> 650 265 8311 >>> blog: http://sanjiva.weerawarana.org/ >>> >>> Lean . Enterprise . Middleware >>> >>> ___ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Kasun Indrasiri >> Software Architect >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> cell: +94 77 556 5206 >> Blog : http://kasunpanorama.blogspot.com/ >> >> ___ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Sanjiva Weerawarana, Ph.D. > Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/ > email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1 > 650 265 8311 > blog: http://sanjiva.weerawarana.org/ > > Lean . Enterprise . Middleware > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Dushan Abeyruwan Associate Tech Lead *Integration Technologies Team* *WSO2 Inc. http://wso2.com/* *Mobile:(+94)714408632* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Review with Paul and Sanjiva: {2013-08-28}
Hi Had a spacing issue the mail which I sent bit earlier, please find the notes with the correct format. *Connector Archive modification* - Connector list rename Import > enable. - Connector operations description > remove synapse library part in end. - Import[enable] link change once import is done. - Rename artifact.xml > connector.xml. in conncetor.xml change toot element to and as sub element <*connector*> <*component* name="twilio" package="org.wso2.carbon.connectors"> Synapse library for Twilio connector - *Icon inside connector archive* - this can be shown near the connector name in the UI. *New Language Re-factoring Proposals* - In seq only model ** * * * * * * * * *(questions: 1) which direction is the message in now? FORWARD 2) what is the payload? RESPONSE* * * * * * * ** - Timer method ** * * * * * * * * *(questions: 1) which direction is the message in now? FORWARD 2) what is the payload? RESPONSE* * * ** - In-out example ** * * * * * * * * *(questions: 1) which direction is the message in now? FORWARD 2) what is the payload? RESPONSE* * * * * * * ** ** *...* ** ** - Callout-nonblocking ( *<>* mediator a new mediator will be implemented instead ), - i,e call blocking =false - true default . - *depreciate* *Callout* mediator when *http://wso2.com/* *Mobile:(+94)714408632* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] ESB Review with Paul and Sanjiva: {2013-08-28}
Hi
There are some spacing issue will send another mail with correct format
Cheers
Dushan
On Fri, Aug 30, 2013 at 10:17 AM, Dushan Abeyruwan wrote:
> Hi
> Please find the notes for the discussion we had during the ESB review
> meeting,
>
>
> *Connector Archive modification*
>
>
>- Connector list rename Import > enable.
>- Connector operations description > remove synapse library part in
>end.
>- Import[enable] link change once import is done.
>- Rename artifact.xml > connector.xml.
>
> in conncetor.xml change toot element to and as
> sub element
>
>
> <*connector*>
>
> <*component* name="twilio" package="org.wso2.carbon.connectors">
>
>
> />
>
>
>
>
>
>
>
> Synapse library for Twilio
> connector
>
>
>
>
>
>
>
>- *Icon inside connector archive* - this can be shown near the
>connector name in the UI.
>
> *New Language Re-factoring Proposals*
>
>
>- In seq only model
>
>
>
>
>
>
>
>
>
>
> {new Non Blocking callout}
>
> (questions: 1) which direction is the message in now? FORWARD
> 2) what is the payload? RESPONSE
>
> {new Non Blocking callout}
>
>
>
>
>
>
>
>
>
>- Timer method
>
>
>
>
>
>
>
>
>
>
>
> (questions: 1) which direction is the message in now? FORWARD
> 2) what is the payload? RESPONSE
>
>
>
>
>
>
>
>- In-out example
>
>
>
>
>
>
>
>
>
>
>
> (questions: 1) which direction is the message in now? FORWARD
> 2) what is the payload? RESPONSE
>
>
>
>
>
>
>
>
>
>
>
>
> ...
>
>
>
>
>
>
>
>
>
>- Callout-nonblocking ( *<>* mediator a new mediator will be
>implemented instead ),
>- i,e call blocking =false - true default .
> - *depreciate* *Callout* mediator when *http://wso2.com/*
> *Mobile:(+94)714408632 *
>
--
Dushan Abeyruwan
Associate Tech Lead
*Integration Technologies Team*
*WSO2 Inc. http://wso2.com/*
*Mobile:(+94)714408632*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] ESB Review with Paul and Sanjiva: {2013-08-28}
Hi
Please find the notes for the discussion we had during the ESB review
meeting,
*Connector Archive modification*
- Connector list rename Import > enable.
- Connector operations description > remove synapse library part in end.
- Import[enable] link change once import is done.
- Rename artifact.xml > connector.xml.
in conncetor.xml change toot element to and as sub
element
<*connector*>
<*component* name="twilio" package="org.wso2.carbon.connectors">
Synapse library for Twilio
connector
- *Icon inside connector archive* - this can be shown near the connector
name in the UI.
*New Language Re-factoring Proposals*
- In seq only model
{new Non Blocking callout}
(questions: 1) which direction is the message in now? FORWARD
2) what is the payload? RESPONSE
{new Non Blocking callout}
- Timer method
(questions: 1) which direction is the message in now? FORWARD
2) what is the payload? RESPONSE
- In-out example
(questions: 1) which direction is the message in now? FORWARD
2) what is the payload? RESPONSE
...
- Callout-nonblocking ( *<>* mediator a new mediator will be
implemented instead ),
- i,e call blocking =false - true default .
- *depreciate* *Callout* mediator when *http://wso2.com/*
*Mobile:(+94)714408632 *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Cloud Connectors - Connector implementation with Java APIs
stem.out.println("TwitterID :" + twitterId);
>>>
>>>twitterId = "CDE";
>>>
>>>}
>>>
>>>
>>> public String getTwitterSecrect() {
>>>
>>> return twitterSecrect;
>>>
>>> }
>>>
>>> public void setTwitterSecrect(String twitterSecrect) {
>>>
>>>this.twitterSecrect = twitterSecrect;
>>>
>>>}
>>>
>>> public String getTwitterId() {
>>>
>>> return twitterId;
>>>
>>> }
>>>
>>> public void setTwitterId(String twitterId) {
>>>
>>>this.twitterId = twitterId;
>>>
>>>}
>>>
>>> public String getMessage() {
>>>
>>> return message;
>>>
>>> }
>>>
>>> public void setMessage(String message) {
>>>
>>>this.message = message;
>>>
>>>}
>>>
>>> }
>>>
>>>
>>> Invocation :
>>>
>>>
>>>
>>>
>>>http://ws.apache.org/ns/synapse";
>>>
>>> name="twitterId"
>>>
>>> expression="$ctx:TWID"
>>>
>>> action="ReadMessage"/>
>>>
>>> http://ws.apache.org/ns/synapse";
>>>
>>> name="twitterId"
>>>
>>> context-name="updatedID"
>>>
>>>
>>> action="UpdateContext"/>
>>>
>>>
>>>
>>>
>>>
>>> [1]
>>> https://svn.wso2.org/repos/wso2/carbon/platform/branches/4.1.0/components/mediation/mediation-library/connectors/org.wso2.carbon.mediation.library.connectors.twitter/4.1.0/src/main/java/org/wso2/carbon/mediation/library/connectors/twitter/TwitterUpdateStatusMediator.java
>>>
>>> [2]
>>> https://svn.wso2.org/repos/wso2/carbon/platform/branches/4.1.0/dependencies/synapse/2.1.1-wso2v3/modules/samples/src/main/java/samples/mediators/extensions/SpringCustomLogger.java
>>> --
>>> Kasun Indrasiri
>>> Software Architect
>>> WSO2, Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> cell: +94 71 536 4128
>>> Blog : http://kasunpanorama.blogspot.com/
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Miyuru Wanninayaka
>> Technical Lead
>> WSO2 Inc. : http://wso2.com
>>
>> Mobile : +94 77 209 9788
>> Blog : http://miyurudw.blogspot.com
>> Flickr : http://www.flickr.com/photos/miyuru_daminda
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Kasun Indrasiri
> Software Architect
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> cell: +94 71 536 4128
> Blog : http://kasunpanorama.blogspot.com/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Dushan Abeyruwan
Associate Tech Lead
*Integration Technologies Team*
*WSO2 Inc. http://wso2.com/*
*Mobile:(+94)714408632*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Proper way to secure configuration for Connectors
>>
>>>> Sanjiva.
>>>>
>>>>
>>>> On Wed, Jul 24, 2013 at 5:24 PM, Kasun Indrasiri wrote:
>>>>
>>>>>
>>>>> - How about not having twiiter.config element and instead we define
>>>>> that as a local entry as mentioned above. Then we only refer them when
>>>>> invoking an operation. (Virtually all operations have 'conf' as an
>>>>> optional
>>>>> parameter and if not specified it will use the existing values from the
>>>>> context)
>>>>>
>>>>> Hello, World (from
>>>>> Sanjiva)
>>>>> Hello, World 2 (from
>>>>> Sanjiva)
>>>>>
>>>>> Hello, World (from
>>>>> Samisa)
>>>>>
>>>>>
>>>>> On Wed, Jul 24, 2013 at 4:51 PM, Sanjiva Weerawarana >>>> > wrote:
>>>>>
>>>>>> On Wed, Jul 24, 2013 at 4:14 PM, Samisa Abeysinghe
>>>>>> wrote:
>>>>>>
>>>>>>> OK, so, it should be at proxy level. If there are two twitter
>>>>>>> connectors for a proxy, they will be defined as twitterYou and twitterMe
>>>>>>> within the proxy scope. And we can re-use them in sequences as we wish.
>>>>>>>
>>>>>>
>>>>>> I don't think I understand what that means ... connector "instances"
>>>>>> are not named - so what does twitterYou an twitterMe mean when there's no
>>>>>> config separated? If there's no config reference, there's only one config
>>>>>> in scope .. whatever was defined earlier in the sequence. So there's only
>>>>>> one around.
>>>>>>
>>>>>> If you want to do a status update as "you" vs "me" then you'd need to
>>>>>> reenter with the right creds and then use it (see
>>>>>> below).
>>>>>>
>>>>>> Dushan why are the properties named
>>>>>>>> synapse.runtime.oauth.accessToken?? There are two problems with this:
>>>>>>>> - this has NOTHING to do with Synapse so its wrong to
>>>>>>>> synapse.runtime.*.
>>>>>>>> - second, MORE IMPORTANTLY, many mediators will have an
>>>>>>>> oauth.accessToken property! So this will not work .. it needs to be
>>>>>>>> twitter.oauth.accessToken (which is what I said the first time IIRC).
>>>>>>>>
>>>>>>>
>>>>>> I made a mistake here .. the property names should be possible to be
>>>>>> arbitrary - otherwise we can't do Samisa's scenario above of tweeting as
>>>>>> X
>>>>>> and tweeting as Y:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> {vault-lookup('*sanjiva*
>>>>>> .twitter.oauth.consumerSecret')}
>>>>>>
>>>>>>
>>>>>> {vault-lookup('sanjiva.twitter.outh.accessTokenSecret')}
>>>>>>
>>>>>>
>>>>>> {vault-lookup('sanjiva.twitter.oauth.accessToken')}
>>>>>>
>>>>>>
>>>>>> {vault-lookup('sanjiva.twitter.oauth.consumerKey')}
>>>>>>
>>>>>> Hello, World (from
>>>>>> Sanjiva)
>>>>>>
>>>>>>
>>>>>>
>>>>>> {vault-lookup('*samisa*
>>>>>> .twitter.oauth.consumerSecret')}
>>>>>>
>>>>>>
>>>>>> {vault-lookup('saisa.twitter.outh.accessTokenSecret')}
>>>>>>
>>>>>>
>>>>>> {vault-lookup('samisa.twitter.oauth.accessToken')}
>>>>>>
>>>>>>
>>>>>> {vault-lookup('samisa.twitter.oauth.consumerKey')}
>>>>>>
>>>>>> Hello, World (from
>>>>>> Samisa)
>>>>>>
>>>>>>
>>>>>> Now someone just has to get the right info into the vault.
>>>>>>
>>>>>> Sanjiva.
>>>>>> --
>>>>>> Sanjiva Weerawarana, Ph.D.
>>>>>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
>>>>>> email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787
>>>>>> 6880 | +1 650 265 8311
>>>>>> blog: http://sanjiva.weerawarana.org/
>>>>>>
>>>>>> Lean . Enterprise . Middleware
>>>>>>
>>>>>> ___
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Kasun Indrasiri
>>>>> Software Architect
>>>>> WSO2, Inc.; http://wso2.com
>>>>> lean.enterprise.middleware
>>>>>
>>>>> cell: +94 71 536 4128
>>>>> Blog : http://kasunpanorama.blogspot.com/
>>>>>
>>>>> ___
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Sanjiva Weerawarana, Ph.D.
>>>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
>>>> email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880| +1
>>>> 650 265 8311
>>>> blog: http://sanjiva.weerawarana.org/
>>>>
>>>> Lean . Enterprise . Middleware
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> Thanks,
>>> Samisa...
>>>
>>> Samisa Abeysinghe
>>> VP Engineering
>>> WSO2 Inc.
>>> http://wso2.com
>>> http://wso2.org
>>>
>>
>>
>>
>> --
>>
>> Thanks,
>> Samisa...
>>
>> Samisa Abeysinghe
>> VP Engineering
>> WSO2 Inc.
>> http://wso2.com
>> http://wso2.org
>>
>
>
>
> --
> Viraj Rajaguru
> Software Engineer
> WSO2 Inc. : http://wso2.com
>
> Mobile: +94 77 3683068
>
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Dushan Abeyruwan
Associate Tech Lead
*Integration Technologies Team*
*WSO2 Inc. http://wso2.com/*
*Mobile:(+94)714408632*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Proper way to secure configuration for Connectors
Hi
Following modification introduced to the connector where parameters being
dropped instead it will be serialized as follows, the changers have
only introduced to connector related implementation and kept call-template
serialization mechanism unchanged since if do change that language it might
become a issue for the customers who are already using the exiting way
which keeping the parameters in call-templates.
[1]
* *
*http://services.samples";>
{//ser:xyz/ser:aaa/ccc}*
*
eWJ8jsreuKT5vbJmPEZi4Aw8zGemhBTS9iKXAMew
*
*
1114764380-5q5qZeANiRrq2W9fbBfRvHtByn6HvIDT6T3Tr98
*
*
{get-property('consumerKey')}*
* *
* *
* *
*hotel*
**
Cheers
Dushan
On Mon, Jul 22, 2013 at 9:10 AM, Dushan Abeyruwan wrote:
> Hi
>
>without doubt I am + 1 for the approach and it can be done:)
>>>
>>
>> +1. And make sure all mediators follow this pattern. Please don't say
>> this mediator has done by this team etc ... :). It is ESB teams
>> responsibility to have a common standards across all mediators :).
>>
>
> Yeah it's ESB team responsibility but I am waiting for
> the answers from IS team why they have followed such a Invalid approach in
> *Entitlement* *mediator* and they should (Must) answers this because up
> to now I haven't hard anything form IS why they took such approach
> I haven't see any @arch mail regarding entitlement mediator approach... :(
>
>
>> thanks,
>> Amila.
>>
>>
>>>
>>>
>>>
>>>>
>>>> The model of using vault-lookup() will work in the dev/test/stage/prod
>>>> lifecycle path as well - just use different vaults for the data.
>>>>
>>>> Sanjiva.
>>>>
>>>>
>>>> On Mon, Jul 22, 2013 at 7:10 AM, Amila Suriarachchi wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jul 20, 2013 at 10:22 PM, Dushan Abeyruwan wrote:
>>>>>
>>>>>> Hi All
>>>>>>
>>>>>> I have done required changes in synapse, there won't be any
>>>>>> existing API's effected due to the given changers , so the overall
>>>>>> process
>>>>>> will be as shown in [1] where attributes required encryption required to
>>>>>> embedded a key [*enc:] *so during the serialization it will be
>>>>>> saved as [2], and during run-time those encrypted values will
>>>>>> be decrypted using the *WSO2MediationSecurityInterceptor* ], the
>>>>>> give solution has implemented and tested in scratch environment and works
>>>>>> as expected.
>>>>>>
>>>>>>
>>>>>> [1] before saving to configuration embedded enc: for the filed
>>>>>> which requires encryption
>>>>>>
>>>>>>
>>>>>>>>>>> value="*enc:*mmm"/>
>>>>>>>>>>> value="*enc:*xxx"/>
>>>>>>>>>>> value="*enc:*eee"/>
>>>>>>>>>>> value="xx"/>
>>>>>>
>>>>>
>>>>> I am not a fan of this parameter concept :). For me something like
>>>>> this is more user friendly.
>>>>>
>>>>> *enc:*mmm
>>>>>
>>>>> thanks,
>>>>> Amila.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> [2] once serialized the values will be encrypted using wso2carbon key
>>>>>> store values
>>>>>> algorithm of encryption
>>>>>>
>>>>>> * /***
>>>>>> * * Encrypt a given plain text*
>>>>>> * * *
>>>>>> * * @param plainTextBytes*
>>>>>> * *The plaintext bytes to be encrypted*
>>>>>> * * @return The cipher text bytes*
>>>>>> * * @throws CryptoException*
>>>>>> * * On error during encryption*
>>>>>> * */*
>>>>>> * public byte[] encrypt(byte[] plainTextBytes
Re: [Architecture] Proper way to secure configuration for Connectors
Hi
without doubt I am + 1 for the approach and it can be done:)
>>
>
> +1. And make sure all mediators follow this pattern. Please don't say this
> mediator has done by this team etc ... :). It is ESB teams responsibility
> to have a common standards across all mediators :).
>
Yeah it's ESB team responsibility but I am waiting for the answers from
IS team why they have followed such a Invalid approach in *Entitlement* *
mediator* and they should (Must) answers this because up to now
I haven't hard anything form IS why they took such approach I haven't see
any @arch mail regarding entitlement mediator approach... :(
> thanks,
> Amila.
>
>
>>
>>
>>
>>>
>>> The model of using vault-lookup() will work in the dev/test/stage/prod
>>> lifecycle path as well - just use different vaults for the data.
>>>
>>> Sanjiva.
>>>
>>>
>>> On Mon, Jul 22, 2013 at 7:10 AM, Amila Suriarachchi wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Sat, Jul 20, 2013 at 10:22 PM, Dushan Abeyruwan wrote:
>>>>
>>>>> Hi All
>>>>>
>>>>> I have done required changes in synapse, there won't be any
>>>>> existing API's effected due to the given changers , so the overall process
>>>>> will be as shown in [1] where attributes required encryption required to
>>>>> embedded a key [*enc:] *so during the serialization it will be saved
>>>>> as [2], and during run-time those encrypted values will be decrypted using
>>>>> the *WSO2MediationSecurityInterceptor* ], the give solution
>>>>> has implemented and tested in scratch environment and works as expected.
>>>>>
>>>>>
>>>>> [1] before saving to configuration embedded enc: for the filed
>>>>> which requires encryption
>>>>>
>>>>>
>>>>>>>>> value="*enc:*mmm"/>
>>>>>>>>> value="*enc:*xxx"/>
>>>>>>>>> value="*enc:*eee"/>
>>>>>
>>>>>
>>>>
>>>> I am not a fan of this parameter concept :). For me something like this
>>>> is more user friendly.
>>>>
>>>> *enc:*mmm
>>>>
>>>> thanks,
>>>> Amila.
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> [2] once serialized the values will be encrypted using wso2carbon key
>>>>> store values
>>>>> algorithm of encryption
>>>>>
>>>>> * /***
>>>>> * * Encrypt a given plain text*
>>>>> * * *
>>>>> * * @param plainTextBytes*
>>>>> * *The plaintext bytes to be encrypted*
>>>>> * * @return The cipher text bytes*
>>>>> * * @throws CryptoException*
>>>>> * * On error during encryption*
>>>>> * */*
>>>>> * public byte[] encrypt(byte[] plainTextBytes) throws CryptoException
>>>>> {*
>>>>> * try {*
>>>>> *
>>>>> *
>>>>> * KeyStoreManager keyMan = KeyStoreManager.getInstance(*
>>>>> * MultitenantConstants.SUPER_TENANT_ID, this.serverConfigService,*
>>>>> * this.registryService);*
>>>>> * KeyStore keyStore = keyMan.getPrimaryKeyStore();*
>>>>> *
>>>>> *
>>>>> * Certificate[] certs = keyStore.getCertificateChain(keyAlias);*
>>>>> * Cipher cipher = Cipher.getInstance("RSA", "BC");*
>>>>> * cipher.init(Cipher.ENCRYPT_MODE, certs[0].getPublicKey());*
>>>>> *
>>>>> *
>>>>> * return cipher.doFinal(plainTextBytes);*
>>>>> *
>>>>> *
>>>>> * } catch (Exception e) {*
>>>>> * e.printStackTrace();*
>>>>> * throw new
>>>>> CryptoException(Messages.getMessage("erorDuringEncryption"), e);*
>>>>> * }*
>>>>> * }*
>>>>>
>>>>>
>>>>>>>>>
Re: [Architecture] Proper way to secure configuration for Connectors
On Mon, Jul 22, 2013 at 8:27 AM, Sanjiva Weerawarana wrote:
> Amila +1 for losing and using elements directly - since we're
> auto generating these mediators we should be able to make the change
> easily. Kasun what do you think?
>
> On @key vs. @foo="{xxx}" model, the problem with @key is that its a
> special attribute that has to be checked everywhere. If we say an attribute
> value or an element value is always a literal value or an XPath expression
> to evaluate ("{xpath-expresssion}") then its very powerful and flexible.
> That can also be implemented trivially via a util method.
>
without doubt I am + 1 for the approach and it can be done
>
> The model of using vault-lookup() will work in the dev/test/stage/prod
> lifecycle path as well - just use different vaults for the data.
>
> Sanjiva.
>
>
> On Mon, Jul 22, 2013 at 7:10 AM, Amila Suriarachchi wrote:
>
>>
>>
>>
>> On Sat, Jul 20, 2013 at 10:22 PM, Dushan Abeyruwan wrote:
>>
>>> Hi All
>>>
>>> I have done required changes in synapse, there won't be any existing
>>> API's effected due to the given changers , so the overall process will be
>>> as shown in [1] where attributes required encryption required to embedded a
>>> key [*enc:] *so during the serialization it will be saved as [2], and
>>> during run-time those encrypted values will be decrypted using the *
>>> WSO2MediationSecurityInterceptor* ], the give solution
>>> has implemented and tested in scratch environment and works as expected.
>>>
>>>
>>> [1] before saving to configuration embedded enc: for the filed
>>> which requires encryption
>>>
>>>
>>>>> value="*enc:*mmm"/>
>>>>> value="*enc:*xxx"/>
>>>>> value="*enc:*eee"/>
>>>
>>>
>>
>> I am not a fan of this parameter concept :). For me something like this
>> is more user friendly.
>>
>> *enc:*mmm
>>
>> thanks,
>> Amila.
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>> [2] once serialized the values will be encrypted using wso2carbon key
>>> store values
>>> algorithm of encryption
>>>
>>> * /***
>>> * * Encrypt a given plain text*
>>> * * *
>>> * * @param plainTextBytes*
>>> * *The plaintext bytes to be encrypted*
>>> * * @return The cipher text bytes*
>>> * * @throws CryptoException*
>>> * * On error during encryption*
>>> * */*
>>> * public byte[] encrypt(byte[] plainTextBytes) throws CryptoException {*
>>> * try {*
>>> *
>>> *
>>> * KeyStoreManager keyMan = KeyStoreManager.getInstance(*
>>> * MultitenantConstants.SUPER_TENANT_ID, this.serverConfigService,*
>>> * this.registryService);*
>>> * KeyStore keyStore = keyMan.getPrimaryKeyStore();*
>>> *
>>> *
>>> * Certificate[] certs = keyStore.getCertificateChain(keyAlias);*
>>> * Cipher cipher = Cipher.getInstance("RSA", "BC");*
>>> * cipher.init(Cipher.ENCRYPT_MODE, certs[0].getPublicKey());*
>>> *
>>> *
>>> * return cipher.doFinal(plainTextBytes);*
>>> *
>>> *
>>> * } catch (Exception e) {*
>>> * e.printStackTrace();*
>>> * throw new
>>> CryptoException(Messages.getMessage("erorDuringEncryption"), e);*
>>> * }*
>>> * }*
>>>
>>>
>>>>> value="*encrypted:*
>>> K+PTyrN7K1KM2kOeFKMv0x9X5EP9qCpS7mJm9mpi9p3FqyYNyd1qCAlHKMA6dXAkCg1mdzL0TvF9ApMjwuVUoijO/C3EWn6Pf4Ju+70e2rsJ3hrbUVuD/SI/NaxS0QAg9mJzg/p0frnugbC+uha85d32yotUWcosKHW26Yjb6Ao="/>
>>> >> value="*encypted:*
>>> WfUb4sTrimV/WDjER8UldK2E2ez/0kC8r3RUWL3o0Lfuq+uZwjJxfIn3YYwRcPT52FSriKdesNg9Hi6sHW2gN4NqyI9pFqG1L3sfDwnlS0u4RAl8ZLq+62rUuVhA2C+XORyEBp8AZYUf1ew1dUSf8LG/+NfyoHmiLmwO3MvPqbo="/>
>>>>> value="*encypted:*
>>> FK2gv27JwmPrR7wybWI732HDQlR6p4jPlbTJQJKga386yGJ43gYpFsgoeilhDz/24tEe+4IqSuajsrWFa7wi8Ot6p+bLsufartodJhHt6zQfNTq6yaVzZWUExRjV2bsnJ477yfwc4Oz30c5
Re: [Architecture] Proper way to secure configuration for Connectors
Hi Folks,
Which secure vault component we suppose to use ? we have wso2
specific carbon component for secure vault [1] and synapse specific [2],
and it seems we have messed up with *synapse core *by including wso2
component
https://svn.wso2.org/repos/wso2/carbon/platform/trunk/dependencies/synapse/2.1.1-wso2v8/modules/core/pom.xml
* ***
* org.wso2.securevault*
* org.wso2.securevault*
* *
org.apache.synapse
synapse-commons
org.apache.synapse
synapse-tasks
org.apache.synapse
synapse-nhttp-transport
[1]
http://svn.wso2.org/repos/wso2/branches/carbon/3.2.0/dependencies/commons/securevault/1.0.0
[2]
https://svn.wso2.org/repos/wso2/carbon/platform/trunk/dependencies/synapse/2.1.1-wso2v8/modules/securevault
On Mon, Jul 22, 2013 at 7:10 AM, Amila Suriarachchi wrote:
>
>
>
> On Sat, Jul 20, 2013 at 10:22 PM, Dushan Abeyruwan wrote:
>
>> Hi All
>>
>> I have done required changes in synapse, there won't be any existing
>> API's effected due to the given changers , so the overall process will be
>> as shown in [1] where attributes required encryption required to embedded a
>> key [*enc:] *so during the serialization it will be saved as [2], and
>> during run-time those encrypted values will be decrypted using the *
>> WSO2MediationSecurityInterceptor* ], the give solution
>> has implemented and tested in scratch environment and works as expected.
>>
>>
>> [1] before saving to configuration embedded enc: for the filed which
>> requires encryption
>>
>>
>>> value="*enc:*mmm"/>
>>> value="*enc:*xxx"/>
>>> value="*enc:*eee"/>
>>
>>
>
> I am not a fan of this parameter concept :). For me something like this is
> more user friendly.
>
> *enc:*mmm
>
> thanks,
> Amila.
>
>
>
>
>>
>>
>>
>>
>>
>> [2] once serialized the values will be encrypted using wso2carbon key
>> store values
>> algorithm of encryption
>>
>> * /***
>> * * Encrypt a given plain text*
>> * * *
>> * * @param plainTextBytes*
>> * *The plaintext bytes to be encrypted*
>> * * @return The cipher text bytes*
>> * * @throws CryptoException*
>> * * On error during encryption*
>> * */*
>> * public byte[] encrypt(byte[] plainTextBytes) throws CryptoException {*
>> * try {*
>> *
>> *
>> * KeyStoreManager keyMan = KeyStoreManager.getInstance(*
>> * MultitenantConstants.SUPER_TENANT_ID, this.serverConfigService,*
>> * this.registryService);*
>> * KeyStore keyStore = keyMan.getPrimaryKeyStore();*
>> *
>> *
>> * Certificate[] certs = keyStore.getCertificateChain(keyAlias);*
>> * Cipher cipher = Cipher.getInstance("RSA", "BC");*
>> * cipher.init(Cipher.ENCRYPT_MODE, certs[0].getPublicKey());*
>> *
>> *
>> * return cipher.doFinal(plainTextBytes);*
>> *
>> *
>> * } catch (Exception e) {*
>> * e.printStackTrace();*
>> * throw new CryptoException(Messages.getMessage("erorDuringEncryption"),
>> e);*
>> * }*
>> * }*
>>
>>
>>> value="*encrypted:*
>> K+PTyrN7K1KM2kOeFKMv0x9X5EP9qCpS7mJm9mpi9p3FqyYNyd1qCAlHKMA6dXAkCg1mdzL0TvF9ApMjwuVUoijO/C3EWn6Pf4Ju+70e2rsJ3hrbUVuD/SI/NaxS0QAg9mJzg/p0frnugbC+uha85d32yotUWcosKHW26Yjb6Ao="/>
>>> value="*encypted:*
>> WfUb4sTrimV/WDjER8UldK2E2ez/0kC8r3RUWL3o0Lfuq+uZwjJxfIn3YYwRcPT52FSriKdesNg9Hi6sHW2gN4NqyI9pFqG1L3sfDwnlS0u4RAl8ZLq+62rUuVhA2C+XORyEBp8AZYUf1ew1dUSf8LG/+NfyoHmiLmwO3MvPqbo="/>
>>> value="*encypted:*
>> FK2gv27JwmPrR7wybWI732HDQlR6p4jPlbTJQJKga386yGJ43gYpFsgoeilhDz/24tEe+4IqSuajsrWFa7wi8Ot6p+bLsufartodJhHt6zQfNTq6yaVzZWUExRjV2bsnJ477yfwc4Oz30c59rhZvkNtGkXXaVp8Fo1nlS18H3mQ="/>
>>> value=*"*xx"/>
>>
>>
>>
>>
>> [3] Synapse config
>> http://ws.apache.org/ns/synapse";>
>>
>> 15000
>>
>> * > provider="org.wso2.carbon.mediation.security.WSO2MediationSecurityInterceptor"/>
>> *
>>
>>
>> any thoughts or improvements which you guys think ?
>>
>>
>> On Sat, Jul 20,
Re: [Architecture] Proper way to secure configuration for Connectors
Hi All
I have done required changes in synapse, there won't be any existing
API's effected due to the given changers , so the overall process will be
as shown in [1] where attributes required encryption required to embedded a
key [*enc:] *so during the serialization it will be saved as [2], and
during run-time those encrypted values will be decrypted using the *
WSO2MediationSecurityInterceptor* ], the give solution has implemented and
tested in scratch environment and works as expected.
[1] before saving to configuration embedded enc: for the filed which
requires encryption
[2] once serialized the values will be encrypted using wso2carbon key store
values
algorithm of encryption
* /***
* * Encrypt a given plain text*
* * *
* * @param plainTextBytes*
* *The plaintext bytes to be encrypted*
* * @return The cipher text bytes*
* * @throws CryptoException*
* * On error during encryption*
* */*
* public byte[] encrypt(byte[] plainTextBytes) throws CryptoException {*
* try {*
*
*
* KeyStoreManager keyMan = KeyStoreManager.getInstance(*
* MultitenantConstants.SUPER_TENANT_ID, this.serverConfigService,*
* this.registryService);*
* KeyStore keyStore = keyMan.getPrimaryKeyStore();*
*
*
* Certificate[] certs = keyStore.getCertificateChain(keyAlias);*
* Cipher cipher = Cipher.getInstance("RSA", "BC");*
* cipher.init(Cipher.ENCRYPT_MODE, certs[0].getPublicKey());*
*
*
* return cipher.doFinal(plainTextBytes);*
*
*
* } catch (Exception e) {*
* e.printStackTrace();*
* throw new CryptoException(Messages.getMessage("erorDuringEncryption"), e);
*
* }*
* }*
[3] Synapse config
http://ws.apache.org/ns/synapse";>
15000
*
*
any thoughts or improvements which you guys think ?
On Sat, Jul 20, 2013 at 8:45 PM, Dushan Abeyruwan wrote:
> Hi all,
> A small correction the relevant config should look like as below described
>
>
>
> value="*enc:*EvTEzc3jj9Z1Kx58ylNfkpnuXYuCeGgKhkVkziYNMs"/>
>
>
> Cheers
> Dushan
>
>
> On Sat, Jul 20, 2013 at 8:39 PM, Dushan Abeyruwan wrote:
>
>> Hi
>> IMO seems like
>> EntitlementMediato<https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/identity/org.wso2.carbon.identity.entitlement.mediator/src/main/java/org/wso2/carbon/identity/entitlement/mediator/EntitlementMediator.java>r
>> approach
>> quite suitable and handy and I would think what it does for the time being
>> is _ _okay _ _ since Entitlement component is NOT resides within synapse
>> (need expert suggestion form IS since they are the one who implemented the
>> current approach) , according to the discussion had (with Kasun at el)
>> thought how we could probably include the same approach for
>> the components resides in synapse.
>>There we have identified the approach which registry getting
>> intercepted could be useful [2].We thought of introducing a security
>> related component [3] a kind of extension point where the
>> SecurityInteceptors will be initialized during init()
>> and readily available in *synapseConfiguration* during serialization or
>> during run-time and with that we could probably utilize the attributes
>> which required for encrypt with special character or sequence as shown [1]
>> anyway I am still doing a feasibility study of the
>> described approach, may be there we might have jump few hurdles to get this
>> done without harming synapse API ..
>>
>> really appreciate thoughts from IS for this approach, do you guys
>> feel any _ _ better more reliable approach than this _ _ ?
>>
>> e.g
>> [1]
>>
>>>
>> value="EvTEzc3jj9Z1Kx58ylNfkpnuXYuCeGgKhkVkziYNMs"/> (if used enc: then
>> during serialization those values encrypited same can be integrated for
>> UI's even this might not be any issue when use DevS approach as well)
>>
>>
>>
>>
>> [2]
>>
>> 15000
>>
>>
>> [3]
>>
>> *SecurityInterceptor
>> (class name or package not finalized yet)*
>> 15000
>>
>>
>>
>>
>> On Sat, Jul 20, 2013 at 7:17 PM, Sanjiva Weerawarana wrote:
>>
>>> Dushan connector creds are going to be user specific. So that means they
>>> have to be able to configure them in a user-accessible way .. and then the
>>> data needs to be stored in
Re: [Architecture] Proper way to secure configuration for Connectors
Hi all,
A small correction the relevant config should look like as below described
Cheers
Dushan
On Sat, Jul 20, 2013 at 8:39 PM, Dushan Abeyruwan wrote:
> Hi
> IMO seems like
> EntitlementMediato<https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/identity/org.wso2.carbon.identity.entitlement.mediator/src/main/java/org/wso2/carbon/identity/entitlement/mediator/EntitlementMediator.java>r
> approach
> quite suitable and handy and I would think what it does for the time being
> is _ _okay _ _ since Entitlement component is NOT resides within synapse
> (need expert suggestion form IS since they are the one who implemented the
> current approach) , according to the discussion had (with Kasun at el)
> thought how we could probably include the same approach for
> the components resides in synapse.
>There we have identified the approach which registry getting
> intercepted could be useful [2].We thought of introducing a security
> related component [3] a kind of extension point where the
> SecurityInteceptors will be initialized during init()
> and readily available in *synapseConfiguration* during serialization or
> during run-time and with that we could probably utilize the attributes
> which required for encrypt with special character or sequence as shown [1]
> anyway I am still doing a feasibility study of the
> described approach, may be there we might have jump few hurdles to get this
> done without harming synapse API ..
>
> really appreciate thoughts from IS for this approach, do you guys feel
> any _ _ better more reliable approach than this _ _ ?
>
> e.g
> [1]
>
>
> value="EvTEzc3jj9Z1Kx58ylNfkpnuXYuCeGgKhkVkziYNMs"/> (if used enc: then
> during serialization those values encrypited same can be integrated for
> UI's even this might not be any issue when use DevS approach as well)
>
>
>
>
> [2]
>
> 15000
>
>
> [3]
>
> *SecurityInterceptor
> (class name or package not finalized yet)*
> 15000
>
>
>
>
> On Sat, Jul 20, 2013 at 7:17 PM, Sanjiva Weerawarana wrote:
>
>> Dushan connector creds are going to be user specific. So that means they
>> have to be able to configure them in a user-accessible way .. and then the
>> data needs to be stored in a secure vault of some kind.
>>
>> For UI driven configs that's easy - we get the password in the UI, store
>> in the vault and refer to it in the mediator config.
>>
>> For hand edited synapse.xml stuff you'd need to let the user do the same.
>> Do we have a per-user vault type concept?
>>
>> Sanjiva.
>>
>>
>> On Fri, Jul 19, 2013 at 11:18 AM, Dushan Abeyruwan wrote:
>>
>>> Hi
>>>Regarding $subject, what would be the best way to accomplish ?
>>> According to the EntitlementMediator implementation it
>>> seems we are using a different approach as shown below [1], any reason
>>> which prevent us moving to synapse secure vault and also seems there are
>>> zero documentation related to Synapse secure vault configuration.
>>>
>>>
>>> [1]
>>>
>>> https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/identity/org.wso2.carbon.identity.entitlement.mediator/src/main/java/org/wso2/carbon/identity/entitlement/mediator/EntitlementMediator.java
>>>
>>>
>>> public void setRemoteServicePassword(String remoteServicePassword) {
>>> if (remoteServicePassword.startsWith("enc:")) {
>>> try {
>>> * this.remoteServicePassword = new
>>> String(CryptoUtil.getDefaultCryptoUtil()*
>>> *
>>> .base64DecodeAndDecrypt(remoteServicePassword.substring(4)));*
>>> } catch (CryptoException e) {
>>> log.error(e);
>>> }
>>> } else {
>>> this.remoteServicePassword = remoteServicePassword;
>>> }
>>> }
>>>
>>> Cheers,
>>> Dushan Abeyruwan
>>> Associate Tech Lead
>>> *Integration Technologies Team*
>>> *WSO2 Inc. http://wso2.com/*
>>> *Mobile:(+94)714408632*
>>>
>>> _______
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Sanjiva Weerawarana, Ph.D.
>> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
>> email: sanj...@wso2.com;
Re: [Architecture] Proper way to secure configuration for Connectors
Hi
IMO seems like
EntitlementMediato<https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/identity/org.wso2.carbon.identity.entitlement.mediator/src/main/java/org/wso2/carbon/identity/entitlement/mediator/EntitlementMediator.java>r
approach
quite suitable and handy and I would think what it does for the time being
is _ _okay _ _ since Entitlement component is NOT resides within synapse
(need expert suggestion form IS since they are the one who implemented the
current approach) , according to the discussion had (with Kasun at el)
thought how we could probably include the same approach for
the components resides in synapse.
There we have identified the approach which registry getting intercepted
could be useful [2].We thought of introducing a security related component
[3] a kind of extension point where the SecurityInteceptors will
be initialized during init() and readily available in
*synapseConfiguration* during serialization or during run-time and
with that we could
probably utilize the attributes which required
for encrypt with special character or sequence as shown [1]
anyway I am still doing a feasibility study of the
described approach, may be there we might have jump few hurdles to get this
done without harming synapse API ..
really appreciate thoughts from IS for this approach, do you guys feel
any _ _ better more reliable approach than this _ _ ?
e.g
[1]
(if used enc: then
during serialization those values encrypited same can be integrated for
UI's even this might not be any issue when use DevS approach as well)
[2]
15000
[3]
*SecurityInterceptor
(class name or package not finalized yet)*
15000
On Sat, Jul 20, 2013 at 7:17 PM, Sanjiva Weerawarana wrote:
> Dushan connector creds are going to be user specific. So that means they
> have to be able to configure them in a user-accessible way .. and then the
> data needs to be stored in a secure vault of some kind.
>
> For UI driven configs that's easy - we get the password in the UI, store
> in the vault and refer to it in the mediator config.
>
> For hand edited synapse.xml stuff you'd need to let the user do the same.
> Do we have a per-user vault type concept?
>
> Sanjiva.
>
>
> On Fri, Jul 19, 2013 at 11:18 AM, Dushan Abeyruwan wrote:
>
>> Hi
>>Regarding $subject, what would be the best way to accomplish ?
>> According to the EntitlementMediator implementation it seems
>> we are using a different approach as shown below [1], any reason which
>> prevent us moving to synapse secure vault and also seems there are zero
>> documentation related to Synapse secure vault configuration.
>>
>>
>> [1]
>>
>> https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/identity/org.wso2.carbon.identity.entitlement.mediator/src/main/java/org/wso2/carbon/identity/entitlement/mediator/EntitlementMediator.java
>>
>>
>> public void setRemoteServicePassword(String remoteServicePassword) {
>> if (remoteServicePassword.startsWith("enc:")) {
>> try {
>> * this.remoteServicePassword = new
>> String(CryptoUtil.getDefaultCryptoUtil()*
>> *
>> .base64DecodeAndDecrypt(remoteServicePassword.substring(4)));*
>> } catch (CryptoException e) {
>> log.error(e);
>> }
>> } else {
>> this.remoteServicePassword = remoteServicePassword;
>> }
>> }
>>
>> Cheers,
>> Dushan Abeyruwan
>> Associate Tech Lead
>> *Integration Technologies Team*
>> *WSO2 Inc. http://wso2.com/*
>> *Mobile:(+94)714408632*
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Sanjiva Weerawarana, Ph.D.
> Founder, Chairman & CEO; WSO2, Inc.; http://wso2.com/
> email: sanj...@wso2.com; phone: +94 11 763 9614; cell: +94 77 787 6880 | +1
> 650 265 8311
> blog: http://sanjiva.weerawarana.org/
>
> Lean . Enterprise . Middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
Dushan Abeyruwan
Associate Tech Lead
*Integration Technologies Team*
*WSO2 Inc. http://wso2.com/*
*Mobile:(+94)714408632*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] Proper way to secure configuration for Connectors
Hi
Regarding $subject, what would be the best way to accomplish ?
According to the EntitlementMediator implementation it seems
we are using a different approach as shown below [1], any reason which
prevent us moving to synapse secure vault and also seems there are zero
documentation related to Synapse secure vault configuration.
[1]
https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/identity/org.wso2.carbon.identity.entitlement.mediator/src/main/java/org/wso2/carbon/identity/entitlement/mediator/EntitlementMediator.java
public void setRemoteServicePassword(String remoteServicePassword) {
if (remoteServicePassword.startsWith("enc:")) {
try {
* this.remoteServicePassword = new
String(CryptoUtil.getDefaultCryptoUtil()*
*
.base64DecodeAndDecrypt(remoteServicePassword.substring(4)));*
} catch (CryptoException e) {
log.error(e);
}
} else {
this.remoteServicePassword = remoteServicePassword;
}
}
Cheers,
Dushan Abeyruwan
Associate Tech Lead
*Integration Technologies Team*
*WSO2 Inc. http://wso2.com/*
*Mobile:(+94)714408632*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Cloud Connector - Tooling
Hi Samisa, IMO yes graphical editor should be enhanced along side with tooling, there were several issues reported under user friendliness of edior @support-dev, anyhow graphical editor is *not* *absolute* *blocker* we can integrate connector story, but in long run we need to that to be enhanced in parallel. Cheers Dushan On Tue, Jul 16, 2013 at 12:45 PM, Samisa Abeysinghe wrote: > So the fist question I have in terms of tooling is that: >tooling will go alongside the graphical editor right? > > > On Tue, Jul 16, 2013 at 12:23 PM, Dushan Abeyruwan wrote: > >> >> Hi >> >> - Now we know all the supported operations by looking at the templates >>> ( get_user_timeline.xml.. etc) and each template will give what are the >>> parameters needed for that operation. >>> >>> - So, everything can be dynamically generated just by looking at the >>> connector archive. From DevS point of view, we can have a pallet for each >>> connector, along with the supported operations. >>> >> >> +1 IMO this has to be a pre-configurable location, where customer >> is freely asks to point where the connectors are gonna stored in dev >> location so, once dev points to the connector archive folder, DevS should >> populate all the available connectors to the pallet.. >> >>> >>> - Users simply drag and drop what ever the required connector operations >>> ( eg: update_status, retweet_status etc) >>> >> >> this should be more closer to the call-template (what I felt only >> dynamic behavior getting involved), and I think we can populate child >> artifact.xml and populate all it's operations. >> Once the operation selected, it's gonna be same as selecting >> template, then populating the parameters... ideally this brings the generic >> thus all other connectors can follow up the same setup. >> >> Additionally each connector wrapped up with it's own icon, where >> during the pallet initialization time those icons can be loaded >> dynamically.. >> >> >> >>> >>> Thanks, >>> >>> -- >>> Kasun Indrasiri >>> Software Architect >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> cell: +94 71 536 4128 >>> Blog : http://kasunpanorama.blogspot.com/ >>> >> >> >> >> -- >> Dushan Abeyruwan >> Associate Tech Lead >> *Integration Technologies Team* >> *WSO2 Inc. http://wso2.com/* >> *Mobile:(+94)714408632* >> > > > > -- > > Thanks, > Samisa... > > Samisa Abeysinghe > VP Engineering > WSO2 Inc. > http://wso2.com > http://wso2.org > -- Dushan Abeyruwan Associate Tech Lead *Integration Technologies Team* *WSO2 Inc. http://wso2.com/* *Mobile:(+94)714408632* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Cloud Connector - Tooling
Hi - Now we know all the supported operations by looking at the templates ( > get_user_timeline.xml.. etc) and each template will give what are the > parameters needed for that operation. > > - So, everything can be dynamically generated just by looking at the > connector archive. From DevS point of view, we can have a pallet for each > connector, along with the supported operations. > +1 IMO this has to be a pre-configurable location, where customer is freely asks to point where the connectors are gonna stored in dev location so, once dev points to the connector archive folder, DevS should populate all the available connectors to the pallet.. > > - Users simply drag and drop what ever the required connector operations ( > eg: update_status, retweet_status etc) > this should be more closer to the call-template (what I felt only dynamic behavior getting involved), and I think we can populate child artifact.xml and populate all it's operations. Once the operation selected, it's gonna be same as selecting template, then populating the parameters... ideally this brings the generic thus all other connectors can follow up the same setup. Additionally each connector wrapped up with it's own icon, where during the pallet initialization time those icons can be loaded dynamically.. > > Thanks, > > -- > Kasun Indrasiri > Software Architect > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > cell: +94 71 536 4128 > Blog : http://kasunpanorama.blogspot.com/ > -- Dushan Abeyruwan Associate Tech Lead *Integration Technologies Team* *WSO2 Inc. http://wso2.com/* *Mobile:(+94)714408632* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
