Introduction to WSO2 Platform

This blog will guide you through the thought process and some implementation details of how you would go about developing a simple application using PHP and MySQL and then show you how you could re-architect the system using WSO2 products. How and why they’re used. It’s written in a very high level way so that you can follow along easily. Objective of this blog is to introduce you to a familiar topic, developing a simple web application and then when different requirements spin up possible problems you have to consider and how WSO2 products provide rich and easy way of solving those problems.

Background

When you’re new to WSO2 platform it can be a bit overwhelming and you might feel that you’re at a loss. Specially if you’re new to web services and haven’t worked with similar software systems before. When you’re starting out you might wonder where to start as the same task can be done in different ways and using different products. Choosing the right products to use for your situation can also be challenging. Fortunately it’s not all rocket science, get use to the lingo and understand a few basic things and you’ll be on your way in no time!

Application design

Before diving into the list of products and what they can do, let’s see some points about application design. If you’re a web developer designing websites for clients you’re probably familiar with blogging tools like Wordpress/Drupal/Joomla etc… If it’s a relatively simple website all you have to do is create a custom theme, putting the right logos/colors and layout and you’re done. You’ll be spending most of your time on the frontend aspects and allowing the underlying content management system you’re using, to update/add new content to the site easily.

Then there are systems that you don’t want to use a content management system. Those situations where using a CMS complicate things than it helps. Simple web applications. For those, you would need a simple server side programming language like PHP and some HTML/CSS to shape up the frontend. Most web applications start this way. You start with a bunch of PHP pages and then when there’s a need to talk to the database you write a “light weight” DB layer which sits on a class of it’s own, you instantiate that class and carry on with the DB operations. Then there’s a whole range of patterns in this area that documents best practices when it comes to developing web apps. MVC, FCP and others. Then there are frameworks which capture these best practices and try to provide you with high level abstractions. CodeIgniter, CakePHP, ZendFramework comes to mind.

So if you’ve been working with this space for some time, web services might not make sense to you. Why do you need web services at all? For example why would you need something that expose data in a database as a web service? That seems ridiculous when you can query the database using mysqli_query() right?

Why do I need web services? I can develop a far more simple web application
with PHP and MySQL!

You’ll probably will go through or might have to come up with an architecture for your web application similar to web services when you have to think about scaling. When that happens you need to be able to treat different parts of the system independently and being able to concentrate on certain functional aspects of the app without having an adverse impact on other parts. You need an application design that distribute functionality into different components. Even though this is a gross over simplification bare with me for a second. Then you need some way of communicating with these distributed components of the system. Using web services is one such solution to the problem and no the only one.

Let’s see how requirements spin up in a typical project that you might have to deal with. First it might be a request like, we need to have an internal web application that give a nice user experience to all our functions in the bank. If you’re tasked with this, then you would need to dive in to what are these functions in the bank and then come up with a web application that will have all these functions. In the beginning it might be such that you’re given a single module as a pilot to see whether it’s successful or not. May be with the savings accounts module in the bank. Let’s say you dive into the requirements, use a DB for transactions and code up the site using PHP. Nice, simple and functional. Have a nice front end everyone is happy and you’re given the go ahead to include more functions. Like, fixed deposit module, credit card processing module, loans processing module and so on. For this example even though I took a bank it still applies to wide variety of systems and companies.

Thinking about possible application extensions, big picture of how your
application will get used in the long run, how it will play along with
the stuff you already have in your organization will save quite a lot of
time when you’re faced with integration tasks down the line

Developing a simple app

So, continuing, if you’ve thought about having all these modules initially then you’re job is easier. If not you need to refactor the code and break it into modules. Cool. You code everything up, hook up the DB, have sections in the UI for all the modules and everything is progessing nicely. May be you put all different modules into a structure like,

 
modules/
    common/
    fixed_deposit/
    loans/
    savings/
    ...

And all the functions that are common to all the modules put into the commons folder. Standard stuff. Easy. Now, if you’re really lucky, initial requirement doc lists requirements to monitor the whole system. If you’re unlucky monitoring requirement will come up when you’re done with the system. You need to somehow log all the operations that are happening in the system and provide a monitoring UI for admin users to find out how the system is progressing, data usage, what modules are getting utilized and what are under utilized and so on. This becomes not only an operational level issue but a management issue too. For example if fixed deposit rate is going down may be it might help to do some marketing and give lucrative deals to attract more fixed deposits. You haven’t thought about monitoring, now you have to add code to log these information in your modules. Then create a dashboard. May be you can create a separate tab in your UI that’s visible only to admin users and selected roles in the management to give a view for this data. Again, not that hard. Your application will look something like the following.

More requirements

At this point if all people were happy and set for the next 10 years then it will be terribly boring. Also it rarely works that way in real life. When you put the system into operation all kinds of requirements can come up. Let’s see some of those,

  1. I need to be able to have the monitoring UI on my iPad, all the operations people should have this iPad/iPhone app to see how the system is performing
  2. We need to have user editable set of rules that allow business users to edit/modify logic of the rules. We don’t and wont edit PHP code everytime when the interest rate is reduced
  3. We need the fixed deposit information to be integrated to the new application we’re building that’s outsourced
  4. We need to expose a subset of information about loans and customers to other banks for creating a black list of bad customers
  5. We need a way to quickly detect fraudulant transactions from our credit card transactions
  6. This system is great, we need to integrate it into the other old systems that we have in our bank. We have some old systems that we need to pull data and display on the new website
  7. We’re going to use a new cheque processing system from another bank, for that we need to send all our check related information to that system securely over the internet. We have to make sure we send this information in a reliable fashion

Problem analysis

If you think ahead, since the system you developed is a single PHP application that utilize a database, there are other concerns as well. If for example, savings account module is heavily used and generate a lot of traffic in the system, this is not only affecting that module but the entire system altogether. If the entire system is down then that’s a big impact on the business. That’s certainly not what you want. PHP application we consider is a monolithic one. Meaning everything is in a single app. Breaking this down to several functions is easier said than done. One option is to break this down and use XML-RPC to do remote procedure calls. When you break functionality down to several pieces and use a bunch of machines to host there are additional concerns that pops up. Like for example, security. You cannot talk between modules with plain text messages because information that you will be sending back and forth are sensitive. It’ll be related to customer information, accounts, credit card information and so on. So you have to at least host the functions that you’ll be hosting other machines through HTTPS. If you need data encription even though it can be implemented, you have to implement in all the different components having a large number of code duplication. You have to maintain and be concious about all this code and test each and every component for functional accuracy with all the additional stuff. Then you have to rethink about monitoring aspects. Same goes for the set of business rules as well. OK, now you have everything separated, then what about that savings accounts module which attracted a lot of traffic? How would you go about scaling that? You can have a bunch of Apache servers having hosting the savings account module and have a load balancer load balance among those. If you have used PHP sessions, and if your functions rely on state that’s stored in the current session, now either you have to enable session replication among the nodes or re-factor your code to make them stateless. Which is going to require some rethinking of doing things. Then, when you have all these changes, you have to get it tested properly for inconsistencies and functional accuracy. It’s a lot of things to consider for a simple PHP application.

Now you understand the problem and complications that all the additional requirements/factors will introduce now let’s look at the WSO2 platform and see how those can help in this situation. Usually when people think about web services in general they think of heavy weight enterprisy stuff that brings unusual complexity and baggage with them that it’s so difficult to manage in a meaningful way. That’s why most of the people prefer to go with simple languages like PHP and have a very lean setup. Another fact is people have heard horror stories of many SOA project failures. People who got bruised by those experiences will not touch anything related to SOA with a ten foot pole. But they will be wrong. Very wrong as we’ll soon see. Ofcourse, if you look at products from, say Oracle, related to SOA they ARE in fact very complex. Multi gigabyte downloads alone should send you a message about what to expect. And you cannot expect anything more from a company who’s run by lawyers, not software engineers.

Choosing the right technology

When you’re choosing a technology for implementing a project, traditionally it boils down into few choices. Leveraging what you already have in place. Like for example if you have an application server, using that. Then ofcourse choosing a technology that’s familiar to your development team is another key. Today however, these choices are changing. What technology gives you the highest turnaround time when it comes to implementing a project seems to be dominant in many situations. Also you have to manage flexibility and maintainability aspects. Ability to adopt to new requirements easily is very important. When you have a new module to implement (still talking in terms of our bank example) if it takes 6 months to get everything going it’s not going to be effective.

Let’s recap our new requirements and think how we’ll effectively re-architect the system.

  1. Your application now should support multiple UIs on multiple devices.
  2. Have to abstract out some business logic into a set of rules
  3. Information should be easy to integrate into other systems
  4. Information should be easy to securely expose into different systems and people. May be role based access to information.
  5. Should be able to identify patterns from the transactions that’s performed
  6. Should be able to extend to adopt and integrate into legacy systems
  7. Have to be able to expose and send information in a reliable fashion without having any message loss in the system
  8. Any part of the system should be able to scale easily
  9. Have to have a monitoring system that’s easy to configure for new modules as well as monitoring the sort of distributed setup we’re going to have
  10. When we break into functionality and have a distributed setup we need to be able to secure the communication that’s happening between modules and external systems

How WSO2 products fit in

Let’s start with the frontend. WSO2 has technologies that you can use to develop frontend, backend and the glue code that goes in between. Usually referred to as middleware. There are several ways you can develop the frontend. You can decide to write your frontend with pretty much any technology, if you’re using WSO2 technology the easiest way to develop the frontend is using Jaggery. Jaggery is a serverside Javascript framework. Similar to NodeJS. It’s easy to change, interpreted and it’s Javascript. WSO2 is putting out a new product called the WSO2 User Engagement Server (UES) that allows you to create frontends by dragging and dropping components. Also, that makes creating dashboards mindblowingly simple. Drag a chart and give the URL which has data and it’ll be there. Although the product page has not been created yet, the beta is out! You can download it from here. Unzip and run wso2server.{sh,bat} file in bin folder. After server is started you can access the portal by pointing your browser to http://localhost:9763/portal/. Default username/password for logging is in admin/admin. Try it out, it’s amazing!

So you have a frontend, also you can allow people to create custom dashboards easily if you want. What now? Now you need to have a set of APIs that implement business functionality. When you have that it’s easy to connect different applications/frontends/apps to get data. If you’re connecting mobile devices then you might want to handle JSON data for ease of processing. Since these APIs can be exposed not only to internal applications but also to external apps then you need to have security. Also monitoring capabilities to monitor who’s using what API, frequency and response times. For this you can use WSO2 API Manager which makes creation and manage API lifecycle through an easily administered web console.

The APIs need to talk to a service or a set of services which implement business functionalities. Since we’re dealing with modules like fixed deposit, loans, cheques each of those can be implemented as a separate service and group all related functionalities to that service. Web services encourage you to do everything in a stateless manner so it’s easy to scale when it comes to that. Service implementation can be done in Java and host it in the Application Server. Application Server is running on an embedded Tomcat instance. Now you have business logic implemented and hosted in the Application Server. Next step we can use the Enterprise Service Bus to make communication between components streamlined and act as a point that integrate different systems. Legacy systems in our example.

Then you can develop a data services layer on top of the database that you were using to exposed those data as web services. So, when you implement business services, those can talk to data services for doing data level operations. This provide a clean interface for interacting with database and make application logic much simpler. You will not need to use JDBC calls or use a separate persistence/ORM layer like Hibernate. When you’re accessing data in the database all you have to do is make another web service call. Then data access layer can have it’s own mechanism of security independent of other systems. This is easy with the Data Services Server where you can expose any database table or a custom query as a web service.

Now comes business rules. Business Rules Server can be used to create a set of reusable rules from which your business logic can then refer to. BRS will expose all your business rules as a web service. So, when you’re calling a business rule to evaluate, all you have to do is call another web service. Let’s see how this solution looks like,

As you can see in the picture we’ve included WSO2 Business Activity Monitor (BAM) for monitoring. In API Manager, ESB, AppServer etc… all have publishing agents that push statistical data about service invocations to BAM. You only have to give connection information and details about service statistics will be collected on BAM. Then you can configure UES to display a custom dashboard of all or subset of events. One good thing about this solution is when it comes to scaling you can scale each and every component without having an adverse effect on other parts of the system. If savings account service is attracting a lot of traffic then you can cluster the Application Server. If your system is generating a lot of events that are sent to BAM then you can cluster BAM and so on.

In the above diagram there is a separate ESB which deals with integration aspects. Also it’s there to provide and connect with legacy systems that will be used.

Out of the requirements that we talked about there’s one more bit that we haven’t considered in the picture above. That’s related to identifying patterns about fradulent credit card transactions. For this we can use WSO2 Complex Event Processing Server (CEP). Since CEP analyses event streams natural place to put CEP is with BAM itself. Because we’re sending all events to BAM anyway for monitoring purposes. Then you can configure different alerts based on the criteria you need.

Conclusion

In summary we looked at a simple web application and with requirements come for integrating additional systems and scaling different parts, possible complexities that it introduce to make things complex. Then we looked at if you think of these problems and anticipate some, how you can have a different architecture for the program you’re designing. Also how some of WSO2 products fit into that problem space and solve some of the tricky issues without much effort.

Retina Display Spoils Everything

Once you get hooked to retina display there’s no going back. You’re pretty much hooked for life. Every other screen you keep seeing pixels and it annoys the hell out. Reading experience just dominates with a retina display. I’m using the word retina, loosely to mean any screen that you can’t see individual pixels. This is one reason iPad Mini is such a letdown for me. True it’s more portable and easy on the hand because it’s light but you still see those individual pixels. Which ruin the whole reading experience. In the tablet world, for me at least it’s not about just having a portable device. It’s about having a portable device with a beautiful screen. A screen that display crisp fonts and sharp pictures. Couple of years from now retina displays will be everywhere. Big screens with retina will be crazy expensive still. Just like anything in the tech industry, it’ll be cheap enough in near future it’ll be accessible to everyone. Now it seems to be really hard to move onto any mobile device that has jagged fonts and edges. Just doesn’t seem good enough.

Using WSO2 G-Reg API - Add Services

WSO2 Governance Registry (G-Reg for short) come with a Registry API and a Governance API. Registry API is mainly there to interact with the G-Reg at a repository level. Then why is this API called the Registry API and not the Repository API? That’s because G-Reg started its life as an SOA Registry first and then on generic repository level functions as well as Governance functions were added. The name Registry API was not changed. Registry API is a SOAP based API and have an associated WSDL. You can find detailed information about these API on G-Reg documentation. This blog post is about some aspects that I found to be useful when you’re trying to work with the API. Please note that this is not a comprehensive API guide, rather the path I took to use these APIs. There are other methods that you can use to archive the same. There are other ways of constructing objects and so on. Treat this as a sort of API getting started if you’re completely new. If you know your way around, dive right in to the Java doc.

Connecting to the Registry

When you’re connecting to the Registry via the web service API you’re essentially making a remote call. So you need the server address and credentials to connect. All the parameters that you have to set is documented in G-Reg documentation here.

Example initializing a WSRegistryServiceClient,

1
2
3
4
5
6
7
8
9
10
11
12
13
System.setProperty("javax.net.ssl.trustStore", CARBON_HOME + File.separator + "repository" +
                File.separator + "resources" + File.separator + "security" + File.separator +
                "wso2carbon.jks");
System.setProperty("javax.net.ssl.trustStorePassword", "wso2carbon");
System.setProperty("javax.net.ssl.trustStoreType", "JKS");

return new WSRegistryServiceClient(SERVER_URL, USERNAME, PASSWORD,
    ConfigurationContextFactory.createConfigurationContextFromFileSystem(
        CARBON_HOME + File.separator + "repository" +
        File.separator + "deployment" + File.separator + "client",
        CARBON_HOME + File.separator + "repository" +
        File.separator + "conf" + File.separator
        + "axis2" + File.separator + "axis2_client.xml"));

Then before you interact with the Governance API you need to set the Repository write mode system property. If you do not do this all your governance operations (addService etc…) will return null and the operation will not happen successfully.

1
System.setProperty(ServerConstants.REPO_WRITE_MODE, "true");

Up to this point what we did was, we set some properties and now is going to connect to G-Reg and get a registry instance object so that we can do governance related stuff. Code below,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
private static final String CARBON_HOME = "C:\\test\\wso2greg-4.5.3";
private static final String USERNAME = "admin";
private static final String PASSWORD = "admin";
private static final String SERVER_URL = "https://localhost:9443/services/";

private static WSRegistryServiceClient initialize() throws Exception {

    System.setProperty("javax.net.ssl.trustStore", CARBON_HOME + File.separator + "repository" +
            File.separator + "resources" + File.separator + "security" + File.separator +
            "wso2carbon.jks");
    System.setProperty("javax.net.ssl.trustStorePassword", "wso2carbon");
    System.setProperty("javax.net.ssl.trustStoreType", "JKS");

    return new WSRegistryServiceClient(SERVER_URL, USERNAME, PASSWORD,
            ConfigurationContextFactory.createConfigurationContextFromFileSystem(
                    CARBON_HOME + File.separator + "repository" +
                            File.separator + "deployment" + File.separator + "client",
                    CARBON_HOME + File.separator + "repository" +
                            File.separator + "conf" + File.separator
                            + "axis2" + File.separator + "axis2_client.xml"));
}

public static void main(String[] args) throws Exception {
    System.setProperty(ServerConstants.REPO_WRITE_MODE, "true");
    Registry registry = GovernanceUtils.getGovernanceUserRegistry(initialize(), USERNAME);
    GovernanceUtils.loadGovernanceArtifacts((UserRegistry)registry);

    ...
}

At this point you can use the Governance API. Governace API documentation can be found here.

Adding a new service

G-Reg API page for attaching a new service list out basic functionalities of how you can use it. Let’s explore more about how to use the API. First thing you have to do is get a service manager instance from the registry object we just created.

1
ServiceManager manager = new ServiceManager(registry);

void addService(Service service) So we have to create new Service object. Our manager instance have a method to create a new service. Service newService(QName qualifiedName)

Let’s see how a new service creation code looks like,

1
Service s = manager.newService(new QName("http://example.com/ns", "MyServiceName"));

There, easy. We created a new service, in order to add this to the Registry you need to call manager.addService() method passing the service object you just created. The service we just created have a namespace URI and a service name. Nothing else. That’s kinda boring. API supports adding all sorts of additional attributes to stuff this service object. Let’s look at those.

void attachPolicy(Policy policy)
void attachWSDL(Wsdl wsdl)
void attachSchema(Schema schema)
void attachLifecycle(String lifecycle)
void attachEndpoint(Endpoint endpoint)

When you’re adding a service the service must have an endpoint to be useful. Then from other programs you can lookup the registry for services, get the endpoint and talk to that service programmatically. So it has to have at least one endpoint in order to be useful. Let’s add an endpoint.

Here’s a place that I went horribly wrong. I looked at this list of functions and thought I could create a service object, stuff it up with different things like attaching an endpoint, a WSDL etc… and then finally add the service using addService() method. Unfortunately the API doesn’t work like that. In order to attach an endpoint to the service the service should be added first! So, I had below lines which seemed natural to write,

1
2
3
4
5
6
7
8
Service s = manager.newService(new QName("http://example.com/ns", "MyTestService"));

EndpointManager em = new EndpointManager(registry);
Endpoint e = em.newEndpoint("http://mytest.com/service/url");

s.attachEndpoint(e);

manager.addService(s);

Executing the above few lines will give you the following error message which is a bit hard to digest and figure out what’s exactly wrong.

13/01/03 12:14:16 ERROR dataobjects.GovernanceArtifactImpl: A path is not associated with the artifact.
Exception in thread "main" java.lang.reflect.InvocationTargetException
    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 com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:112)
Caused by: org.wso2.carbon.governance.api.exception.GovernanceException: A path is not associated with the artifact.
    at org.wso2.carbon.governance.api.common.dataobjects.GovernanceArtifactImpl.checkRegistryResourceAssociation(GovernanceArtifactImpl.java:619)
    at org.wso2.carbon.governance.api.common.dataobjects.GovernanceArtifactImpl.attach(GovernanceArtifactImpl.java:550)
    at org.wso2.carbon.governance.api.services.dataobjects.ServiceImpl.attachEndpoint(ServiceImpl.java:405)
    at main.java.org.wso2.carbon.registry.importer.XLSImporter.main(XLSImporter.java:76)
    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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)
    ... 5 more

Why does it say a path is not associated with the artifact? The API is designed in such a way that you’re adding or attaching stuff to a resource that exist in the Registry already. If it exist there should be a unique path for that in the registry if not there’s no path. Hence the error. So you have to make sure to add the service first and then attach the endpoint. Following snippet worked like a charm,

1
2
3
4
5
6
7
8
Service s = manager.newService(new QName("http://example.com/ns", "MyTestService"));
manager.addService(s);

EndpointManager em = new EndpointManager(registry);
Endpoint e = em.newEndpoint("http://mytest.com/service/url");
em.addEndpoint(e);

s.attachEndpoint(e);

It’s helpful to note here that this API has 4 things you can attach to a service. Endpoint, WSDL, Policy and Schema. In other words Endpoints, WSDLs, Policies, Schemas and Services seems to be the high level things that you deal with the Governance Registry. But from the UI you will see only four major items. Everything except Endpoints. Endpoints get created automatically when you upload a WSDL to the registry and it’ll create dependencies between the services in the WSDL and endpoints. You can add new endpoints to the Registry through the API as you just saw. If you don’t use the API then how to add a set of endpoints to the Registry? Here you can use WSO2 Developer Studio to create endpoints as resources and upload them to the Registry. So it’ll create endpoints and you can later look them up from the API and attach to your services.

Following the same principal, similarly you can add a schema for this service and attach as well.

1
2
3
4
SchemaManager sch = new SchemaManager(registry);
Schema schema = sch.newSchema(FileUtils.readFileToByteArray(new File("test.xsd")));
sch.addSchema(schema);
s.attachSchema(schema);

Another way to attach stuff to a service is through the addAttribute() method. Has the following signature,

void addAttribute(String key, String value)

So with this method you can add an endpoint and other associated items with a service. In order to add stuff you need to know what are the possible keys. Let’s look at the G-Reg UI for a bit, specifically Add Service UI. The form for adding a service is shown in the following image,

Here the thing that you should note is the sections have a gradient background.So generally the key that you have to use have the format lowercase(section) + “_” + camelCase(name). There are a few exceptions to this though. When you’re adding the service name, the key you should use is overview_name. Here’s the entire list of keys according to the above image.

overview_name
overview_namespace
overview_version
overview_scopes
overview_types
overview_description

So the overview section is pretty much self explanatory after you get to know the convention. Next section is Contacts. When you click Add Contact there will be a two columns to fill. Contact Type (which is a drop down) and Contact Name/Organization Name. The default drop down cannot be changed using this API. Meaning if you provide a new value then it’ll not be automatically added and visible as an item in the drop down. The drop down list of items must be configured before hand when you configure the definition of the service. This definition file can be edited using the G-Reg UI and is referred to as RXT - Registry Extension Type. You can add new items to this service UI by navigating to Extensions -> Artifact Types and edit service. Adding contacts require slightly different syntax. You can add as many contacts as you please so the syntax is,

contacts_entry

For this key, since the value has two columns in the UI you need to separate them with a colon. First field you cannot change, so you need to click the drop down and get what are the possible values and then you should use the exact same value otherwise it’ll not be added. A valid value look like “Technical Owner:John Doe”.

Next, Interface section

interface_wsdlURL
interface_transportProtocols
interface_messageFormats
interface_messageExchangePatterns

Here the URL you give for the interface_wsdlURL should be pointing to a valid WSDL file. At the time of adding the resource Registry will automatically download the WSDL, add it as a dependency and will put the location of the WSDL within the registry in the WSDL URL field. Rest of the drop down fields you need to check the drop down and find out what the actual possible values are and give the exact value.

Same applies for Security section. Possible values,

security_authenticationPlatform
security_authenticationMechanism
security_authorizationPlatform
security_messageIntegrity
security_messageEncryption
security_comments

Next up is Endpoints section. Here you can add any number of endpoints. Endpoints also take two fields. The environment and the actual endpoint. So you have to separate the environment and the URL with a colon. You need to find which environment the endpoint should go on to (Unknown, Dev, Test, Stag, Prod). Here’s an example - "Dev:http://dev.example.com/service". If you just want to add a URL then you should have the colon in front. Otherwise the tokenizer will think http is the first part and will drop it! So adding a URL alone should look something like ":http://example.com/service". Notice the colon at the beginning of the string.

Helium Stick

I’ve been on an outward bound program some time ago that’s designed for leadership and team building. The program itself was educational and had activities that you should do as a team. I was particularly impressed by one such activity that involved getting into two groups, forming two lines face to face and then trying to put down a stick that sits on top of your fingers. Everyone’s goal is to lower your hands so that the stick will go down. Instead what happens is everyone shout at other people to lower the stick but the stick itself goes up! Unbelievable. Then we were told to concentrate on our own hand and not look and others, then the stick actually came down.

After some googling the activity seems to be going by the name Helium Stick. Wilderdom site seems to have a large collection of such games that you typically would do on an outward bound program.

Looking Back 2012

Years come and go. This is one of those years that just flew by in a whim. You just loose track of time when you’re having fun! This year was an exceptional year in terms of the experiences and type of work that I got the opportunity to do.

I got the chance to visit different countries and work with remarkable people and make great friends all over the world! Experiencing different cultures, food, customs, life styles were one of the best parts when it comes to traveling. Another great thing about traveling is that you’ll get to interact with a lot of different people. People from all walks of life. People that work with you, people that you have random conversations with on different places, people that tries to pick up a fight with you on local watering holes, people who’ll try to intimidate you and so forth. Diversity of people are truly amazing. It’s a stark difference to the people you normally would hang out with or get to interact with on your normal walk of life. Being somewhat of an introvert, having to interact with this wide variety of people fascinated me. The more I talked to people the more I realized how little I know and how much is there to learn. There’s an astounding amount of information out there.

Like most programmers I was comfortable looking at a monochrome screen in a dark room doing “computer stuff”. Dealing with computers was far more easier than dealing with people. Then I had to talk to people about it. Not blogging but you know … face to face. Initially it was challenging but it got easier with time. You have to talk/present information in a manner that the other person can understand and explain and clear their doubts. Not one or two people but several. One thing I realized through all these is that writing code is the easy part. Explaining it to people, doing presentations/demos and other human interactions was the hard part. As with anything else, it becomes easier with practice. I loved every second of it. These so called soft skills were invaluable.

As personal life goes, this year was filled with ups and downs, twists and scary turns as well. Life, one of those things that you have to man up and deal with. This year was not without it’s own share of let downs, mistakes and set backs. I’m looking forward to the next year that will bring more challenges and let’s see how things progress.

The year in blogging was not too good. I couldn’t do more than a couple of blogs. Looking forward for a more noisy year in terms of the blog :-) This year marks the year I watched the most confusing and complex movies of all time. It’s none other than Cloud Atlas. With a ridiculously complex plot and as one of the most confusing stories of all time to be put to the telly, it stands out as a significant event this year.

I was thoroughly disappointed about the Mayans. Or I should say angry instead. It’s exactly 10 days passed the dooms day. What a let down. I thought I’ll be going toward a bright light when I wake up 22nd morning but instead there were no bright light. Woke up with a headache instead. Pulling pranks on humanity. Not cool. SRSLY.

I’m forgetting about twenty five thousand other things that have happened over the past year. This is not a thorough analysis but a very short and lazy dump of a few things. I’m really grateful to the things life brought over the past year. It has been truly an amazing ride. I’m looking forward for the year ahead.

Wish you all a happy new year!