Showing posts from December, 2009

Blue Moon walks us into 2010

As the Blue moon walks us into 2010, its a good time to reflect the past year, but what exactly is the blue moon? lets have the reflection first then the blue moon ... Shall we? thanks :) 2009, a year has past, new lessons learned, new experiences acquired, the world existed before I was born and so will it be when I would be laid to rest. World does not need me for it to go on, for that there is Allah, then in this world no one would be left off without being tried and tested, would i be an exception? Nope sir that is not an option. Amazing the way Allah has designed the test, so dynamic with varying conditions there is no point in life when he is not watching you, the angels recording you, I know we have no choice to opt out of this test. But guys we are human beings and who does not like an easy question paper :). is there a way to get an easy test, there is "One who is satisfied with 'little' from Allah, HE would be satisfied with 'little' from them&q

Kerala High Court Stays Investigations

The Kerala high court has stayed further investigations into a matter of alleged 'forceful conversion' read about it here or here or here

Islamic Role Models

My self and a few friends were visiting a buzurg ( a deeni elder ),  During the wait a discussion spawned up, the topic being who is the role model for the Muslim's from the contemporary time frame. The active discussion revolved around big names alive today including Uelema(Islami Scholars), Saintly elders, Kings, Mufties (the people who gives fatwa), Daees(people who invite towards islam). Each name which came up for the discussions had exceptional qualities. A person said "Look at this person(so and so) see how simple a life he is living" Another said "This persons understanding of the Quraan and Sunna is so very clear, it makes much sense to me" Another was quick to point out "See the impact of this particular persons speeches and discourses, it is really amazing" Another noted "When i listen to the speeches of this person I get this strong inspiration to change and reform my self" Another noted "And this guy, he is

Four Management Lessons

Lesson Number One A crow was sitting on a tree, doing nothing all day. A small rabbit saw the crow, and asked him, "Can I also sit like you and do nothing all day long?" The crow answered: "Sure, why not." So, the rabbit sat on the ground below the crow, and rested. All of a sudden, a fox appeared, jumped on the rabbit and ate it. Management Lesson: To be sitting and doing nothing, you must be sitting very, very high up. Lesson Number Two A turkey was chatting with a bull. "I would love to be able to get to the top of that tree," sighed the turkey, "but I haven't got the energy. "Well, why don't you nibble on some of my droppings?" replied the bull. "They're packed with nutrients." The turkey pecked at a lump of dung and found that it actually gave him enough strength to reach the first branch of the tree. The next day, after eating some more dung, he reached the second branch. Finally after a fort

Climate Treaty Copenhagen

World eagerly awaits for a treaty that would address to safeguard and protect the environment and hence the climate, greenpeace and others are on a 'jihad' to make sure it happens. Despite the dignitaries coming together for this cause, people who are involved still are not expecting  a sensible outcome but what they are hoping for is a miracle to happen. Has the matter of things been degraded to such a level that only miracles can solve the issue? Lets look at the issue at hand here, in a pictorial way   We all human beings are driven by our needs, desires and other activities which impact the world we live in, so there is your cause and there is your effect. Today we are driven by our own selfish desires, which unfortunately do not care much about the impact that it makes, like shown below. Today we are driven by our selfish goals, we are not ready to make some sacrifices and be a little selfless in our matters to reach a consensus for general well being, and yet we

SOA Standards & Building Blocks

SOA is dependent on standards to achieve interoperability and flexibility. It is vital for an SOA architect to have a dashboard that acts as a reference to the various technology standards. This is such a reference deck, to see which all standards you need to know, whether it is for Solution design, implementation, consultancy or even certification. Click on each standards for details. WS-I WSDM BPEL WSRP WS-Transaction WS-Coordination WSDM WS-Security WS-Trust WS-Federation WS-SecureConversation WS-SecurityPolicy WS-Provisioning WS-Privacy WS-Reliable Messaging WSDL UDDI WS-Policy WS- Discovery SOAP,SOAP Attachments WS-Addressing , WS-Notification JMS, RMI, IIOP etc

SOA Building Blocks WSRP

Integration of remote content and application logic into an End-User presentation has been a task requiring significant custom programming effort. Typically, vendors of aggregating applications, such as a portal, write special adapters for applications and content providers to accommodate the variety of different interfaces and protocols those providers use. The goal of this specification is to enable an application designer or administrator to pick from a rich choice of compliant remote content and application providers, and integrate them with just a few mouse clicks and no programming effort. This revision of the specification adds Consumer managed coordination, additional lifecycle management and a set of related aggregation enhancements. This specification is the effort of the OASIS Web Services for Remote Portlets (WSRP) Technical Committee which aims to simplify the effort required of integrating applications to quickly exploit new web services as they become available. This

SOA Building Blocks WS-Privacy

Organizations create, manage and use web services. These organizations need to state their privacy policies. They also need to require that incoming requests adhere to these policies

SOA Building Blocks WS-I

The Web Services Interoperability Organization (WS-I) is an industry consortium chartered to promote interoperability amongst the stack of web services specifications. WS-I does not define standards for web services; rather, it creates guidelines and tests for interoperability. Read about - profile1-2 Read about - profile 1-1

SOA Building Blocks WS-Notification

WS-Notification is a family of related white papers and specifications that define a standard Web services approach to notification using a topic-based publish/subscribe pattern. The Event-driven, or Notification-based, interaction pattern is a commonly used pattern for inter-object communications. Examples exist in many domains, for example in publish/subscribe systems provided by Message Oriented Middleware vendors, or in system and device management domains. This notification pattern is increasingly being used in a Web services context. WS-Notification is a family of related white papers and specifications that define a standard Web services approach to notification using a topic-based publish/subscribe pattern. It includes:     * Standard message exchanges to be implemented by service providers that wish to participate in Notifications     * Standard message exchanges for a notification broker service provider (allowing publication of messages from entities that are not them

SOA Building Blocks WS-Addressing

Web Services Addressing (WS-Addressing) defines two interoperable constructs that convey information that is typically provided by transport protocols and messaging systems. These constructs normalize this underlying information into a uniform format that can be processed independently of transport or application. The two constructs are endpoint references and message information headers. A Web service endpoint is a (referenceable) entity, processor, or resource where Web service messages can be targeted. Endpoint references convey the information needed to identify/reference a Web service endpoint, and may be used in several different ways: endpoint references are suitable for conveying the information needed to access a Web service endpoint, but are also used to provide addresses for individual messages sent to and from Web services. To deal with this last usage case this specification defines a family of message information headers that allows uniform addressing of messages indepe

SOA Building Blocks WS-Discovery

This specification defines a multicast discovery protocol to locate services. The primary mode of discovery is a client searching for one or more target services. To find a target service by the type of the target service, a scope in which the target service resides, or both, a client sends a probe message to a multicast group; target services that match the probe send a response directly to the client. To locate a target service by name, a client sends a resolution request message to the same multicast group, and again, the target service that matches sends a response directly to the client. To minimize the need for polling, when a target service joins the network, it sends an announcement message to the same multicast group. By listening to this multicast group, clients can detect newly-available target services without repeated probing. To scale to a large number of endpoints, this specification defines multicast suppression behavior if a discovery proxy is available on the networ

SOA Building Blocks WS-Policy

WS-Policy is a specification that allows web services to use XML to advertise their policies (on security, Quality of Service, etc.) and for web service consumers to specify their policy requirements. WS-Policy provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of entities in an XML Web services-based system. WS-Policy defines a framework and a model for the expression of these properties as policies. WS-Policy defines a policy to be a collection of policy alternatives, where each policy alternative is a collection of policy assertions. Some policy assertions specify traditional requirements and capabilities that will ultimately manifest on the wire (e.g., authentication scheme, transport protocol selection). Other policy assertions have no wire manifestation yet are critical to proper service selection and usage (e.g., privacy policy, QoS characteristics). WS-Policy provides a single policy grammar to allow both ki

SOA Building Blocks WS-Reliable Messaging

This specification (WS-ReliableMessaging) describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. Many errors may interrupt a conversation. Messages may be lost, duplicated or reordered. Further the host systems may experience failures and lose volatile state. WS-ReliableMessaging provides an interoperable protocol that a Reliable Messaging (RM) Source and Reliable Messaging (RM) Destination use to provide Application Source and Destination a guarantee that a message that is sent will be delivered. The guarantee is specified as a delivery assurance. The protocol supports the endpoints in providing these delivery assurances. It is the responsibility of the RM Source and RM Destination to fulfill the delivery assurances, or raise an error. The protocol defined here allows endpoints to meet this guarantee for the delivery assurances defined below. Persistence considerations

SOA Building Blocks WSDM

WSDM specification (MUWS) defines how the ability to manage, or how the manageability of, an arbitrary resource can be made accessible via Web services. In order to achieve this goal, MUWS is based on a number of Web services specifications, mainly for messaging, description,discovery, accessing properties, and notifications. A Web service endpoint provides access to a manageable resource. An example of a manageable resource is a printer that has the capability to alert when its toner is low, or, a magnetic storage disk that reports its internal temperature in the form of a web service operation. A manageability consumer discovers the Web service endpoint and exchanges messages with the endpoint in order to request information, subscribe to events, or, control the manageable resource associated with the endpoint. An example of a manageability consumer is a management system, or, a business automation process, or simply, any Web service application. In order to discover the We

SOA Building Blocks WS-Provisioning

WS-Provisioning describes the APIs and schema necessary to facilitate interoperability between provisioning systems and to allow software vendors to provide provisioning facilities in a consistent way. The specification addresses many of the problems faced by provisioning vendors in their use of existing protocols, commonly based on directory concepts, and confronts the challenges involved in provisioning Web services described using WSDL and XML Schema. The WS-Provisioning interface is an open standard that is available to other companies that want to develop interoperable provisioning scenarios and systems. Read more about it Here

SOA Building Blocks WS-SecurityPolicy

The Web Services Security Policy Language (WS-SecurityPolicy) specification defines a set of security policy assertions that apply to Web Services Security: SOAP Message Security, WS-Trust, and WS-SecureConversation. This specification takes the approach of defining a base set of assertions that describe how messages are to be secured. Flexibility with respect to token types, cryptographic algorithms, and mechanisms used, including using transport-level security, is part of the design and allows for evolution over time. The intent is to provide enough information for compatibility and interoperability to be determined by Web services participants, along with all information necessary to actually enable a participant to engage in a secure exchange of messages. Read More Here

SOA Building Blocks WS-SecureConversation

The Web Services Secure Conversation Language (WS-SecureConversation) is built on top of the WS-Security and WS-Policy models to provide secure communication between services. WS-Security focuses on the message authentication model, but not a security context, and thus is subject to several forms of security attacks. This specification defines mechanisms for establishing and sharing security contexts, and deriving keys from security contexts, to enable a secure conversation. By using the SOAP extensibility model, modular SOAP-based specifications are designed to be composed with each other to provide a rich messaging environment. Therefore, WS-SecureConversation by itself does not provide a complete security solution. WS-SecureConversation is a building block that is used in conjunction with other Web service and  application-specific protocols (for example, WS-Security) to accommodate a wide variety of security models and technologies. Read More Here

SOA Building Blocks WS-Federation

WS-Federation describes how to use the existing Web services security building blocks to provide federation functionality, including trust, single sign-on (and single sign-off), and attribute management across a federation. WS-Federation is really a family of three specifications: WS-Federation, WS-Federation Passive  Client, and WS-Federation Active Client. WS-Federation itself describes how to implement a federation in a Web services world. In particular, WS-Federation focuses on the relationships between parties and the high-level architecture that supports these relationships. The two individual documents, WS-Federation Active and WS-Federation Passive, describe how to implement individual federation solutions. WS-Federation Active describes how to implement federation functionality in the active client environment. Active clients are those that are Web services-enabled, that is, able to issue Web services requests and react to a Web services response. Leveraging the Web servi

SOA Building Blocks WS-Trust

The Web Services Trust Language (WS-Trust) uses the secure messaging mechanisms of WS-Security to define additional primitives and extensions for the issuance, exchange, and validation of security tokens. WS-Trust also enables the issuance and dissemination of credentials within different trust domains. In order to secure a communication between two parties, the two parties must exchange security credentials (either directly or indirectly). However, each party needs to determine if they can trust the asserted credentials of the other party. This specification defines extensions to WS-Security for issuing and exchanging security tokens and ways to establish and access the presence of trust relationships. The Web service security model defined in WS-Trust is based on a process in which a Web service can require that an incoming message prove a set of claims (e.g., name, key, permission, capability, etc.). If a message arrives without having the required proof of claims, the serv

SOA Building Blocks WSS(WS-Security)

WS-Security describes enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication. These mechanisms can be used to accommodate a wide variety of security models and encryption technologies. The protocol contains specifications on how integrity and confidentiality can be enforced on Web services messaging. The WSS protocol includes details on the use of SAML and Kerberos, and certificate formats such as X.509. The WS-Security specification provides message-level security. The advantage of using WS-Security instead of Secure Sockets Layer (SSL) is that it can provide end-to-end message level security. This means that the messages are protected even if the message goes through multiple services, or intermediaries. Additionally, WS-Security is independent of the transport layer protocol. It can be used for any SOAP binding, not just for SOAP over HTTP.

SOA Building Blocks WS-Coordination

WS-Coordination This specification describes an extensible framework for providing protocols that coordinate the actions of distributed applications. Such coordination protocols are used to support a number of applications, including those that need to reach consistent agreement on the outcome of distributed activities. The framework defined in this specification enables an application service to create a context needed to propagate an activity to other services and to register for coordination protocols. The framework enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment. Additionally this specification describes a definition of the structure of context and the requirements for propagating context between cooperating services.    Applications use the Activation service to create the coordination context f

SOA Building Blocks WS-Transaction

Services within the realm of SOA could be located within an enterprise our outside it, a business process that spans within as well as outside the enterprise would not normally have a session that binds these spanned processes together. What if your account gets debited and the bill is not paid, well ... you can call the customer care and ask them "why is my bill not paid while my account is debited?" and the reply would be "Sir you need to wait 24 hours so that the amount is rolled back/or forward", then you call them after 24 hours and tell them "You said 24 hours my account is still not updated.." and they reply "Sir it is 24 WORKING HOURS ..." well you get the picture, this is about transactions across disparate systems and environments. This is why and where WS-Transactions come into picture. look at the specs here and a artilce here and here 

Building Blocks of SOA - BPEL

Any business is a set of processes which culminate in delivery of goods or services and generating revenue in exchange. SOA provides a technical blueprint with the business to deliver goods/services and generate revenue. Let us take a following flow 1 - The simple shop process starts, when a customer sends a shopping cart and a user ID. 2 - The process requires the delivery address and the credit card number of the customer. The information is sent in two different messages, which may arrive in an arbitrary sequence. 3 - Finally the customer finishes the process and the shopping information is logged. It is possible to make it into a code, write objects, functions and procedures to make this happen. In SOA world we use a different form of coding its called BPEL, the content, variables flow all defined within XML- get details here lets look at a simple variable definition Like wise these the content could be any of these <receive><reply><invoke><