Wednesday, August 24, 2011

What we can Thottle in WSO2 Stratos(1.5.1 Release) Cloud Environment - Tomcat server Based throttling

What we can Throttle in WSO2 Stratos(1.5.1 Release) Cloud Environment - Tomcat server Based throttling
In wso2 stratos throttling we will be able to throttle few parameters related to service and bandwidth usages. In this post i will briefly describe the parameters that we can throttle with wso2 stratos 1.5.1 release.


01. Registry Resource Volume
    For Registry usages we will be able to throttle following parameters
     Registry incoming data actions - put/ importResource/ restore
     Registry outgoing data actions - dump/ get
02. Service Bandwidth
     Throttle the service incoming and out going message sizes to the  Web Services(Axis2 Service/  JAX-WS Service/ Jar Service/ Jar Service) hosted at wso2 Stratos
     Application Server.For each incoming and outgoing messages throttling agent check whether that tenant is exceeded incoming and outgoing bandwidths. then only that allow users to invoke services.We can use two parameters(incoming/ outgoing) related to service bandwidth for throttling rules. For this throttling agent use Handler extended from AbstractHandler and that handler act as a listener for service invocations.
     Service incoming action
     Service outgoing action
03. webApp bandwidth
     Throttle the service incoming and out going based on message sizes to the Web Application Archive (.war) files hosted in Application server.For this webApp throttling we use valve extended from CarbonTomcatValve.That valve act as a listener and check whether tenant allow it or not. Here we can use two parameters(incoming/ outgoing) related to webApp bandwidth for throttling rules.
     webApp incoming action
     webApp outgoing action
04. User Count
     Number of users per given tenant.


So all together we will be able to throttle 7 actions as follows for given tenant.
01. Registry incoming data actions - put/ importResource/ restore
02. Registry outgoing data actions - dump/ get
03. Service incoming action
04. Service outgoing action
05. webApp incoming action
06. webApp outgoing action
07. User count per tenant

See original post

Usage metering and throttling in cloud computing - introduction for Users/Developers

Here in this post i will describe how to use usage metering and throttling in cloud environment. For this post i will use WSO2 stratos which is a complete Platform-as-a-Service for private and public clouds. Lets see how we do usage metering and throttling in stratos.

What is WSO2 Stratos ?

WSO2 Stratos is a complete SOA and developer platform offered as a self-service, multi-tenant, elastic runtime for private and public cloud infrastructures. What that means is that our complete SOA platform - now enhanced with Tomcat and Webapp support - is available as a  "cloud native" runtime that you can either use on the Web (yes - you can try it out right now), on Amazon VPC, or on your own internal private cloud based on Ubuntu Enterprise Cloud, Eucalyptus and (coming soon) vmWare vSphere. It is a complete Platform-as-a-Service for private and public clouds.

Download stratos source and more documents available at http://wso2.org/library/stratos

Post on how to build stratos 1.5.1 source available at

http://sanjeewamalalgoda.blogspot.com/2011/08/how-to-build-wso2-stratos-151-from.html

Sign up for a free account at  stratos private cloud https://stratoslive.wso2.com

What is Tenant ?

In stratos we used term tenant. What is tenant? it’s like an organization (sanjeewa.com) and it may few users (like departments within organization). There is administrator for each tenant and others are users. Administrator can allow users to use services and he is the person who governs the entire system for tenant. See following diagram for understanding tenant.

Tenant

Figure: Tenant and its users

Why we need Usage and Throttling ?

WSO2 stratos throttling component is the only one tomcat server based throttling module. And WSO2 Stratos 1.5.1 provides many new features like metering throttling and billing. So with WSO2 Stratos you will be able to measure, throttle and bill the server usage. Its really important to have reliable billing/ throttling model for cooperate service providers. Stratos 1.5.1 provides complete solution for web services with pricing model. So we will look at this usage and throttling model in detail. So this process has 2 main actions.

1. Before user perform some action we will check whether he is allow to do it or not(Ex adding new service/ service invocation).

2. After performing some action we keep it record (sanjeewa.com tenant used 100kb service Bandwidrh)

See following diagram for overview of usage and throttling.

sss 

Figure : Usage And Throttling Overview

Usage Agent

Usage agent is responsible for measure parameters and publishes them into Business Activity monitor server(Where we store data and monitor). for each and every tenants agent measure some important parameters related to their usage of bandwidth and resources(Service/webApp bandwidth, Registry usage, User count). This usage metering process use some advanced listening technologies to avoid slows down or blocks entire process.

As an example let say some web service hosted by sanjeewa.com try to invoke by some client so this invocation takes 100kb service bandwidth. So we will store this entry this tenant(sanjeewa.com) got service bandwidth of 100kb at this time

Usage Summery generator

Summery generator component responsible for summarize captured data. And after collecting raw data we do sorting and summarization periodically and store those records in database. Those records are available per hourly, monthly, daily, quarterly and annually.

As example after hour we will put above 100kb entry to hourly table. Then at the end of the day it will go to daily table with corresponding day of month.

Throttling Manager

Throttling is used to avoid excess usage of resources and bandwidth. Throttling manager periodically check the usage records(The data captured by above mentioned usage agent) available and evaluate throttling rules and define set of actions for each and every tenant. These actions are contain what tenants can do what cannot do what are the error messages that we have to show them. Those rules are written in drools. Drools is a business rule management system (BRMS) with a forward chaining inference based rules engine, more correctly known as a production rule system, using an enhanced implementation of the Rete algorithm. Using a rules engine can lower an application's maintenance and extensibility costs by reducing the complexity of components that implement complex business logic. So inside WSO2 stratos throttling component is use drools for throttling configurations and provide user interface to change rules in easier way. After evaluating Throttling rules for each tenant we will store the validation information(What tenant allow to do and what should block) in registry with tenant ID

Example :Throttling manager check the monthly data available in monthly service bandwidth table and check the Drool correspond to that tenant(Drool specify the service bandwidth allow to this user and actions when limit exceeding). If that user didn’t exceed limit it will put entry to registry saying sanjeewa.com is allow to service invocation else it will put entry saying not allowed.

Throttling Agent

Throttling agent is acting as a supervising agent who check the actions taken by users. Basically this will check registry entry for given tenant (Put by throttling manager). To achieve higher performance throttling agent use in memory implementation. It will take copy of registry entries and keep it cached. So reading validation information from cache is much faster than reading registry.

As an example When some tenant/users try to invoke web service this agent check the corresponding registry entry for user weather he is allow to do this or not. If he can do agent will allow to do it otherwise it will prompt message to user saying the issue.

See original post

How to configure usage in Cloud Environment using Stratos – User Guide

 

Here in this post i hope to discuss how to set up wso2 Stratos with usage metering. In this post i will mainly focus on how to setup and fine tuning parameters for usage metering. If you need more information on usage metering and throttling see my previous post from here. First you need to understand few terms

Usage Agent – Component which measures resource usage(use listening technology) and store it (Publish it to other server to record it).This usage metering process use some advanced listening technologies to avoid slows down or blocks entire process.

As an example let say some web service(hosted by sanjeewa.com) is invoked by some client. so this invocation takes 100kb service bandwidth. So usage agent will store this entry this tenant(sanjeewa.com) got service bandwidth of 100kb at this time

In order to usage metering work properly we have to do few configurations in stratos services.Usage metering is based on simple concept that is listening. There few listeners to listen the actions performed by user and those listeners  report what they heard to some other server(Business Activity Monitor). And those record will be store there in some ordered format.We will first identify those listeners.

01. Registry Listener – This listener will listen to each and every action related to registry(get, put, add, delete etc.. ) Then store them as bandwidth usage.

02. User Add Listener – This listener is there to listen user adding actions and keep updating user count of tenants

03. Service/Web App bandwidth listener – This listener is mainly listen to incoming and out going message sizes and store those data as bandwidth usages. For this listener usage agent use tomcat valve data statics.

See following Diagram for overview of usage metering process

Usageagentt

Figure : Overview Of Usage Metering Process

Data publisher – Data publisher is available inside the usage agent.When usage agent starts Data publisher creates the connection to the end point of BAM. In order to do this we have to provide Server URL of BAM instance running on.Let see how we do this configuration.This usage metering process happens at each and every stratos service so usage agent is available in every service of stratos. You can see carbon.xml file in every service inside the repository/conf folder. In carbon.xml file you will see following entry

<BamServerURL>https://bam.cloud-test.wso2.com:9447/services/</BamServerURL>

You have to give correct BAM server URL with /services part. you will see this URL when bam server starts up.Then only usage agent will be able to publish data to BAM.

Then these metered usage data will be available for any decision making process. Users(Tenants) can view their usage and super administrator can can view all tenants usages. Throttling manager use those records  to check whether users exceeded their allowed limits or not.

There are some other important parameters to configure for publisher.Those parameters are used configure to how we accumulate, how often we publish them to Bam kind of things. Since those configurations are developer level changes i will discuss it on separate post.

See original post

How to configure throttling in Cloud Environment using WSO2 Stratos – Users Guide

 

Here in this post i hope to discuss how to set up wso2 Stratos with throttling. In this post i will mainly focus on how to setup and fine tuning parameters for throttling and usage metering. If you need more information on usage metering and throttling see my previous post from here. First you need to understand few terms.If you need to understand more on throttling on Cloud environment please refer the this post on Amila Maharachchi’s Blog 

Throttling Manager – Manage, Evaluate what users can do and cannot do based on their subscription plans and their current usage.

Throttling Agent – This component detects user actions and allow them to do it or block it based on the Validation information generated by throttling manager

Usage Plan- There 4 types of usage plans available at WSO2 services. According to usage plan users will allow different volume of resources and service usage.(Demo/SMB/Professional/Enterprise). You will see more information on usage plans available at WSO2 StratosLive from here.

So we have to configure few things in order to work properly

01. How often throttling manager executes. Throttling manager periodically evaluates the tenants usage of resources(Service/webApp bandwidth, Registry usage, User count) and check it with their maximum allowed limit. After that process it store this validation data on registry. Here we can configure when start this evaluation process and how often we do this. To configure this we have to change configuration file( throttling-config.xml ). Before that you have to set up WSO2 Stratos properly(Manager/ IS/ any other services). Then go to inside of manager/repository/conf folder. There you will see throttling-config.xml file and that file has following entries.

<parameters>

<parameter name="interval">60</parameter>

<!--minutes = If This set to negative(-) value then throttling manager excecution will disable-->

<parameter name="delay">15</parameter>

</parameters>

interval parameter is there to specify the time frequency(in minutes) of executing throttling manager.According to this configuration it says execute rules after 60 minutes. With this configuration Manager will detect any excess usage of resources within one hour. after each 60 minutes It will call Data services and get current usage of each and every tenant and updating their actions(What they are allow to do or what they are not allowed)

delay parameter is there to define when to start first rule execution.According to this configuration server will run first throttling rule execution after 15 minutes time of server started.

15 minutes and 60 minutes are recommended values. But if you need much more accuracy you can reduce that interval value(But its advisable use some value more than 3 minutes otherwise it will causes to performance drop). And also remember reducing this time always causes to higher CPU Usage. If you don't need to run throttling manager you can disable it by setting negative value for  interval parameter. If you plan to run manager instance without throttling you can use this configuration.

02. How other Services allow to use Throttling manager. In order to  use throttling manager by services we have to modify configuration in each and every services that we use(Appserver/ IS/ BAM/ DSS etc..). Those services need to access throttling manager at WSO2 Stratos Manager. In that case we have to modify throttling-agent-config.xml file. That file has following content.

<throttlingAgentConfig xmlns="http://wso2.com/carbon/multitenancy/throttling/agent/config">

<parameters>

<parametername="managerServiceUrl">https://cloud-test.wso2.com/services/</parameter>

<parameter name="userName">admin</parameter>

<parameter name="password">admin</parameter>

</parameters>

</throttlingAgentConfig>

managerServiceUrl – is the URL of manager running on. Manager services URL. you will see this URL when manager starts up at terminal. by default this will set to local host.

userName – Here we have to specify Stratos Manager server super admin user name (By default it will be admin)

password  Here we have to specify Stratos Manager server super admin password (By default this will be admin)

This configuration is used by other services except manager to run the throttling rules at manager. As an example when we try to add new user identity server will call manager throttling manager to report new user adding. Otherwise within one hour of throttling rule execution time tenant user may add any number of users. To avoid such misuses we use this technique.

03. How to write throttling rules. For each usage plans we have to specify the upper limit of resource and service usage. And then if any user try to go beyond that limit throttling agent will stop that action immediately. As example if Demo account is allow to add 1 users we have to specify it in throttling rules. You will see throttling-rules.drl file inside manager/repository/conf. At first time manager takes rules from that file and store it in registry. Only super admin user for stratos manager allow to change throttling rules. If you logged in as super Admin you will see throttling menu. by clicking it you will see throttling rules editor window where you can write rules. There is other blog post on how to write throttling rules if you are interested please refer it .

See original post

How to build wso2 stratos 1.5.1 from the source

WSO2 Stratos is the most complete, enterprise-grade, open PaaS, with support for more core services than any other available PaaS today.
WSO2 Stratos provides the core cloud services and essential building blocks for example federated identity and single sign-on, data-as-a-service and messaging-as-a-service and more, required for developing SaaS and cloud applications.
Here below i will describe how to build stratos 1.5.1 from source.
You will find more information on wso2 stratos main page from this Link
Download stratos source from the hosted location
$ wget http://dist.wso2.org/products/stratos/1.5.1/wso2-stratos-1.5.1-src.zip

unzip content into some given location
unzip wso2-stratos-1.5.1-src.zip

go inside the extracted folder and start build it on line
stratos151src@sr2:~/stratos151src$mvn clean install

if it fails due to some reason(may be due to on line repo problems) follow the below guide lines.
In order to build carbon products we need to build axis2 first if that is not available at online repos

stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/dependencies/axis2/1.6.1-wso2v1
Then build dependencies
And continue build in following order with given commands
stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/dependencies$ mvn clean install

stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/orbit$ mvn clean install -Dmaven.test.skip=true

stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/service-stubs$ mvn clean install -Dmaven.test.skip=true
You must build carbon core with tests so use following command
stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/core$ mvn clean install

Before build components we have to little change for stratos pom.xml file. Due to the error in pom file location of
org.wso2.carbon.tenant.dispatcher folder.

So lets see how we can do that modification
Go to stratos folder as follows
stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/components/stratos$ vi pom.xml

Do the following change
replace line
org.wso2.carbon.tenant.dispatcher/3.2.0
with
org.wso2.carbon.tenant.dispatcher/1.5.1

Then build components
stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/components$mvn clean install

Then we have to build features
stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/features$mvn clean install

Then we have to build products and services
stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/products$ ls
as  bam  bps  brs  carbon  cep  css  dss  esb  greg  gs  is  lb  manager  mb  ms  pom.xml  wsf

here you will see available products inside products folder
if you need to build appserver product and service use the following command. same way you can do this for other products as well

stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/products/as/4.1.1$mvn clean install
Then built packs will be available on following location
stratos151src@sr2:~/stratos151src/wso2-stratos-1.5.1-src/products/as/4.1.1/modules/distribution/service/target








See original post

Tuesday, August 23, 2011

SSL enabled JConsole to monitor a WSO2 Carbon Server Securely

Written by Denis Weerasiri

WSO2 Products like WSO2 AS, ESB, BPS etc. are MBeans enabled servers such that they can be monitored via JMX clients. JConsole is a graphical JMX monitoring client which comes as a part of JDK.
Recently I had to securely monitor a remote WSO2 carbon server.
But the problem is, now any remote user can implement a MBean on the target server and use System.exit() from the client end to kill the Carbon server. So we need to harden  (or secure and restrict) the communication between client and server.
So I used jConsole via a SSL tunnel which enforces client authentication and RMI-registry authentication. Here’re the steps I took to solve the problem.
Note - Feel free to shout back in case you need more clarifications. In some steps I assumed the audience is aware of JMX, public key cryptography etc.

Content

Applied for
  • Carbon 3.2.0 (or above) based products (WSO2 BPS 2.1.0, WSO2 AS 4.1.0, WSO2 ESB 4.0.0 etc)

  • Sun JDK 1.6.0_24


Enable remote JMX monitoring for Carbon
    Once you start a WSO2 Carbon instance, default JMX Server is started as bound to localhost.
    Refer the Carbon console log.

    You can modify these ports at $CARBON_HOME/repository/conf/carbon.xml. See

    But to enable remote access, the JMX server should be unbound from localhost and bound to a remotely accessible IP address. This can be done by modifying $CARBON_HOME/repository/conf/advanced/jmx.xml. Modify the to the preferred IP address.

    Once the server is restarted, any external user can remotely monitor the Carbon instance via the exposed ports.
    See the console log to make sure, whether the modifications were applied correctly.

    Now the problem is using this exposed URL, a remote user can implement a MBean on the target server and use System.exit() from the client end to kill the Carbon instance. So we need to harden  (or secure and restrict ) the communication between client and server.

    Enforcing SSL
    Next step is to adding SSL to the communication.
    First of all we need to create a certificate which is used to encrypt the communication between JMX client and JMX server. For the simplicity we can use the keytool shipped with JDK to generate a self-signed certificate which will be used by the Carbon instance.
    Note - For more information on keytool refer http://download.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html

    Use the following command to generate the certificate.
    Note - you can prefer any place to keep the certificates. In as Carbon developers we use this location to store as a best-practice.

    During this operation, a public and private key pair and a certificate which is signed by the private key is generated.

    Now we need to export this self-signed certificate which is used by the JMX server and import it into trust store of our JMX client. In our case it’s jConsole. To do that use the following steps.
    1. Export the certificate to file called jConsole.cert

    2. Securely transfer jconsole.cert to the machine where the JMX client is installed

    3. Import the jconsole.cert to a truststore used by jConsole using the following command


    Now all the configurations are set for enforce SSL communication. Now the Carbon instance and jConsole need to be restarted with relavant JVM options.
    • Use the following command to start the Carbon instance with the mentioned JVM options.
      Note - Here the keystore password is what is specified while generating the self-signed certificate for Carbon instance.

    • To start jConsole


    Now the next step is to enforce SSL client authentication.

    Enforcing SSL client authentication

    To enable SSL client authentication, what we have to do is same as enforcing SSL communication.
    All we have to do is generate the self-signed certificate for jConsole and export that certificate and import it back to a trust store used by the Carbon instance.

    Use the following command to generate the certificate.

    Now Export the certificate to file called jconsole_client.cert.

    Then securely transfer jconsole_client.cert to where the Carbon instance is running.

    Now import jconsole_client.cert to the trust store used by Carbon instance using the following command.

    Now all the configurations are set for enforce SSL communication and SSL client authentication. Now the Carbon instance and jConsole need to be restarted with relavant JVM options.
    • Use the following command to start the Carbon instance with the mentioned JVM options.
      Note - Here the keystore password is what is specified while generating the self-signed certificate for Carbon instance.


    • To start jConsole use the following command


    Enforcing RMI-registry authentication

    Now RMI-registry which is remotely accessible from a separate port (in the above description it’s 9999) also need to be enforced with SSL client authentication. As we have all configured the trust stores and keystores in both client and server end, only requirement to enable RMI-registry authentication is to add the following JVM option to the WSO2 Carbon instance starting script.

    eg - 

    See original post

    WSO2 BPS 2.1.0 Available for Download

    Written by Denis Weerasiri


    The WSO2 Business Process Server(BPS) team is pleased to announce the release of 2.1.0 version of the Open Source Business Process server. WSO2 BPS 2.1.0 is based on WSO2 Carbon 3.2.0 which is the OSGi-based component framework allows the complete set of WSO2 products to leverage shared components, ensuring a consistent set of features between products, a consistent user experience, and reusing of identical components. You can find the release note for WSO2 BPS 2.1.0 from here.

    Two fresh products; WSO2 MB and WSO2 CEP also were released with the existing set of products.

    Few excerpts from the WSO2 BPS 2.1.0 release note...
    • WSO2 Business Process Server (BPS) is an easy-to-use Open Source Business Process Server that executes business processes written following WS-BPEL standard. WS-BPEL is emerging as the defacto standard for composing multiple synchronous and asynchronous web services into collaborative and transactional process flows which increase the flexibility and agility of your Service Oriented Architecture. WSO2 BPS is powered by Apache ODE and available under Apache Software License v2.0. WSO2 BPS provides a complete Web based graphical console to deploy, manage and monitor business process and process instances.

    • WSO2 BPS is developed on top of the revolutionary Carbon platform (Middleware a' la carte), and is based on the OSGi framework to achieve the better modularity for you SOA. Carbon platform contains lots of new features and many other optional components that can be used to customize or enhance the functionalities provided by BPS to suits you SOA needs. In addition to installing optional components you can uninstall unwanted features without any trouble.
      WSO2 team recently released 3.2.0 version of WSO2 Carbon platform which is the OSGi-based component framework allows the complete set of products to leverage shared components, ensuring a consistent set of features between products, a consistent user experience, and reusing of identical components.

    • An open source product, WSO2 BPS is available under the Apache Software License (v2.0) . This includes all of the extra integration and management functionality as well.

    See original post

    Apache Axis2: Code Generator

    Written by Thilini

    Validate the wsdl file using wsdl validator.
    This tool is available in every carbon product.


    The wsdl2java tool is bundled with Axis2 Binary Distribution.


    goto AXIS2HOME/bin and execute following command to generate java source.


    sh wsdl2java.sh -uri /home/thilini/BPELApplicationAdmin.wsdl -o temp -u





    -u --unpack-classes Unpack classes. This option specifies whether to unpack the classes and generate separate classes for the databinders.






    -o <output Location> --output <output Location> Output file location. This is where the files would be copied once the code generation is done. If this option is omitted the generated files would be copied to the working directory.


    Here you need to provide the absolute path for the validated wsdl file. Then it will store generated source at temp folder or wherever you defined it in the above command.



    See original post

    Packaging Components in a Single Server: P2 Feature Management

    Written by Thilini

    Packaging components on one server is a marvelous feature addition that will enable you to create your own SOA solution with all wanted features.



    As a example lets assume you need to get Data Service Hosting functionality inside Enterprise Service Bus (ESB), You simply need to install it as a p2 feature inside ESB.



    P2 features come as a hosted solution as well as a zip archive. You can use either the hosted solution [1] or the packaged solution [2], but if you are behind a proxy you will face a problem when using hosted solution. In that case use the zip archive.



    [1] https://svn.wso2.com/repo/p2repo/carbon/releases/3.2.0/

    [2] http://dist.wso2.org/p2-zip/carbon/releases/3.2.0/20-06-2011/p2-repo.zip



     Add p2 location: Point to either [1] or [2]





     Find Features



    Select components that you need to install.

              eg: Service Hosting (for WSO2 App Server features) , Data Service Hosting / Datasource Management (for WSO2 Data Services Server)











    Restart the server after successfully installing selected features.







    Finds installed features as shown below.





    Refer more details on Provisioning WSO2 Carbon based SOA Products with Equinox P2 and find p2repository locations from [3].

    [3] http://wso2.org/projects/carbon/provisioning-wso2-carbon-with-equinox-p2



    See original post

    Saturday, February 26, 2011

    How to setup a BPEL project in Carbon Studio from an existing BPEL artifact

    Written by Denis Weerasiri


    In this blog post is about how to setup a WSO2 Carbon Studio BPEL project from an existing BPEL artifact.
    Suppose there's a BPEL process, and you need to edit it via WSO2 Carbon Studio. We can't directly open a BPEL process via Carbon Studio. First you need to create a BPEL project and import the BPEL process to that BPEL project.

    How to create Carbon Studio BPEL project from an existing BPEL process
    • Start Eclipse Carbon Studio. Here you need to make sure you have installed Carbon Studio in Eclipse version you use.
    • In the menu bar goto File -> New -> Other -> BPEL Project . Then the following dialog will appear.

    • Click on Next. Then the following dialog will appear.

    • Add a Project name .Under Configuration click on Modify and put a check on BPEL 2.0 Facet. Click OK.


    • Then click Finish in “New BPEL Project” dialog box.
    • Now the Carbon Studio BPEL project has been created. And now we need to import the process files to this project.
    • For that; first extract a process we have provided. 
    • Then in Carbon Studio; Right click on the project in the “Project Explorer” Window -> Import... Then the following wizard will pop up. Choose “File System”, then click Next.


    • Then the following dialog will appear. And give the location of the previously extracted BPEL process in 7. Then add all the files in that BPEL process. Then Click on Finish.

    • Now the Carbon Studio project is created and you can edit the BPEL process via our editor.


    How to deploy and run BPEL projects
    • In Carbon Studio goto File -> Export. Then in the appearing dialog choose "WSO2 BPS BPEL Artifact". Then export the project.
     
    • Add the created BPEL artifact to WSO2 BPS via Web UI.

    See original post

    Saturday, February 19, 2011

    WSO2 Carbon Studio: Tools for WSO2 Middleware Platform

    WSO2 is an open source middleware company with a complete and comprehensive SOA middleware platform which is well known as Carbon and a PaaS which is known as Stratos.  But without proper tools, developers who develop their own solutions based on these SOA middleware will not get maximum benefits of them. Therefore, tools can play a significant role in reaching new sights. WSO2 Carbon Studio plays this significant role for WSO2 Carbon stack and Stratos PaaS by allowing new developers to try and evaluate Carbon platform with ease and making tasks easier for existing users.  WSO2 Carbon Studio is a collection of Eclipse plugins which enhances Eclipse IDE functionalities by extending IDE features to support WSO2 Carbon products and Stratos  with many other SOA features. Therefore Eclipse users can download Carbon Studio install it on your Eclipse installation. We decided to use Eclipse because it is completely free and open source and it is the most popular and widely used Java IDE and it will allow us to reach a much wider audience than any other IDE.   Following are the features that are included in the latest Carbon Studio 1.0.4 release. Application Server ToolsCreate and Edit Apache Axis2 Web ServiceContract first (Top down approach) Code first (Bottom-up approach) Create WSDL for Apache Axis2 Web Service archive (aar file) Generate Web Service clientFrom aar file From WSDL Web ApplicationsCreate and edit web applications Test and debug Apache Axis2 Services and Web Applications Deploy Apache Axis2 services and web applications Deploy JAX-WS services Enterprise Service Bus ToolsView, Create and EditEndpoints Proxy Services Sequences Local Entries Create custom mediators Registry Referencing Test and debug custom mediators and other ESB artifacts Deploy custom mediators and other ESB artifactscontaining as hot deployable file containing as registry resource Governance Registry ToolsCreate and deploy registry resource artifactsfrom a local file or a folder Import from a registry or as a registry dump Create, edit, debug and deploy registry handlers and filters Registry ManagementWorking with a registry onlineAdding multiple remote registries at once View, add, edit and delete registry resources and collections Import (drag-drop) resources from registry and file system View, add, edit and delete Properties, Associations, Dependencies, Comments and Tags Modify permission of a resource or collection Easily modify resources through configured Eclipse editors Check-out registry content to Eclipse workspace Working with a registry in the offline modeAdd resources in Eclipse workspace to the registry Add, modify and delete checked-out resources in the workspace and commit the changes back Sync the checked-out resources with the online registry User ManagementAdd, modify and delete users Modify the permissions of a given role Modify permission for a selected registry resource Business Process Server ToolsView, create and edit BPEL projects Test and deploy BPEL artifacts Gadget Server ToolsCreate and edit gadgets Test and deploy gadget artifacts Data Services Server ToolsCreate and edit data services (XML configurations) Create and edit data services validators Test and deploy data services artifacts and data services validators Carbon ToolsCreate, edit, debug and deploy Carbon UI bundles Deploy third party libraries as bundles Test and deploy data service artifacts and data service validators The recommended configuration for WSO2 Carbon Studio is as follow. 1. Eclipse Helios (3.6) or Helios SR1 (3.6.1) for Java EE developers.2. Oracle JDK 1.63. Any Operating System4. Around 100Mb of Hard Disk space In order to install Carbon Studio, there are 2 methods of doing that. You can follow any of them according to your preference. 1. Offline installation via Downloaded WSO2 Carbon Studio P2 features- If you prefer download first and install later, this option is for you.2. Online installation via WSO2 P2 feature repository

    See original post

    Tuesday, February 15, 2011

    Tools for Developers who want to use SOA Middleware

    Written by Sami

    The WSO2 Carbon Studio is a complete, Eclipse-based SOA development environment, consisting of a broad set of development tools for developing Services, Clients and other related SOA artifacts for your SOA.

    You can develop SOA applications using wide array of artifacts with WSO2 Carbon Studio.

    The full list of WSO2 Carbon Studio features include:

    Application Server Tools

    1. Create and edit Apache Axis2 Web service
      • Contract first (Top-down approach)
      • Code first (Bottom-up approach)
    2. Create WSDL for Apache Axis2 Web service archive (aar file)
    3. Generate Web service client
      • From aar file
      • From WSDL
    4. Web Applications
      • Create and edit web applications
    5. Test and debug Apache Axis2 services and Web applications
    6. Deploy Apache Axis2 services and web applications
    7. Deploy JAX-WS services

    Enterprise Service Bus Tools

    1. View, create and edit
      • Endpoints
      • Proxy Services
      • Sequences
      • Local Entries
    2. Create custom mediators
    3. Registry referencing
    4. Test and debug custom mediators and other ESB artifacts
    5. Deploy custom mediators and other ESB artifacts
      • Containing as hot deployable file
      • Containing as registry resource

    Governance Registry Tools

    1. Create and deploy registry resource artifacts
      • from a local file or a folder
      • Import from a registry or as a registry dump
    2. Create, edit, debug and deploy registry handlers and filters
    3. Registry management
      • Working with a registry online
        • Adding multiple remote registries at once
        • View, add, edit and delete registry resources and collections
        • Import (drag-n-drop) resources from from registry and file system
        • View, add, edit and delete properties, associations, dependencies, comments and tags
        • Modify permission of a resource or collection
        • Easily modify resources through configured eclipse editors
        • Check-out registry content to eclipse workspace
      • Working with a registry in the offline mode
        • Add resources in Eclipse workspace to the registry
        • Add, modify and delete checked-out resources in the workspace and commit back changes
        • Sync the checked-out resources with the online registry
      • User management
        • Add, modify and delete users
        • Modify permissions of a given role
        • Modify permission for a selected registry resource

    Business Process Server Tools

    1. View, create and edit BPEL projects
    2. Test and deploy BPEL artifacts

    Gadget Server Tools

    1. Create and edit gadgets
    2. Test and deploy gadget artifacts

    Data Services Server Tools

    1. Create and edit data services (XML configurations)
    2. Create and edit data services validators
    3. Test and deploy data service artifacts and data service validators

    Carbon Tools

    1. Create, edit, debug and deploy Carbon UI bundles
    2. Deploy third party libraries as bundles
    3. Test and deploy data service artifacts and data service validators

    See original post

    Monday, February 14, 2011

    Interesting, but unsolved error when building Apache Axiom

    Written by Amila Maharachchi

    These days I was busy with getting the WSO2 Carbon trunk building successfully. While working on it, I encountered an interesting build failure when building Apache Axiom with tests.

    Lets think, the Carbon trunk's structure is as follows.


    Carbon
    |--Dir1
    |--Axiom
    |--dirX
    |--dirY
    |--Dir2
    |--Dir3

    If I go to the Axiom folder and build it with tests, it builds successfully. But, if I stay in Dir1 (i.e. the parent directory which Axiom is in) and give the maven command to build all modules in Dir1 (with tests), I get this error. This seems to happen when building the Axiom OSGI Test Suite.


    -------------------------------------------------------
    T E S T S
    -------------------------------------------------------
    The current artifact axiom-osgi-run-1.2.12-SNAPSHOT.jar is not a valid bundle
    Running org.apache.axiom.test.ServiceTest
    Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0 sec
    [FATAL ERROR] org.apache.felix.ipojo.junit4osgi.plugin.Junit4osgiPlugin#execute() caused a linkage error (java.lang.LinkageError) and may be out-of-date. Check the realms:
    [FATAL ERROR] Plugin realm = app0.child-container[org.apache.felix:maven-junit4osgi-plugin:1.0.0]
    urls[0] = file:/home/amila/.m2/repository/org/apache/felix/maven-junit4osgi-plugin/1.0.0/maven-junit4osgi-plugin-1.0.0.jar
    urls[1] = file:/home/amila/.m2/repository/junit/junit/3.8.1/junit-3.8.1.jar
    urls[2] = file:/home/amila/.m2/repository/org/apache/felix/org.apache.felix.framework/1.6.1/org.apache.felix.framework-1.6.1.jar
    urls[3] = file:/home/amila/.m2/repository/org/apache/felix/org.osgi.core/1.2.0/org.osgi.core-1.2.0.jar
    urls[4] = file:/home/amila/.m2/repository/org/apache/felix/org.osgi.compendium/1.2.0/org.osgi.compendium-1.2.0.jar
    urls[5] = file:/home/amila/.m2/repository/org/apache/felix/org.osgi.foundation/1.2.0/org.osgi.foundation-1.2.0.jar
    urls[6] = file:/home/amila/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
    urls[7] = file:/home/amila/.m2/repository/org/apache/felix/org.apache.felix.ipojo/1.2.0/org.apache.felix.ipojo-1.2.0.jar
    urls[8] = file:/home/amila/.m2/repository/org/apache/felix/org.apache.felix.ipojo.metadata/1.2.0/org.apache.felix.ipojo.metadata-1.2.0.jar
    urls[9] = file:/home/amila/.m2/repository/org/apache/felix/org.apache.felix.ipojo.handler.extender/1.2.0/org.apache.felix.ipojo.handler.extender-1.2.0.jar
    urls[10] = file:/home/amila/.m2/repository/org/apache/felix/org.apache.felix.ipojo.junit4osgi/1.0.0/org.apache.felix.ipojo.junit4osgi-1.0.0.jar
    urls[11] = file:/home/amila/.m2/repository/net/sourceforge/cobertura/cobertura/1.9/cobertura-1.9.jar
    urls[12] = file:/home/amila/.m2/repository/oro/oro/2.0.8/oro-2.0.8.jar
    urls[13] = file:/home/amila/.m2/repository/asm/asm/2.2.1/asm-2.2.1.jar
    urls[14] = file:/home/amila/.m2/repository/asm/asm-tree/2.2.1/asm-tree-2.2.1.jar
    urls[15] = file:/home/amila/.m2/repository/log4j/log4j/1.2.9/log4j-1.2.9.jar
    urls[16] = file:/home/amila/.m2/repository/org/apache/ant/ant/1.7.0/ant-1.7.0.jar
    urls[17] = file:/home/amila/.m2/repository/org/apache/ant/ant-launcher/1.7.0/ant-launcher-1.7.0.jar
    urls[18] = http://felix.extensions:9/
    [FATAL ERROR] Container realm = plexus.core
    urls[0] = file:/media/dev/software/apache-maven-2.1.0/lib/maven-2.1.0-uber.jar
    urls[1] = file:/home/amila/.m2/repository/org/apache/maven/archetype/archetype-packaging/2.0-alpha-4/archetype-packaging-2.0-alpha-4.jar
    urls[2] = file:/home/amila/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
    [INFO] ------------------------------------------------------------------------
    [ERROR] FATAL ERROR
    [INFO] ------------------------------------------------------------------------
    [INFO] loader constraint violation: loader (instance of org/codehaus/classworlds/RealmClassLoader) previously initiated loading for a different type with name "org/codehaus/plexus/util/xml/XMLWriter"
    [INFO] ------------------------------------------------------------------------
    [INFO] Trace
    java.lang.LinkageError: loader constraint violation: loader (instance of org/codehaus/classworlds/RealmClassLoader) previously initiated loading for a different type with name "org/codehaus/plexus/util/xml/XMLWriter"
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
    at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
    at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
    at org.codehaus.classworlds.RealmClassLoader.loadClassDirect(RealmClassLoader.java:195)
    at org.codehaus.classworlds.DefaultClassRealm.loadClass(DefaultClassRealm.java:255)
    at org.codehaus.classworlds.RealmClassLoader.loadClass(RealmClassLoader.java:214)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
    at org.apache.felix.ipojo.junit4osgi.plugin.XMLReport.generateReport(XMLReport.java:194)
    at org.apache.felix.ipojo.junit4osgi.plugin.Junit4osgiPlugin.executeTest(Junit4osgiPlugin.java:573)
    at org.apache.felix.ipojo.junit4osgi.plugin.Junit4osgiPlugin.invokeRun(Junit4osgiPlugin.java:447)
    at org.apache.felix.ipojo.junit4osgi.plugin.Junit4osgiPlugin.execute(Junit4osgiPlugin.java:253)
    at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:356)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
    at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
    at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
    at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
    [INFO] ------------------------------------------------------------------------
    [INFO] Total time: 2 minutes 7 seconds
    [INFO] Finished at: Sat Feb 12 23:44:07 IST 2011
    [INFO] Final Memory: 233M/964M


    Several other people have encountered this problem, but I didn't see a solution for this. If you know the reason for this, please add a comment. It will be very helpful :).

    See original post

    Friday, January 28, 2011

    Create Business Processes, Human Tasks, with many other features

    Written by Denis Weerasiri


    Suppose you need to write a business process/human task with some quality of service features like security, throttling caching etc. Or suppose you need inject ESB characteristics like service mediation, routing, load balancing, message enrichment etc. to incoming and outgoing message sequences.
    Now what if you can do all these stuff with one server instance without using different products for different requirements, isn't it great?
    WSO2 Carbon is capable on this due to its component architecture. Not only that you can do these stuff using Carbon UI very easily.
    Due to WSO2 Carbon's OSGi based component architecture, you can customize WSO2 products based on your requirements.

    Here I'm writing about how those stuff can be done in a very high level.

    1. Security, Caching, Throttling to Business processes/Human tasks.
    WSO2 BPS is inherently support this, and you can use the BPS Web UI to configure, monitor and maintain business processes with these features. The more interesting thing is; the whole set of WSO2 carbon products, have this unique interface. So once you get familiar with one product, you can use other products very easily. As an example, to enable throttling to service mashup, data service or SOAP service etc, user sees an unique interface.

    Here are some screen-shots of the service dashboard.

    Main service dashboard

    Security configuration

    Throttling configuration

    Caching configuration

    Try-it configuration


    2. How to embed ESB like features
    How to install ESB features - To use WSO2 ESB features what you need to do is install ESB related features to BPS. But I would prefer install BPS features into ESB as the number of BPS features are less than ESB features. As any WSO2 product is a set of OSGi components; there is no any difference in installing BPS features to ESB product and installing ESB features to BPS product.

    Here is a screen-shot of feature management page


    Now if you are already familiar with WSO2 ESB; using ESB features on business processes/ human tasks is no different from using ESB features on any other service.
    eg - writing a proxy service for a business process and use message mediation in in-sequence and out-sequence. etc

    See original post

    Tuesday, January 18, 2011

    SSL Debugging - Part - II - Intercepting traffic between WSO2 Carbon FE and BE

    All WSO2 products are based on WSO2 Carbon, which sits as the core for all of them.

    We do have a clear Front-End [FE], Back-End [BE] separation - where the FE web application talks to the BE, via web service calls.

    This benefits the end user - which adds the flexibility of developing his own client to the corresponding back end functionality in a language independent manner.

    All UI components you see in the default distribution talk to the BE services via SOAP over HTTPS.

    In case of digging in to an issue - since this is on HTTPS - it's hard to intercept the communication channel and figure what exact messages being passed from FE to BE.

    This is how you can do it - to intercept messages flowing over SSL.

    Prerequisites:
    1. ssldump
    2. The private key of WSO2 Carbon, in PEM format - you can download it from here.

    Run the following command from where you have the private key, and start any WSO2 Carbon based product - say on HTTPS port 9443

    :\> sudo ssldump -Ad -k wso2carbon.pem -p wso2carbon -i lo0 host localhost and port 9443

    Make sure to have the correct interface set as per your system.[-i lo0] and start the ssldump before you start the server.

    Now you can track all the messages between FE and BE in clear text.
    1 8 0.0621 (0.0007) C>SV3.1(203) application_data
    ---------------------------------------------------------------
    POST /services/AuthenticationAdmin HTTP/1.1
    Content-Type: application/soap+xml; charset=UTF-8; action="urn:login"
    User-Agent: Axis2
    Host: localhost:9443
    Transfer-Encoding: chunked

    ---------------------------------------------------------------
    1 9 0.0626 (0.0005) C>SV3.1(399) application_data
    ---------------------------------------------------------------
    173
    <?xml version='1.0' encoding='UTF-8'?>
    <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
    <soapenv:Body>
    <ns1:login xmlns:ns1="http://authentication.services.core.carbon.wso2.org">
    <ns1:username>admin</ns1:username>
    <ns1:password>admin</ns1:password>
    <ns1:remoteAddress>0:0:0:0:0:0:0:1%0</ns1:remoteAddress>
    </ns1:login>
    </soapenv:Body>
    </soapenv:Envelope>
    0

    ---------------------------------------------------------------
    1 10 0.2071 (0.1445) S>CV3.1(544) application_data
    ---------------------------------------------------------------
    HTTP/1.1 200 OK
    Server: Apache-Coyote/1.1
    Set-Cookie: JSESSIONID=37FC902E5E7C6C0D081E28B4DF067A76; Path=/; Secure
    Content-Type: application/soap+xml;charset=UTF-8
    Transfer-Encoding: chunked
    Date: Fri, 19 Nov 2010 02:44:26 GMT

    11f
    <?xml version='1.0' encoding='UTF-8'?>
    <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
    <soapenv:Body>
    <ns:loginResponse
    xmlns:ns="http://authentication.services.core.carbon.wso2.org">
    <ns:return>true</ns:return>
    </ns:loginResponse>
    </soapenv:Body>
    </soapenv:Envelope>

    See original post

     

    Copyright 2009 All Rights Reserved Revolution Two Church theme modified by Milinda Pathirage