Re: [Architecture] Implementing Latency Metrics Calculation Feature in GW

[Imesh Gunaratne]

On Wed, Dec 16, 2015 at 12:38 PM, Isuru Ranawaka  wrote:
>
>
>- Data receiver needs to be Asynchronously collect the data without
>blocking GW threads.
>
> What would be the approach we are planning to take here?

Thanks

>
>- Latency Calculation Engine should be configurable (such as  per
>request updating or time based updating)
>- Scheduler is for  notify the Engine to calculate latency values
>timely based.
>- There should be extension point to add event formatters in order to
>publish events in different formatters when needed.
>- As a default values are published through JMX via m beans.
>
>
> thanks
>
> IsuruR
> --
> Best Regards
> Isuru Ranawaka
> M: +94714629880
> Blog : http://isurur.blogspot.com/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Imesh Gunaratne*
Senior Technical Lead
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: http://imesh.gunaratne.org
Lean . Enterprise . Middleware
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [MSS] Support lifecycle methods

[Imesh Gunaratne]

Hi Isuru,

In MetricsInterceptor, I can see multiple interceptors are collecting data
but could not figure out how they are published to a central server. It it
done by the metric manager? Would you mind explaining how this works?

https://github.com/wso2/product-mss/blob/v1.0.0-alpha/carbon-mss/components/org.wso2.carbon.mss/src/main/java/org/wso2/carbon/mss/metrics/MetricsInterceptor.java

Thanks

On Fri, Dec 18, 2015 at 2:31 PM, Isuru Perera  wrote:

> Hi,
>
> In Standalone service mode, we support deploying multiple service
> instances. That's the main concern I have. If a user adds multiple
> services, the initialization step will run multiple times. Let's look at my
> suggestion in next release.
>
> I made changes and sent a PR [1]. The init() methods are synchronized and
> it will initialize only once.
>
> [1] https://github.com/wso2/product-mss/pull/86
> 
>
> On Fri, Dec 18, 2015 at 11:57 AM, Sagara Gunathunga 
> wrote:
>
>>
>>
>> On Fri, Dec 18, 2015 at 11:33 AM, Isuru Perera  wrote:
>>
>>> Hi all,
>>>
>>> I'm trying to refactor code and move the initialization logic out from
>>> the interceptors we have. i.e. MetricsInterceptor [1] and
>>> HTTPMonitoringInterceptor [2]. With current lifecycle method support, we
>>> can write some initialization code within the service only [3].
>>>
>>
>> Since we are very close to GA release, let's continue with current
>> service lifecycle approach and finish refactoring of above 2 Interceptor as
>> we planed, while we can continue this discussion separately.
>>
>>>
>>> I understand that it's better to have a separate class for
>>> initialization logic. But I need to make sure that initialization runs only
>>> once. That's why I initially wrote the initialization logic at the
>>> interceptor level. The user will add interceptor only once to the MSS
>>> application [4].
>>>
>>> If there are multiple services (as in sample [4]], we cannot ask user to
>>> initialize in each service as the initialization will run multiple times.
>>> We can solve that by changing the initialization code to run once. But I
>>> don't think that a good idea. There will be duplicate code in each service
>>> to initialize Metrics and HTTP Monitoring.
>>>
>>
>> Basically we have two deployment modes.
>>
>> 1.) Standalone service mode (aka MSS-lite)
>>
>> - In this mode we deploy single service per single application hence IMO
>> service lifecycle annotations are sufficient because initialization code
>> anyway run only one time.  BTW did you find any use cases that we can't
>> cover with service LC methods under this mode ?
>>
>> 2.) OSGi server mode
>>
>> Since this mode is based on OSGi, can't we just use OSGi features such as
>> bundle activators, OSGi-service annotations[1] such as @Acitvate,
>> @Deactivate instead of inventing something new ?  We already use above OSGi
>> features to register/deregister microservices, register/deregister
>>  Interceptor etc.
>>
>> [1] -
>> https://kishanthan.wordpress.com/2014/03/29/using-annotation-with-osgi-declarative-services/
>>
>> Thanks !
>>
>>
>>>
>>> Is it possible to have lifecycle method support for the entire MSS
>>> application as well? Something similar to ServletContextListener [5]?
>>>
>>> Thanks!
>>>
>>> Best Regards,
>>>
>>> [1]
>>> https://github.com/wso2/product-mss/blob/v1.0.0-alpha/carbon-mss/components/org.wso2.carbon.mss/src/main/java/org/wso2/carbon/mss/metrics/MetricsInterceptor.java#L47-L85
>>> [2]
>>> https://github.com/wso2/product-mss/blob/v1.0.0-alpha/carbon-mss/components/org.wso2.carbon.mss/src/main/java/org/wso2/carbon/mss/httpmonitoring/HTTPMonitoringInterceptor.java#L80-L196
>>> [3] https://github.com/wso2/product-mss/tree/master/samples/lifecycle
>>> [4]
>>> https://github.com/wso2/product-mss/blob/v1.0.0-alpha/samples/metrics/src/main/java/org/wso2/carbon/mss/example/Application.java#L39-L40
>>> [5]
>>> http://docs.oracle.com/javaee/6/api/javax/servlet/ServletContextListener.html
>>>
>>>
>>>
>>> On Sun, Nov 15, 2015 at 7:46 PM, Sagara Gunathunga 
>>> wrote:
>>>


 On Sun, Nov 15, 2015 at 7:40 PM, Afkham Azeez  wrote:

> Can you fix the metric code to ise this?
>
 I can work with IsuruP, still metrics/DAS code are not familiar to me.

 Thanks !

> On Nov 15, 2015 6:32 PM, "Sagara Gunathunga"  wrote:
>
>>
>>
>> On Thu, Nov 12, 2015 at 8:41 PM, Afkham Azeez  wrote:
>>
>>>
>>>
>>> On Thu, Nov 12, 2015 at 5:05 AM, Sagara Gunathunga 
>>> wrote:
>>>
 Use case
 --
 MS F/W should support at least two bean lifecycle methods so that
 one method get call during the service start-up while other one get 
 call
 just before the 

Re: [Architecture] PPaaS Artifact Migration Tool

[Malmee Weerasinghe]

Hi All,
This is the component architecture diagram of PPaaS Artifact Migration
Tool.
@ Chamila : Thank you for the suggestions and we will improve the tool as
mentioned.


​
We highly appreciate your suggestions on this model.
Thank you.

On Fri, Dec 18, 2015 at 1:09 AM, Chamila De Alwis  wrote:

> Hi Malmee,
>
> Great work on the migration tool. AFAIU this is as far as we can go to
> ease the migration process for a Stratos user.
>
> Some improvements that can be implemented, IMO, are,
>
> 1. Rename bin/run.sh to bin/stratos.sh to conform with the existing
> pattern where each separate Stratos component is started with a script
> named stratos.sh
> 2. If the path of the config file (currently config.properties) can also
> be an input value like the log4j config file, it might be easy to reuse the
> same tool with several config files, pointing to several Stratos
> installations at the same time.
> 3. Since configuration is a global state throughout a running instance,
> IMO it can be included as static final values in a static Config class.
> This might prove useful than the system property approach for several
> reasons, one being that after loading the config, it wouldn't be
> accidentally changed.
> 4. IMO the singleton implementations can be static classes (Transformation
> and ConversionTool). They don't seem to have any state.
> 5. Apache Commons library seems to provide some functions in a safer
> manner for some of the implemented methods like configuration loading[1]
> and file writing [2].
> 6. From a superficial look it seems the fetch methods on OldArtifactLoader
> can be refactored in to a single method. Please look in to this
> possibility.
> 7. If the existing RestClient implementation is going to be maintained,
> IMO it would be a better design to let the configuration decide whether to
> skip host and cert verification, as discussed in the code review.
> 8. Move Constants to the root folder, since it's been called by other
> classes as well.
> 9. The next step can be to convert the Constants code file to a
> configuration file (XML/YAML) for configurable options like the endpoints,
> default values and cert path can be configured and the tool can be run
> against any future versions as well. However AFAIU, that is out of scope
> for the initial implementation.
>
>
> [1] -
> http://fahdshariff.blogspot.com/2013/04/adding-java-system-properties-from.html
>
> [2] -
> http://www.avajava.com/tutorials/lessons/how-do-i-write-a-string-to-a-file-using-commons-io.html
>
>
>
> Regards,
> Chamila de Alwis
> Committer and PMC Member - Apache Stratos
> Software Engineer | WSO2 | +94772207163
> Blog: code.chamiladealwis.com
>
>
>
> On Wed, Dec 16, 2015 at 10:07 AM, Malmee Weerasinghe 
> wrote:
>
>> Hi Imesh,
>>
>> We will include a component architecture diagram of the PPaaS Artifact
>> Migration Tool.
>>
>> Thanks.
>>
>> On Tue, Dec 15, 2015 at 10:53 PM, Imesh Gunaratne  wrote:
>>
>>> Hi Malmee,
>>>
>>> It would be better if you can draw a component architecture diagram to
>>> illustrate how this tool works.
>>>
>>> This might help us to understand how much load it can handle if the
>>> existing Private PaaS 4.0.0 environment has considerable amount of
>>> artifacts and subscriptions and how those can be processed efficiently.
>>>
>>> Thanks
>>>
>>> On Tue, Dec 15, 2015 at 10:39 PM, Malmee Weerasinghe 
>>> wrote:
>>>
 Hi All,
 We are developing a tool to convert PPaaS 4.0.0 artifact JSON files to
 PPaaS 4.1.x. [1]

 There are changes in the artifacts deployment process in PPaaS 4.0.0
 compared to 4.1.0. So this tool is developed for those who need to migrate
 from PPaaS 4.0.0 to 4.1.0.

 We take the artifacts JSONs of PPaaS 4.0.0 through REST API endpoints,
 convert them using the bean classes of PPaaS 4.0.0 and 4.1.0 which are
 accessed via a dependency and generate output artifacts to to be compatible
 with PPaaS 4.1.x. In this process, we use default values for the additional
 artifacts.

 These are the conversions we have implemented already.
  - auto scale policy artifacts
  - network partition list artifacts
  - deployment policy artifacts
  - cartridge artifacts
  - application artifacts
  - application sign ups - convert the cartridge subscription artifacts
 JSONs output from Subscription Manager [2]
  - domain mappings

 Would appreciate it if you could give your suggestions and comments on
 this.
 [1]
 https://github.com/nishadi/product-private-paas/tree/master/tools/migration/ppaas-artifact-converter
 
 [2]
 https://github.com/wso2/product-private-paas/tree/master/tools/migration/subscription-manager/4.0.0
 

[Architecture] WSO2 Carbon Kernel 5.0.0 Released !!!

[Aruna Karunarathna]

*WSO2 Carbon Kernel 5.0.0 - Released !!!*


We are pleased to announce the release of WSO2 Carbon Kernel 5.0.0. It is
now available to download from here
.
The source and tag location for this release are available here
.

WSO2 Carbon Kernel 5.0.0 is the core of the next-generation WSO2 Carbon
platform. We have completely rearchitected Carbon Kernel from the ground up
with the latest technologies and patterns. Additionally, the Carbon Kernel
is now a lightweight, general-purpose OSGi runtime specializing in hosting
servers, providing key functionality for server developers. The result is a
streamlined and even more powerful middleware platform than ever before.

This release of the WSO2 Carbon Kernel includes the following key features. For
further details please see the documentation
.


Key Features

   - Transport Management Framework
   - Logging Framework with Log4j 2.0 as the Backend
   - Carbon Startup Order Resolver
   - Dropins Support for OSGi Ready Bundles
   - Jar to Bundle Conversion Tool
   - Artifact Deployment Engine
   - Pluggable Runtime Support





Fixed Issues

   - WSO2 Carbon Kernel 5.0.0 - Fixed Issues
   

Known Issues

   - WSO2 Carbon Kernel 5.0.0 - Known Issues
   

How To Contribute

You can find more instructions on how to contribute on our documentation
 site.

If you have any suggestions or are interested in Carbon Kernel 5.0.0
discussions, you can join the d...@wso2.org or architecture@wso2.org mailing
lists.
Reporting Issues

We encourage you to report issues, documentation errors regarding WSO2
Carbon Kernel 5.0.0 through the public issue tracking system
.


Thanks,

WSO2 Carbon Team
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [BPMN] Implementing correlation support for BPMN Rest API

[Firzhan Naqash]

Hi Frank,

Please find my comments inline.

The process model you have drawn enables multiple receiving message events
in parallel. According to the BPMN 2.0 spec this is not allowed for
key-based correlation (i.e. the correlation mechanism similar to BPEL
correlation sets); but it is allowed for predicate based correlation (often
used in collaborations).  I assume that we are not dealing with
collaborations here. Thus, only one of the events/tasks will receive the
message - you see mainly two ways in which this is handled by an engine,
(i) the engine randomly assigns the message, or (ii) a runtime error
occurs. Not sure what our implementation does


Yeah. When we enable multiple message receiving events in parallel, BPMN
engine will throw an error. But when you provide the activity id ( Unique
id that we use in the process definition model to identify an
event receiver) along with the message, BPMN engine can determine the event
receiver to be executed. On the other hand, if we have only single
message receiving event, we don't have to provide the activity id.


Why are the correlation-keys not sufficient?  When a process is
instantiated it gets tightly coupled with a process model, i.e. a version
of a certain process model; and all correlation-keys associated with that
instance are coupled with that version.


Exactly, we apply the correlation-keys to identify the process instances.
But in addition to that clients can use the *processInstanceVariables* variable
to add/update their user-defined/business variables to the process instance
during the process instance execution and it's not being used to filter
out the process instances.


Regards,
Firzhan
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WebSockets support in ESB 4.10

[Kasun Indrasiri]

Hi all,

We are working on adding WebSockets support into ESB 4.10. For the default
HTTP transport we won't be able to incorporate it as HTTPCore doesn't offer
native WebSockets support. However, with the concept of inbound
endpoints/connectors we will be able to implement it by leveraging Netty.
So that means we have to use a dedicated HTTP port with WebSocket support.

Kevin can you please share the main WebSockets use cases that we came up
with.

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

Re: [Architecture] WebSockets support in ESB 4.10

[Kasun Indrasiri]

Yes Eranga. That's is a valid use case. AFAIR, we discuss about this use
case with Kevin.

@Kevin : WDYT?

On Tue, Dec 22, 2015 at 12:03 PM, Eranga Perera  wrote:

> Hi,
>
> How can we facilitate broadcasting to a web socket channel. If there are
> multiple subscribers to that channel can we discriminate what messages
> should go to each subscriber. I am thinking how a web socket chat
> application be implemented with ESB mediation sequences.
>
> Eranga.
>
> On Tue, Dec 22, 2015 at 11:12 AM, Kevin Ratnasekera 
> wrote:
>
>> Hi all,
>> Here are the main use cases we found with related to WebSockets support
>> in 410.
>>
>> 1. Websocket client to Websocket endpoint via ESB
>>
>>
>>
>> 2. Websocket client to HTTP endpoint via ESB
>>
>>
>>
>> 3. HTTP client to Websocket endpoint via ESB
>>
>>
>> In each of the main use cases we need to support following sub use cases.
>>
>> 1. Header based routing scenario. This will be depend on the HTTP header
>> specified at the initial handshake stage.
>> 2. Content transformation scenario. As Websockets allows two way
>> communication, we should be able to support two way mediation.
>>
>> Configuration should include two dispatching sequences on for
>> bidirectional message flows. one for the client to backend mediation other
>> for the backend to client mediation.
>>
>> 3. Support different content types for Websocket frames dynamic way. This
>> is handled using Websocket Sub protocol.
>>
>> Regards
>> Kevin
>>
>> On Tue, Dec 22, 2015 at 10:22 AM, Kasun Indrasiri  wrote:
>>
>>> Hi all,
>>>
>>> We are working on adding WebSockets support into ESB 4.10. For the
>>> default HTTP transport we won't be able to incorporate it as HTTPCore
>>> doesn't offer native WebSockets support. However, with the concept of
>>> inbound endpoints/connectors we will be able to implement it by leveraging
>>> Netty. So that means we have to use a dedicated HTTP port with WebSocket
>>> support.
>>>
>>> Kevin can you please share the main WebSockets use cases that we came up
>>> with.
>>>
>>> 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
>>
>>
>
>
> --
> Eranga Perera
> *Senior Lead Solutions Engineer*
> *WSO2, Inc. *
> Mobile :  +94 72 778 4250
> eran...@wso2.com
>



-- 
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

Re: [Architecture] Connector Improvements 2016

[Malaka Silva]

Hi Elilmatha & Ashalya,

Can you list down the connectors we are planning to improve.

We need minimum of 2 batches of 8-10 connectors to start next year.

On Mon, Dec 14, 2015 at 5:50 PM, Malaka Silva  wrote:

> Hi Elilmatha,
>
> Connectors like GotoWebinar, Concur and Github will be improved when we
> are using those for internal integration.
>
> What we need to focus here is to get some other connectors in batches of
> 5-10 and improve usability and method coverage.
>
> One way to select connectors from pool of 140+ is considering factors like
> usage, popularity, no of users, usage of enterprise integration use cases
> or business domain.
>
> We need to get that list first.
>
>
> On Mon, Dec 14, 2015 at 2:38 PM, Elilmatha Sivanesan 
> wrote:
>
>>
>> Hi all,
>>
>> We are planning to improve the following ESB connectors in Q1 next year.
>>
>>- Facebook - Need to improve the existing methods with new api
>>changes.
>>- GotoWebinar - Need to implement the attendees resources
>>- Paypal - Need to implement more resources
>>- Hubspot - Need to implement more resources
>>- Concur  - Need to implement invoice resources
>>- Github - Need to implement more resources
>>- Amazon Connectors - Need to verify all amazon connectors
>>(amazonsqs,amazondb,amazonsns,amazons3,amazonses)with ESB 4.9.0
>>
>> Thanks.
>> --
>> *S.Elilmatha*
>> Associate  Software Engineer,
>>
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> Mobile 0779842221.
>>
>>
>
>
> --
>
> 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/
> 
> https://store.wso2.com/store/
>
> Save a tree -Conserve nature & Save the world for your future. Print this
> email only if it is absolutely necessary.
>



-- 

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/

https://store.wso2.com/store/

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

Re: [Architecture] WebSockets support in ESB 4.10

[Kevin Ratnasekera]

Hi all,
Here are the main use cases we found with related to WebSockets support in
410.

1. Websocket client to Websocket endpoint via ESB



2. Websocket client to HTTP endpoint via ESB



3. HTTP client to Websocket endpoint via ESB


In each of the main use cases we need to support following sub use cases.

1. Header based routing scenario. This will be depend on the HTTP header
specified at the initial handshake stage.
2. Content transformation scenario. As Websockets allows two way
communication, we should be able to support two way mediation.

Configuration should include two dispatching sequences on for bidirectional
message flows. one for the client to backend mediation other for the
backend to client mediation.

3. Support different content types for Websocket frames dynamic way. This
is handled using Websocket Sub protocol.

Regards
Kevin

On Tue, Dec 22, 2015 at 10:22 AM, Kasun Indrasiri  wrote:

> Hi all,
>
> We are working on adding WebSockets support into ESB 4.10. For the default
> HTTP transport we won't be able to incorporate it as HTTPCore doesn't offer
> native WebSockets support. However, with the concept of inbound
> endpoints/connectors we will be able to implement it by leveraging Netty.
> So that means we have to use a dedicated HTTP port with WebSocket support.
>
> Kevin can you please share the main WebSockets use cases that we came up
> with.
>
> 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

Re: [Architecture] WebSockets support in ESB 4.10

[Eranga Perera]

Hi,

How can we facilitate broadcasting to a web socket channel. If there are
multiple subscribers to that channel can we discriminate what messages
should go to each subscriber. I am thinking how a web socket chat
application be implemented with ESB mediation sequences.

Eranga.

On Tue, Dec 22, 2015 at 11:12 AM, Kevin Ratnasekera  wrote:

> Hi all,
> Here are the main use cases we found with related to WebSockets support in
> 410.
>
> 1. Websocket client to Websocket endpoint via ESB
>
>
>
> 2. Websocket client to HTTP endpoint via ESB
>
>
>
> 3. HTTP client to Websocket endpoint via ESB
>
>
> In each of the main use cases we need to support following sub use cases.
>
> 1. Header based routing scenario. This will be depend on the HTTP header
> specified at the initial handshake stage.
> 2. Content transformation scenario. As Websockets allows two way
> communication, we should be able to support two way mediation.
>
> Configuration should include two dispatching sequences on for
> bidirectional message flows. one for the client to backend mediation other
> for the backend to client mediation.
>
> 3. Support different content types for Websocket frames dynamic way. This
> is handled using Websocket Sub protocol.
>
> Regards
> Kevin
>
> On Tue, Dec 22, 2015 at 10:22 AM, Kasun Indrasiri  wrote:
>
>> Hi all,
>>
>> We are working on adding WebSockets support into ESB 4.10. For the
>> default HTTP transport we won't be able to incorporate it as HTTPCore
>> doesn't offer native WebSockets support. However, with the concept of
>> inbound endpoints/connectors we will be able to implement it by leveraging
>> Netty. So that means we have to use a dedicated HTTP port with WebSocket
>> support.
>>
>> Kevin can you please share the main WebSockets use cases that we came up
>> with.
>>
>> 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
>
>


-- 
Eranga Perera
*Senior Lead Solutions Engineer*
*WSO2, Inc. *
Mobile :  +94 72 778 4250
eran...@wso2.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [MSS] Support lifecycle methods

[Isuru Perera]

Hi Imesh,

In Metrics, there are Reporters [1]. For example, DAS reporter [2] will
publish metrics to a DAS server. Metrics Reporter will not publish an event
for each invocation. The reporter will report periodically and we can
configure that time interval.

I hope this is clear.

Thanks!

[1] http://dropwizard.github.io/metrics/3.1.0/manual/core/#reporters
[2]
https://github.com/wso2/carbon-metrics/blob/v1.2.0-M2/components/org.wso2.carbon.metrics.das.reporter/src/main/java/org/wso2/carbon/metrics/das/reporter/DASReporter.java



On Tue, Dec 22, 2015 at 6:11 AM, Imesh Gunaratne  wrote:

> Hi Isuru,
>
> In MetricsInterceptor, I can see multiple interceptors are collecting data
> but could not figure out how they are published to a central server. It it
> done by the metric manager? Would you mind explaining how this works?
>
>
> https://github.com/wso2/product-mss/blob/v1.0.0-alpha/carbon-mss/components/org.wso2.carbon.mss/src/main/java/org/wso2/carbon/mss/metrics/MetricsInterceptor.java
>
> Thanks
>
> On Fri, Dec 18, 2015 at 2:31 PM, Isuru Perera  wrote:
>
>> Hi,
>>
>> In Standalone service mode, we support deploying multiple service
>> instances. That's the main concern I have. If a user adds multiple
>> services, the initialization step will run multiple times. Let's look at my
>> suggestion in next release.
>>
>> I made changes and sent a PR [1]. The init() methods are synchronized and
>> it will initialize only once.
>>
>> [1] https://github.com/wso2/product-mss/pull/86
>> 
>>
>> On Fri, Dec 18, 2015 at 11:57 AM, Sagara Gunathunga 
>> wrote:
>>
>>>
>>>
>>> On Fri, Dec 18, 2015 at 11:33 AM, Isuru Perera  wrote:
>>>
 Hi all,

 I'm trying to refactor code and move the initialization logic out from
 the interceptors we have. i.e. MetricsInterceptor [1] and
 HTTPMonitoringInterceptor [2]. With current lifecycle method support, we
 can write some initialization code within the service only [3].

>>>
>>> Since we are very close to GA release, let's continue with current
>>> service lifecycle approach and finish refactoring of above 2 Interceptor as
>>> we planed, while we can continue this discussion separately.
>>>

 I understand that it's better to have a separate class for
 initialization logic. But I need to make sure that initialization runs only
 once. That's why I initially wrote the initialization logic at the
 interceptor level. The user will add interceptor only once to the MSS
 application [4].

 If there are multiple services (as in sample [4]], we cannot ask user
 to initialize in each service as the initialization will run multiple
 times. We can solve that by changing the initialization code to run once.
 But I don't think that a good idea. There will be duplicate code in each
 service to initialize Metrics and HTTP Monitoring.

>>>
>>> Basically we have two deployment modes.
>>>
>>> 1.) Standalone service mode (aka MSS-lite)
>>>
>>> - In this mode we deploy single service per single application hence IMO
>>> service lifecycle annotations are sufficient because initialization code
>>> anyway run only one time.  BTW did you find any use cases that we can't
>>> cover with service LC methods under this mode ?
>>>
>>> 2.) OSGi server mode
>>>
>>> Since this mode is based on OSGi, can't we just use OSGi features such
>>> as bundle activators, OSGi-service annotations[1] such as @Acitvate,
>>> @Deactivate instead of inventing something new ?  We already use above OSGi
>>> features to register/deregister microservices, register/deregister
>>>  Interceptor etc.
>>>
>>> [1] -
>>> https://kishanthan.wordpress.com/2014/03/29/using-annotation-with-osgi-declarative-services/
>>>
>>> Thanks !
>>>
>>>

 Is it possible to have lifecycle method support for the entire MSS
 application as well? Something similar to ServletContextListener [5]?

 Thanks!

 Best Regards,

 [1]
 https://github.com/wso2/product-mss/blob/v1.0.0-alpha/carbon-mss/components/org.wso2.carbon.mss/src/main/java/org/wso2/carbon/mss/metrics/MetricsInterceptor.java#L47-L85
 [2]
 https://github.com/wso2/product-mss/blob/v1.0.0-alpha/carbon-mss/components/org.wso2.carbon.mss/src/main/java/org/wso2/carbon/mss/httpmonitoring/HTTPMonitoringInterceptor.java#L80-L196
 [3] https://github.com/wso2/product-mss/tree/master/samples/lifecycle
 [4]
 https://github.com/wso2/product-mss/blob/v1.0.0-alpha/samples/metrics/src/main/java/org/wso2/carbon/mss/example/Application.java#L39-L40
 [5]
 http://docs.oracle.com/javaee/6/api/javax/servlet/ServletContextListener.html



 On Sun, Nov 15, 2015 at 7:46 PM, Sagara Gunathunga 
 wrote:

>
>
> On Sun, Nov 15, 2015 at 7:40 PM, 

Re: [Architecture] Implementing Latency Metrics Calculation Feature in GW

[Isuru Perera]

Hi IsuruR,

As you said, please try to use Metrics feature. In Metrics, you can use a
reporter [1] and it will periodically report metrics.

[1] http://dropwizard.github.io/metrics/3.1.0/manual/core/#reporters

On Tue, Dec 22, 2015 at 6:28 AM, Imesh Gunaratne  wrote:

>
>
> On Wed, Dec 16, 2015 at 12:38 PM, Isuru Ranawaka  wrote:
>>
>>
>>- Data receiver needs to be Asynchronously collect the data without
>>blocking GW threads.
>>
>> What would be the approach we are planning to take here?
>
> Thanks
>
>>
>>- Latency Calculation Engine should be configurable (such as  per
>>request updating or time based updating)
>>- Scheduler is for  notify the Engine to calculate latency values
>>timely based.
>>- There should be extension point to add event formatters in order to
>>publish events in different formatters when needed.
>>- As a default values are published through JMX via m beans.
>>
>>
>> thanks
>>
>> IsuruR
>> --
>> Best Regards
>> Isuru Ranawaka
>> M: +94714629880
>> Blog : http://isurur.blogspot.com/
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Imesh Gunaratne*
> Senior Technical Lead
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057
> W: http://imesh.gunaratne.org
> Lean . Enterprise . Middleware
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Isuru Perera
Associate Technical Lead | WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware

about.me/chrishantha
Contact: +IsuruPereraWSO2 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] WebSockets support in ESB 4.10

[Kevin Ratnasekera]

since the the images are not rendered properly I am attaching the google
document [1] herewith

[1]
https://docs.google.com/document/d/1rPmJT-NVsPTC1SlUZUGw4gUQJjZ2R_K1rBIAY2a1dBc/edit

Regards
Kevin

On Tue, Dec 22, 2015 at 11:12 AM, Kevin Ratnasekera  wrote:

> Hi all,
> Here are the main use cases we found with related to WebSockets support in
> 410.
>
> 1. Websocket client to Websocket endpoint via ESB
>
>
>
> 2. Websocket client to HTTP endpoint via ESB
>
>
>
> 3. HTTP client to Websocket endpoint via ESB
>
>
> In each of the main use cases we need to support following sub use cases.
>
> 1. Header based routing scenario. This will be depend on the HTTP header
> specified at the initial handshake stage.
> 2. Content transformation scenario. As Websockets allows two way
> communication, we should be able to support two way mediation.
>
> Configuration should include two dispatching sequences on for
> bidirectional message flows. one for the client to backend mediation other
> for the backend to client mediation.
>
> 3. Support different content types for Websocket frames dynamic way. This
> is handled using Websocket Sub protocol.
>
> Regards
> Kevin
>
> On Tue, Dec 22, 2015 at 10:22 AM, Kasun Indrasiri  wrote:
>
>> Hi all,
>>
>> We are working on adding WebSockets support into ESB 4.10. For the
>> default HTTP transport we won't be able to incorporate it as HTTPCore
>> doesn't offer native WebSockets support. However, with the concept of
>> inbound endpoints/connectors we will be able to implement it by leveraging
>> Netty. So that means we have to use a dedicated HTTP port with WebSocket
>> support.
>>
>> Kevin can you please share the main WebSockets use cases that we came up
>> with.
>>
>> 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

Re: [Architecture] Fully automate cloud to cloud (iPaaS) use cases

[Thulasika Vijayanathan]

Hi,

I will look into that as well.


Thanks,

On Tue, Dec 8, 2015 at 11:35 AM, Malaka Silva  wrote:

> Hi,
>
> One of the main issues we had when automating the integration use cases is
> accesstokens getting expired and need human interaction to continue the
> service.
>
> From connector side (Since September release) we have added methods to
> renew the tokens using refresh token.
>
> With ESB 4.10 registry persistence feature we can fully automate this use
> case.
>
> As the first stage we are going to check how this can be done. For this
> will be using the sync service from Salesforce to Google Sheets as the
> model use case.
>
> We will plan to do this change focusing on following points.
>
>1. Connectors should make use of this ESB 4.10 new feature.
>2. Connector should be also compatible with previous versions.
>
> May be we can introduce a new init method for esb 4.10?
>
> Thulasika is currently checking this.
>
> @Thulasika please use this thread to update the findings.
>
> 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/
> 
> https://store.wso2.com/store/
>
> Save a tree -Conserve nature & Save the world for your future. Print this
> email only if it is absolutely necessary.
>



-- 
Thulasika
Associate Software Engineer
Mobile:0778014295
email: thulas...@wso2.com 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [EMM200] Performance & Load Testing

[Prabath Abeysekera]

One of the performance hits identified while analysing the JFR dumps taken
out of EMM 2.0 set-ups is the time taken for token validation. The nature
of the aforesaid token validation is that, a service stub is used to invoke
an admin service deployed as part of EMM's Key Manager profile for token
validation and the stub instances are created per-request to avoid the
impact that is likely to be caused by stubs being less thread-safe. This
pattern proved to be very expensive as it was quite evident that the stub
instantiation is expensive. As a fix, a pool of stubs was introduced to
mitigate the above explained impact with appropriate means to cleanup
metadata just before the pooled stubs are returned to the pool. This helped
doubling the numbers obtained for a properly distributed set-up of EMM 2.0.
Please refer [1] for the source code.

[1]
https://github.com/wso2/carbon-device-mgt/commit/11957f1e478f884cc1f100debb4bbc8290c0901c

Cheers,
Prabath

On Mon, Dec 21, 2015 at 2:44 PM, Dileesha Rajapakse 
wrote:

> 1. Install Jmeter
> *sudo apt-get install jmeter*
>
> 2. Replace the '*/usr/share/jmeter/lib/*' directory with the 'lib'
> directory which could be downloaded from below link. (This file contains
> all the necessary library files needed to run test scripts)
>
> https://drive.google.com/file/d/0B1raQ3vGHU8uMjlhZU1EVzR0VGc/view?usp=sharing
>
> 3. Download and extract the scripts file
>
> https://drive.google.com/file/d/0B1raQ3vGHU8uaXhULTZzQUQwamc/view?usp=sharing
>
> The above '*EMM200LoadTests.zip*' file contains a total of 5 files.
>
>- *emm_devices.csv *- Contains information about 50 unique devices
>- *EnrollDevices.jmx* - Enrolls Devices
>- *AddOperations.jmx* - Adds Operations to enrolled devices (2
>operations per each device)
>- *GetPendingOperations.jmx* - Hits the '/mdm-android-agent/operation'
>endpoint which is the most heavily used API of the EMM
>- *MDM2LoadTesting.jmx* - This script contains a sample Jmeter test
>plan which has several additional useful test ThreadGroups which can be
>used to simulate scenarios such as Operation Execution, Policy Creation and
>Policy Monitoring
>
> *[Important]* Make sure the 'emm_devices.csv' file and the script files
> are in the same folder.
> 4. Specify these parameters when running test scripts
>
> *JHOST* --> Server Host
> *JPORT* --> Server Port
> *JUSERS* --> Number of Users (Concurrency)
> *JLOOPCOUNT* --> Number of Iterations per User
>
>
> Device Enrollment
>
> jmeter -n -JHOST= -JPORT=
> -JUSERS= -JLOOPCOUNT= -t EnrollDevices.jmx -l
> errors.log
>
>
>- To enroll a '*n*' number of devices set the parameters as follows, 
> *(-JUSERS)*(-JLOOPCOUNT)
>= n*
>
>
> Add Operations
>
> jmeter -n -JHOST= -JPORT=
> -JUSERS= -JLOOPCOUNT= -t AddOperations.jmx -l
> errors.log
>
>
> Get Pending Operations
>
> jmeter -n -JHOST= -JPORT=
> -JUSERS= -JLOOPCOUNT= -t
> GetPendingOperations.jmx -l errors.log
>
>
> --
> Dileesha Rajapakse
> *Intern - Engineering*
> Mobile : +94 (0) 772 555 933
> Tel  : +94 112 741 505
> dilee...@wso2.com
>



-- 
Prabath Abeysekara
Technical Lead
WSO2 Inc.
Email: praba...@wso2.com
Mobile: +94774171471
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [EMM200] Performance & Load Testing

[Sumedha Rubasinghe]

Prabath,
API Manager has the same setup and it uses a Thrift client for the same (in
the place of using a stub for admin service)
Can't we use the same Thrift server/client pattern?We had a similar
situation in BAM data publisher. There also we used Thrift for performance
reasons.

Stubs are known to have performance problems for high concurrent scenarios
due to marshalling/un-marshalling.



On Mon, Dec 21, 2015 at 3:20 PM, Prabath Abeysekera 
wrote:

> One of the performance hits identified while analysing the JFR dumps taken
> out of EMM 2.0 set-ups is the time taken for token validation. The nature
> of the aforesaid token validation is that, a service stub is used to invoke
> an admin service deployed as part of EMM's Key Manager profile for token
> validation and the stub instances are created per-request to avoid the
> impact that is likely to be caused by stubs being less thread-safe. This
> pattern proved to be very expensive as it was quite evident that the stub
> instantiation is expensive. As a fix, a pool of stubs was introduced to
> mitigate the above explained impact with appropriate means to cleanup
> metadata just before the pooled stubs are returned to the pool. This helped
> doubling the numbers obtained for a properly distributed set-up of EMM 2.0.
> Please refer [1] for the source code.
>
> [1]
> https://github.com/wso2/carbon-device-mgt/commit/11957f1e478f884cc1f100debb4bbc8290c0901c
>
> Cheers,
> Prabath
>
> On Mon, Dec 21, 2015 at 2:44 PM, Dileesha Rajapakse 
> wrote:
>
>> 1. Install Jmeter
>> *sudo apt-get install jmeter*
>>
>> 2. Replace the '*/usr/share/jmeter/lib/*' directory with the 'lib'
>> directory which could be downloaded from below link. (This file contains
>> all the necessary library files needed to run test scripts)
>>
>> https://drive.google.com/file/d/0B1raQ3vGHU8uMjlhZU1EVzR0VGc/view?usp=sharing
>>
>> 3. Download and extract the scripts file
>>
>> https://drive.google.com/file/d/0B1raQ3vGHU8uaXhULTZzQUQwamc/view?usp=sharing
>>
>> The above '*EMM200LoadTests.zip*' file contains a total of 5 files.
>>
>>- *emm_devices.csv *- Contains information about 50 unique devices
>>- *EnrollDevices.jmx* - Enrolls Devices
>>- *AddOperations.jmx* - Adds Operations to enrolled devices (2
>>operations per each device)
>>- *GetPendingOperations.jmx* - Hits the
>>'/mdm-android-agent/operation' endpoint which is the most heavily used API
>>of the EMM
>>- *MDM2LoadTesting.jmx* - This script contains a sample Jmeter test
>>plan which has several additional useful test ThreadGroups which can be
>>used to simulate scenarios such as Operation Execution, Policy Creation 
>> and
>>Policy Monitoring
>>
>> *[Important]* Make sure the 'emm_devices.csv' file and the script files
>> are in the same folder.
>> 4. Specify these parameters when running test scripts
>>
>> *JHOST* --> Server Host
>> *JPORT* --> Server Port
>> *JUSERS* --> Number of Users (Concurrency)
>> *JLOOPCOUNT* --> Number of Iterations per User
>>
>>
>> Device Enrollment
>>
>> jmeter -n -JHOST= -JPORT=
>> -JUSERS= -JLOOPCOUNT= -t EnrollDevices.jmx -l
>> errors.log
>>
>>
>>- To enroll a '*n*' number of devices set the parameters as follows, 
>> *(-JUSERS)*(-JLOOPCOUNT)
>>= n*
>>
>>
>> Add Operations
>>
>> jmeter -n -JHOST= -JPORT=
>> -JUSERS= -JLOOPCOUNT= -t AddOperations.jmx -l
>> errors.log
>>
>>
>> Get Pending Operations
>>
>> jmeter -n -JHOST= -JPORT=
>> -JUSERS= -JLOOPCOUNT= -t
>> GetPendingOperations.jmx -l errors.log
>>
>>
>> --
>> Dileesha Rajapakse
>> *Intern - Engineering*
>> Mobile : +94 (0) 772 555 933
>> Tel  : +94 112 741 505
>> dilee...@wso2.com
>>
>
>
>
> --
> Prabath Abeysekara
> Technical Lead
> WSO2 Inc.
> Email: praba...@wso2.com
> Mobile: +94774171471
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
/sumedha
m: +94 773017743
b :  bit.ly/sumedha
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [BPMN] Implementing correlation support for BPMN Rest API

[Frank Leymann]

The process model you have drawn enables multiple receiving message events
in parallel. According to the BPMN 2.0 spec this is not allowed for
key-based correlation (i.e. the correlation mechanism similar to BPEL
correlation sets); but it is allowed for predicate based correlation (often
used in collaborations).  I assume that we are not dealing with
collaborations here. Thus, only one of the events/tasks will receive the
message - you see mainly two ways in which this is handled by an engine,
(i) the engine randomly assigns the message, or (ii) a runtime error
occurs. Not sure what our implementation does.  But many people (including
me) consider a process model that specifies concurrent consumption of the
same message a severe modeling error...


Why are the correlation-keys not sufficient?  When a process is
instantiated it gets tightly coupled with a process model, i.e. a version
of a certain process model; and all correlation-keys associated with that
instance are coupled with that version. Correlation-keys don't come out of
the blue: the firsts correlation keys used to instantiate the process
instance are "arbitrary" but after that correlation keys "must fit" -
admittedly, the BPMN spec is not precise on it, but BPEL (that is the
template for that) is more precise.

Maybe I am missing the point what we want to achieve, i.e. that we need all
the information Firzhan sketches...


Best regards,
Frank

2015-12-16 5:40 GMT+01:00 Chathura Ekanayake :

>
>
>
>
>>
>>
>> We need to have the process definition id, in case there are multiple
>> versions of the same process definition exists with in the engine. Because
>> of this we are having it as an optional parameter.
>>
>
> I agree with that. But can we make message name optional? We use process
> definition id, activiti id, correlation variables, etc to locate the
> execution. Once an execution is located, I think we need to provide the
> message name when triggering the message event.
>
>
>>
>>
>>
>> On Mon, Dec 14, 2015 at 2:25 PM, Chathura Ekanayake 
>> wrote:
>>
>>> Hi Firzhan,
>>>
>>>
>>> *processDefinitionKey/processDefinitionId/messageName* (compulsory)

 Either one relevant property out of three should be specified in the
 request.

>>>
>>> Shouldn't we provide messageName or signalName irrespective of the
>>> availability of process definition key or id. Once we queried an execution,
>>> I think we need either a message name or a signal name to trigger the
>>> receive event. Please check with API.
>>>
>>>
>>>

 *activityId *(optional)

 This property is required when there are more than one receivers
 waiting for the same message/signal in different execution flows.



 ​​
 In the above process flow,  all three or two of the execution flows
 might be waiting for the same message.

 *action *(compulsory)

 actions can be either messageEventRecieved/signalEventRecieved/signal.

 *signalName* (optional)

 If we have any signal related actions, then *signalName* has to be
 specified.


 *variables* (optional)

 This holds the task specific local variables that can be used to query
 and filter the relevant process instances.

 *processInstanceVariables* (optional)

 All the instance variables except correlation variables can be
 mentioned here.


 *correlationVariables* (compulsory)

 All the correlation variables should be mentioned here. By default it
 performs the equal operation of that variables.

 *variables* and *processInstanceVariables *can be used to speed up the
 querying process and the correlation variables should be unique across the
 process instances.

>>>
>>> Correlation variables are the ones used to query the relevant execution.
>>> Process instance variables are used to pass in new data values with the
>>> message. What is the purpose of the first "variables" parameter?
>>>
>>> Regards,
>>> Chathura
>>>
>>>
>>>
>>>
>>
>
> ___
> 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