date:20150425

Re: [Architecture] Generic workflow executor across the platform

2015-04-25 Thread Frank Leymann

Dear Pulasthi,

having a way to define simple BPEL processes in a form-based manner would
be great!  Do you have some details on this?


Best regards,
Frank

2015-04-20 8:42 GMT+02:00 Pulasthi Mahawithana :

> Hi Frank,
>
> We thought of having a simple form based approach at user end. We will use
> some BPELs as templates and get the inputs from a form to customize it.
>
> On Sat, Apr 11, 2015 at 8:02 PM, Frank Leymann  wrote:
>
>> Hi Pulasthi,
>>
>> when you have "users without BPEL knowledge" in mind, you assume that
>> these users have programming skills, correct?  I.e. that they provide the
>> "workflow process" in JavaScript, for example, correct?
>>
>> Or do you work on a new very easy-to-use workflow language?
>>
>>
>> Best regards,
>> Frank
>>
>> 2015-04-04 14:40 GMT+02:00 Pulasthi Mahawithana :
>>
>>> Hi Frank,
>>>
>>> I sent a separate mail[1] with the architecture. Our main objective was
>>> to provide the workflow support for the events in IS and [1] was designed
>>> to address that. Furthermore we plan to provide a way to easily configure a
>>> workflow process and deploy it at BPS (for the users without BPEL
>>> knowlege). The work for that is in progress and we will update with the
>>> details soon.
>>>
>>> [1] [Architecture] Generic workflow support
>>>
>>> On Thu, Apr 2, 2015 at 8:31 PM, Frank Leymann  wrote:
>>>
 Hi Pulasthi, hi Tanja,

 can you provide a consolidated architecture figure, please?  Can you
 also position in your architecture BPS?  I assume the requirements you
 address by your architecture is the ability to create an "on-ramp workflow"
 for ES, AM,... in a "fast" way, correct?

 Thanks!


 Best regards,
 Frank

 2015-04-02 12:54 GMT+02:00 Pulasthi Mahawithana :

> Hi Tanya,
>
> The actual architecture is bit different from the one you mentioned
> here (I'll send a separate mail with details). The executors are
> responsible only for executing workflow in some manner (can be BPEL, Web
> Service or even some java code), and they can be registered as OSGI
> services. The persisting is done by the WorkflowManager before calling the
> executor.
>
> The WorkflowRequestHandler is the one responsible for creating
> workflow requests for an event, and handling the callback for the same
> event. So, what you said can be achieved at this point by customizing the
> workflow request creation (persist somewhere and provide link in workflow
> request). Since you create asset disabled and enable it after workflow
> completion it will work. However there are some events where we have to
> wait till the workflow completion to perform the actual action. That was
> the reason to persist the request. Also note that all workflow parameters
> are not set to the workflow executor. We can filter out parameters that
> won't be needed at workflow (I will send those details in a separate 
> mail).
>
>
>
>
> On Thu, Apr 2, 2015 at 3:26 PM, Tanya Madurapperuma 
> wrote:
>
>> Hi Johann and all,
>>
>> As per the offline chat with Pulasthi, the executor serialize the
>> workflow info and save in the database before calling the bpel service.
>> (see the diagram below)
>>
>>
>> So in our case if we are to use this component, we will have to do a
>> network call with all the information for the workflow request (might
>> include large files such as images and videos etc as admin needs to 
>> approve
>> them)
>> Also at the call back we have to resend the same info back.
>>
>> We thought it would be more convienient and performance friendly, if
>> we persist those information at our end and provide an endpoint where the
>> admin can access all the information.
>>
>> For an example, say asset creation process.
>> Once the user fills the asset creation form, we will persist that
>> info in a database with a flag so that it won't be visible in the store 
>> to
>> the other users. And when triggering the workflow we send an endpoint 
>> with
>> a token and admin can view the created asset info with that endpoint. 
>> Admin
>> will be redirected to store to display the newly created (pending) asset.
>> With that we don't need to worry about sending/rendering images at the
>> workflow admin application.
>>
>> WDYT?
>>
>> Thanks,
>> Tanya
>>
>> On Wed, Apr 1, 2015 at 10:20 AM, Tanya Madurapperuma 
>> wrote:
>>
>>> Hi Johann,
>>>
>>> Thanks for the response.
>>> IMO it is better if we can make the WorkflowRequestDAO more generic
>>> where we can plug any storing mechanism. WDYT?
>>>
>>> Thanks,
>>> Tanya
>>>
>>> On Tue, Mar 31, 2015 at 5:29 PM, Johann Nallathamby >> > wrote:
>>>
 Hi Tanya,

 On Tue, Mar 31, 2015 at 4:59 PM, Tanya

Re: [Architecture] Operations Center RestAPI

2015-04-25 Thread Frank Leymann

Dear Chaya,

I have to apologize for not responding for such a long time...

In case you have a bit more information about your APIs for me, I could
comment more meaningful. E.g. when to use which header, how to structure
URLs etc.

As an initial comment, using PUT to execute commands is not really RESTful:
you should use POST. The reason for this is that PUT is considered
idempotent, i.e. you can perform the same PUT many times, always producing
the same result. I suspect that this is not the case in your scenario, i.e.
if you use the same PUT to execute a command a second time, there is no
guarantee that the command produces exactly the same results than before.
Furthermore, PUT is usually used to update a resource (sometime for
creating a resource).

Also, we (API Man team, ES team, self) are currently discussing versioning.
I suggest that you join this discussion so that we all follow the same
approach for versioning.


Best regards,
Frank

2015-03-18 13:14 GMT+01:00 Chaya Sandamali :

> Dear Frank,
>
> With OC portal[1] you can view the topology of the cluster .
> (admin/admin). We have currently following URIs with external API.
>
> GET
>
>- [2] - view all cluster data
>- [3] - view details of a specific cluster
>- [4] - view all server data of a specific cluster
>- [5] - view specific sever details
>
> PUT
>
>- [6] -execute cluster wide commands
>- [7]- execute commands on a specific server
>
>
> [1] http://192.168.57.22:9763/sso/login.jag
> [2]
> http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/
> [3]
> http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}
> [4]
> http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/nodes
> [5]
> http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/nodes/{nodes-id}
> [6]
> http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/commands/{command-id}
> [7]
> http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/nodes/{node-id}/commands/{command-id}
>
> Thank you.
>
> Regards,
> Chaya
>
> Chaya Sandamali
> Software Engineering Intern
> WSo2 Inc
> Mobile: +94714905772
> LinkedIn: http://lk.linkedin.com/pub/chaya-sandamali/90/694/a59/
>
> On Wed, Mar 18, 2015 at 4:48 PM, Frank Leymann  wrote:
>
>> Dear Chaya,
>>
>> is there a pointer to the REST API?  I would be interested in its URIs,
>> HTTP methods used on each URI, header fields supported, status codes
>> returned...
>>
>> Thanks!
>>
>>
>> Best regards,
>> Frank
>>
>> 2015-03-18 9:28 GMT+01:00 Chaya Sandamali :
>>
>>> Hi all,
>>>
>>> After the last review,we came up with a data model for the API. I have
>>> attached an initial model of the design and currently the OperationsCenter
>>> Rest API is implemented with this new model and following are the new
>>> improvements in internal API part.
>>>
>>> Execute restart command as a cluster wide operation in *round-robin *
>>> fashion.
>>>
>>>- GRACEFUL_RESTART
>>>- FORCE_RESTART
>>>
>>> Execute shut down command on the cluster
>>>
>>>- GRACEFUL_SHUTDOWN
>>>- FORCE_SHUTDOWN
>>>
>>> Thank you.
>>>
>>> Regards,
>>> Chaya
>>>
>>> Chaya Sandamali
>>> Software Engineering Intern
>>> WSo2 Inc
>>> Mobile: +94714905772
>>> LinkedIn: http://lk.linkedin.com/pub/chaya-sandamali/90/694/a59/
>>>
>>>

>>>
>>> ___
>>> 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
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 API Manager 1.9.0 Alpha Released!

2015-04-25 Thread Lakmali Baminiwatta

WSO2 API Manager 1.9.0 Alpha Released!

WSO2 API Manager team is pleased to announce the Alpha release of WSO2 API
Manager 1.9.0.
This release includes following features,improvements and bug fixes.
Bug

   - [APIMANAGER-2138 ] - API
   Docs - Issues with updating /adding new documents
   - [APIMANAGER-2653 ] - [AM
   stats] API_REQUEST_SUMMARY stat event ,apiPublisher has to be include
   username of API publisher
   - [APIMANAGER-2703 ] -
   Blank drop down menu and wrong caption in the absence of tier permission
   for the logged in user
   - [APIMANAGER-2890 ] - API
   Manager- setting defaultAutoCommit property when using postgresql
   - [APIMANAGER-2946 ] - API
   provider inconsistent in external store
   - [APIMANAGER-3119 ] -
   Intermittent: Throws an error when updating store after publishing APIs
   from publisher
   - [APIMANAGER-3129 ] - API
   Store view by tag issue
   - [APIMANAGER-3139 ] -
   Exception when logging into admin-dashboard when BPS is not configured
   - [APIMANAGER-3164 ] -
   When changing endpoint from 'WSDL Endpoint' to 'HTTP Endpoint' WSDL
   resource not getting removed
   - [APIMANAGER-3212 ] - API
   Manager chunk14 -RC5 Error occurs when adding a document having a special
   character for document name
   - [APIMANAGER-3232 ] - API
   Publisher Statistics Page Show Continuous Loading like view
   - [APIMANAGER-3239 ] -
   Gramatical error in the Implement panel in publisher
   - [APIMANAGER-3280 ] - Per
   API forum has dissappeared in 1.8.0
   - [APIMANAGER-3310 ] -
   Password fields in Store signup requires length validation
   - [APIMANAGER-3332 ] -
   Can't Publish APIs to WSO2 External API Stores when API's implementation is
   "Specify Inline"
   - [APIMANAGER-3335 ] -
   [Publisher API] Issue creating API without visibility
   - [APIMANAGER-3376 ] -
   APIM creates duplicate scope entries in database when same scope applied
   for multiple resources.
   - [APIMANAGER-3391 ] -
   APIScopeTestCase Failure
   - [APIMANAGER-3406 ] -
   Throttle Policy Enforcement with new Tokens
   - [APIMANAGER-3407 ] - API
   version is showed twice in API edit mode of Implement and Manage pages
   - [APIMANAGER-3409 ] - API
   gets created with sequence 'none' when Sequences is selected with default
   values
   - [APIMANAGER-3414 ] -
   'None' auth type is set for newly added resources
   - [APIMANAGER-3416 ] -
   Certificate error verifying Thrift connection
   - [APIMANAGER-3423 ] - API
   Publisher - API document remains on the screen after deleted when document
   name contains special characters
   - [APIMANAGER-3427 ] - API
   Manager - Design API page takes more then 10 sec to switch between entry
   fields
   - [APIMANAGER-3428 ] -
   Repeat subscriptions APIM
   - [APIMANAGER-3430 ] -
   PageView Count in GA reporting is not accurate.
   - [APIMANAGER-3434 ] -
   Errors are displayed when browsing API Console in Store
   - [APIMANAGER-3436 ] -
   Failing to specify a throttling tier causes the api to not publish correctly
   - [APIMANAGER-3437 ] -
   error when addding an API
   - [APIMANAGER-3449 ] -
   Merge https://wso2.org/jira/browse/ESBJAVA-3137 fixes
   - [APIMANAGER-3460 ] - API
   subscription statistics doesn't get updated until user invokes the
   particular API for the for the first time.

Improvement

   - [APIMANAGER-1704 ] - Do
   we need to expose OPTIONS request in the UI?
   - [APIMANAGER-1740 ] -
   Documentatoin l

Re: [Architecture] Operations Center RestAPI

2015-04-25 Thread Frank Leymann

Hi Nirmal,

I agree that the path is somehow redundant. We should agree cross products
on the structure of our APIs.

What about the following prefix (i.e. after the context string) to each our
our APIs:
   /wso2-api/{product-code}



Best regards,
Frank

2015-03-18 13:36 GMT+01:00 Nirmal Fernando :

> Hi Chaya,
>
> Do we really need OCServer/services/oc-server/external/
>  
> part
> in the URL? In a RESTFull API, every such path element should represent a
> resource and also should be nouns.
>
> You can use the /api as the root context, it's how GitHub API designed too.
>
> I suggest /api/clusters instead of /
> OCServer/services/oc-server/external/oc/clusters/
> 
>
>
> On Wed, Mar 18, 2015 at 5:44 PM, Chaya Sandamali  wrote:
>
>> Dear Frank,
>>
>> With OC portal[1] you can view the topology of the cluster .
>> (admin/admin). We have currently following URIs with external API.
>>
>> GET
>>
>>- [2] - view all cluster data
>>- [3] - view details of a specific cluster
>>- [4] - view all server data of a specific cluster
>>- [5] - view specific sever details
>>
>> PUT
>>
>>- [6] -execute cluster wide commands
>>- [7]- execute commands on a specific server
>>
>>
>> [1] http://192.168.57.22:9763/sso/login.jag
>> [2]
>> http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/
>> [3]
>> http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}
>> [4]
>> http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/nodes
>> [5]
>> http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/nodes/{nodes-id}
>> [6]
>> http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/commands/{command-id}
>> [7]
>> http://192.168.57.22:9783/OCServer/services/oc-server/external/oc/clusters/{cluster-id}/nodes/{node-id}/commands/{command-id}
>>
>> Thank you.
>>
>> Regards,
>> Chaya
>>
>> Chaya Sandamali
>> Software Engineering Intern
>> WSo2 Inc
>> Mobile: +94714905772
>> LinkedIn: http://lk.linkedin.com/pub/chaya-sandamali/90/694/a59/
>>
>> On Wed, Mar 18, 2015 at 4:48 PM, Frank Leymann  wrote:
>>
>>> Dear Chaya,
>>>
>>> is there a pointer to the REST API?  I would be interested in its URIs,
>>> HTTP methods used on each URI, header fields supported, status codes
>>> returned...
>>>
>>> Thanks!
>>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> 2015-03-18 9:28 GMT+01:00 Chaya Sandamali :
>>>
 Hi all,

 After the last review,we came up with a data model for the API. I have
 attached an initial model of the design and currently the OperationsCenter
 Rest API is implemented with this new model and following are the new
 improvements in internal API part.

 Execute restart command as a cluster wide operation in *round-robin *
 fashion.

- GRACEFUL_RESTART
- FORCE_RESTART

 Execute shut down command on the cluster

- GRACEFUL_SHUTDOWN
- FORCE_SHUTDOWN

 Thank you.

 Regards,
 Chaya

 Chaya Sandamali
 Software Engineering Intern
 WSo2 Inc
 Mobile: +94714905772
 LinkedIn: http://lk.linkedin.com/pub/chaya-sandamali/90/694/a59/


>

 ___
 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
>>
>>
>
>
> --
>
> Thanks & regards,
> Nirmal
>
> Senior Software Engineer- Platform Technologies Team, WSO2 Inc.
> Mobile: +94715779733
> Blog: http://nirmalfdo.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] [Dev] WSO2 Message Broker 3.0.0 Milestone 7 Released !

2015-04-25 Thread Dushan Abeyruwan

Hi
 Something wrong with milestone release note, should include Improvements
done, bug fixes inline rather providing link, please go with standard
template we have
  Please refer other product's milestone releases.

Cheers,
Dushan

On Wed, Apr 22, 2015 at 4:30 AM, Pumudu Ruhunage  wrote:

> *WSO2 Message Broker 3.0.0 Milestone 7 Released !*
>
>
> The WSO2 Message Broker team is pleased to announce the 7th milestone
> release of WSO2 Message Broker (MB)  3.0.0.
>
> WSO2 Message Broker (WSO2 MB) 3.0.0 is designed to be a fast, lightweight
> and user friendly open source distributed message brokering system under
> the Apache Software License v2.0
> . It primarily allows
> system administrators and developers to easily configure JMS queues and
> topics which could be used for message routing, message stores and message
> processors.
>
> WSO2 MB is compliant with Advanced Message Queuing Protocol Version 0-9-1,
> Java Message Service Specification version 1.1 and MQTT protocol version
> 3.1. WSO2 MB 3.0.0 is developed on top of the revolutionary WSO2 Carbon
> platform  (Middleware a' la carte), an
> OSGi based framework that provides seamless modularity to your SOA via
> modularization. This release also contains many other new features and a
> range of optional components (add-ons) that can be installed to customize
> the behavior of the MB. Further, any existing features of the MB which are
> not required to your environment can be easily removed using the underlying
> provisioning framework of Carbon. In a nutshell, WSO2 MB can be fully
> customized and tailored to meet your exact SOA needs.
>
> You can download this distribution from [1].
>
> Release notes for this milestone can be found at [2].
>
> Known issues are listed at [3].
>
> This milestone has mainly focused on bug fixes and
> performance improvements.
> How You Can Contribute:Mailing Lists
>
> Join our mailing list and correspond with the developers directly.
>
>-
>
>Developer List : d...@wso2.org | Subscribe | Mail Archive
>
>-
>
>User List : StackOverflow.com
>
>
> Reporting Issues
>
> WSO2 encourages you to report issues and your enhancement requests for the 
> WSO2
> MB using the public JIRA .
>
> You can also watch how they are resolved, and comment on the progress..
>
>
> [1]
> https://svn.wso2.org/repos/wso2/scratch/MB/3.0.0/M7/wso2mb-3.0.0-SNAPSHOT-m7.zip
> 
>
> [2]
> https://wso2.org/jira/secure/ReleaseNote.jspa?projectId=10200&version=11766
> 
>
> [3]
> https://wso2.org/jira/browse/MB#selectedTab=com.atlassian.jira.plugin.system.project%3Aissues-panel
>
>
> --
> Pumudu Ruhunage
> Associate Software Engineer | WSO2 Inc
> M: +94 779 664493  | http://wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Dushan Abeyruwan | Technical Lead
Technical Support-Bloomington US
PMC Member Apache Synpase
WSO2 Inc. http://wso2.com/
Blog:http://dushansview.blogspot.com/
Mobile:(001)812-391-7441
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Generic workflow executor across the platform

Re: [Architecture] Operations Center RestAPI

[Architecture] WSO2 API Manager 1.9.0 Alpha Released!

Re: [Architecture] Operations Center RestAPI

Re: [Architecture] [Dev] WSO2 Message Broker 3.0.0 Milestone 7 Released !

5 matches

Site Navigation

Mail list logo

Footer information