Re: [Architecture] Decoupling API-GW from API Publisher/Store
Agreed that making this pluggable is important, although it poses
interesting management issues (the publishing experience in particular).
Another design point, after discussing with a key prospect: ability to
decentralize the administration of the GWs by getting them to pull their
configuration from the central repository. All the APIs are managed
centrally (as in metadata management) but are executed in a decentralized
way (in different countries for example). Monitoring is central though.
Isabelle.
-
*Isabelle Mauny*
VP, Product Strategy - WSO2, Inc. - http://wso2.com/
On Mon, Jul 25, 2016 at 11:54 AM, Sanjeewa Malalgoda <sanje...@wso2.com>
wrote:
> Hi All,
> Day by day we are getting many requirements for exact same requirement.
> So i think we need to consider this for upcoming release. WDYT?
>
> Thanks,
> sanjeewa.
>
> On Tue, Jan 26, 2016 at 2:17 PM, Joseph Fonseka <jos...@wso2.com> wrote:
>
>> Hi All
>>
>> +1 for making the new GW pluggable.
>>
>> Apart from defining a GWInterface we might have to generalize some UI
>> parts ie mediation, advance endpoint configs which are currently specific
>> to ESB or those UI parts also needs to be pluggable.
>>
>> Regards
>> Jo
>>
>>
>>
>>
>>
>>
>> On Tue, Jan 26, 2016 at 12:29 PM, Sanjeewa Malalgoda <sanje...@wso2.com>
>> wrote:
>>
>>> Hi All,
>>> We quickly went through code and checked how we can accommodate this
>>> change with minimum changes to current implementation.
>>> I can see 2 places where we can plug this as extension (and let users to
>>> implement as per requirements).
>>> API publisher is the only component that need direct API gateway access.
>>> Other components do not need direct API gateway access. And gateway will
>>> use other components.
>>>
>>>
>>> 01. Extract interface from APIGatewayAdminClient and make it pluggable.
>>> Then we may need to implement API related methods, secure
>>> vault(according to requirements) related methods and sequence related
>>> methods there.
>>> As of now we have abstract class for admin client and
>>> implementation is APIGatewayAdminClient.
>>> In that case we need to implement like 15 methods which are
>>> coupled to our current synapse based gateway.
>>>
>>> 02. Extract interface from APIGatewayManager and let users to do their
>>> implementation based on it and plug it to publisher.
>>> Then we will have interface similar to below and its more generic
>>> than previously mentioned implementation.
>>>
>>> public interface APIGatewayManagerInterface {
>>> Map<String, String> publishToGateway(API api, APITemplateBuilder
>>> builder, String tenantDomain);
>>> Map<String, String> removeFromGateway(API api, String tenantDomain);
>>> Map<String, String> removeDefaultAPIFromGateway(API api, String
>>> tenantDomain);
>>> boolean isAPIPublished(API api, String tenantDomain)throws
>>> APIManagementException;
>>> }
>>>
>>> Both of these implementations should support multiple environment use case.
>>> In APIGatewayManager we are checking multiple environments and if we used
>>> APIGatewayManager as extension point then users are free to implement that
>>> logic as well.
>>> However this pluggable component need to have access to API Manager
>>> configuration reader and get certain properties(environment details,
>>> gateway url etc) from that.
>>>
>>> Next we need to think about what we are going to do for handlers and custom
>>> sequences.
>>> As per offline chat with chanakaF next version of gateway will have some
>>> mechanism to extend mediation sequence.
>>> And also there will be alternative for handlers.
>>> So we may use them while doing implementation for new gateway.
>>>
>>> For both of these implementations we need to make APITemplateBuilder
>>> pluggable(this builder is responsible for create API description based on
>>> predefined template).
>>> Then we can maintain template builder for each gateway type.
>>>
>>> WDYT?
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>>
>>> On Tue, Jan 19, 2016 at 10:25 AM, Kasun Indrasiri <ka...@wso2.com>
>>> wrote:
>>>
>>>> @Sanjeewa,
>>>> I think we have to provide an abstraction
Re: [Architecture] GW/ESB5 messaging architecture
It will have that Harshana - We are making this part of the engine design. Isabelle. - *Isabelle Mauny* VP, Product Management - WSO2, Inc. - http://wso2.com/ email: isabe...@wso2.com - mobile (Spain) : +34 616050684 - mobile (Sri Lanka) +94 (0)774777663 Landline: +1 (650) 745 4499 (USA) or +94 (11) 214 534 (SL) Extension : 7302 On Tue, Jan 19, 2016 at 1:10 PM, Harshana Eranga Martin < harshan...@gmail.com> wrote: > Hi Kasun, > > Does the C5 ESB, GW and Carbon Transport has the message debug capability > similarly what you are building with C4 mediation debugger capability at > the moment? > > If not it would be quite useful to build a mediation debugging capability > as a core capability so that every product inherently have the capability. > Once DevS team build the visual debugging interface users can use DevS to > test and debug the implementations on the fly for any product. > > Thanks and Regards, > Harshana > > On Tuesday, 19 January 2016, Kasun Indrasiri <ka...@wso2.com> wrote: > >> >> >> On Tue, Jan 19, 2016 at 11:50 AM, Kasun Indrasiri <ka...@wso2.com> wrote: >> >>> Hi, >>> >>> This is a summary of how we support messaging with C5 ESB and GW. >>> >>> *Carbon Message [1] * >>> - This is the generic message representation which contains message >>> headers and reference to extract the message body (fully type-aware and no >>> canonicalization required) >>> - The idea is to use this as the generic message representation across >>> the all the products that uses carbon-transport. >>> >>> *Carbon Transports* >>> - Protocol handling layer that converts the wire msg -> carbon message >>> (receiving) and carbon-message -> wire msg (sending). >>> - The objective is to make sure all products can use same transports >>> with generic message representation (without any canonicalized message such >>> as SOAP). At the moment with C4, since we don't have a generic message >>> representation, different products has to implement their own protocol >>> handlers/transports to cater to their specific needs. (eg: ESB, CEP etc.) >>> >>> *Carbon Message Processor* (API) [2] >>> - Any component that want to consume message from transport has to >>> implement this and plug that in. >>> - We use this mechanism to receive messages into the GW message >>> processor/engine through the Netty transport [3]. >>> - In addition you can use the TransportSender in case if you want to >>> send message out from the message processor impl through any protocol. >>> >>> *CarbonCallback[4] * >>> - We don't use in and out flow model any more in the new architecture. >>> So, both request and response flows work asynchronously with the use of >>> callbacks. (Idea is to later replace this with RxJava) >>> >>> I think all these things are completely independent from ESB/GW and can >>> be used as the generic messaging architecture for C5. >>> >>> [1] >>> https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonMessage.java >>> [2] >>> https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonMessageProcessor.java >>> >>> [3] >>> https://github.com/wso2/product-gw/blob/master/carbon-gw/components/org.wso2.carbon.gateway/src/main/java/org/wso2/carbon/gateway/internal/mediation/camel/CamelMediationEngine.java >>> >>> [4] >> https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonCallback.java >> >> >>> @Shafreen/Senduran : Please add if anything else is missing. >>> >>> Thanks, >>> -- >>> Kasun Indrasiri >>> Software Architect >>> WSO2, Inc.; http://wso2.com >>> lean.enterprise.middleware >>> >>> cell: +94 77 556 5206 >>> Blog : http://kasunpanorama.blogspot.com/ >>> >> >> >> >> -- >> Kasun Indrasiri >> Software Architect >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> cell: +94 77 556 5206 >> Blog : http://kasunpanorama.blogspot.com/ >> > > > -- > Sent from Gmail Mobile for IPhone > > ___ > 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
Re: [Architecture] Workflow Implementation in IS 5.1.0
address is from WSO2. Now - I need to select what needs to be done during the add user operation. User picks one of the available *workflow templates* - and fill the data required. If there are more than one implementations for the picked* workflow template *system will present you an option to pick the workflow (rather unlikely) if not - system already associates the available workflow with the selected workflow template - user has to nothing there. Thanks regards, -Prabath On Tue, Jul 14, 2015 at 11:36 AM, Isabelle Mauny isabe...@wso2.com javascript:_e(%7B%7D,'cvml','isabe...@wso2.com'); wrote: Prabath, Couple of clarifications: - If a user ( customer ) adds a template, what would they need to write ? The template definition *AND* the implementation (i.e. executor) ? i.e other words they have to describe the interface to the workflow itself and then implement the workflow in say BPEL ? Or Java ? or whatever ? - How does a customer maps between the template and the executor ? (i.e. how do parameters defined in template becomes Receive data in BPEL for example) Thanks, Isabelle. - *Isabelle Mauny* VP, Product Management - WSO2, Inc. - http://wso2.com/ On Tue, Jul 14, 2015 at 6:22 PM, Prabath Siriwardena prab...@wso2.com javascript:_e(%7B%7D,'cvml','prab...@wso2.com'); wrote: It looks like still there are some confusions regarding IS workflow implementation. So, thought of sharing my thoughts on the design - and hopefully this be helpful to clear out the doubts. AFAIK - the framework for the following is already implemented. Basic design principals. 1. Simplicity. Keep simple things simple and have provisions to add more complex stuff 2. Not coupled into any implementation. No hard coupling to BPEL 3. Not coupled into WSO2 BPS. (part of 2 as well) 4. Not specific to IS Terminology: 1. *Workflow* - implementation independent abstract representation of the concrete workflow has two parts, *initializer* and the *executor*. If its BPEL based workflows the initializer can be used to initialize the BPEL and deploy it in the corresponding BPEL engine. And the executor will execute the workflow in runtime. 2. *Attachment Point* - you should be able to attach a workflow to an *Attachment Point *and will get executed in runtime when a request hits the corresponding *Attachment Point*. Some examples of *Attachment Points* : add_user, delete_user, add_role, add_xacml_policy, update_xacml_policy. *Attachment Points* - are independent from the *workflow*. *Attachment Points* are introduced into system via an OSGi service. For example user_add, user_update, role_add - all those Attachment Points are announced into the system by a UserManagerOperationListner. *Attachment Points *can be developed and deployed independently. Once the system discovers the availability of an *Attachment Point *- it will display that to the user - so he can engage and workflow to that *Attachment Point.* 3. *Attachment Point Template* These are coupled to specific* Attachment Points*. For example, the *Attachment Point Template *- associated with the user_add *Attachment Point* may look like following. *user match : reg-ex* Now the *Attachment Point* will invoke the associated workflow executor only if the above criteria is met. 4. *Workflow Template *: These templates should be announced to the system along with the *workflow* implementation. This template is independent from the *Attachment Point Template*. This tell how to configure the workflow. With this approach you can have the same work flow - but configured in different ways based on the* Attachment Point*. Once example could be: Step-1 Approvers : role1 OR role2 AND user1 Step-2 Approvers : role3 OR role4 AND user3 likewise... Okay - so far everything discussed above are related to the core framework design. In IS 5.1.0 we need to have a concrete implementation of followings.. 1. *Attachment Points*- for all user / role related operations. 2. *Attachment Point Templates* - for all user / role related operations. 3. *Workflow* - initiator and executor for WSO2 BPS BPEL implementation - and concrete multi-step approval BPEL workflow. 4. *Workflow Templates*: A template for the multi-step approval BPEL workflow Please let me know if you have any doubts or suggestions.. also Johann/Pulsathi please verify whether the implementation is done according to this. -- Thanks Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://blog.facilelogin.com http://blog.api-security.org -- Thanks Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://blog.facilelogin.com http://blog.api-security.org
Re: [Architecture] Workflow Implementation in IS 5.1.0
Prabath, Couple of clarifications: - If a user ( customer ) adds a template, what would they need to write ? The template definition *AND* the implementation (i.e. executor) ? i.e other words they have to describe the interface to the workflow itself and then implement the workflow in say BPEL ? Or Java ? or whatever ? - How does a customer maps between the template and the executor ? (i.e. how do parameters defined in template becomes Receive data in BPEL for example) Thanks, Isabelle. - *Isabelle Mauny* VP, Product Management - WSO2, Inc. - http://wso2.com/ On Tue, Jul 14, 2015 at 6:22 PM, Prabath Siriwardena prab...@wso2.com wrote: It looks like still there are some confusions regarding IS workflow implementation. So, thought of sharing my thoughts on the design - and hopefully this be helpful to clear out the doubts. AFAIK - the framework for the following is already implemented. Basic design principals. 1. Simplicity. Keep simple things simple and have provisions to add more complex stuff 2. Not coupled into any implementation. No hard coupling to BPEL 3. Not coupled into WSO2 BPS. (part of 2 as well) 4. Not specific to IS Terminology: 1. *Workflow* - implementation independent abstract representation of the concrete workflow has two parts, *initializer* and the *executor*. If its BPEL based workflows the initializer can be used to initialize the BPEL and deploy it in the corresponding BPEL engine. And the executor will execute the workflow in runtime. 2. *Attachment Point* - you should be able to attach a workflow to an *Attachment Point *and will get executed in runtime when a request hits the corresponding *Attachment Point*. Some examples of *Attachment Points* : add_user, delete_user, add_role, add_xacml_policy, update_xacml_policy. *Attachment Points* - are independent from the *workflow*. *Attachment Points* are introduced into system via an OSGi service. For example user_add, user_update, role_add - all those Attachment Points are announced into the system by a UserManagerOperationListner. *Attachment Points *can be developed and deployed independently. Once the system discovers the availability of an *Attachment Point *- it will display that to the user - so he can engage and workflow to that *Attachment Point.* 3. *Attachment Point Template* These are coupled to specific* Attachment Points*. For example, the *Attachment Point Template *- associated with the user_add *Attachment Point* may look like following. *user match : reg-ex* Now the *Attachment Point* will invoke the associated workflow executor only if the above criteria is met. 4. *Workflow Template *: These templates should be announced to the system along with the *workflow* implementation. This template is independent from the *Attachment Point Template*. This tell how to configure the workflow. With this approach you can have the same work flow - but configured in different ways based on the* Attachment Point*. Once example could be: Step-1 Approvers : role1 OR role2 AND user1 Step-2 Approvers : role3 OR role4 AND user3 likewise... Okay - so far everything discussed above are related to the core framework design. In IS 5.1.0 we need to have a concrete implementation of followings.. 1. *Attachment Points*- for all user / role related operations. 2. *Attachment Point Templates* - for all user / role related operations. 3. *Workflow* - initiator and executor for WSO2 BPS BPEL implementation - and concrete multi-step approval BPEL workflow. 4. *Workflow Templates*: A template for the multi-step approval BPEL workflow Please let me know if you have any doubts or suggestions.. also Johann/Pulsathi please verify whether the implementation is done according to this. -- Thanks Regards, Prabath Twitter : @prabath LinkedIn : http://www.linkedin.com/in/prabathsiriwardena Mobile : +1 650 625 7950 http://blog.facilelogin.com http://blog.api-security.org ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [ESB] Can we get rid of the usage of get-property function?
Totally +1 to that suggestion.. backward compatibility is key .. - *Isabelle Mauny* VP, Product Management - WSO2, Inc. - http://wso2.com/ On Wed, Jun 17, 2015 at 3:17 PM, Colin Roy-Ehri col...@wso2.com wrote: +1 It would be great to simplify the options available for property lookup. I think this would increase the usability of our product. I am also concerned about customers migrating their existing xml code. In order to gain performance by moving away from get-property, would customers need to revise all their use of these mediators? I support deprecating the get-property from the UI wizard and Dev Studio, but it would also be great to revise the get-property implementation for future versions. In other words, would it be possible to change the get-property implementation so that proxies, APIs and sequences could be migrated forward without change, and still use the more efficient scoped-style efficient implementation? This would prevent the registry performance hit, and prevent the necessity for customers to modify all their xml code. Thanks, Colin Roy-Ehri Software Engineer *WSO2, Inc. : wso2.com http://wso2.com/* *Mobile* : 812-219-6517 On Wed, Jun 17, 2015 at 2:41 AM, Kasun Indrasiri ka...@wso2.com wrote: Hi, It seems we can get rid of the usage of get-property and stick to the usage of scope variable declarations only (the current impl of get-property function always triggers a call to ESB registry interface, which can be a performance hit). For example we can use: $ctx, $trp etc to get required property values from the context. @Nadeeshan : we need to include $registry: as well. Any other use cases that we need to cover? -- 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 ___ 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
Re: [Architecture] MB 3.0 Metrics
All, Are those counters available via JMX ? Isabelle - *Isabelle Mauny* VP, Product Management - WSO2, Inc. - http://wso2.com/ On Fri, May 22, 2015 at 7:21 AM, Anuja Herath an...@wso2.com wrote: Hi Ramith, Thanks for the suggestion. Let's add disruptor related metrics to 'INFO' level. Regards, Anuja On Fri, May 22, 2015 at 10:47 AM, Ramith Jayasinghe ram...@wso2.com wrote: I think knowing the state if inbound/outbound disruptors is important at the first look ( when trouble shooting). Shall we make that 'INFO' level. @IsuruP: Can we change matrics configs on the fly with out restarting the servers ( e.g. enable debug level stats) and will there be lots of logs/data accumulated over time with use of matrices library? regards Ramith On Fri, May 22, 2015 at 10:40 AM, Anuja Herath an...@wso2.com wrote: Hi All, We are going to add carbon metrics support for MB 3.0. After implementing, we will be able to identify and troubleshoot bottlenecks at different levels in MB easily. Following is the list of metrics that we are going to implement at initial stage. MetricLog LevelDescriptionMessages Received/secINFONumber of messages recieved per second. This metric is calculated when a message reaches server.Acknowledges Sent/secINFONumber of acknowledgments sent to publishers per second.Total ChannelsINFOTotal number of active channels.Messages Published/secINFONumber of message published per second. This metrics is calculated when server publishes a message to a subscriber.Acknowledges Received /secINFONumber of acknowledgments received from publishers per second.Total ConsumersINFOTotal number of active consumers.Database read latencyINFOAverage value of time taken for database read calls.Database write latencyINFOAverage value of time taken for database write calls.Total Messages in Inbound DisruptorDEBUGCurrent number of messages in inbound disruptor.Total Messages in Outbound DisruptorDEBUGCurrent number of messages in outbound disruptor.Database latencies (Method Level)DEBUGOperation wise latencies of database calls.Cluster Coordinator LatencyDEBUGLatency of cluster coordination -- Anuja Herath *Software Engineer* *WSO2, Inc.* Mobile : +94 (0)71 429 8861 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Ramith Jayasinghe Technical Lead WSO2 Inc., http://wso2.com lean.enterprise.middleware E: ram...@wso2.com P: +94 777542851 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Anuja Herath *Software Engineer* *WSO2, Inc.* Mobile : +94 (0)71 429 8861 ___ 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
Re: [Architecture] [APIM] Export and Import APIs
I am sorry, I don't understand your logic and I am +1 with Harshana (HI there !) This is not about importing and exporting APIs, it's about enabling the automated deployment of API artifacts across multiple environments. That's the target goal- Import and export is a side-effect of that-Let's focus on that first - How the file will be generated underneath is an implementation detail.- We need to create a packaged delivery application, which contains the API defintion, it's meta-data, attached description (WADL, WSDl, etc.) , attached docs (files, URLs.) - If we don't do that, we don't fulfill the requirement of passing a FULL API definition across environments. The CApp *is* the archive- And we need to desing the structure of that CApp. If we do something else, people will have to repackage their APIs when we move to a CApp. I think the priority is to design the contents/structure of that archive. Thanks, Isabelle. - *Isabelle Mauny* VP, Product Management - WSO2, Inc. - http://wso2.com/ On Wed, May 6, 2015 at 10:58 AM, Sanjeewa Malalgoda sanje...@wso2.com wrote: On Wed, May 6, 2015 at 11:30 AM, Harshana Eranga Martin harshan...@gmail.com wrote: Hi Thilini, I think this is a very useful feature for the platform. API Management users are going to benefit from this a lot as we have been facing the issue for long time with multiple environments. I have few concerns about the implementation though. Please see the comments inline. Thanks and Regards, Harshana -- Harshana Eranga Martin Senior Software Engineer Asian Mobile Banking Web: https://www.commbank.com.au/ http://wso2.com ECF Committer: http://www.eclipse.org/ecf/ Blog: http://harshana05.blogspot.com Profile: https://www.google.com/profiles/harshana05 On 6 May 2015 at 11:43, Thilini Cooray thili...@wso2.com wrote: Hi, *Regarding Isabelle's concerns,* a) This feature will be available as a custom application. Therefore we decided to package this as a WAR. I think it is not right to export APIs as a WAR file. WAR is already a well known file extension allocated for Web-Apps. It is going to complicate the life of users of both Web-Apps and API Management feature. Actually its not the archive format for APIs. What they meant was they develop this rest API (for archive APIs) as jax-rs application and bundled it as WAR file in away that we can deploy in API Manager server. Then you will call to that JAX-RS service and request archived APIs and it will return as .zip file. You will get that data as multipart form data or any other format. I also believe as Isabelle suggested exporting the API as an artifact in the C-App would be the best mechanism. This will allow you to implement a new C-App artifact deployer for API manager and introduction of new Artifact type with an artifact structure. This Artifact deployer will understand the artifact metadata structure and knows how to interpret the metadata as well as generation of the metadata and the artifact when someone requests to export from the Publisher App. This would be a clean way to implement the export and import feature. Yes C-App would be good approach. But adding API is bit complicate process that and adding sequence, proxy service etc. So i think we can start with API archive and then later bundle it to C-App, WDYT? Having the API as an separate entity in the C-App would help the concern of deployment of Sequences as well since Sequences are already an artifact type supported in the Platform. Hence you can export and import the API and Sequence independent of each other using C-App. API will contain the reference to the Sequence in the API artifact and once the C-App deployed, it will deploy the API artifact as well as referenced Sequence. It will allow you to reuse the same sequence across multiple APIs while the Sequence itself can be governed independently of the APIs. Thanks and Regards, Harshana b) The QoS details will also be stored in the API c) Swagger file is also inside the meta information. *Regarding Srinath's concerns,* We are storing meta-information in JSON format. We only support Swagger and it will be stored under meta information. Actually we do not need to export swagger content when we export API. Swagger is just a definition that we use to import API definition. And in future we may use different API description languages. Once we imported it to our platform we need to maintain all data in our platform. So IMO we dont need to include swagger json to archive, Instead of that we should be able to generate swagger based on our API metadata. And our plan is to make it customizable in future. So if you need to generate swagger, raml or any other API description base on our metadata you need to implement interface provided by us. Lets not bind to single API description language and make
Re: [Architecture] Improving app versioning support in App Manager - (Next release)
I thought this was the default behavior since it's already working like this in API- M so +1 to make the version change transparent to users. When you say next release, you mean 1.1.0 ? or 1.0.0. Isabelle. - *Isabelle Mauny* VP, Product Management - WSO2, Inc. - http://wso2.com/ On Mon, May 4, 2015 at 5:35 PM, Sumedha Rubasinghe sume...@wso2.com wrote: On Mon, May 4, 2015 at 8:30 PM, Dinusha Senanayaka dinu...@wso2.com wrote: Hi, We thought of doing some changes to current versioning support in App Manager. Current model is similar to Create new version functionality in API Manager. All versions are appeared on store (unless previous version is deprecated) and each app is having separate gateway endpoint with version. This result in having different urls for each versioned app. Not like the APIs, Apps are end user base and url should be constant while there is only latest version off app appeared on the store. So we thought of adding following changes to current model, *Current model:* *Publisher* - All versions are appeared on publisher - Can edit all versions except retired/depecated apps *Store* - All versions are appeared on store - Users can subscribe to any version *Gateway * - Each versioned app is having different url eg: http://localhost/app1/v1 http://localhost/app1/v2 *New model:* *Publisher* - All versions are appeared on publisher - Can edit only latest version *Store* - Only latest version is available *Gateway* - GW url is constructed without appending version to url eg: http://localhost/app1 *Implementation changes:* When new version added to an app: It should be when a new version of an app is published (not added). - Make it as the default version - Retire all previous versions - Move all existing subscriptions to new version (seamless to enduser) With new model new version creations are not visible to end user, he will always use the new version seamlessly. Appreciate any feedback. Regards, Dinusha. -- Dinusha Dilrukshi Associate Technical Lead WSO2 Inc.: http://wso2.com/ Mobile: +94725255071 Blog: http://dinushasblog.blogspot.com/ -- /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] [APIM] Export and Import APIs
All, Can you please confirm: a) That the packaging is a CApp (i.e. talks to API Manager deployer). b) Where is the QOS setup stored ( the managed part ) - For backup purposes, it would be great to attach QoS to the API. or do we assume that users will have to attach the QoS part manually (i.e.. after deployment we get an API in CREATE mode). c) Where is the Swagger file describing the API stored ? As part of meta-data ? I don't think sequences themselves should be there, just the link. Sequences are reusable across APIs and must not be deployed as part of the API itself. However, I should be able to package a set of sequences and deploy them to an API Manager (again, as CApp, as we do for the ESB). The sequences themselves can be managed/versioned/ separately. As for the tiers etc, those are dependent setup that must be in place before you import in the target environment - Part of the env preparation. We could create an import/export for that too (it's a simple check.out/check.in from registry). Same applies to workflows, store definitions, etc. Isabelle. __ Isabelle Mauny VP, Product Management; WSO2, Inc.; http://wso2.com/ On Apr 22, 2015, at 4:38 PM, Colin Roy-Ehri col...@wso2.com wrote: Hi! I'm really excited about this feature - it will be of great benefit to our customers. I have no improvements to suggest on your implementation plan. One point you might want to work into your tests is to ensure the swagger definitions remain consistent after an import/export. Of particular concern is the swagger YAML definitions available through the publisher. It shouldn't be too hard to code into a test. :) Thanks, Colin Thanks, Colin Roy-Ehri Software Engineer WSO2, Inc. : wso2.com Mobile : 812-219-6517 On Wed, Apr 22, 2015 at 7:15 AM, Thilini Cooray thili...@wso2.com wrote: Hi all, We are in the process of introducing API Export and Import feature for WSO2 API Manager. This feature can be used in scenarios such as moving APIs from staging to production environment. API Export This operation mainly sends an archive which consists of all the required resources for a API to be recreated in another API Manager instance. We have identified following folder structure to be included in the archive Screen Shot 2015-04-22 at 3.20.47 PM.png API Import Import feature accepts an API archive with the above mentioned structure and create a new API under current provider. Feature Implementation Generating archive (in API export) and extracting archive (in API import) can either be done in server or client side Currently we are planning to develop a RESTful API for export and import functionality where archive generation for requested APIs and all the related functionality are taken place in the server side. Decision for server side implementation was mainly made due to high number of network calls and high possibility of network failures that can happen in client side. The RESTful service is halfway done. currently it can export and import meta information only. Export API method calls org.wso2.carbon.apimgt.api.APIProvider.getAPI(APIIdentifier) and transforms received API object to a json file. Import API method receives json file via RESTful call and converts the json to an API object. This object is then sent to org.wso2.carbon.apimgt.api.APIProvider.addAPI(api) method and a new API will get created. Several concerns can arise with this implementation approach API object can have environment specific details which are not compatible with the importing environment There are some customisable attributes such as tiers (Ex : tiers in exporting environment may not be available in importing side) which may not be available on the importing environment Therefore we would like to know whether there is a better approach for implementing this. Suggestions and ideas for implementing this export import API feature is highly welcome. Thank you. -- Best Regards, Thilini Cooray Software Engineer Mobile : +94 (0) 774 570 112 E-mail : thili...@wso2.com WSO2 Inc. www.wso2.com lean.enterprise.middleware ___ 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 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Issue: A publisher in APIPublisher can see only limited details about a particular API.
It used to be that the rest of the information on an API was read-only. The Manage tab MUST be editable by publisher. Isabelle. - *Isabelle Mauny* VP, Product Management - WSO2, Inc. - http://wso2.com/ On Wed, Mar 11, 2015 at 10:56 AM, Supun Wijerathne sup...@wso2.com wrote: In APIPublisher in WSO2 API Manager, a publisher can only see the details provided by the overview tab of info page of an API. Is it better to let a publisher see the information of an API which can be seen with Edit link of info page. ( The same information a creator/admin see, as uneditable) ? And, is it better to let a publisher to edit the details in Manage page of an API ? Thanks.!! -- *Supun Wijerathne* Software Engineering Intern. WSO2, Inc. lean.enterprise.middleware Mobile: +94778591187 sup...@wso2.com LinkedIn http://lk.linkedin.com/in/supunwijerathne ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] BAM 3.0 Spark Script and Console UI in Dashboard
+1 as long as you have a clear user's role separation of the UIs you're creating - Don't mix managing/configuring the product with consulting dashboards in the same applications (i.e. URL). I feel that over the platform we have a key need for high-level configuration tasks that do not belong in the traditional admin console. Either that , or enhancing/segmenting the admin console to again clearly separate the tasks that are conducted by different roles. Isabelle. - *Isabelle Mauny* VP, Product Management - WSO2, Inc. - http://wso2.com/ On Mon, Mar 9, 2015 at 8:07 AM, Sinthuja Ragendran sinth...@wso2.com wrote: Hi, BAM dashboards are used so far to visualize the graphs, etc for presenting the data, but we are thinking of moving some of the operations from admin console to dashboard for a seamless user interaction. Basically in BAM 3.0, the users would like to execute some queries on the console, and then he/she can export as script and schedule it. And then within same application he/she can switch the tabs, and visualize the graphs. Since these are end user related operations and more frequently performed in the run time, IMHO it's more better to have it in the dashboard so that the user can stick into one context, rather switching back and forth to management console and dashboard. But we do have other UIs such as streams, input/output adapters etc will remain in the management console as those are actual devops related operations. Please share your thoughts in above approach. Thanks, Sinthuja. -- *Sinthuja Rajendran* Senior Software Engineer http://wso2.com/ 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 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Decoupling Authorization Server - Mapping existing oAuth applications with API manager.
I am not clear who the target user is or what the use case is. Can you share that please ? Isabelle. - *Isabelle Mauny* VP, Product Management - WSO2, Inc. - http://wso2.com/ On Fri, Mar 6, 2015 at 5:08 PM, Roshan Wijesena ros...@wso2.com wrote: Hi, When providing the capability to plug in an External Authorization Server for managing tokens and clients, a need may also arise to associate already existing Oauth clients with Applications created in API Manager. We are working on a solution to cater the above requirement. When users log in to the store and navigate to the subscription page, they can decide whether they want to an entirely new OAuth client or associate an existing OAuth client with the Application in APIM side. Users can associate an existing Oauth App by enabling a check box. If they check the option, they will be given a text box to enter the consumer key of the oAuth client. Once users click on generate button we will create a new mapping for that consumer key with the API Manager application. If someone wants to disable this feature completely they can turn it off by changing a config setting from api-manger.xml config file. Regards Roshan. -- Roshan Wijesena. Senior Software Engineer-WSO2 Inc. Mobile: *+94719154640 %2B94719154640* Email: ros...@wso2.com *WSO2, Inc. :** wso2.com http://wso2.com/* lean.enterprise.middleware. ___ 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
Re: [Architecture] [Dev] Improving Impact Analysis Feature on G-Reg
+1 - The relationship path is very important to highlight. Right-click on a node, say Show Relationships , or Show Dependencies - And then center the object and highlight the relationships.. Now, I am going to complicate this, but… This really calls for 3D :D - Let the user rotate graph .. Isabelle. - *Isabelle Mauny* VP, Product Management - WSO2, Inc. - http://wso2.com/ On Sun, Feb 22, 2015 at 6:00 PM, Frank Leymann fr...@wso2.com wrote: HI Jerad, thanks, the gif was helpful :-) Very nice tool! Coloring nodes is optional (I would even argue: not needed). But coloring relations will in fact improve comprehension of the user. See for example when you select in your gif a subset of relationship types: it is still unclear which relationship types connect the nodes. I would rank relationship coloring much higher than node coloring. Best regards, Frank 2015-02-21 6:31 GMT+01:00 Jerad Rutnam je...@wso2.com: Hi Frank, I get your point. Agree for giving users more flexible features. Yes, we were discussing about the coloring nodes, and this was decided to have like an optional feature. So it will be an enhance feature for filtering option. Which we decided to work on after releasing the tool. :) Please find the attached animated .gif image, that will give better idea about the tool functions. (Use chrome or better .gif previewer to open - since the file is large, it might not work on all the browsers correctly) Thanks, Jerad -- *Jerad Rutnam* *Software Engineer* WSO2 Inc. lean | enterprise | middleware M : +94 77 959 1609 | E : je...@wso2.com | W : www.wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Decoupling Authorization Serever - Changes Happening on API Store
Amila, Very good points. +1 for adding TTL to token generation calls.. This is what most other API Management solutions do. Isabelle. - *Isabelle Mauny* VP, Product Management - WSO2, Inc. - http://wso2.com/ On Mon, Feb 16, 2015 at 11:53 AM, Amila De Silva ami...@wso2.com wrote: Hi All, With API Manager 1.9.0, capability will be provided to plug in an External Authorization server. With this change, Authorization Server will be the only entity creating OAuth clients, and issuing access tokens. In order to seamlessly support some of the existing APIM features, certain changes should be done on the Store: 1. Generating Application Token using an Extended Grant Type As of now, Store UI allows to specify a validity period when Generating an Application Access Token. In the previous releases this was possible, since KeyManager component could directly access the tables where tokens are kept. So after generating a token through UI, Store could update the newly generated token giving a preferred validity period. After decoupling Authorization Server, Store would no longer be able to do this, through a direct DB call. Solution to overcome this problem would be to use an entirely new Grant Type to Generate the Application Access Token. The new Grant type would accept validity period as a new parameter and use it when generating the Application Access Token. 2. Using a Separate Table to store Application Access Tokens Currently, when rendering the UI, Store gets the Access Token by querying the Database directly. After decoupling AS, if we are to Display the Application Token, we would have to Keep the token in a separate Table. In this scenario, Store would act as another client App created on the AS and the Table for storing tokens will be used as a temporary storage. This means that only the most recent Access Token will be kept in, and the table won’t be used to obtain token meta data (such as validity period , Consumer Key) during an API invocation. 3. Generate the token only using /token, /authorize endpoints First time when creating an Application Access Token, Store calls APIKeyMgtSubscriberService.getApplicationAccessToken to obtain a token. This method, simply creates a token and write it down to IDN_OAUTH2_ACCESS_TOKEN, setting token’s type to Application. However when moving forward, we would have to obtain the the Application Access Token only using standard OAuth endpoints. 4. Determining the type of a token using a scope In API Manager, the type of the token (whether it is Application or Application User) is kept in IDN_OAUTH2_ACCESS_TOKEN along with the token. Token Type is used when validating API Invocations (When defining a resource, the type of token required to access it can be specified, and a resource can be only accessed with a token of the specified type). Since the type of the token is tightly coupled with our implementation of Tokens, to make it usable across different Authorization Servers, Token type will be mapped to a scope. So Application Tokens will have a scope like am:application_token (we can make the scope name configurable). When a token is generated through the Store UI, Store will request the token with this scope. These are the major changes required for the Store to function properly. Would appreciate your feedback on these. -- *Amila De Silva* WSO2 Inc. mobile :(+94) 775119302 ___ 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
Re: [Architecture] RFC:Building Performance Probes into WSO2 Platfrom
+1 to make it more granular. We need a similar design to group/manage events publishing ( for analytics ) as well. Isabelle. - *Isabelle Mauny* VP, Product Management; WSO2, Inc.; http://wso2.com/ On Wed, Jan 28, 2015 at 3:48 AM, Isuru Perera isu...@wso2.com wrote: Hi Chintana, It's possible to turn on/off metrics at runtime via JMX. I have added a JMX Bean to change the Metric levels. So, if the level is set to OFF, the metrics collection will be stopped. This level can be set initially via a system property at startup. As you mentioned, we cannot set system property externally at runtime and therefore I used JMX to avoid any server restarts when changing the levels. Right now, this metric level is applied to all metrics. However Azeez suggested that we should allow setting levels for each Metrics, so that we can enable/disable a set of metrics (similar to log4j). This part is not yet implemented. Thanks! Best regards, On Tue, Jan 27, 2015 at 9:04 PM, Chintana Wilamuna chint...@wso2.com wrote: Hi Isuru, Is it possible to turn on/off metrics using a runtime property? Correct me if I'm wrong, using a system property for metrics you have to restart the server for metrics to be turned on/off? -Chintana On Tue, Jan 27, 2015 at 1:42 AM, Isuru Perera isu...@wso2.com wrote: Hi Paul, Thanks for the suggestions. I just had a quick chat with Johann. Since there is some more time for next IS release, we can start integrating metrics with IS. I'll set up a meeting with IS team. As you mentioned, it would be great if we can integrate Metrics to ESB. As I know, ESB Team is in final stages for 4.9.0 release and I think we will have to integrate metrics after ESB 4.9.0 release. Kasun, WDYT? Thanks! Best Regards, On Fri, Jan 23, 2015 at 12:34 PM, Paul Fremantle p...@wso2.com wrote: I suggest one of the following: * The ESB already has very advanced metrics. So a good test would be to see if we can get all of those easily with the new component. That would quickly get the new component up to a high quality. * The Identity Server market is becoming much more performance sensitive, so metrics in IS would be really valuable. Paul On 23 January 2015 at 06:59, Isuru Perera isu...@wso2.com wrote: Hi all, This is just a quick update on Metrics integration. - We decided to use a separate repository for metrics [1]. The main reason is that we want to integrate Metrics to upcoming releases and it will take a longer time for products to use a new Carbon Kernel version. - Developed a new JDBC Reporter for Metrics [2] - Now I'm working on a new UI for Metrics visualization. I experimented with other tools and we decided to have a lightweight UI, which can be integrated to WSO2 Products. I'm planning to use the data from a database and that's the main reason to develop a new JDBC reporter. I'll share the details of the UI later. Since the core part for Metrics API is ready, we can start integrating to the products. Srinath, please let me know which product to start with. Then we can discuss with relevant product team. Thanks! Best Regards, [1] https://github.com/wso2/carbon-metrics [2] https://github.com/wso2/carbon-metrics/blob/master/components/org.wso2.carbon.metrics.jdbc.reporter/src/main/java/org/wso2/carbon/metrics/reporter/JDBCReporter.java On Tue, Dec 23, 2014 at 3:35 PM, Isuru Perera isu...@wso2.com wrote: Hi Sameera, I sent a PR to carbon4-kernel repository [1]. Could you please review and merge it? I created CARBON-15115 [2] for that. Thanks! [1] https://github.com/wso2/carbon4-kernel/pull/125 [2] https://wso2.org/jira/browse/CARBON-15115 On Wed, Dec 3, 2014 at 1:53 PM, Ramith Jayasinghe ram...@wso2.com wrote: Yep. This needs to be evaluated on loaded environments. On Wed, Dec 3, 2014 at 1:39 PM, Isuru Perera isu...@wso2.com wrote: Hi all, I have committed what I did so far to the WSO2 SVN scratch area [1]. There are two components. 1. org.wso2.carbon.metrics.manager - Contains the WSO2 Metrics API, which will be used in the WSO2 platform. 2. org.wso2.carbon.metrics.impl - The implementation of Metric Service, which will internally use the Metrics Java Library [2]. The main reason for having our own API is to introduce the support for different metrics levels. This will also make sure that we are not tightly coupled with Metrics Java library. The org.wso2.carbon.metrics.manager.MetricManager [3] class has the main API. This class is similar to the Metrics' MetricRegistry class [4] and I have taken the helper methods to generate names etc. Yesterday, I organized a code review and following are the notes: Participants: Azeez, Sameera, Ramith. Code review was based on revision 210170 [5] - Azeez mentioned that having a global configuration for Level
Re: [Architecture] Improve the way of publishing API into Gateways
Thanks Nuwan, Still would to see the design /publishing flow and where that option will come in - We already have an option to publish to gateways in the UI, this option should ideally be placed there. Let's review in the end-to-end publish flow meeting I have setup for tomorrow. Isabelle. - *Isabelle Mauny* VP, Product Management; WSO2, Inc.; http://wso2.com/ On Wed, Jan 28, 2015 at 4:27 AM, Nuwan Dias nuw...@wso2.com wrote: @Isabelle yes, the UI would tick the line if a given API is available in a particular environment. And would give the flexibility for a publisher to deploy/undeploy the API runtime from any given Gateway(s). @Chinthana, yes its the admin (guy who has access to the configuration) that defines the environments. What would be shown on this UI is the master Gateway node of each environment. Each environment could have dep-sync configured and sync the API(s) across its cluster. @Tharindu, I think we need to make this as a pop up which would appear when a user presses the 'Publish' button. The pop up would only appear if there are more than 1 environments configured. Else it would just publish as it does today. Thanks, NuwanD. On Tue, Jan 27, 2015 at 8:57 PM, Chintana Wilamuna chint...@wso2.com wrote: +1 Also how does one define an environment? As the super admin? Also when depsync is configured an environment can have multiple servers, how would you group a set of machines to an environment? -Chintana On Tue, Jan 27, 2015 at 3:55 AM, Isabelle Mauny isabe...@wso2.com wrote: What are the user stories for this ? When would a customer deploy to multiple gateways ? If they created separate production/sandbox runtime right ? be careful on not getting out of sync here.. If you let customers decide where to deploy, then you need to give them an overview of where an API was deployed last. They need to be able to know where something is deployed and decide to later deploy to somewhere else. This needs to be decided at API publishing time, not at API design time . Please review the API design/prototype/deploy flow and involve the UX team in this. Thanks. - *Isabelle Mauny* VP, Product Management; WSO2, Inc.; http://wso2.com/ On Tue, Jan 27, 2015 at 12:35 PM, Tharindu Dharmarathna tharin...@wso2.com wrote: Hi all, In API Manager if we need to publish an API from API publisher, we can publish it to multiple gateways. but publisher can't select a particular Gateway to publish. I have come up with following solution to solve this problem. *Improvement* 1. Give user to select which gateways to published in the mean time of publishing API using API publisher. *UI change in manage section in API Publisher* 1. Insert following UI block after the Resources Block. Thanks and Regards. -- *Tharindu Dharmarathna*Associate Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: *+94779109091 %2B94779109091* ___ 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 -- Chintana Wilamuna Solutions Architect WSO2, Inc.; http://wso2.com lean.enterprise.middleware phone: +1 408 429 3321 blog: http://engwar.com/ linkedin: http://www.linkedin.com/in/chintanawilamuna twitter: twitter.com/std_err ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Nuwan Dias Associate Tech Lead - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729 ___ 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
Re: [Architecture] Replacing BAM Toolbox Format with CAR
+1 to make this consistent with platform. Isabelle. - *Isabelle Mauny* VP, Product Management; WSO2, Inc.; http://wso2.com/ On Sat, Jan 17, 2015 at 12:28 PM, Anjana Fernando anj...@wso2.com wrote: Hi everyone, From BAM 3.0, we are thinking of replacing the toolbox packaging to CAR files. The main motive for this came with CEP also requiring a packaging format for their artifacts. So either, they also needed to use our toolbox format, or else, go to a CAR packaging format, which is used with other artifacts in the platform. So basically, as I feel, our artifacts like, stream definitions, analytics scripts, UI pages are also in the same category as ESBs sequences, proxies, endpoints etc.. so if they also don't use a new packaging format, but rather use CAR, we also don't have a special reason to have a separate one. So for these reasons, and also not to have too many packaging formats in the platform, we also though of going with the standard model with CAR. CEP have already suggested this for their artifacts in the thread [1]. If there are any concerns, please shout. [1] [Architecture] cApp deployer support for WSO2 CEP Cheers, Anjana. -- *Anjana Fernando* Senior Technical Lead WSO2 Inc. | http://wso2.com lean . enterprise . middleware ___ 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
Re: [Architecture] [Dev] WSO2 IS Audit Dashboard
Shani, One obvious design point is that it needs to work across a cluster of IS servers. So the gadgets need to be deployable to a detached UES server , or the gadgets need to be part of the manager node of the cluster. Totally +1 with Dulitha on the usage of CEP alerts. Somebody needs to be able to set some thresholds (say 50 failed login attempts/sec) and raise an alert when that threshold is reached + stop accepting requests from this IP. Isabelle. - *Isabelle Mauny* VP, Product Management; WSO2, Inc.; http://wso2.com/ On Tue, Dec 30, 2014 at 6:52 AM, Chamin Nalinda cha...@wso2.com wrote: Hi Shani, It is the same. No such deliverable date. I'm assigned to continue this after previous intern left. On Mon, Dec 29, 2014 at 3:03 PM, Shani Ranasinghe sh...@wso2.com wrote: Hi Chamin, Is this the same as the discussion that is carried out on the mail thread [Architecture] IS statistics dashboard ? If not what's the difference? And also, since you have mentioned this is for IS 5.0, IS 5.0 is already released. So how will this be available for any interested parties? Do we have any target date for the deliverable? On Mon, Dec 22, 2014 at 12:22 AM, Chamin Nalinda cha...@wso2.com wrote: Hi Dulitha, In the case of publishing data to BAM do you recommend using creating custom data publisher to BAM as in [1] since Message Tracer is not for internal massage monitoring. [1] http://wso2.com/library/articles/2012/07/creating-custom-agents-publish-events-bamcep/ On Mon, Dec 22, 2014 at 9:54 AM, Chamin Nalinda cha...@wso2.com wrote: Hi Dulitha, Thanks for your suggestions and opinions. Regards !!! On Mon, Dec 22, 2014 at 4:18 AM, Dulitha Wijewantha duli...@wso2.com wrote: Hi Chamin, A potential problem we saw was in use cases where admin services were consumed with APIM fronted. The correlation id has to pass through APIM - IS as well. @Nuwan did a small fix on this to get it to work. The other important matter is to actually visualize useful reports. The example you gave is actually something that should be fed to CEP cause most of the time - realtime action has to be taken on authentication failed attempts. Below are some good use cases - - All the actions performed by a user for time period - All the actions performed by a user breaking down on sessions - Authentication requests log segmented to time slices (how many failed requests were sent in a minute) - Client IP/hostnames that were used to perform authentication Cheers~ On Thu, Dec 18, 2014 at 10:54 PM, Chamin Nalinda cha...@wso2.com wrote: Hi all, I'm in the process of developing a dash board for WSO2 IS 5.0.0 . In the first iteration, need to capture relevant information regard to Authentication use cases. Below are some use cases. Success/Fail login attempts during last hour ? Success/Fail login attempts during last hour by user Peter ? etc... The approach that is suggest, to co-relate requests and responses then feed data to BAM. Then periodically retrieve data from BAM and display in IS Audit Dashboard. BAM Message Tracer is one suggestion. And rather than using Axis2 Handler to match requests and response using a separate class is another suggestion. I would like to have some ideas prior to begin ( the best approach, using existing classes already there etc...) Thanks in advance. -- *Chamin Nalinda* Intern - Engineering WSO2 Inc. http://www.wso2.com lean.enterprise.middleware Mobile: (+94) 77 241 66 04 Linkedin: https://www.linkedin.com/in/chaminnalinda Web: http://www.ckreativity.com Blog: http://techspiro.blogspot.com/ ___ Dev mailing list d...@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev -- Dulitha Wijewantha (Chan) Software Engineer - Mobile Development WSO2 Inc Lean.Enterprise.Mobileware * ~Email duli...@wso2.com duli...@wso2mobile.com* * ~Mobile +94712112165 %2B94712112165* * ~Website dulitha.me http://dulitha.me* * ~Twitter @dulitharw https://twitter.com/dulitharw* *~Github @dulichan https://github.com/dulichan* *~SO @chan http://stackoverflow.com/users/813471/chan* -- *Chamin Nalinda* Intern - Engineering WSO2 Inc. http://www.wso2.com lean.enterprise.middleware Mobile: (+94) 77 241 66 04 Linkedin: https://www.linkedin.com/in/chaminnalinda Web: http://www.ckreativity.com Blog: http://techspiro.blogspot.com/ -- *Chamin Nalinda* Intern - Engineering WSO2 Inc. http://www.wso2.com lean.enterprise.middleware Mobile: (+94) 77 241 66 04 Linkedin: https://www.linkedin.com/in/chaminnalinda Web: http://www.ckreativity.com Blog: http://techspiro.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Folder structure of Analytics Toolbox (BAM CEP)
Hi Mohan, A detail but I would avoid using product names such as Jasper or Hive - This may evolve over time (even if not short term) and we would need to change the toolbox install process if underlying technology was changed. Isabelle. - *Isabelle Mauny* VP, Product Management; WSO2, Inc.; http://wso2.com/ On Thu, Oct 30, 2014 at 9:09 AM, Mohanadarshan Vivekanandalingam mo...@wso2.com wrote: On Thu, Oct 30, 2014 at 8:30 PM, Sriskandarajah Suhothayan s...@wso2.com wrote: Hi The current folder structure[1] does not extend clearly for CEP integration and hence we have to decide on the new folder structure of the Analytics Toolbox. shall we have inputs - adaptors - builders outputs - adaptors - formatters streams uis - gadgets - jaggery-apps reports - jesper analytics - executionplans - hive-scrips Thoughts? +1.. Above structure covers all the artifacts which are available at the moment. I think analyzers.properties file is missed in above, what is the best place for that (anaytics or new folder called scheduler) ?? Thanks, Mohan Regards Suho [1]https://docs.wso2.com/display/BAM200/Creating+a+Custom+Toolbox -- *S. Suhothayan* Technical Lead Team Lead of WSO2 Complex Event Processor *WSO2 Inc. *http://wso2.com * http://wso2.com/* lean . enterprise . middleware *cell: (+94) 779 756 757 %28%2B94%29%20779%20756%20757 | blog: http://suhothayan.blogspot.com/ http://suhothayan.blogspot.com/twitter: http://twitter.com/suhothayan http://twitter.com/suhothayan | linked-in: http://lk.linkedin.com/in/suhothayan http://lk.linkedin.com/in/suhothayan* -- *V. Mohanadarshan* *Software Engineer,* *Data Technologies Team,* *WSO2, Inc. http://wso2.com http://wso2.com * *lean.enterprise.middleware.* email: mo...@wso2.com phone:(+94) 771117673 ___ 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
Re: [Architecture] Proposed ESB connector scenario - Integrating ZOHO CRM with Campaign Monitor, CallRail, Twitter, Facebook, Quickbooks and JIRA
+1 Great base for a demo as well.. Isabelle. __ Isabelle Mauny On Jul 22, 2014, at 4:30 AM, Shevan Goonetilleke she...@wso2.com wrote: Having all these connectors integrated together would form a good test for the connectors that were previously developed and tested as standalone connectors. Once developed and tested we should probably publish them as 4 separate scenarios like - 1. ZOHO CRM for campaign and lead management 2. ZOHO CRM for order management etc These can also eventually form separate recipes on the iPaaS. Any other thoughts? On Fri, Jul 18, 2014 at 3:38 PM, Rasika Hettige rasi...@gmail.com wrote: 1. Overview ZohoCRM is on-demand Customer Relationship Management (CRM) software as a Service (SaaS) solution that delivers complete CRM functionality at a fraction of the price of other offerings. With ZohoCRM you can manage all your Sales, Marketing, Customer Support Service, Inventory Management and Email within a single business system. Hence it is not only an application or tool but it is a way of doing business. 2.Benefits of ZohoCRM ZohoCRM has its own calendar through which meetings could be scheduled and events could be managed. This facilitates easy follow up with clients and leads. It is also a collaboration tool which has its own messaging and chatting components through which the business opportunity is enhanced. ZohoCRM could also be easily integrated with external APIs such as Quickbooks for financial and inventory management, Campaign monitor for lead management and etc. Great value for money; It provides greater software applications for businesses at reasonable and affordable prices. Therefore it increases revenue at a lower cost. 3.Zoho CRM Business Scenario In describing the business scenario of ZohoCRM, it can be divided into sections such as Initiate Marketing, Process Sales, Manage Orders and Support as shown below: 3.1 Initiate Marketing Step 1: Either campaigns and/or Leads can be created as the starting point of ZohoCRM. 1a. Create Campaigns Create campaigns in Zoho CRM and create them as draft campaigns in Campaign Monitor API. Email these campaigns to subscribers in Campaign Monitor API. Post details of events related to the campaigns in the campaign owner’s Facebook wall. Advantages of integrating with Campaign Monitor API Campaign Monitor is an email marketing service, which can be used to publish campaigns to bring more business to the company. Advantages of integrating with Facebook API Facebook can be used as a marketing tool where you can post your campaign details on your wall and get interested individuals as leads in ZohoCRM. 1b. Create Lead Create leads directly in Zoho CRM. Lead creation can be done by retrieving the clicker’s details (who clicks on the link) from the Campaign Monitor API. Creating leads by retrieving information from the Twitter API (by searching tweet contents or hash tags). Leads can also be created by retrieving the caller’s contact details from the CallRail API. Associate leads with products which are either goods or services that can be sold or purchased by the organization. Advantages of integrating with Twitter API Twitter is an online social networking and microblogging service that could be used to increase marketing and identifying leads in ZohoCRM by searching tweet contents/ hash tags. Advantages of integrating with Campaign Monitor API Campaign Monitor can be used to aquire new subscribers(leads) in ZohoCRM. Advantages of integrating with CallRail API CallRail API is call tracking tool which can be used to capture caller details as leads in ZohoCRM to initiate marketing. Step 2: Convert Lead Convert the qualified leads to an Account (organizations) and Contact (individuals), optionally a Potential (opportunity). The contacts in ZohoCRM can be created as customers in Quickbooks for accounting purposes. If the lead is unqualified then the status is updated as Junk Lead. 3.2 Process Sales Step 3: Initiate sales process by creating Quotes. Create quotes as estimates in Quickbooks for accounting purposes. Step 4: Once the order is won, it can be converted to a sales order and it could be created in Quickbooks for accounting purposes. If the order is lost, update the Potential/Quote as Closed-Lost in ZohoCRM as well as update the estimates in Quickbooks. Step 5: Create invoices for the sales orders in ZohoCRM. Create invoices in Quickbooks for accounting purposes. Advantages of integrating with Quickbooks API As an accounting API, QuickBooks helps to record book-keeping functionalities by mapping relevant financial details such as customers, invoices, sales orders in ZohoCRM. 3.3 Manage Orders Step 6: Create Vendors by retrieving vendors from Quickbooks. Create Products by retrieving
Re: [Architecture] DataMapper as a seperate feature in DeveloperStudio
+1 to put it all together - DataMapping is an integral part of creating mediation flows . We did not decouple Smooks, why would we decouple this one ? Isabelle. - *Isabelle Mauny* VP, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com - mobile (Spain) : +34 616050684 - mobile (Sri Lanka) +94 (0)774777663 Landline: +1 (650) 745 4499 (USA) or +94 (11) 214 534 (SL) Extension : 7302 On Tue, Apr 29, 2014 at 6:56 AM, Lali Devamanthri l...@wso2.com wrote: Hi, IMO, 'adding datamapper mediator to a proxy' is equal to 'adding a sequence mediator to a proxy'. If we haven't separate the sequence graphical editor from ESB graphical editor, Why we needs to decouple datamapper editor ? Thanks, /Lali On Tue, Apr 29, 2014 at 9:55 AM, Viraj Rajaguru vi...@wso2.com wrote: Hi, I think Datamapper should be a separate feature and decouple from ESB graphical editor. Thanks, Viraj. On Mon, Apr 28, 2014 at 8:46 PM, Susinda Perera susi...@wso2.com wrote: Hi All I came across few dependancy resolving issues while i was trying to build an installed-distribution pack, As i feels these issues could be eliminated if we could think on $subject and seperate the coupling. WDYT @ Viraj/Jasintha : Is this required or(the other alternative is) can we simply include this within esb_graphical_editor feature and resolve the dependacy issues in the same manner. Thanks /Susinda -- *Susinda Perera* Software Engineer Mobile:(+94)716049075 WSO2 Inc. http://wso2.com/ Tel : 94 11 214 5345 Fax :94 11 2145300 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- 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 -- *Lali Sudaththa Devamanthri* Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 71 895 4922 http://www.wso2.com ___ 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
Re: [Architecture] Developer Forum for the API Store
Nuwan, Couple points: a) Will a publisher will be able to create one forum per API (at the time of publishing) .. This should be optional BTW. b) If a developer has not subscribed to an API, will they have access to the forum ? Can you please share a mockup of the forums viewer ? how is it be embedded in the API store/API publisher page ? Thanks. __ Isabelle Mauny Vice-President, Product Management; WSO2, Inc.; http://wso2.com/ On Apr 22, 2014, at 11:34 AM, Nuwan Dias nuw...@wso2.com wrote: Hi, This is to discuss on the architecture of a Developer Forum on the API Store. The basic requirement is for an application developer to be able to initiate discussions on various topics and other developers to be able to reply and carry on with the discussions. The replies will be on a flat (single level) structure. The topic creator can also categorize (tag) a topic choosing from a pre-defined set of categories. There will be two ways one can initiate a forum discussion 1. Create a generic forum topic by visiting the forums page and clicking on a button. 2. Browse to an API detail page and click on a button to start a new forum topic. In this case the forum topic will be linked to the API and hence one can filter out discussions for a given API. This requirement brings out the need for the same visibility rules to be applied on the API as well as to its corresponding forum discussions. The implementation will consist of a back-end and front-end (UI) components. The back-end will contain the core business logic of the forum's functionality and will be implemented on top of a defined interface. The plan is to have the back-end as a separate carbon component. The front-end will be a jaggery UI. The first implementation of the back-end will be a registry based implementation. Reasoning for opting for a registry based implementation is as below 1. The API permissions model (for visibility) can be reused since APIs are also registry artifacts. 2. Pagination support 3. Registry indexing support 4. Clear separation of concerns for Multi Tenancy. One drawback of the registry is that a given tenant user not being able to write to another tenant registry. We plan to solve this by allowing that particular user to comment as 'anonymous' and capture his username via in input (textbox). There will be 3 types of registry resources (rxts) involved in the implementation. 1. topic.rxt - Represents the forum topic. Will have attributes as Subject, Body, etc. 2. reply.rxt - Represents a reply for a given topic. Has an association to topic.rxt 3. category.rxt - Represents a forum topic category (similar to a tag) The resource hierarchy for the topic.rxt and reply.rxt would be as shown below Forum Registry Architecture (1).png The rxts are stored under a sub-collection of root collection 'topics'. The sub-collection is a variable which could either be 'common' (for general topics) and in the form of 'provider_apiname_version' for topics linked to a particular API(s). The resource permissions are applied to the sub-collection so that visibility of those topics are handled accordingly. Thoughts welcome Thanks, NuwanD. -- Nuwan Dias Associate Tech Lead - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729 ___ 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
Re: [Architecture] Visual tool to manually build data-mapper input and output tree structures
All, I think Not Null with a checkbox works out. Pretty standard in SQL tools. Isabelle. - *Isabelle Mauny* Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com - mobile (Spain) : +34 616050684 - mobile (Sri Lanka) +94 (0)774777663 Landline: +1 (650) 745 4499 (USA) or +94 (11) 214 534 (SL) Extension : 7302 On Thu, Apr 10, 2014 at 2:15 PM, Gayan Yalpathwala gay...@wso2.com wrote: Hi Susinda, On Thu, Apr 10, 2014 at 4:53 PM, Susinda Perera susi...@wso2.com wrote: Hi Gayan Don't we represent this nullable and nillable check-boxes with some user understandable captions. These are xml/avro schema jargon and IMO these need to be replaced with something more meaningful for user. We can change nillable to Allow empty values and nullable to Value can be null. WDYT? Thanks On Thu, Apr 10, 2014 at 3:26 PM, Gayan Yalpathwala gay...@wso2.comwrote: Hi Jasintha, On Thu, Apr 10, 2014 at 2:14 PM, Jasintha Dasanayake jasin...@wso2.comwrote: On Wed, Apr 9, 2014 at 12:40 PM, Gayan Yalpathwala gay...@wso2.comwrote: Hi, Visual data mapper currently operates by taking two avro schemas for input and output. Considering the fact that end users are not supposed to write avro schema by themselves, we have decided to provide a UI to manually build the schema of input and output. This will basically extend the current input and output boxes implementation in data-mapper editor. Users can build the schema from scratch and add a new element by choosing the option provided in right click menu. [image: Inline image 2] This will pop up the following dialog asking user input for element name and respective attributes. [image: Inline image 4] Here, Element type combo box will list all primitive types supported by avro. Eg:- STRING, INT, DOUBLE etc. The element added will appear as the root node of a tree structure and user can add more elements by choosing either Add new child or Add new sibling options from right click menu. These two options will be available for every element added further. [image: Inline image 3] I think it's better to have a option in this menu, to import existing types(Avro types), and provide a edit option to change the data type of the existing element. Also I personally preferred to have another sub context menu which provide following 3 items 1) create record element 2) create record list element 3) create a field element +1 for this approach. What if the first menu item be Add new and three options (record element, records list element, field) in its sub context menu? This way, we can get rid of Add new sibling menu item and introduce a second menu item to import existing types instead. I think this option might be simple and easy for users rather having a complex dialog and ask to define those information , WDYT ? /Jasintha A user can use this method to build a complete schema without having any idea about the underlying avro schema specification. Please raise and forward if you have any thoughts and concerns on design aspects and the flow that I have mentioned. Thanks, -- *Gayan Kaushalya Yalpathwala* Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 71 8682704 http://asia14.wso2con.com/ http://asia14.wso2con.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Jasintha Dasanayake * *Software EngineerWSO2 Inc. | http://wso2.com http://wso2.com/ lean . enterprise . middleware* *mobile :- 0711368118* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture Thanks, -- *Gayan Kaushalya Yalpathwala* Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 71 8682704 http://asia14.wso2con.com/ http://asia14.wso2con.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Susinda Perera* Software Engineer Mobile:(+94)716049075 WSO2 Inc. http://wso2.com/ Tel : 94 11 214 5345 Fax :94 11 2145300 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture Thanks, -- *Gayan Kaushalya Yalpathwala* Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 71 8682704 http://asia14.wso2con.com/ http://asia14.wso2con.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo
Re: [Architecture] Propose tool's GUI test scenario editor
Hi Rushkan, Thanks for your proposal. Is this for WSO2 Automation Framework ? Would this be a DevStudio (Eclipse) plugin ? Isabelle. - *Isabelle Mauny* Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com - mobile (Spain) : +34 616050684 - mobile (Sri Lanka) +94 (0)774777663 Landline: +1 (650) 745 4499 (USA) or +94 (11) 214 534 (SL) Extension : 7302 On Fri, Mar 21, 2014 at 7:20 PM, Rukshan Chathuranga rcruksha...@gmail.comwrote: - User will be able to write test cases using natural language - Editor will suggest the keywords and parameter - It validate the user input - Text editor basic functions + test run function will provided to the user - Will be able to write no of Test cases -- Department Of Computer Science Engineering, Faculty Of Engineering, University Of Moratuwa. Sri lanka. WEB: http://rukspot.com/ ___ 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
Re: [Architecture] Improve G-Reg default lifecycle to Enterprise level
How is that related to C5 ?? C5 is a research project at this point.. Coming up with a more representative LC as default can be done now, based on our extensive experience with customers... Isabelle. -- Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com isabe...@wso2.com - mobile: +34 616050684 On Mon, Mar 3, 2014 at 5:07 AM, Janaka Ranabahu jan...@wso2.com wrote: Hi G-Reg team, The default G-Reg lifecycle needs to be improved to Enterprise level. The current one we have only has 3 lifecycle states which does not have cover the full SDLC. Also we do not have a good set of check items in each state. Could we take some of the real world samples which are been widely used and model our default lifecyle based on those. That would improve the user experience a lot. Also do you guys have any plans to improve this with C5? WDYT? Thanks, Janaka -- *Janaka Ranabahu* Senior Software Engineer; WSO2 Inc.; http://wso2.com * E-mail: jan...@wso2.com http://wso2.com**M: **+94 718370861 %2B94%20718370861* Lean . Enterprise . Middleware ___ 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
Re: [Architecture] Improved UI for capturing service information
All, IMO, this has way too much vertical scrolling - the list of fields is overwhelming in the advanced list. We need to use horizontal space, with tabs for example, grouping the fields by themes. Mandatory stuff is on first tab, additional data is on other tabs. Isabelle. -- Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com isabe...@wso2.com - mobile: +34 616050684 On Tue, Feb 18, 2014 at 4:51 PM, Chandana Napagoda chand...@wso2.comwrote: Hi Senaka, I agree with your suggestion. As Pulasthi has proposed, we can redesign the screen with, required fields grouped into one section, and other contents collapsed in Show Advance Settings area. This is much similar to what we have used in project asset UI. Here with I have attaching an example design for add and edit view. Regards, Chandana On Tue, Feb 18, 2014 at 2:53 AM, Pulasthi Supun pulas...@wso2.com wrote: Hi All, How about adding a link like for example Show Advance Settings to list all the information and only show the most required fields in the default view. Regards, Pulasthi On Mon, Feb 17, 2014 at 12:20 PM, Senaka Fernando sen...@wso2.comwrote: Hi Chandana, This looks good. Firstly, when we create the service asset in the store, we need to think whether it is necessary for everything that you store in the G-Reg's service asset to be listed here. I know it is useful to have an asset in the repository that can capture everything, but in terms of the UI, we should think twice as to what's needed. For example, when I'm adding a new service as a provider, or when I'm updating information about it, what do I like to be seeing/updating? If you think along these lines this UI is far too complicated to use. Can we identify what fields make sense to be on this? Thanks, Senaka. On Mon, Feb 17, 2014 at 8:50 AM, Chandana Napagoda chand...@wso2.comwrote: Hi All, We are creating a WSO2 Enterprise Store based UI to capture Service Information and this new UI is also based on the Configurable Governance Artifacts(RXT). Here with I have attached the initial design of ES based Add Service UI. In this design, overview section (first section of RXT) is visible and other sections are collapsed. Either user can enter other information or proceed with save action. In Edit view, all the sections are expanded. Please refer the attached screenshots. Changes which will be made to saved RXT will be reflected to new UI as well. Suggestions are welcome. Regards, Chandna -- *Chandana Napagoda* Senior Software Engineer WSO2 Inc. - http://wso2.org *Email : chand...@wso2.com chand...@wso2.com**Mobile : +94718169299 %2B94718169299* *Blog :http://cnapagoda.blogspot.com http://cnapagoda.blogspot.com* -- *[image: http://wso2.com] http://wso2.com Senaka Fernando* Senior Technical Lead; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1 408 754 7388 %2B1%20408%20754%207388; ext: 51736*; *M: +94 77 322 1818 %2B94%2077%20322%201818 Linked-In: http://linkedin.com/in/senakafernando http://linkedin.com/in/senakafernando*Lean . Enterprise . Middleware -- -- 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 -- *Chandana Napagoda* Senior Software Engineer WSO2 Inc. - http://wso2.org *Email : chand...@wso2.com chand...@wso2.com **Mobile : +94718169299 %2B94718169299* *Blog :http://cnapagoda.blogspot.com http://cnapagoda.blogspot.com* ___ 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
Re: [Architecture] Some ESB Feedback
Basic requirements for this (see #1948 and #955). a) It needs to be external to the actual service executing (i.e. I must not have to change the sequence to get debugging working). b) I need to be able to see headers, properties values and body before and after each mediator execution c) I need to be able to provide input data to a service right from Studio d) I need to be able to test a sequence on its own ( without putting it inside a proxy service) - Proxy service is generated behind the scenes when I test the sequence. To start with, we can execute a service and write the information somewhere , which can then be displayed in DevStudio in a specific plugin. Next step (phase 2) , put some breakpoints on mediators to stop the execution. Isabelle. -- Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com isabe...@wso2.com - mobile: +34 616050684 On Wed, Dec 11, 2013 at 12:36 PM, Shafreen Anfar shafr...@wso2.com wrote: Hi Isabell, will do. Hi Srinath, Sure, let's have a F2F chat whenever that works for you. However, today I am out of the office :). On Wed, Dec 11, 2013 at 3:43 PM, Srinath Perera srin...@wso2.com wrote: Hi Shafreen, For debugging we can write a mediator that can block/ unblock the current execution and let users control that through remote calls (one way to do this). Shall we chat F2F sometime. --Srinath On Wed, Dec 11, 2013 at 3:15 PM, Shafreen Anfar shafr...@wso2.comwrote: Hi, I think having some sort of debugging mechanism would be really helpful. Some other external developers also raised the same issue during the training session on connectors. In fact, they even asked for the same thing - print all properties at a given point . Hi Srinath, We have created two Redmin issues on debugging [1] https://redmine.wso2.com/issues/2148 [2] https://redmine.wso2.com/issues/2147 The idea we have in mind for now is to write a mediator that would print the current status of the Message Context such as headers, properties and current payload in readable manner. However, IMO, the ideal debugger should be written in collaboration with DevS where you get to add breakpoints and everything. On Tue, Nov 26, 2013 at 12:00 PM, Srinath Perera srin...@wso2.comwrote: Have you guys seen this thread? lets chat and Add redmine items if make sense. --Srinath On Wed, Sep 25, 2013 at 8:40 AM, Srinath Perera srin...@wso2.comwrote: Kasun, miyuru can we chat sometime and send mail/ add redmine items. --Srinath On Sat, Sep 21, 2013 at 7:49 AM, Sanjiva Weerawarana sanj...@wso2.com wrote: Great feedback! For adding stuff to admin console .. generally I'm -1 on adding developer stuff to the admin console. We've in fact been moving more and more towards making it more of just an admin console and not a developer tool. Added Jackie too for doc updates. Jackie please review mail from Srinath below if you haven't seen it already. Sanjiva. On Tue, Sep 17, 2013 at 9:40 PM, Srinath Perera srin...@wso2.comwrote: I did worked with ESB lot in a previous week and have some feedback 1. Now Docs are pretty good, we managed without having to ask ESB team much even though none of us work work with ESB day to day 2. Descriptions need few samples - currently often each mediator has one example. But if it can be used in different ways, it helps to have few examples. Ant manual does this very well. 3. It is bit tricky to find out where some stuff are. I think overall section structure can improve I think. Payload mediator is a life saver, and it make the expereince very neat. But still there are many samples that uses enrich which can be done with payload. Need to update the samples to use new things like payload medatior and receive method in send for service chaining Still one of the main challenge is debugging. I think we can improve experience by adding more logging. - improve log .. so we can add log messages without taking too much real state of the program (I sent a mail to arch@) - Add a mediator like env command that let us print all properties at a given point - Another idea is to add an mediator to hold execution and may be let interactive control and inspection for debugging via a admin service call (mapped as scripts) We need a list of all supported xpath functions in one place(is it already there?) Our aggregate is implicitly bound to a closest clone/ iterate. If you think is language terms, it actually solve three problems. 1) create new threads 2) iterate messages 3) wait for and process things (join threads) As all three cases are linked, sometime it is tricky to use aggregate and iterate. Think we can improve things. I will send another mail. Few other things 1. I think we need a say to do things atomically in ESB. Something like synchronised block or check and set operation . 2. I
Re: [Architecture] ESB Custom Mediator Support in DevS Graphical Editor
Are we sure about this ? I am really -1 on removing custom mediators in general. For me custom mediators are about providing a reusable way of executing the same stuff again and again (and gives you more power, reusability than scripting) - Granted, they have been used to do connectors work, but is that the only thing they are used for ? Plus say I did create some custom mediators already - they are proven and I need to reuse them. So what happens in I *want* to use a custom mediator in DevS 3.3 and ESB 4.8 - What's my workaround ? Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Nov 7, 2013, at 9:17 PM, Selvaratnam Uthaiyashankar shan...@wso2.com wrote: Yes, I think, we discussed about deprecating custom mediators and use only connectors? Kasun, is that the plan? Regards, Shankar On Thursday, November 7, 2013, Kasun Indrasiri wrote: With the connectors.. we hardly need custom mediators. Isn't it? I guess no user will try to write mediator factories/serializers and write custom mediator, when he can do the same thing with templates with zero Java code. :) On Wed, Nov 6, 2013 at 10:17 PM, Sanjiva Weerawarana sanj...@wso2.com wrote: +1. On Wed, Nov 6, 2013 at 11:39 PM, Harshana Martin harsh...@wso2.com wrote: Hi All, Currently if you include an ESB configuration with elements introduced using an ESB Custom mediator, ESB Graphical Editor will wipe them out since it cannot identify the custom elements from it's core model. With ESB Cloud connector framework in DevS, we have introduced the capability for the editor to validate configuration elements loaded from extensions to the editor other than it's core element model. With this same concept we can further extend the Graphical editor easily to support ESB Custom mediators as well by populating the Custom mediators in to the tool pallet by reading the custom mediator configurations inside the Jar file. This will allow users to use the Custom mediators as well. Since 99% of the use cases won't need a new Custom mediator, we will not add this feature to DevS 3.3.0 (since it is already feature complete) and schedule this for DevS 3.4.0. WDYT? Thanks and Regards, Harshana -- Harshana Martin Associate Technical Lead WSO2 Inc. : http://wso2.com Mobile: +94 775 998 115 Profile: https://www.google.com/profiles/harshana05 Blog: http://harshana05.blogspot.com Twitter: http://twitter.com/harshana05 ___ 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/ -- S.Uthaiyashankar VP Engineering WSO2 Inc. http://wso2.com/ - lean . enterprise . middleware Phone: +94 714897591 ___ 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
Re: [Architecture] ESB Custom Mediator Support in DevS Graphical Editor
+1 to everything you said Kasun :) But we deprecate and we remove please, plus we provide migration steps/strategy for customers who are already using custom mediators. Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Nov 18, 2013, at 12:55 PM, Kasun Indrasiri ka...@wso2.com wrote: Hi Isabelle, Some clarifications so that we are in the same page :). - Class Mediator - A java mediator with custom message mediation logic. - Custom Mediator - A mediator with its own configuration language (with Mediator Factories and Serializers) with custom message mediation logic. So, we are only going to remove custom mediator support but not class mediator support. If a user ran in to a scenario, where he needs his own configuration language, then connectors is the preferred and the easiest way. On Mon, Nov 18, 2013 at 4:55 PM, Isabelle Mauny isabe...@wso2.com wrote: Are we sure about this ? I am really -1 on removing custom mediators in general. For me custom mediators are about providing a reusable way of executing the same stuff again and again (and gives you more power, reusability than scripting) - Granted, they have been used to do connectors work, but is that the only thing they are used for ? Plus say I did create some custom mediators already - they are proven and I need to reuse them. So what happens in I *want* to use a custom mediator in DevS 3.3 and ESB 4.8 - What's my workaround ? If an user already have a custom mediator, then they have to turn that in to a 'class' mediator, wrap around with templates and form a connector and use it. Custom mediators are rarely used compared to class mediators, So, I'm +1 for removing that from DevS. Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Nov 7, 2013, at 9:17 PM, Selvaratnam Uthaiyashankar shan...@wso2.com wrote: Yes, I think, we discussed about deprecating custom mediators and use only connectors? Kasun, is that the plan? Regards, Shankar On Thursday, November 7, 2013, Kasun Indrasiri wrote: With the connectors.. we hardly need custom mediators. Isn't it? I guess no user will try to write mediator factories/serializers and write custom mediator, when he can do the same thing with templates with zero Java code. :) On Wed, Nov 6, 2013 at 10:17 PM, Sanjiva Weerawarana sanj...@wso2.com wrote: +1. On Wed, Nov 6, 2013 at 11:39 PM, Harshana Martin harsh...@wso2.com wrote: Hi All, Currently if you include an ESB configuration with elements introduced using an ESB Custom mediator, ESB Graphical Editor will wipe them out since it cannot identify the custom elements from it's core model. With ESB Cloud connector framework in DevS, we have introduced the capability for the editor to validate configuration elements loaded from extensions to the editor other than it's core element model. With this same concept we can further extend the Graphical editor easily to support ESB Custom mediators as well by populating the Custom mediators in to the tool pallet by reading the custom mediator configurations inside the Jar file. This will allow users to use the Custom mediators as well. Since 99% of the use cases won't need a new Custom mediator, we will not add this feature to DevS 3.3.0 (since it is already feature complete) and schedule this for DevS 3.4.0. WDYT? Thanks and Regards, Harshana -- Harshana Martin Associate Technical Lead WSO2 Inc. : http://wso2.com Mobile: +94 775 998 115 Profile: https://www.google.com/profiles/harshana05 Blog: http://harshana05.blogspot.com Twitter: http://twitter.com/harshana05 ___ 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/ -- S.Uthaiyashankar VP Engineering WSO2 Inc. http://wso2.com/ - lean . enterprise . middleware Phone: +94 714897591 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture ___ Architecture mailing list Architecture@wso2.org
Re: [Architecture] [Meeting Notes] UES integration with BAM / CEP / APIM
Sure - These are static dashboards. But a user must be able to create their own dashboards , on top on the ones we are delivering by default. In this case, they would create their own toolbox , leveraging the gadgetgen tool you discussed right? Thanks. -- Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com isabe...@wso2.com - mobile: +34 616050684 On Tue, Nov 12, 2013 at 11:10 AM, Tanya Madurapperuma ta...@wso2.comwrote: On Tue, Nov 12, 2013 at 3:24 PM, Isabelle Mauny isabe...@wso2.com wrote: For APIM, we need consumer dashboards as well. Isabelle, Consumer dashboards are static dashboards that we can ship with APIM. Right ? IS there a need for consumers to go ahead and create dashboards themselves containing their preferred gadgets and layouts ? Dashboards that we discussed here are of that nature which will be created by the user himself. Isabelle. __ *Isabelle Mauny *Director, Product Management; WSO2, Inc.; http://wso2.com/ On Nov 12, 2013, at 10:52 AM, Tanya Madurapperuma ta...@wso2.com wrote: Hi all, Following is the meeting notes of the $Subject. Participants : Anjana, Gokul, Mohan, Lasantha, SameeraP, Shiro, Lalaji, Joe, Chan, Gillian (over the phone), UES team BAM = 1. Some tool simialar to Gadget gen tool will developed in UES side and there will be a url from carbon console for the gadget gen tool 2. User can give the database query in the tool and get the data and then pass it to the UES gadgets CEP = 1. Events are published to BAM --- create datasources--- create gadget--- publish to store --- create dashboard 2. Reuse the suggested gadget gen tool APIM = 1. Required predefined dashboard for subscribers with same set of gadgets therefore APIM does not have a requirment of creating customizable dashboards. Future items == 1. Personalization of dashboards - allowing whether user's changes to be overriden by admin's chnages? 2. multi-tenancy in ues Please add if I have missed anything. Thanks, Tanya. -- Tanya Madurapperuma Software Engineer, WSO2 Inc. : wso2.com Mobile : +94718184439 ___ 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 -- Tanya Madurapperuma Software Engineer, WSO2 Inc. : wso2.com Mobile : +94718184439 ___ 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
Re: [Architecture] Cloud Connector Enhancements
+1 -
Please share a conclusion for this thread.
Isabelle.
--
Isabelle Mauny
Director, Product Management; WSO2, Inc.; http://wso2.com/
email: isabe...@wso2.com isabe...@wso2.com - mobile: +34 616050684
On Thu, Nov 7, 2013 at 7:57 PM, Jackie Wheeler jac...@wso2.com wrote:
Can we rename the configKey attribute to initKey to make it clearer?
On Thu, Nov 7, 2013 at 7:14 AM, Kasun Indrasiri ka...@wso2.com wrote:
Let me try to write the config for this :
//As the first step, we may initiate the connector with 'init' for user
'foo'
*twitter.init*
* consumerSecretxx/consumerSecret*
*
accessTokenSecret{wso2:vault-lookup('foo_ats')}/accessTokenSecret*
* accessToken{wso2:vault-lookup('foo_at')}/accessToken*
* consumerKey{wso2:vault-lookup('foo_ck')}/consumerKey*
* /twitter.init*
//Now I'm using the initiated connector (with user 'foo')
*twitter.sendDirectMessage*
*userIDxxx/userID*
*messagexxx/message*
*/twitter.sendDirectMessage*
//Again using the same connector with user 'foo'
*twitter.search*
* searchwso2/search*
*/twitter.search*
// Now I need to invoke an operation with a different twitter
configuration for user 'bar'.
*twitter.sendDirectMessage configKey=barTwitterConfig*
*userIDxxx/userID*
*messagexxx/message*
*/twitter.sendDirectMessage*
//Now should I override the current config with 'barTwitterConfig' or use
the initiated 'foo' config?
*twitter.search*
* searchwso2/search*
*/twitter.search*
The connector config can be externalize as follows.
Local Entry :
*localEntry xmlns=http://ws.apache.org/ns/synapse
http://ws.apache.org/ns/synapse key=kasunTwitterConfig*
* twitter.config*
* consumerSecretxx/consumerSecret*
* accessTokenSecret{wso2:vault-lookup('xx')}/accessTokenSecret*
* accessToken{wso2:vault-lookup('aa')}/accessToken*
* consumerKey{wso2:vault-lookup('bb')}/consumerKey*
* /twitter.config*
*/localEntry*
This may be not the ideal config, but we need to build something around
this.
On Thu, Nov 7, 2013 at 5:43 AM, Dushan Abeyruwan dus...@wso2.com wrote:
Hi Kasun,
Now if this call init instead config, this will conflict with
configRef, feeling something mismatching..
twitter.sendDirectMessage configKey=
userIDxxx/userID
messagexxx/message
/twitter.sendDirectMessage
On Thu, Nov 7, 2013 at 3:55 PM, Isabelle Mauny isabe...@wso2.comwrote:
+1 on changing to *init* instead of config. My only concern is that
init does not imply (in the name) that credentials are being used to
connect somewhere but I agree login might be too restrictive, so we need to
compromise.
I would also put the second enhancement as part of next milestone. Then
do an internal review and decide on the last part then ( auto-completion ).
Thanks,
Isabelle.
--
Isabelle Mauny
Director, Product Management; WSO2, Inc.; http://wso2.com/
email: isabe...@wso2.com isabe...@wso2.com - mobile: +34 616050684 *-
In USA (from Oct 27 till Nov 5th) *
On Wed, Nov 6, 2013 at 7:44 AM, Kasun Indrasiri ka...@wso2.com wrote:
We had several offline discussions on the $subject and we came up with
some enhancements.
*Renaming connector 'config' operation *
It seems using 'config' as an operation in a given connector is bit
confusing.
These are the alternatives that we have discussed.
*twitter.login* - (IMO, loging is not a generic term and that might
depends on the API that we are using)
*twitter.init* - We can init a connector and then invoke any
operation. If we want to switch to a different config, we can again to an
init with a different config and so on.
(We need these changes for 4.8)
*Registry Browser for selecting connector config (DevS)*
Add a registry browser button in the Init Ref(or config) property
field in Dev Studio so that users don't have to remember and type the Init
configuration's registry path in the field but can select it.
*Field Auto-completion (DevS/connectors) *
We need to be able to provide auto-complete and documentation on each
operation, so we talked about generating XSDs for them. The XSDs can be
part of the connector archive. However, we will be able to add this in a
future ESB release.
Please share your thoughts and incorporate the required changes in to
4.8.
--
Kasun Indrasiri
Software Architect
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware
cell: +94 77 556 5206
Blog : http://kasunpanorama.blogspot.com/
--
Dushan Abeyruwan
Associate Tech Lead
*Integration Technologies Team*
*WSO2 Inc. http://wso2.com/ http://wso2.com/*
*Mobile:(+94)714408632 %28%2B94%29714408632*
--
Kasun Indrasiri
Software Architect
WSO2, Inc.; http://wso2.com
lean.enterprise.middleware
cell: +94 77 556 5206
Blog : http://kasunpanorama.blogspot.com/
--
*Jackie Wheeler*
VP, Technical Content
WSO2, Inc.
Mobile: +1 510 725-2876
http://wso2.com/
___
Architecture
Re: [Architecture] APIM Supporting additional endpoint types
All, We already have a tool to create endpoints : Dev Studio. All we need is a way to choose the endpoints from a list in the APIM UI . Recreating the endpoints UI in the publisher would duplicate dev and maintenance work. We should create a clean integration between DevStudio and API publisher, to create/publish sequences and endpoints into the API Manager registry and use them from the Publisher UI. Can we do this as part of Phase 1 ? Isabelle. -- Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com isabe...@wso2.com - mobile: +34 616050684 On Thu, Oct 3, 2013 at 4:40 AM, Sanjiva Weerawarana sanj...@wso2.comwrote: On Wed, Oct 2, 2013 at 2:50 PM, Joseph Fonseka jos...@wso2.com wrote: In the current APIM we only support Address endpoint type. So we are planing to include other endpoint types which are supported by the ESB. Following are the other endpoint types Address Endpoint https://10.100.5.20:9445/carbon/endpoints/addressEndpoint.jsp? Defines the direct URL of the serveice Default Endpoint http://docs.wso2.org/display/ESB403/Default+Endpoint Defines additional configuration for the default target Failover Group https://10.100.5.20:9445/carbon/endpoints/failoverEndpoint.jsp? Defines the endpoints that the service will try to connect to in case of a failure. This will take place in a round robin manner HTTP Endpoint https://10.100.5.20:9445/carbon/endpoints/httpEndpoint.jsp? Defines a URI Template based REST Service endpoint Load Balance Endpoint https://10.100.5.20:9445/carbon/endpoints/loadBalanceEndpoint.jsp? Defines groups of endpoints for replicated services.The incoming requests will be directed to these endpoints in a round robin manner. These endpoints automatically handle the fail-over cases as well Recipient List Group https://10.100.5.20:9445/carbon/endpoints/recipientlistEndpoint.jsp? Defines the list of endpoints a message will be routed to Template Endpoint https://10.100.5.20:9445/carbon/endpoints/templateEndpoint.jsp? Defines a template endpoint that can parameterfy endpoints WSDL Endpoint https://10.100.5.20:9445/carbon/endpoints/wsdlEndpoint.jsp? Defines the WSDL, Service and Port Jo does this also address secured endpoints? E.g. basic auth secured or WSSec-UT or other (as long as its supported by the ESB)? From the above list do we need to ? and how to include the following ? 1. Default Endpoint What does this mean? 2. HTTP Endpoint - This require to populate the uri template during mediation. 3. Template Endpoint - You need to specify a template when creating an endpoint. So this is a way to create an endpoint based on some info in the incoming request? Some of the above need additional configuration. As I understood configure meditations and defining templates. Do we have to provide UI for them as well. I think we need to provide a UI to define these endpoints. Is there something other than that in your mind? By templates you didn't mean ESB templates right? 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 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] APIM Supporting additional endpoint types
Hi, Supporting HA endpoints is a customer requirements (HA and LB) I have another idea for this: if we package several templates for each endpoint , and allow users to just set the parameters for each template , we would cover 80% of cases. If somebody wants to register a new template they can create it in Studio and deploy it in the right registry location, as we do for sequences. @Joe, Would a text field, allowing you to enter the URI template be enough for your requirement ? As you found out, uri-template are supported by the underlying engine, but not at the UI level right now. Thanks, Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Oct 3, 2013, at 11:23 AM, Kasun Indrasiri ka...@wso2.com wrote: I don't think it is necessary to support all the endpoint supported from ESB. Following endpoint type would be sufficient in API-M context. - Address EP - HTTP EP - We dynamically formulate the EP address based on URI Templates. These EPs should be able to cater most of the requirements. Do we have to support LB/FO at API-GW level? On Thu, Oct 3, 2013 at 11:19 AM, Joseph Fonseka jos...@wso2.com wrote: Hi Sanjiva Jo does this also address secured endpoints? E.g. basic auth secured or WSSec-UT or other (as long as its supported by the ESB)? The plan is to add most of the Endpoint configuration to the Publisher UI without over complicating it. So I guess we can handle WSSec-UT as well and basic auth is already supported by APIM. From the above list do we need to ? and how to include the following ? 1. Default Endpoint What does this mean? From what I read Default Endpoint is used to add QoS and other configurations to an endpoint which is resolved from the to address of message context. 2. HTTP Endpoint - This require to populate the uri template during mediation. 3. Template Endpoint - You need to specify a template when creating an endpoint. So this is a way to create an endpoint based on some info in the incoming request? Yes HTTP Endpoint has the ability to generate the BE Service Endpoint URI based on the message so you have to configure how to do it in the mediator. So this require to have UI in the publisher to configure the mediators. IMHO better to look at some use-cases before incorporating this. Some of the above need additional configuration. As I understood configure meditations and defining templates. Do we have to provide UI for them as well. I think we need to provide a UI to define these endpoints. Is there something other than that in your mind? By templates you didn't mean ESB templates right? Well in ESB you can create endpoint templates which can be one of the other endpoint types. When you want to create an endpoint using those templates you can use Template Endpoint Type in endpoint creation and select the relevant template. So do we need AM to support keeping predefined endpoint templates? Regards Jo -- Joseph Fonseka Senior Tech Lead WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 772 512 430 skype: jpfonseka ___ 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 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Drop the requirement of having multiple App Owners per Application in App Factory
Hi, Could we transfer ownership from one user to another ? The same way that in GDoc there is only one owner of a doc, however that right can be transferred to somebody else. Also, could we identify that person as AppOwnerAppKey ( for example, AppOwner-HelloWorld, that should be a unique combination) and we use that as the provider name in APIM (as opposed to the *actual* name of the Owner, such as Punnadi) Then anybody in the AppOwner role (1 or N) will be able to browse the keys and see them for that App , right ? Same could be applied if we decide that the Dev role is actually the subscriber - Anybody with Dev role, for that app , can be a subscriber and therefore see the keys and generate them. Is that possible at all ? Isabelle. -- Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com isabe...@wso2.com - mobile: +34 616050684 On Mon, Sep 23, 2013 at 12:51 PM, Paul Fremantle p...@wso2.com wrote: That is really circular logic: APIM requires exactly one subscriber. We have one app owner, so we decided to make that the subscriber. Now, because there can only be one subscriber we can't make more that one app owner. There are two simple solutions to this: 1) Create a new role (API Subscriber) and make that only assignable to one person 2) Fix API Manager so that it can support group subscribers. I don't think making a single app owner because of this is the right answer. Paul On 23 September 2013 11:22, Punnadi Gunarathna punn...@wso2.com wrote: Hi Paul, We have had a discussion mail earlier (i.e subject Issue in App subscription and Key generation with API Manager in AppFactory) on Architecture group and I have mentioned the reason there in more details. In summary there is a limitation in APIM where there is no such a concept as Group Subscription. Therefore in App Factory, if there is a application and number of members in the team (App Owner, Developers etc) only one person can login to APIM and subscribe to APIs. So if there are several developers we will have to identify one person from them. Instead since we have 1 App Owner per application we have decided to give subscription/key generation rights to App Owner. On Mon, Sep 23, 2013 at 3:19 PM, Paul Fremantle p...@wso2.com wrote: I don't see why the App Owner is the person to generate the keys anyway. Normally it would be one of the devs. This looks like something where we need to define exactly what behaviour we would like to see is, and then implement that in APIM. For example, if I generate keys for an app, who else in the team should see them? I actually don't know the answer to that question. I think we need to figure that out first. Paul On 23 September 2013 10:44, Punnadi Gunarathna punn...@wso2.com wrote: Hi All, Myself and Dimuthu had a offline chat regarding $subject and please find more details on why that cannot be done. -If we allow to have multiple App Owners per application then there will be an issue with APIM. That is; AppOwner1 creates an Application called App1 in App Factory. Then he invites few more people as App Owners say AppOwner2 and AppOwner3. AppOwner1 login to API Manger and subscribe App1 with API1 and generate key pairs. Based on the current APIM implementation, any other App Owner who will login to APIM will not be able to see the previous subscriptions or already generated keys. Furthermore they can subscribe the same application individually again with the API1 and generate new keys. This is why we thought of not having multiple App Owners per application. So then comes the question if the AppOwner1 leaves the company, then how can we manage the App1 as well as its subscribed APIs? In such a situation we thought to provide scripts to update both App Factory and APIM databases in such a way that the old App Owner will be updated with the new App Owner details. Please let us know your thought on this. -- Thanks and Regards, Punnadi Gunarathna Senior Software Engineer, WSO2, Inc.; http://wso2.com http://wso2 Blog: http://hi-my-world.blogspot.com/ Tel : 94 11 214 5345 Fax :94 11 2145300 http://lalajisureshika.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
Re: [Architecture] Extension Point to associate custom sequences to in/out/fault flows in APIManager.
I realize I have not responded to your deployment question : why can't we use the exact same methodology we use for the ESB ? Provided the sequences are dynamic and stored in the registry, all we need is to publish those sequences in the prod registry and make sure the gateway can access that (which it can anyway in the normal setup). Also, we should assume the sequences are developed by a different role and need to be provisioned when the the API publisher is publishing the API. WDYT? Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Aug 2, 2013, at 3:26 PM, Isabelle Mauny isabe...@wso2.com wrote: Sanjeewa, That will be phase 2 :) A web editor for the flows is definitely something we have to do and will do, but not for the next release! Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Aug 2, 2013, at 3:10 PM, Sanjeewa Malalgoda sanje...@wso2.com wrote: On Fri, Aug 2, 2013 at 4:16 PM, Isabelle Mauny isabe...@wso2.com wrote: All, So this is part of the overall plan of supporting API manager in DevStudio. Today, you can develop and deploy sequences, leveraging the full power of ESB mediators, as per this : http://docs.wso2.org/wiki/display/AM140/Adding+a+Mediation+Extension - However, it's a manual process. The purpose of this feature is to make the deployment of sequences easier : as a developer, I can create sequences to be deployed at the gateway level from DevStudio and push them to the AM repository. When an API is published, I can pick the sequence from the sequences list as an IN or OUT sequence, and the manual deployment process explained above would happen automatically (so for example, I would have a REST_to_SOAP_SERVICEA sequence, apply it as IN sequence for APIA and it would be automatically applied to the right place (i.e. saved as APIA:v1.0.0--IN) in the right folder. If sequences need to be composed, this would need to happen in DevStudio, not in the API Publisher UI (for now). This would be really useful feature IMO. But how external API publisher connect and create sequences using developer studio(I mean how we can do this in production deployment)? Also i would like to share my thought on supporting additional operations to API flow. How about having optimized view of ESB mediation flow editor inside API manager? So we can let users to add different operations like adding header, remove header, log message, enrich message and etc. We do not necessary to let all publishers to do this we an have role based control mechanism. We can ask API publishers to go and create API but if they want to do any additional operations we can direct them to sequence editor user interface. I was thinking about having such editor in API manager publisher ui. Also i have observed some of other API management tools support that type of mediation flow editors. Thanks, Sanjeewa. So implementing this is two-fold a) Tools to push the sequences into the right place in the API Manager registry from Dev Studio ( or allow users to export sequences and import them manually using the check-in client or similar in case remote access to GW registry is not allowed). b) Changes in publisher UI to pick sequence file from registry and deploy them to the gateway. I think those two actions need to be decoupled to allow deploying one sequence to a cluster of gateways at publishing time. Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Jul 31, 2013, at 9:39 PM, Sumedha Rubasinghe sume...@wso2.com wrote: I think we should wait for Isabelle to provide explanation. I am also not clear of what is the exact requirement. Isabelle, This is regarding Feature #72: Extension Point to associate sequences to inbound/outbound/fault flows . Could you elaborate bit more please? On Wed, Jul 31, 2013 at 9:07 PM, Sanjeewa Malalgoda sanje...@wso2.com wrote: On Wed, Jul 31, 2013 at 1:20 PM, Vijayaratha Vijayasingam rat...@wso2.com wrote: Hi all; Our requirement Allow users to create their own sequences and make them available in the API configuration. A developer creates the necessary sequences to say log, audit requests, may be add authorization via XACML , whatever is needed and pushes those with a description to the API publisher repository. When a publisher comes in (@ publisher UI) and publishes in API, the list of sequences is visible and he can pick one from the lists. Existing feature Currently we have a mediation extension point(it is a synapse rest handler) where, it picks the existing sequences (which are deployed following a naming convention) and whenever a request comes in to the API, handler
Re: [Architecture] Developer-Studio Icons
You should not need to specify anything on the icon if the test below has a meaning, that is it can say : Set To: HTTP Header, as opposed to Property. See https://wso2.org/jira/browse/ESBJAVA-1811- You need to cater for this enhancement in the ESB diagram design. +1 to make to have a preference to toggle between icon+text vs. just icon. Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com - mobile (Spain) : +34 616050684 - mobile (Sri Lanka) +94 (0)774777663 On Aug 5, 2013, at 11:45 AM, Praveena Sarathchandra pravee...@wso2.com wrote: I'm +1 for using text below icons, because these are not like standard icons that people are used to. Maybe you can let the user toggle the text on/off using a shortcut key. Also, because the size of these icons are small, they should not have any complex designs. You can have a look at Entypo[1] or Fontawesome[2] icon fonts for some inspiration. Regarding the color scheme, I think it'd be better if you can follow a pastel-like color scheme. Diagrams would look easy on the eye when there are so many different kinds of elements in them. For this you can try Kuler[3] to find one of your choice. [1] http://www.entypo.com/ [2] http://fortawesome.github.com/Font-Awesome/ [3] https://kuler.adobe.com/pastel-art-colors/ On Mon, Aug 5, 2013 at 2:33 PM, Chanaka Jayasena chan...@wso2.com wrote: We had an internal discussion about the icons and designs. Plan is to get the line art representation of the 1st and 4th concepts and draw the icons, rather than using complex artwork. The icons will be grouped according to what is used in ESB web console. These grouped icons will be differentiated by the shape of the icon container, and the color of the icon.The text in the icons will be kept since the repeating text below the icons should be the description that the user is adding. Unfortunately my previous images does not represent that idea. I am in the process of creating a new screen to visualize the proposed concept. thanks, Chanaka On Mon, Aug 5, 2013 at 10:21 AM, Samisa Abeysinghe sam...@wso2.com wrote: So different colors is a good point as far as picking the difference goes. But they got to be noticeably different. The good thing about concept one is the clear imaging in there. So we need a combination of concept one and three where we could have clear imaging and clear color based differentiation to help pick the right one to match the need from the bunch of options available, while you are at the task of developing. On Mon, Aug 5, 2013 at 9:43 AM, Kasun Indrasiri ka...@wso2.com wrote: - We thought of including the text along with the icon, because all mediators cannot be represented with just an icon. EIPs can be used for few mediators, but not all mediators cannot be represented with EIP icons. And the text below the icon can be anything (such as a comment) that user wants to add (which will be saved as the sequence/mediation description in the config). - I prefer the icon shape as with concept-3 with a different color scheme (and with out fancy colored icons inside) On Mon, Aug 5, 2013 at 5:34 AM, Chanaka Jayasena chan...@wso2.com wrote: Designing meaningful Icons for Fault mediator , Aggregate Mediator can be easy enough, but for complex synarios it will be hard to represent the idea and grasp the idea from the icon as well. From the users perspective when user tries to read a flow of elements, it will be easy for the user if there is a word attached to it where he can read it on the spot rather than try to find it by going through a documentation. I personally like the first one but the third one is more color contrasting, which adds one more plus point for the users to bind memories to associated color patterns of icons. One minus point in the third one I see is that, the text representation is bit inconsistent compared to the first one. thanks, Chanaka On Sat, Aug 3, 2013 at 8:54 PM, Isuru Perera isu...@wso2.com wrote: On Sat, Aug 3, 2013 at 8:31 PM, Sanjiva Weerawarana sanj...@wso2.com wrote: Personally I don't like them .. they're going to be too complicated at the 50x50 type size they're in reality. Second, the words in the icons don't make sense IMO. Yes. I think the words are not needed on icons. We just have to make sure the icon is meaningful. Third the colors seem too strong? Of course I'm color blind so my color choices are not one to bet on. -- Isuru Perera Senior Software Engineer | WSO2, Inc. | http://wso2.com/ Lean . Enterprise . Middleware Twitter: http://twitter.com/chrishantha | LinkedIn: http://lk.linkedin.com/in/chrishantha/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo
Re: [Architecture] Mock up screens for BAM events activity search
I understand Inosh - What I am saying is that the person designing the streams is not the person searching for messages - So the UI can't use BAM terminology. Actually the message console should most likely be a UI which is independent from the BAM UI itself, using the aggregated data in the analytics database (or are we looking into searching directly into the Cassandra database ?) The person searching for messages knows about the problem domain , i.e. an IP number, a partner name, a timestamp are available. Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Jul 29, 2013, at 9:24 AM, Inosh Goonewardena in...@wso2.com wrote: Hi Isabelle, In this case we have to use stream concept in our search queries because we can't just search through the messages using the given values to the list of properties. What we search here is events which have certain values for certain properties. So the search should bound with a event stream and that has to be provided in the search query. Other than that those event properties also needs to be indexed as well. On Mon, Jul 29, 2013 at 12:27 PM, Inosh Goonewardena in...@wso2.com wrote: Hi, Events and activity search need to support queries like (stream1.prop1=1 or stream2.prop2=2) and (stream1.prop3=3). So that we have to handle ordering of those conditions properly as well. With this UI that requirement can be managed easily. In the other hand devops are aware of the properties that have been indexed and the query they want to search. So I believe we can meet our search requirements with proposed UIs On Fri, Jul 26, 2013 at 10:28 PM, Isabelle Mauny isabe...@wso2.com wrote: All, Please keep in mind that this console is meant to be used by DevOps. They don't know what a stream is and have no reason to know - So , don't use that terminology in the UI - You need to abstract the UI from the underlying implementation. The UI needs to talk about messages, not events or streams which are product concepts. Behind the scenes, the search might be based on stream1.property = value, but in the UI this is not what I want to see in the UI : just the list of properties I can search on (in other words, the UI does not expect me to know the properties list, but rather just expect to know the values I want to input to the search.) Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com - mobile (Spain) : +34 616050684 - mobile (Sri Lanka) +94 (0)774777663 On Jul 26, 2013, at 12:36 AM, Inosh Goonewardena in...@wso2.com wrote: Yea, greater than, less than, .. operations can be supported for int, double, long types. On Fri, Jul 26, 2013 at 12:54 PM, Malith Dhanushka mal...@wso2.com wrote: Hi, For what extent that query grammar would get implemented. Is it possible to filter values from streams. ( ie - stream1.property1 value1 ) ? On Fri, Jul 26, 2013 at 11:44 AM, Inosh Goonewardena in...@wso2.com wrote: Hi Hasitha, This a only a read only view. U may have a valid point about data removal. But we have to discuss about that matter. On Fri, Jul 26, 2013 at 5:25 AM, Hasitha Hiranya hasit...@wso2.com wrote: Hi, +1 for new event search UI. It brings flexibility. Is this a read-only view? What if somebody want to do a query and remove all the data found? Is it not valid a use-case? Thanks On Thu, Jul 25, 2013 at 7:23 PM, Inosh Goonewardena in...@wso2.com wrote: I have attached modified mock screens. Appreciate your feedbacks On Thu, Jul 25, 2013 at 5:41 PM, Srinath Perera srin...@wso2.com wrote: ah sorry :) --Srinath On Thu, Jul 25, 2013 at 5:40 PM, Anjana Fernando anj...@wso2.com wrote: Hi Srinath, I think we got the term ordering confused here :) .. I wasn't really talking about temporal ordering of the events there (I think we can ignore that for the initial version of search) .. I was mentioning how we properly give the ordering of the conditions there .. as in the and, or operators .. like we can say A and B or C, where by usual operator precedence it'll be (A and B) or C .. but we may also want to give something like A and (B or C) .. I was just mentioning the syntax we will need to show the mentioned behavior, we can't do it in a simple way in an UI. Cheers, Anjana. On Thu, Jul 25, 2013 at 5:27 PM, Srinath Perera srin...@wso2.com wrote: Hi Anjana, For example, stream1.prop1=1 - stream2.prop1=1 to show the ordering (note the arrow). Actually, this is the CEP event pattern format (http://wso2.com/library/articles/2013/06/understanding-siddhi-powers-wso2-cep-2x, see sequence). IMHO, if we need to show temporal ordering, CEP has the format. May be there is room to improve, but in which case
Re: [Architecture] Support for publishing into multiple API Stores in API Manager
Lalaji, Looks great - Just one comment - Please add a display name to the store definition, which can be localized ( i.e. there is a fixed name used internally and a display name for the UI which can change ) - This will allow for multi-lingual stores names. Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com - mobile (Spain) : +34 616050684 - mobile (Sri Lanka) +94 (0)774777663 On Aug 2, 2013, at 2:30 PM, Lalaji Sureshika lal...@wso2.com wrote: Hi, Please find the implementation details,that we are going to do for achieving above mentioned new approach. Below configuration will be added to api-manager.xml [default this config section will be commented out],to define the external stores,that we are going to publish from APIPublisher. ExternalAPIStores ExternalAPIStore NameStore1/Name TypeWSO2/Type Endpointhttp://localhost:9763/store/Endpoint Usernamex/Username Passwordx/Password /ExternalAPIStore ExternalAPIStore NameProgrammableWeb/Name Typexxx/Type Endpointx/Endpoint /ExternalAPIStore ExternalAPIStore NameStore2/Name TypeWSO2/Type Endpointhttp://localhost:9763/store?tenant=wso2/Endpoint Usernamex/Username Passwordx/Password /ExternalAPIStore /ExternalAPIStores In above configuration,based on type attribute of each external APIStore,it will be differentiated.Note as the first,we are going to give support for WSO2 APIStores and later it will be extend to support other types of stores [eg:programmableweb] as well APIPublisher changes In APIPublisher UI, there will be only two visibility options as ; 1) Allowed Anonymous Access -Visible to anonymous/every user 2) Restricted by Roles -Restrict by users' roles And additionally,if the above 'ExternalAPIStores' configuration is uncommented,the option called Publish to External APIStores will be showed in UI to share the API across APIStores.These external APIStores could be WSO2 based APIStores [eg: tenant based stores] or other ones. Screenshot-23.png To publish to external APIStores addition to the embedded APIStore of running Publisher,we'll be using their specific exposed APIs and first we'll be focusing only on publishing APIs to WSO2 APIStores.For that we'll be used the APIPublisher exposed REST API[1]. APIStore changes The current logic of iterating tenant registries to get APIs will be removed and, If the APIManager running in MT mode, 1) If try to access /Store as an anonymous user -the urls for the tenant stores will be showed in APIStore[/store] 2) If try to access /Store as a tenant user -The store will be redirect to tenant store [/store?tenant=?] Else if APIM running in super tenant mode,the permitted APIs will display in APIStore[/store] based on API visibility. Feedbacks welcome.. [1] http://docs.wso2.org/wiki/display/AM140/Publisher+APIs Thanks; On Tue, Jul 30, 2013 at 12:44 AM, Nuwan Bandara nu...@wso2.com wrote: Hi With the new proposal the previous super tenant store will be a store of stores. If we take an example lets assume there are two tenants WSO2 and Foo, the super tenant store will just show URLs of WSO2 store and Foo Store, where users can navigate to. When an anonymous user goes to one of these store, (s)he will only see the public APIs of that tenant. Subsequently the older super store will be replaced by a simple OOTB store, where any tenant can push APIs. its like a public store hosted somewhere, which anybody can push APIs. Regards, /Nuwan On Tue, Jul 30, 2013 at 1:08 PM, Nuwan Dias nuw...@wso2.com wrote: On Tue, Jul 30, 2013 at 12:45 PM, Sumedha Rubasinghe sume...@wso2.com wrote: This discussion happened as part of *Enterprise Store* discussion. Participants: Nuwan, Azeez, Sanjiva, Srinath, NuwanD, Lalaji, Sanjeewa, Sumedha Current Functionality: 1. At the point of publishing an API, publisher can select the visibility scope (one of Globally visible, selected tenants, tenant only [private/public]). 2. Based on selected scope, APIs will be created with correct set of permission indicators in WSO2 Governance Registry 3. @ the point of populating a store, based on the store type APIs will be fetched from tenant registries Limitations in this approach: 1. Assumption of single registry for all tenants (fetching, publishing criteria fails with tenant partitioning) 2. High computational cost for populating global tenant store (also known as super tenant store) 3. API publishing is only supported for WSO2 API Store type 4. Tight coupling with WSO2 API Store semantics for API publishing fetching New Approach: 1. At the point of publishing an API, it can also be published to multiple (external) stores 2. These stores
Re: [Architecture] Extension Point to associate custom sequences to in/out/fault flows in APIManager.
Sanjeewa, That will be phase 2 :) A web editor for the flows is definitely something we have to do and will do, but not for the next release! Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Aug 2, 2013, at 3:10 PM, Sanjeewa Malalgoda sanje...@wso2.com wrote: On Fri, Aug 2, 2013 at 4:16 PM, Isabelle Mauny isabe...@wso2.com wrote: All, So this is part of the overall plan of supporting API manager in DevStudio. Today, you can develop and deploy sequences, leveraging the full power of ESB mediators, as per this : http://docs.wso2.org/wiki/display/AM140/Adding+a+Mediation+Extension - However, it's a manual process. The purpose of this feature is to make the deployment of sequences easier : as a developer, I can create sequences to be deployed at the gateway level from DevStudio and push them to the AM repository. When an API is published, I can pick the sequence from the sequences list as an IN or OUT sequence, and the manual deployment process explained above would happen automatically (so for example, I would have a REST_to_SOAP_SERVICEA sequence, apply it as IN sequence for APIA and it would be automatically applied to the right place (i.e. saved as APIA:v1.0.0--IN) in the right folder. If sequences need to be composed, this would need to happen in DevStudio, not in the API Publisher UI (for now). This would be really useful feature IMO. But how external API publisher connect and create sequences using developer studio(I mean how we can do this in production deployment)? Also i would like to share my thought on supporting additional operations to API flow. How about having optimized view of ESB mediation flow editor inside API manager? So we can let users to add different operations like adding header, remove header, log message, enrich message and etc. We do not necessary to let all publishers to do this we an have role based control mechanism. We can ask API publishers to go and create API but if they want to do any additional operations we can direct them to sequence editor user interface. I was thinking about having such editor in API manager publisher ui. Also i have observed some of other API management tools support that type of mediation flow editors. Thanks, Sanjeewa. So implementing this is two-fold a) Tools to push the sequences into the right place in the API Manager registry from Dev Studio ( or allow users to export sequences and import them manually using the check-in client or similar in case remote access to GW registry is not allowed). b) Changes in publisher UI to pick sequence file from registry and deploy them to the gateway. I think those two actions need to be decoupled to allow deploying one sequence to a cluster of gateways at publishing time. Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Jul 31, 2013, at 9:39 PM, Sumedha Rubasinghe sume...@wso2.com wrote: I think we should wait for Isabelle to provide explanation. I am also not clear of what is the exact requirement. Isabelle, This is regarding Feature #72: Extension Point to associate sequences to inbound/outbound/fault flows . Could you elaborate bit more please? On Wed, Jul 31, 2013 at 9:07 PM, Sanjeewa Malalgoda sanje...@wso2.com wrote: On Wed, Jul 31, 2013 at 1:20 PM, Vijayaratha Vijayasingam rat...@wso2.com wrote: Hi all; Our requirement Allow users to create their own sequences and make them available in the API configuration. A developer creates the necessary sequences to say log, audit requests, may be add authorization via XACML , whatever is needed and pushes those with a description to the API publisher repository. When a publisher comes in (@ publisher UI) and publishes in API, the list of sequences is visible and he can pick one from the lists. Existing feature Currently we have a mediation extension point(it is a synapse rest handler) where, it picks the existing sequences (which are deployed following a naming convention) and whenever a request comes in to the API, handler checks whether a custom sequence available for that particular API and if it is available it executes that custom sequence . Implementation We could use Devstudio to develop the custom sequences and deploy them in APIManager. From the publisher UI, we could provide a UI option to select the existing sequences. Once selected, we could change the sequence name to follow the naming convention(needed for handler) and store them in the registry (should we store at local registry(file sytem)/user registry?) Handler can take care of the execution part(it is already implemented) So who is going to develop and add those sequences to API gateway? I guess it should done by administrator of system
Re: [Architecture] Throttling Support at API Resource Level
All, With all those throttling limits with the same name, it's getting very confusing to understand what is going to happen in the end. We should introduce a few more default ones , with more significant names - Also, how are we checking that the limits we are setting at different levels make sense, for example: if publisher sets a Silver limit on GET for an API (a limit which can't be changed) , the consumer can't subscribe to API at Gold level (he will never get that SLA) - Also, in the UI, if the list of available Tiers contains say Silver and Bronze for the overall API , Unlimited and Gold can't be available for API level throttling. Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Jul 24, 2013, at 11:14 PM, Samisa Abeysinghe sam...@wso2.com wrote: So, on the UI, how can I say 10 for Gold and 5 for Silver? On Thu, Jul 25, 2013 at 11:31 AM, Sanjeewa Malalgoda sanje...@wso2.com wrote: Attaching UI components screen shots. Thanks, Sanjeewa. On Wed, Jul 24, 2013 at 3:54 PM, Sumedha Rubasinghe sume...@wso2.com wrote: On Wed, Jul 24, 2013 at 3:06 PM, Srinath Perera srin...@wso2.com wrote: Hi All, I am sorry I missed this thread. Did not we planned to do this via Siddhi? that will give a very comprehensive solution IMO. Srinath, We have only added another level of throttling capability for APIs. This is still utilizing existing WSO2 Throttling component capabilities. Once we have Siddhi based throttling component, we can switch. But right now Siddhi based throttling is not a stable option for immediate release IMO. --Srinath On Thu, Jul 18, 2013 at 6:52 PM, Samisa Abeysinghe sam...@wso2.com wrote: On Thu, Jul 18, 2013 at 9:36 AM, Sanjeewa Malalgoda sanje...@wso2.com wrote: Hi Samisa, On Thu, Jul 18, 2013 at 6:02 AM, Samisa Abeysinghe sam...@wso2.com wrote: So it looks to me that we can only throttle based on requests per second. Yes as of now we support only within time window. This is fine for the first cut implementation. However, how extensible is this implementation? How easily can another type of trotting strategy be added? We need to implement API throttle handler and implement doThrottle method doThrottle(MessageContext mc) inside above method we can retrieve any information we need(from message context or usage data store). Then we need to define throttle key for this scenario(it can be name, access key). then we have to call canAccess(context, Key, tier). This canAccess is not new implementation and already available in throttle module and we are using it. I think it is a mistake that we are looking at this problem with the limitations of the existing throttling component. We need to take a step back and look at what API throttling need. Our original throttling component may not even have been designed with that in mind. Another question is what is the relationship between what is throttled and what is monitored (using BAM for e.g.) When we monitor API usage using usage handler we do capture all information available with message context and use subset of that for throttling purposes. We do not capture message bandwidth for API call. Do we not want to capture BW at some point? Using subset for throttling is again not acceptable. Why are we using a subset? Again, we need to look at this without Axis2 oriented mindset. We need to think APIs. What would the users want when they throttle APIs? Moreover, in order to make throttling decisions, we need to make use of data that is being monitored. Meaning BAM feeds back into throttling. There needs to be one to one mapping here. Thanks, Sanjeewa On Wed, Jul 17, 2013 at 6:06 PM, Sanjeewa Malalgoda sanje...@wso2.com wrote: On Wed, Jul 17, 2013 at 5:52 PM, Samisa Abeysinghe sam...@wso2.com wrote: Well, when it said throttling, I got the impression that we could do things like: - number of calls per second (rate limit) We do support this at 3 levels as i mentioned. - bits per second (bandwidth limit) We don't support this as of now. etc. on a time window. Thanks, Sanjeewa On Wed, Jul 17, 2013 at 5:44 PM, Sumedha Rubasinghe sume...@wso2.com wrote: On Wed, Jul 17, 2013 at 5:23 PM, Samisa Abeysinghe sam...@wso2.com wrote: Throttling based on which parameters? For now we have only considered Access Token + API sub context + HTTP Verb How does that get mapped into tier? @ the point of API being published, a tier will be associated to each API sub context + HTTP Verb. So throttling (if configured @ resource level) will happen against each access token. Does the params change tier to tier or are they same across all tiers? Yes. They can be. But for now, we have only considered above (which seems to have supported most of the client cases
Re: [Architecture] Storage Server - HDFS Browser
Understood - Jaggery app then ... Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Jul 23, 2013, at 12:53 AM, Srinath Perera srin...@wso2.com wrote: Hi Isabelle, IMO this is not a great usecase for Gadgets. This is core functionality that should come from core application menus. If you consider BAM, that is a great usecase for Gadgets, as users are looking for a Dashboard, and same for Governance cases I think. IMO not in SS server case. --Srinath On Mon, Jul 22, 2013 at 9:02 PM, Isabelle Mauny isabe...@wso2.com wrote: Can we make of all of these gadgets and leverage UES as a central mechanism to install those gadgets and have a clean/lean user interface ? Then we can associate roles with gadgets and let users compose their own microsites/dashboard to visualize this information. Admin console is a bit restrictive, plus it's hosted inside the server and we want those visualizations to work across a cluster. Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com - mobile (Spain) : +34 616050684 - mobile (Sri Lanka) +94 (0)774777663 On Jul 21, 2013, at 7:58 PM, Sanjiva Weerawarana sanj...@wso2.com wrote: +1 .. I think SS has become an end-user tool more and more. In that case we need to have an end-user UI, not an admin console. Of course user here maybe developer instead of real user but in hosted PaaS scenarios that person is very important. Sanjiva. On Mon, Jul 22, 2013 at 1:19 AM, Prabath Abeysekera praba...@wso2.com wrote: Hi Sanjiva, On Sat, Jul 20, 2013 at 7:19 PM, Sanjiva Weerawarana sanj...@wso2.com wrote: Hmmm .. is this an admin activity or end user activity? I'd consider this, more or less an end-user activity from SS standpoint as a provisioning manager. The idea is to have this as a tool similar to H2 console and Cassandra explorer which we already have in SS, to browse (and do some user-specific customizations) on the respective provisioned entities, for end-users. It seems to me we're heading towards requiring a separate end user app for SS. I'm ok with going ahead with it within the admin console for now but we probably need to plan to write a new Jaggery app as a human UI for SS right? My initial idea was, this particular UI component being implemented would ideally fit into Tools menu in the current Management Console UI. However, it would be cool to plan for a Jaggery app too. We'd also probably need to think of writing similar apps for Cassandra Explorer, etc? Sanjiva. On Fri, Jul 19, 2013 at 3:49 PM, Shani Ranasinghe sh...@wso2.com wrote: Hi, Thanks for your feedback. Please find my comments below. On Fri, Jul 19, 2013 at 1:16 PM, Prabath Abeysekera praba...@wso2.com wrote: Hi Sumedha, On Fri, Jul 19, 2013 at 12:33 PM, Sumedha Rubasinghe sume...@wso2.com wrote: Some feedback. Your using the same tree view being used by Registry Explorer. right? If not, please use the same. The functionality required is almost the same. 'RenameFolder' is missing a space. Done. String 'Folder' is redundant. Only action names 'Create', 'Rename', 'Delete' would suffice. Do we support Symbolic Links? Done. Yes we are planning to support Symbolic Links. Can we make menu options under 'Cassandra Explorer' 'Hadoop File System' more intuitive? Yes. Will do the changes. Yeah +1. Further we're planning to move Cassandra Explorer, etc under tools menu as they are more or less tools to browse the provisioned infrastructure. That would also give more prominence to the main functionalities offered via SS. Do we support connecting to multiple HDFS? If yes, we need a connect option. Yes, we are currently working on it. On Fri, Jul 19, 2013 at 12:12 PM, Shani Ranasinghe sh...@wso2.com wrote: Hi, I am working on the HDFS Browser for the Storage Server product. Please find the UI's created for this component as decided by the team in its initial phase. This does not include the UI for file operations. If a file is listed in the detail view, the actions (Similar to the UI titled 'DetailViewActions') will be listed as following, 1. Rename file 2. Delete File 3. Download File Appreciate your thoughts on this. Thanks, Shani Ranasinghe Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 77 2273555 linked in: lk.linkedin.com/pub/shani-ranasinghe/34/111/ab ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- /sumedha b : bit.ly/sumedha ___ Architecture mailing list Architecture@wso2
Re: [Architecture] Storage Server - HDFS Browser
Can we make of all of these gadgets and leverage UES as a central mechanism to install those gadgets and have a clean/lean user interface ? Then we can associate roles with gadgets and let users compose their own microsites/dashboard to visualize this information. Admin console is a bit restrictive, plus it's hosted inside the server and we want those visualizations to work across a cluster. Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com - mobile (Spain) : +34 616050684 - mobile (Sri Lanka) +94 (0)774777663 On Jul 21, 2013, at 7:58 PM, Sanjiva Weerawarana sanj...@wso2.com wrote: +1 .. I think SS has become an end-user tool more and more. In that case we need to have an end-user UI, not an admin console. Of course user here maybe developer instead of real user but in hosted PaaS scenarios that person is very important. Sanjiva. On Mon, Jul 22, 2013 at 1:19 AM, Prabath Abeysekera praba...@wso2.com wrote: Hi Sanjiva, On Sat, Jul 20, 2013 at 7:19 PM, Sanjiva Weerawarana sanj...@wso2.com wrote: Hmmm .. is this an admin activity or end user activity? I'd consider this, more or less an end-user activity from SS standpoint as a provisioning manager. The idea is to have this as a tool similar to H2 console and Cassandra explorer which we already have in SS, to browse (and do some user-specific customizations) on the respective provisioned entities, for end-users. It seems to me we're heading towards requiring a separate end user app for SS. I'm ok with going ahead with it within the admin console for now but we probably need to plan to write a new Jaggery app as a human UI for SS right? My initial idea was, this particular UI component being implemented would ideally fit into Tools menu in the current Management Console UI. However, it would be cool to plan for a Jaggery app too. We'd also probably need to think of writing similar apps for Cassandra Explorer, etc? Sanjiva. On Fri, Jul 19, 2013 at 3:49 PM, Shani Ranasinghe sh...@wso2.com wrote: Hi, Thanks for your feedback. Please find my comments below. On Fri, Jul 19, 2013 at 1:16 PM, Prabath Abeysekera praba...@wso2.com wrote: Hi Sumedha, On Fri, Jul 19, 2013 at 12:33 PM, Sumedha Rubasinghe sume...@wso2.com wrote: Some feedback. Your using the same tree view being used by Registry Explorer. right? If not, please use the same. The functionality required is almost the same. 'RenameFolder' is missing a space. Done. String 'Folder' is redundant. Only action names 'Create', 'Rename', 'Delete' would suffice. Do we support Symbolic Links? Done. Yes we are planning to support Symbolic Links. Can we make menu options under 'Cassandra Explorer' 'Hadoop File System' more intuitive? Yes. Will do the changes. Yeah +1. Further we're planning to move Cassandra Explorer, etc under tools menu as they are more or less tools to browse the provisioned infrastructure. That would also give more prominence to the main functionalities offered via SS. Do we support connecting to multiple HDFS? If yes, we need a connect option. Yes, we are currently working on it. On Fri, Jul 19, 2013 at 12:12 PM, Shani Ranasinghe sh...@wso2.com wrote: Hi, I am working on the HDFS Browser for the Storage Server product. Please find the UI's created for this component as decided by the team in its initial phase. This does not include the UI for file operations. If a file is listed in the detail view, the actions (Similar to the UI titled 'DetailViewActions') will be listed as following, 1. Rename file 2. Delete File 3. Download File Appreciate your thoughts on this. Thanks, Shani Ranasinghe Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 77 2273555 linked in: lk.linkedin.com/pub/shani-ranasinghe/34/111/ab ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- /sumedha b : bit.ly/sumedha ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture Regards, Prabath -- Prabath Abeysekara Associate Technical Lead, Data TG. WSO2 Inc. Email: praba...@wso2.com Mobile: +94774171471 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture Shani Ranasinghe Software Engineer WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 77 2273555 linked in: lk.linkedin.com/pub/shani-ranasinghe/34/111/ab ___ Architecture mailing list Architecture@wso2.org
Re: [Architecture] Automatic generation of WADLs for ESB REST Proxy Services
+1 to Swagger and use of annotations of APIs and REST services anywhere ( not just the ESB! ) - Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com - mobile (Spain) : +34 616050684 - mobile (Sri Lanka) +94 (0)774777663 On Jul 20, 2013, at 3:49 AM, Samisa Abeysinghe sam...@wso2.com wrote: On Sat, Jul 20, 2013 at 6:50 AM, Hasitha Hiranya hasit...@wso2.com wrote: Hi, As I read WSDL 2.0 enables REST. One problem is it is not widely adopted. The other is, if you are not using SOAP, it is overkill to use WSDL 2.0 just for REST - it is the http binding. On Sat, Jul 20, 2013 at 6:35 AM, Shelan Perera she...@wso2.com wrote: Hi, Yes. It can be used for client side as well as server side code gen too. thanks On Sat, Jul 20, 2013 at 6:21 AM, Samisa Abeysinghe sam...@wso2.com wrote: Can Swagger be used to autogen clients etc? On Fri, Jul 19, 2013 at 4:50 PM, Sumedha Rubasinghe sume...@wso2.com wrote: +1 for the functionality. But haven't seen that much of traction over WADL with most of the customers we have dealt with so far. Swagger (https://developers.helloreverb.com/swagger/) on the other hand is much more widely accepted IMO. WSO2 AM 1.4.0 has the initial integration done with Swagger. There are some usability improvements planned for future versions. On Fri, Jul 19, 2013 at 4:44 PM, Nirmal Fernando nir...@wso2.com wrote: WDYT of $subject? I think this would be a useful feature. -- Thanks regards, Nirmal Senior Software Engineer- Platform Technologies Team, WSO2 Inc. Mobile: +94715779733 Blog: http://nirmalfdo.blogspot.com/ -- /sumedha b : bit.ly/sumedha ___ 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 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Shelan Perera Senior Software Engineer Integration Technology Group WSO2, Inc. : wso2.com lean.enterprise.middleware. Blog : blog.shelan.org Linked-in : http://www.linkedin.com/pub/shelan-perera/a/194/465 Twitter :https://twitter.com/#!/shelan Mobile : +94 772 604 402 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Hasitha Abeykoon Software Engineer; WSO2, Inc.; http://wso2.com cell: +94 719363063 blog: abeykoon.blogspot.com ___ 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 ___ 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
Re: [Architecture] Supporting multiple environments for the API Gateway
Almost agree :) I think we have to make a distinction between sandbox and a lab environment to deploy a *preview* of an API - it's not ready to go, may be I will expose it to only a selected set of customers to be part of a beta program for example. It's not a 1.0, it's 0.8 - The main difference between sandbox and a labs envt, is that the versions deployed in sandbox and prod are the same. That is, since the versions on sandbox and prod are the same, promoting does not make sense. However promoting from labs to Sandbox/Prod does make sense. Lab env has no SLA, may be even no access keys, changes often and may break, does not have a rigid lifecycle, etc. a) Number of env must be configurable - Although internal name can be fixed (sandbox, prod, lab), needs to have a display name which can vary AND can be localized (in different languages) b) Maximum 3 envs (Labs, Sandbox, Prod). After that, I agree we are mixing managing the API lifecycle and Service lifecycle. c) No promotion from sandbox to prod - However I must be able to have only Sandbox available while production is getting ready d) Eventually, promotions from labs to sandbox/production. d) Labs env has different setup, fixed SLA (only silver), optional subscription, different forums attached, separate statistics if any. e) SLAs on sandbox and production are different f) statistics on sandbox are separated from production. In the config below, I don't understand why the API endpoint is inside the envt config. Isnt't this part of the API config as it is now ? Thanks, Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com - mobile (Spain) : +34 616050684 - mobile (Sri Lanka) +94 (0)774777663 On Jul 18, 2013, at 12:52 PM, Nuwan Dias nuw...@wso2.com wrote: We (Sumedha, Srinath, Azeez, Sanjiva and a few from the APIM-Team) had a meeting to discuss on $subject and we came to a conclusion to maintain production and sandbox environments only. The reason is that since we're talking about APIs and not about the actual implementation of it, it does not make much sense to have an API deployed on multiple environments. An API could either be in production or in sandbox. Whatever that is not production is considered to be sandbox. The concept of promoting from sandbox to production was also invalidated. If a given API has both production and sandbox endpoints, it will be deployed onto both environments at the time of publishing. If it has only one it will only be deployed onto the relevant environment. If the other endpoint is added later, it will be deployed onto that environment at that point. After the conclusions of the discussions, the environment configuration would be similar to the following. Environments Environment Typeproduction/Type ServerURLhttps://192.168.10.100:9443/services//ServerURL Usernameadmin/Username Passwordadmin/Password APIEndpointURLhttp://192.168.10.100:8280,https://192.168.10.100:8243/APIEndpointURL /Environment Environment Typesandbox/Type ServerURLhttps://192.168.20.100:9443/services//ServerURL Usernameadmin/Username Passwordadmin/Password APIEndpointURLhttp://192.168.20.100:8280,https://192.168.20.100:8243/APIEndpointURL /Environment /Environments Thanks, NuwanD. On Thu, Jul 18, 2013 at 8:43 AM, Nuwan Dias nuw...@wso2.com wrote: On Wed, Jul 17, 2013 at 5:56 PM, Samisa Abeysinghe sam...@wso2.com wrote: On Wed, Jul 17, 2013 at 5:30 PM, Nuwan Dias nuw...@wso2.com wrote: On Wed, Jul 17, 2013 at 5:14 PM, Samisa Abeysinghe sam...@wso2.com wrote: Is the design such that, if we want more than 2 environments, that can be facilitated? Yes, this can be facilitated. Where would that config go? Also, ideally, want to be able to use my own names in my setup rather than sandbox/prod say staging/live Yes, that's the idea. These names will be displayed on the Store when listing the environments. The config would reside in the api-manager.xml. Although you can have multiple environments those will have to be categorized into two main types (production and sandbox) since we only support two key-types. I haven't thoroughly thought about the xml config but I'm guessing it would be similar to the following. Environments environment nameLive/name typeproduction/type deployByDefaultfalse/deployByDefault ServerURLhttps://192.168.10.100:9443/services//ServerURL Usernameadmin/Username Passwordadmin/Password APIEndpointURLhttp://192.168.10.100:8280,https://192.168.10.100:8243/APIEndpointURL /environment environment nameStaging/name typeproduction/type
Re: [Architecture] ESB Cloud Connectors
All connection information needs to be stored outside of the config , potentially in a security vault, same as userid/passwords. I think we need a connector security config, which can be also changed from one environment (dev, QA, etc.) to another. Also, for all connectors who require OAuth for authentication , I think we need a common authentication module which manages access/refresh tokens , and can be used dynamically from a sequence/proxy. Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Jul 16, 2013, at 7:37 AM, Kasun Indrasiri ka...@wso2.com wrote: As we have all the core level improvements done to cater the requirements of cloud connectors, we have started the implementation of the connectors. So as the first milestone, we are planning to have Salesforce (basic impl) and Google SpredSheet connectors and implement an integration scenarios out of those connectors. Also for the first milestone, we will include the twitter connector as well. The plan is to ship connectors with ESB 4.9 along with tooling support from DevS. The set of connectors planned for this are Salesforce, Google Spread Sheet, Twitter, Jira and Twilio. Some of the sample configs from the twitter connector with its dynamic synapse configs : proxy name=SearchPlacesTwitter transports=https http startOnLoad=true trace=disable description/ target inSequence log/ twitter.search_places parameter name=oauth.consumerSecret value=xxx/ parameter name=oauth.accessTokenSecret value=xx/ parameter name=oauth.accessToken value=x-x/ parameter name=oauth.consumerKey value=x/ parameter name=latitude value=40.71435/ parameter name=longitude value=-74.00597/ /twitter.search_places header name=To action=remove/ property name=NO_ENTITY_BODY scope=axis2 action=remove/ property name=RESPONSE value=true scope=default type=STRING/ send/ /inSequence /target /proxy proxy name=getUserTimeLine transports=https http startOnLoad=true trace=disable description/ target inSequence log/ twitter.get_user_timeline parameter name=oauth.consumerSecret value=xx/ parameter name=oauth.accessTokenSecret value=xx/ parameter name=oauth.accessToken value=x-x/ parameter name=oauth.consumerKey value=xx/ /twitter.get_user_timeline header name=To action=remove/ property name=NO_ENTITY_BODY scope=axis2 action=remove/ property name=RESPONSE value=true scope=default type=STRING/ send/ /inSequence /target /proxy -- Forwarded message -- From: Kasun Indrasiri ka...@wso2.com Date: Fri, May 17, 2013 at 1:31 PM Subject: Synapse Dynamic configuration for Cloud Connectors To: architecture architecture@wso2.org, DEV d...@wso2.org Cc: Sanjiva Weerawarana sanj...@wso2.com, Paul Fremantle p...@wso2.com, Samisa Abeysinghe sam...@wso2.com, Azeez Afkham az...@wso2.com, Isabelle Mauny isabe...@wso2.com, Miyuru Wanninayaka miy...@wso2.com, Dushan Abeyruwan dus...@wso2.com, Harshana Martin harsh...@wso2.com, Srinath Perera srin...@wso2.com Hi, As per the discussions we had on the Cloud Connector implementation in ESB, initially we came up with a model where we have a connector element for each connector invocation. That was mainly due to the limitations of Synapse because of Synapse doesn't support dynamic config at that time. Having a dynamic generation of config based each connector is having so many advantages over the fixed connector config approach. So, we have modified synapse such that it can load dynamic configuration, iff a mapping template is defined as a mediation-library and imported in to the synapse config. There were few areas that we have to change to carter this requirement. - Initial sequence/mediator deployment during start-up. (Look for imports and resolve the dyn - Hot deployment of artifacts - Synapse library and import apis. In summary, the way how it works is: - Connector is implemented as a mediation library along with all the required templates and class mediators (or any other resource). Refer : wso2_twitter.zip - Once the connector (mediation lib) is deployed in the ESB, then the uses can import it with the use of synapse imports which will be applied globally for the synapse config
Re: [Architecture] APIM Subscription Blocking - allow blocking Production access only
+1 - This implies to have different SLAs applied at Prod and Sandbox though, as discussed earlier. Isabelle. -- Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com isabe...@wso2.com - mobile: +34 616050684 On Fri, Jul 5, 2013 at 10:17 AM, Paul Fremantle p...@wso2.com wrote: Agreed. We also need to support having ONLY a sandbox and no production endpoint for beta or early access to new APIs. Paul On 5 July 2013 08:22, Lakmali Baminiwatta lakm...@wso2.com wrote: Hi all, In API Manager, the API creator can block a particular subscription on an API to disable access to it until s/he decides to unblock it again. With this blocking, both production and sandox invocations with that subscription is blocked. But there can be situations where there is a broken app. Then while fixing it, access to sandbox is needed to test the subscription. Therefore this improvement is suggested to block only the production access. Currently in APIM we keep Subscription Status (SUB_STATUS) for a subscription, which is set as BLOCKED once the subscription is blocked. Then in an API call, while doing the key validation it checks the SUB_STATUS for the subscription related to that key and blocks the call if it was in BLOCKED state. So what we can do here is, do the blocking if the Key Type is Production only. Any concerns, thoughts are welcome. Thanks, Lakmali -- Lakmali Baminiwatta* * Software Engineer WSO2, Inc.: http://wso2.com lean.enterprise.middleware mobile: +94 71 2335936 blog : lakmali.com * * -- Paul Fremantle CTO and Co-Founder, WSO2 OASIS WS-RX TC Co-chair, VP, Apache Synapse 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 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Issue in App subscription and Key generation with API Manager in AppFactory
+1 - also, only the App owner should be in the subscriber role. SSO needs to work for the AppOwner though. Isabelle. __ Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ On Jun 14, 2013, at 6:53 PM, Ajanthan Balachandran ajant...@wso2.com wrote: On Fri, Jun 14, 2013 at 10:14 PM, Punnadi Gunarathna punn...@wso2.com wrote: Hi All, We have identified $subject and the scenario is as follows: AppOwner creates an Application called App1 in App Factory. He loggs-in to API Manger and subscript App1 with API1 and generate key pairs. He also invite few developers for App1. Based on the current implementation, any other developer who will login to App Factory will not be able to see the previous subscription or already generated keys and also since sso is enabled at API Manager front, they can subscribe the same application individually again with the API1 and generate new keys. But as per the requirement there should be only a single set of keys generated for sandbox and production separately for a particular application (It is true that we can regenerate keys and it is accepted). But with the above scenario, each person can generate different key sets for same application and this will be a hassle in terms of usage. As we discussed with Sumedha, API Manager currently does not support group wise key generation. Therefore we have come up with a below strategy to prevent each user from creating separate keys for the same application over and over again. That is, Only the AppOwner will have the privilege to subscribe to an API and re/generate keys with API Manager. The generated keys will be saved in DB and when other users (dev,qa,devops) login, they can only see the generated keys. We will also make SSO disabled and no buttons will be available in UI to go to API Manager for these user roles. If SSO is disabled(API store) how the appowner is going to login and subscribe to API(manually entering the credential again)? Feel free to share your feedback. -- Thanks and Regards, Punnadi Gunarathna Senior Software Engineer, WSO2, Inc.; http://wso2.com email: punn...@wso2.com ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- ajanthan -- Ajanthan Balachandiran Senior Software Engineer; Solutions Technologies Team ;WSO2, Inc.; http://wso2.com/ email: ajant...@wso2.com; cell: +94775581497 blog: http://bkayts.blogspot.com/ Lean . Enterprise . Middleware ___ 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
Re: [Architecture] Using CEP to support Throttling
How will this work in a cluster ? Throttling decisions are typically taken using cluster-wide data ( such as 50 reqs for this API, no matter how many gateways are running ) . Isabelle. -- Isabelle Mauny Director, Product Management; WSO2, Inc.; http://wso2.com/ email: isabe...@wso2.com isabe...@wso2.com - mobile: +34 616050684 On Thu, Jun 6, 2013 at 7:04 PM, Paul Fremantle p...@wso2.com wrote: Nuwan Siddhi is just a Java library, so this can be embedded. Paul On 6 June 2013 17:52, Nuwan Dias nuw...@wso2.com wrote: On Thu, Jun 6, 2013 at 3:28 PM, Sriskandarajah Suhothayan s...@wso2.comwrote: On Thu, Jun 6, 2013 at 3:10 PM, Vijayaratha Vijayasingam rat...@wso2.com wrote: Hi; APIM team has different kind of throttling+rate limiting requirements (eg:ip/timer/geo based)..As Srinath pointed we believe that CEP would be the right solution, since we cannot have all these different scenarios/requirements to be implemented in our throttling module.. Is there any possibility integrate CEP engine with our throttling module ? Yes this is possible Currently you can use Siddhi directly to achieve this. In this case you have to pass all the events the trigger throttling directly to Siddhi and, when a matching throttling condition reached CEP will fire an output back to APIM so that it can take action based on the CEP's response. How feasible is it to run Siddhi as an embedded engine within APIM? I am thinking along the lines of avoiding an additional hop between the API Gateway and CEP. Is it also possible to persist the throttling information to a database? Probably not on every request but batch by batch With CEP 3.0.0 we are writing an Event Processor component( as of mail thread CEP 3.0 towards a Complete eventing solution to the platform), when that is done you will also be able to provide a proper UI for the users to edit Siddhi throttling queries So, all products can still use throttling module, which can handle all the complex rate/thorrtling policies.. +1 Suho Thanks On 5 June 2013 15:13, Sriskandarajah Suhothayan s...@wso2.com wrote: On Wed, Jun 5, 2013 at 1:27 AM, Srinath Perera srin...@wso2.comwrote: Hi All, Currently we have a java based throttling solution. But we need that to extended (e.g. support throughput based throttling), and support more complicated condition that currently parameterized. IMO, best way to do this is to support this by integrating CEP (Siddhi) engine directly at java level. It is very light weight . We can let users provide CEP queries which will control throttling. Basically, there will be inbuilt event stream definitions, and Siddhi listener that monitors a given event stream and adjust event acceptance. Users provide CEP queries. I think it is too heavy publish events via thrift API if we try to send it via the network. WDYT? +1 CEP team can provide the necessary support if any of the product teams (eg: ELB, BPS, AF or AM) is willing to replace their current or have an alternate throttling module Suho --Srinath -- Srinath Perera, Ph.D. Director, Research, WSO2 Inc. Visiting Faculty, University of Moratuwa Member, Apache Software Foundation Research Scientist, Lanka Software Foundation Blog: http://srinathsview.blogspot.com/ Photos: http://www.flickr.com/photos/hemapani/ Phone: 0772360902 -- *S. Suhothayan * Software Engineer, Management Committee Member, Data Technologies Team, *WSO2 Inc. *http://wso2.com * http://wso2.com/* lean . enterprise . middleware *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ twitter: http://twitter.com/suhothayan | linked-in: http://lk.linkedin.com/in/suhothayan* * * ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- -Ratha mobile: (+94)755906608 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *S. Suhothayan * Associate Technical Lead, Management Committee Member, Data Technologies Team, *WSO2 Inc. *http://wso2.com * http://wso2.com/* lean . enterprise . middleware *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ twitter: http://twitter.com/suhothayan | linked-in: http://lk.linkedin.com/in/suhothayan* * * ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Nuwan Dias Senior Software Engineer - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Paul Fremantle CTO and Co-Founder
Re: [Architecture] G-Reg Lifecycle, BPEL Integration
+1 on making this generic - The example below seems to imply that a customer
can call any service ?? I thought we were to provide an interface to implement
(in the Java sense) and a proper WSDL / WADL for that service. i.e define the
parameters that will be passed to the service and the format of the response
coming back .
You also need some kind of timeout mechanism - i.e. how long will you wait
before deciding that the transition process is stuck and has failed.
Also, what is the logic for actually executing the transition or not ? Is this
something I need to put in the response ? Are you checking an HTTP return code
?
Last this is very SOAP focused. Why can't I call a REST service ?
Isabelle.
__
Isabelle Mauny
Director, Product Management; WSO2, Inc.; http://wso2.com/
email: isabe...@wso2.com - mobile (Spain) : +34 616050684 - mobile (Sri Lanka)
+94 (0)774777663
On Jun 4, 2013, at 3:52 PM, Pulasthi Supun pulas...@wso2.com wrote:
Hi All,
Did a few changes based on the feedback provided.
1. Changed BpelExecutor to WSExecutor
2. each {@somename} will be replaced by checking if there is an attribute or
and property by this name priority will be given to attributes
2. The new configuration looks as follows
execution forEvent=Promote
class=org.wso2.carbon.governance.registry.extensions.executors.WSExecutor
parameter name=async value=false /
parameter name=response.destination
value=/_system/governance/apimgt/applicationdata/provider/a/aaa/1.0.0/api
/
parameter name=save.type value=attribute /
parameter name=save.name value=wsresponse /
parameter name=response.xpath value=//as:result /
parameter name=response.namespace value=http://wso2.org/bps/sample;
/
parameter name=response.namespace.prefix value=as /
parameter name=epr
value=http://{@hsost}:{@port}/services/AdderProcess.AdderProcesshttpAdderProcessBindingEndpoint/;
/
parameter name=payload
p:AdderProcessRequest xmlns:p=http://wso2.org/bps/sample;
!--Exactly 1 occurrence --
x xmlns=http://wso2.org/bps/sample;{@xvalue}/x
!--Exactly 1 occurrence --
y xmlns=http://wso2.org/bps/sample;{@yvalue}/y
/p:AdderProcessRequest
/parameter
/execution
Required parameters
epr - End Point Reference of the
payload - The Payload that needed to invoke the
Optional parameters
async - Define whether the BPEL process to be called in an synchronous or
asynchronous manner by default synchronous approach is used
In the asynchronous mode no response will be saved ( Default -
synchronous )
response.destination - defines the path of the resource to which the response
will be saved ( Default - The current resource path )
save.type - defines whether the response is to be saved as an property or
attribute ( Default - attribute)
save.name - defines the name of the property of attribute that response is
saved to ( Default - respnose)
response.xpath - defines the xpath that is to be used to extract an value
from the response xml ( Default - if not provided the whole response xml will
be saved as an string )
response.namespace - namespace of the response
response.namespace.prefix - namespace prefix used in the xpath
Regards,
Pulasthi
On Sat, Jun 1, 2013 at 9:41 PM, Pulasthi Supun pulas...@wso2.com wrote:
Hi All
I also agree with Janaka , this was started off with the aim to allow BPEL
processes to be called during an lifecycle transition hence it was initially
treated as an BPEL Integration.So it would be appropriate to rename this as
web service executor since the design is already capable of invoking any web
service.
Regarding Eranda's question.
What you mean by a response of a business process? Can you please give an
example use case for a process sending a response.
BPEL is exposed as a web services so as in normal web service BPEL processes
may reply back with an response.
Thanks,
Pulasthi
On Sat, Jun 1, 2013 at 2:37 AM, Senaka Fernando sen...@wso2.com wrote:
Hi Eranda,
I agree with Janaka. A process that we invoke from an executor need not
always be a BPEL, it can actually be any endpoint. If it happens to be a BPEL
process, we can provide some specific interfaces (if required later on), but
right now - I mean at this level - everything Pulasthi mentioned is generic
for both BPEL and any regular WS. Therefore, we should not be having the word
BPEL in these sample configurations.
Thanks,
Senaka.
On Sat, Jun 1, 2013 at 2:23 AM, Eranda Sooriyabandara era...@wso2.com wrote:
Hi Janaka,
On Sat, Jun 1, 2013 at 2:04 AM, Janaka Ranabahu jan...@wso2.com wrote:
Hi Pulasthi, Senaka,
Why are we saying BPEL Integration? BPEL process is also exposed
