Monday, November 30, 2009

Cloud Dude and Enterprise Suit


Written by Sami

Cloud dude: Hello, I’m a Cloud.

Enterprise suit: And hello, I’m Enterprise Software. (Struggling with three huge suitcases)

Cloud dude: Enterprise, what do you have in those bags? They look heavy.

Enterprise suit: These? Oh this is all the baggage I bring along with me to customer sites. You know, up-front licensing costs, upgrades, service packs, installation kits, extra hardware, extra disks; you know, all the stuff that I need to set up at a customer site.

Cloud dude: You need a hand with that? You know, I don’t really need any of that when I go to customers—I travel pretty light. (Extends both free hands to offer assistance)

Enterprise suit: No, no, I’ll be fine. I’ll just … (Starts walking, falls over, flat on the floor, baggage landing on top of him, rumpling his suit.) Besides, my customers always know to keep a spare room open for all of my baggage when I arrive.

Cloud dude: (Shrugs and smiles.)


See original post

WSO2 Enterprise Service Bus - Endpoint Error Handling


Written by Sami

An Endpoint is an abstraction of the service provider. Once a message is sent using a mediator, it should know what the service provider endpoint is. The endpoint is capable enough to provide this information. In a scenario where several ideal service endpoints serves requests of the same type, WSO2 ESB can be used as a Load Balancer. The main reason behind it is that all these endpoints are having the same functionality and it is natural to view them as a single unit.

WSO2 Enterprise Service Bus has the concept of building endpoints to represent service provider Endpoints. The following are the Endpoints built on WSO2 Enterprise Service Bus.

  1. Address Endpoint
  2. WSDL Endpoint
  3. Default Endpoint
  4. Load Balancing Endpoint
  5. Fail-Over Endpoint

Out of the above mentioned lot, the most widely used Endpoints are Address and WSDL Endpoints. Each Endpoint has its own XML configuration in the Synapse Language. Synapse Language is an XML language used for configuring the Enterprise Service Bus.

Since Endpoints send the message out, they can encounter various transport errors. For example connection may time out, or connection may be closed by the actual service. This article by Supun, is a very good read on how to deal with error handling with ESB's endpoints.

See original post

Friday, November 27, 2009

WSO2 Business Activity Monitor is about to go Beta


Written by Sami

WSO2 BAM's first beta pack will be announced in the coming hour or so.

After many long nights, fixing and re-fixing bugs, evaluating and re-evaluating the dashboards, reports and the UI in general, it is somewhat stable now.

Also, I think WSO2 BAM is the first product from WSO2 to go into production even before the release. We are using it internally to monitor the Governance as a Service could instance.

Thought it is still in 1.0.0 beta, there are many interesting aspects of WSO2 BAM worth discussing, which I will do in the coming week.

See original post

Friday, November 20, 2009

SOA Governance as a Service


Written by Sami

WSO2 Governance as a Service enables enterprises to configure their own SOA Governance Registry with no software set up at all. This multi-tenant, hosted version is completely self-serviced with each tenant or domain having its own theme, own logo and of course own users. While it can be managed by its own user community, tenants optionally can publish some data publicly, for example business-to-business service entries

With WSO2 Governance as a Service enterprises are able to instantly:

  • Store services, WSDLs, Schemas and policies and make their discovery easy
  • Manage service metadata and lifecycles
  • Maintain multiple versions of services
  • Keep track of dependencies and associations of WSDLs and Schemas
  • Subscribe for updates in resources and lifecycles
  • Mange users with proper permission settings

and much more. Since this is a service, the best way to learn is by trying the service out for yourself!

See original post

Wednesday, November 18, 2009

Cloud is Hot and Cloud has Reasons


Written by Sami

It is in the peak of the hype curve, Cloud computing. While in hype's peak, every one jumps on it, so it becomes hot.

However, Cloud Computing also has its reasons for coming into being. And it will change the face of computing, with a lasting effect, in the years to come.

Cloud, as all other technical revolutions, is not going to solve world hunger. But it will help solve many business and IT problems. The most prominent are the pay as you go and use what you need models. You can kick start something, with little and with the hope of expanding, based on the demands. And it is leading computing to the services arena. We used to think about our systems deployments and stacks of hardware that supported the deployment as commodities. No more. Cloud enables us to look at those as services. This coupled with software, provides powerful service platforms. For example, now you can have any computing element, even something like middleware available as a service, thanks to the cloud.

SOA middleware deployed on the cloud can be used to expose your internal enterprise to your external world, including suppliers, customers and partners. The challenge is of course, to leverage the cloud, without compromising security and ensuring the integrity and confidentiality of the piles of enterprise data models. Hence, just for the sake of going with cloud, an organization cannot afford to put everything to run with the cloud. There are elements that you should expose to the cloud and there are elements that you should not.

What could be exposed with less risk? For example, your service interfaces and policies need to be shared with external parties. And those service meta data also has their own lifecycles that you need to monitor and manage closely. Sounds like SOA governance? Yes it is about Governance. Rather than managing your own SOA governance setup, what if you could use it as a service, with proper access control? If you could your CRM run with a software as a service (SaaS) model, why not leverage SOA Governance as a Service?

Piles of legacy data should not be exposed to he cloud, nor it is a good idea to move those to a SaaS model. However, the need to integrate and grant access to trusted parties is real. So how about exposing the internal services as proxies in the cloud and still keep the real services within the intranet, with the warm safe feeling of staying home? Yes that too can be done with a Cloud Services Gateway.

See original post

WSO2 SOA Platform Enters in to the Cloud


WSO2 announced the launch of their SOA platform inside the Cloud earlier this week. With this launch, you can try out and use their comprehensive SOA platform inside the cloud.

WSO2 Cloud Platform consists of various products, including

See original post

WSO2 cloud platform launched!


Written by Sanjiva Weerawarana

After a lot of hard work by a lot of people, we finally launched our cloud platform on Monday!

Check out Paul's blog for some info and of course the Web site. I will blog more later!

See original post

Tuesday, November 17, 2009

SOA in the Cloud


Written by Sami

The WSO2 Cloud Platform is designed to make it easy for enterprises to take their middleware to the cloud. We address all aspects of SOA middleware and support all the different styles of cloud deployment that enterprises are exploring as they float into cloud computing.

The WSO2 Cloud platform is comprised of Cloud Virtual Machines, Cloud Connectors, Cloud Services and Cloud Middleware.

See original post

Monday, November 16, 2009

Using Axis2 Dynamic Client to invoke Secured Web Services


When invoking a secured web service with Axis2, usually we tend to use Axis2 ServiceClient at the service consumer’s end. This is mainly due to the simplicity of the API of the ServiceClient. Since we are invoking a secured service, we have to point the ServiceClient to the security policy which is applied to the service. Usually this policy is stored in the file system and a policy object created by reading that file is added to the ServiceClient options. Following code snippets depicts the above mentioned procedure.

options.setProperty(RampartMessageData.KEY_RAMPART_POLICY, loadPolicy(policyPath));

With this approach, whenever the service policy is changed, the changes should be introduced to the client side policy file manually. This is not manageable in a scenario where a large number of clients access the same secured service which is subjected to frequent changes in the policy. In such cases, Axis2 Dynamic Client comes in handy.

RPCServiceClient or Axis2 Dynamic Client is an extension to the Axis2 ServiceClient. When instantiating a RPCServiceClient, the URL of the WSDL of the service, the QName of the service in the WSDL and the intended port name should be passed as parameters in addition to the Configuration Context.

RPCServiceClient dynamicClient = new RPCServiceClient(confContext, new URL(""),
  new QName("", "HelloService"), "HelloServiceHttpSoap12Endpoint");

During this instantiation, the policy which is appearing in the WSDL is extracted and applied to the web service client. So when the policy is changed, always the changes get reflected in the client side.

Then you can engage modules in same way as with ServiceClient. Since RPCServiceClient is extending ServiceClinet, engage(String moduleName) method is inherited.


Now we have passed the service policy and engaged the Rampart module. What else is missing here? Yes. It is the rampart-config which is used to pass the client-side configuration data for Rampart. In this case, we can construct the rampart-config element programmatically and append it to the policy derived from the WSDL.

Constructing rampart-config programmatically is straight forward. Following code snipped demonstrates how to construct the rampart-config corresponding to a Username Token based Security Scenario.

RampartConfig rampartConfig = new RampartConfig();

Then append this rampart-config to the policy derived from the WSDL.

Map endPoints = dynamicClient.getAxisService().getEndpoints();
AxisBinding axisBinding = ((AxisEndpoint) endPoints.values().iterator().next()).getBinding();
Policy policy = axisBinding.getEffectivePolicy();

Here we are taking the effective policy and append the rampart-config and overriding the existing policy using the updated policy.

Now we can invoke the service.

Object[] returnArray = dynamicClient.invokeBlocking(new QName("","greet"),
new Object[]{"Alice"}, new Class[]{String.class});

We are using the blocking invocation here. The QName of the operation in WSDL file, an array of objects with the parameters and an array of Class objects for the return types are passed into this method.

With the successful completion of that method, we have invoked a service securely using an Axis2 Dynamic Client.

References :

See original post

Wednesday, November 11, 2009

Talk on "State of Services" at EDGE APAC in Canberra, AU


Written by Sanjiva Weerawarana

I gave a keynote talk this morning at EDGE APAC in Canberra on the topic of SOA .. sort of a walk thru the history, what has been achieved and what the future is like. Yeah, all in 1hr.

See original post

Tuesday, November 10, 2009

Secured SOA


See original post

Monday, November 9, 2009

WSO2 Mashup Server at Mashup Australia


Written by Tyrell

Mashup Australia is an initiative by the Australian government to open up public data for broader consumption. It's similar to what they've done in Washington, but closer to home. So I decided to submit an entry on behalf of the WSO2 Mashup Server team.

The Mashup;
  1. Uses data provided by the Australian government (an Excel spreadsheet) regarding the country’s mines and exposes them as a Data Service (using WSO2 Data Services)
  2. The Mashup consumes this Data Service (just another SOAP Web Service), processes the data and publishes in a format easily palatable by the client side Javascript
  3. On the client side with Google Maps the data is displayed according to the geographical location of the Mines. Using the filters available, the Mines can be pin pointed based on the type of mineral(s) they harvest.
If you like this mashup, please don't forget to rate it!

See original post

WSO2 practicing open development further


Written by Sanjiva Weerawarana

From the time we started WSO2, Paul and I have both been dead certain that we always wanted to be a truly open company. That is, not a proprietary/closed company which simply releases software under an open source license, but rather a company which is more like an open source project in terms of how it does its technical work. The reason for this is because we believe that being open will bring more people to participate in our work which will eventually help us do better than our less-open competitors. Nope, we are not about to share how we do are doing business :-).

That of course comes from our Apache legacy of having started so many different projects and watching many of them succeed beyond our wildest dreams. Apache SOAP, Apache Axis, Apache Axis2, Apache Synapse, Apache WSIF are some of the examples.

We of course started the WSO2 Oxygen Tank ( for exactly that purpose. ALL of our code is there and we had a ton of different mailing lists for all the different projects.

That’s where the problems first started – by having separate mailing lists for each project/product, it became cumbersome for us to keep track of all the lists and to participate properly in all of them. Also, as we moved towards unifying our products around a single framework (as we’ve now done with WSO2 Carbon), the separate lists meant that every conversation had to be cc’ed to multiple lists – very annoying when you’re on the receiving end via multiple lists.

The other part of the problem was that we also had to have some internal communication mechanism to discuss customer issues. So we set up an internal list called architecture@ which was meant to be ONLY for customer issues – stuff that we couldn’t discuss publicly because they involved specific customer issues. However, due to a variety of reasons, over time the architecture@ list became the place where we ended up discussing many of the core issues that we went through when making the transition to Carbon.

Not any more!

We have recently done a MAJOR re-org of all the lists and also done a major cleanup of all internal lists. Now on we have:

  • 3 –dev lists: carbon-dev, wsf-dev and commons-dev. Carbon-dev is for all discussion related to all Carbon core stuff and every product built with it (ESB, WSAS, BAM etc.). WSF-dev is for discussion related to Web service frameworks – the low level stuff that provides WS-* functionality for Carbon. Commons-dev is to discuss all “other” projects in OxygenTank; stuff that’s common to various bits but not strictly a Carbon product or a WSF product.
  • Corresponding –issues and –svn lists: to separate user discussions, JIRA notifications and SVN notifications, respectively.
  • Per product –user lists and of course forums.
  • New public list which is used for all architecture discussions. If you’re more of a high level person then that’s the most interesting list to participate in to understand what we’re doing, why we’re doing it, how we’re doing it and of course to be part of the process of deciding what/when/how we do it. Competitors are welcome, especially those that want to de-cloak ;-).

Internally, the architecture@ list is gone for good! Instead, we now have a support-dev list to discuss customer issues and ONLY customer issues. In addition, we have a strategy@ list to discuss how we plan to take over the world (;-)) and a few other lists which will become apparent soon! However, if the discussion is related to any architectural matters related to any of our products, it WILL happen on architecture@.

Want to be part of our [extended] family? Come join us on See:

See original post


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