Skip to main content

Are You Adapting Your architecture TO suit a vendor??? Learn how to find a vendor who adapts to your architecture?

Countless vendors, including proprietary middleware industry giants like IBM and Oracle, and open source platform companies like WSO2, have built products that enable SOA to varying extents.

But no middleware product has taken a componentized approach to their own middleware “silos”. The features and functions of each middleware product have been predetermined by the vendor’s software designers, not built to each individual customer’s specification.

WSO2 is presenting this nice little article and explaining how we can benefit by using there all new componentized Carbon as a solution for this problem.
http://wso2.org/project/carbon/making_good_soa_great.pdf


Content

  • Componentization reaches enterprise it

  • The need for modular middleware

  • Use case base explanation

  • Painless service creation & integration

  • Set the pace of your SOA adoptions

  • WSO2 Carbon: the evolution of middleware

Comments

Post a Comment

Popular posts from this blog

Overriding default look and feel of GREG - 5.3.0

Following list explains what are the best approach for different use cases. 1 ) - You created a new asset type, and you need to change the look and feel of the details page in the listing page just for that new asset type. To create a new asset type you need to login to the carbon console (username:admin, password:admin) https:// :9443/carbon/ Navigate to Extensions > Configure > Artifacts Click "Add new Artifact" link at the bottom of the page. By default in the "Generic Artifact" area "application" asset type is loaded. Note the shortName="applications" in the root node. "applications" is the name of the asset type. Browse in to /repository/deployment/server/jaggeryapps/store/extensions/assets Create a folder with name "applications"    Now we can override the files in /repository/deployment/server/jaggeryapps/store/extensions/app/greg-store-defaults   Since we are overriding the details page we need to...
Post a Comment
Read more

Simple client side validation library

  Client side validation has never been easy.. Include jQuery and the validator.js < script src = " http://code.jquery.com/jquery-1.11.3.min.js " ></ script > < script src = " ../validate.js " ></ script > Simple validation < form id = " myForm " > < label >User Name < span class = " red-star " >*</ span > </ label > < input type = " text " name = " userName " class = " validate-required " /> < br /> < label >Password < span class = " red-star " >*</ span ></ label > < input type = " password " name = " password " class = " validate-required " /> < br /> < input type = " submit " value = " Login " /> </ form > ...
1 comment
Read more

Role of GREG permission-mappings.xml

 GREG has a permission-mapping.xml. We can find it at /home/chanaka/Desktop/greg/wso2greg-5.2.0/repository/conf/etc/permission-mappings.xml Each entry has three attributes. managementPermission resourcePermission resourcePaths  Ex: managementPermission="/permission/admin/manage/resources/govern/server/list" resourcePermission="http://www.wso2.org/projects/registry/actions/get" resourcePaths="/_system/governance/trunk/servers" /> There are default configurations in this file. These entries are mapping each permission in the permission tree in to resource paths and assign them permissions. With the above line in the permission-mappings.xml, an admin user who assign the permission " /permission/admin/manage/resources/govern/server/list " will be able to do get operations on registry resources stored at " /_system/governance/trunk/servers ". We can provide multiple resource paths by separating them by comas. There...
Post a Comment
Read more