Enhancing BPM Processes Performance

Declaring BPM Processes Instance Variables as "Separated"...

From my personal experience it has been seen so far that if the BPM Processes has big Instance Variables like Value Objects,Transfer Objects, Collection Objects, they consume lot of memory for processing each single instance and BPM Engine starts throwing Severe Exceptions like "Max Instance Size has exceeded",which will hinder the progress of execution of business activity.

Below is the short synopsis related to different ways of increasing Max Instance Size in ALBPM...

Advantages:
1)Enhance BPM Processes Execution
2)Lowering the BPM Message size can affect the performance of these processes specially...

Disadvantages of Higher Message size:
Each single process instance takes that much more time to persist to BPM DB and they are stored as Binary Objects(BLOB) in DB...so it will increase the cache memory/space consumed by these processes in DB

Workaround with 32KB Instance Size:
Declare these 'big' (10k or more) instance variables (VO/TO)as 'separated'. In ALBPM,while declaring variables,there is an attribute called 'Category' and the default value is 'Normal'. If you declare an instance variable as 'Separated' the data will be stored in another database table and it's size won't count towards the process instance size and it will not affect the BPM DB Cache Memory..

Cataloging Components in ALBPM

1)When registering/creating Java Libraries as part of External Resources in BPM Studio, we have two options :Versionable and Non-versionable
If we select "Versionable",then the JARS will be included in the Project Export from Studio and when the project is published and deployed into an Enterprise Environment, then these will be stored as binaries in the BPM Directory Service..The BPM Engine and Workspace applications will be pulling them and injecting into appropriate classloader...As per the configuration for the Java Libraries in the Enterprise Process Administrator,they are just there for a reference..The binding is determined at project publication time if we use "Versionable" Java Libraries..

2)On the other hand,if we use Non-Versionable Libraries for BPM Cataloging,then manually we need to include them into Process Administrator's Classpath...Most likely, these JARS wll need to be copied into Process Administrators' WEB-INF/lib directory.... and the path is, ~/albpm5.7/j2eewl/webapps/webconsole/WEB-INF/lib and then restart the BPM Server...

Basic principle to follow before you catalog BPM components in Studio is to make sure

1 )The "External Resources" does include "Versionable" libraries before publishing/deploying the BPM project to get the latest JAR files and make them run in ALBPM Enterprise Server. Right Click -> "External Resources" -> Select "Versionable" -> then do a publish/deploy project in Studio.

2) Then complete the BPM Catalog process manually from studio

Copy the Application JARS in BPM Webconsole and Portal WEB-INF/lib folder and regenerate BPM EAR to get latest versions of these files and then execute BPM cataloging from Studio using External Resources..

Anatomy & Physiology of Android OS

Android has been designed as a modern mobile platform that will enable applications to take full advantage of the mobile device capabilities. This session will break down the various components of the Android platform, examine how they work, and give developers a deeper understanding of the underlying technologies that drive the Android platform...

This video tutorial will give you deep understanding of how Linux Kernel 2.6.24 is stacked up inside Android OS including the different drivers,libraries and runtime interfaces which drives the Android platform and the applications which run on it....

Source: GoogleDevelopers

EJB 3.1 Specifications Overview

Source: The Server Side.....

Kenneth Saks is the specification lead for Enterprise JavaBeans 3.1 (JSR 318) . This talk will give the latest update on the contents of the EJB 3.1 specification , which will soon be released for Public Draft Review.

With its 3.0 release, the Enterprise JavaBeans™ (EJB™) architecture underwent a dramatic simplification targeted at ease of use for application developers. The purpose of the Enterprise JavaBeans 3.1 specification is to further simplify the EJB architecture by reducing its complexity from the developer's point of view, while also adding new features in response to the needs of the community.

Topics will include : .war packaging of EJB components, improved unit testing support, portable global JNDI names, singleton beans, startup/shutdown callbacks, a simplified(no interface) local view, asynchronous session bean invocations, automatic timer creation, and more

Live Video streaming by Ustream

Visa to Develop Applications for Android, Nokia Phones

Visa wants to become a part of your mobile phone, working with Nokia on realizing mobile payments and also announcing services for Google's Android platform.

The idea of using the mobile phone as a payment device has been around for along time, but has not yet encountered widespread success. With more than 3 billion mobile devices already in the market today, though, Visa sees a big opportunity to extend its reach, according to Elizabeth Buse, global head of product at Visa.

For future owners of the T-Mobile G1 and other upcoming Android phones, Visa will at first include three services, Alerts, Offers and Locator, which will be available for download before the end of the year.

With Alerts consumers will receive what Visa calls "near real-time" notification of purchase activity, based on rules defined by the cardholder.

Offers and Locator will make it possible for users to receive targeted offers, based on for example previous purchases, and show consumers nearby locations of shops or ATMs that accepts Visa. The two functions can also be combined. Consumers would opt in to the services, only activating those they choose, and would be able to opt out at any time, according to Visa.

The services will at first be offered to Chase Visa card holders in the U.S., and Visa says it plans to add more banks later.

Visa is also developing a payment application that will enable consumers to make mobile payments with Android phones.

Visa's work with Nokia is also about making payments possible using the mobile phone. Using the Nokia 6212 classic, expected to be available starting next month, users will be able to make contactless payments, remote payments, money transfers, as well as receive alerts and notifications, according to Nokia.

What makes all that possible is built-in support for a technology called NFC (Near-Field Communications), which lets consumers simply wave the phone within a few inches of a special point-of-sale reader to complete a transaction.

Nokia and Visa will first do trials with financial institutions, but for it to really take off the retail sector has to get onboard, and that is currently a blocking point, according to Richard Webb, directing analyst at Infonetics Research.

"Mobile payments are a good thing for the mobile sector, but there is no real gain for the retail sector, which would have to upgrade its systems for payments to work," said Webb.

Companies such as Nokia and Visa have to explain what's in it for retailers, but there are also other aspects that need to be addressed before mobile payments can take off, including security and trust, according to Webb.

Business Process Management- Quick look at three more products

Business Process Management ,the subject or concept which is gripping every major enterprise applications deployment now-a-days coupled with SOA/Web Services, has been part of my pedigree since more than a year now and the more I tend to learn about it, the more I feel like a naive,its such a vast concept . Many people have asked me how do you define a "Business Process Management"? and I tend to come up with different answers (not my fault...because each of the BPM solution providers have their own definition and meaning to it.

First thing first, as part of BPM initiatives so far I have been exposed to different products like Jboss JBPM(I still feel this is the best one,as far as IDE based BPM tools go,next best Intalio) , Albpm , Savvion & Intalio.

Currently Iam working on an enterprise application using ALBPM(Aqualogic BPM) from BEA as the BPM product and good thing is adopted by many leading companies and the thing which sometimes worries me about it is very little documentation and support from BEA(thats my perception) and coming from IDE background primarily for most of the development ,I feel it is behind Jboss Jbpm or Intalio because these products does support IDEs like Eclipse,which definitely makes my life easy as a Developer,Well BEA may argue with me that ALBPM Studio 6.0 has development environment similar to Eclipse or rather built on Eclipse IDE,but then Iam using ALBPM Studio 5.7 right now which doesnt come with full IDE support ...But I must say among commercial solutions this fits the bill...

And over the year,one thing which has worried me as a BPM Developer is how best I can make the Business Analysts or the business folks,understand the business processes which I have developed better,because in hindsight we expect them to be not technical savvy to really understand the workflow pattern being used nor how it has been developed since their major priority is how best this workflow/application fits their business needs .....For Example,l to overcome this situation,in one of my assignments while using Jboss Jbpm,I had to develop an EXE file or installer (something like Java Web Start)for BA and Testers,which simulates the workflow processes being developed without them having to worry about seeing it in action in a IDE ..And then as part of my curiosity and research,I realized there are different BPM solutions/products out there in IT industry that are so easy to understand ,that even non-technical folks can understand.And with this article Iam going to introduce such BPM products because most of them are browser based and not IDE based ...

Today we will be looking at 3 different BPM products that have been adopted by noted companies and how best they are serving the needs for workflow management and development.I will be giving an overview about each one of them,their features and benefits
I) Appian : Accidently I came across this product and it is definitely worth trying in any business process management effort. And when I see its customers list who have adopted Appian-Enterprise-based business process management (BPM) solution for their IT department it definitely must have some reason to it.Then I realized the advantages/benefits it brings to the table.From its legacy in the portal/knowledge-management (KM) space, Appian has built its functionality into a full blown BPM suite. In turn, it's built on a Java base following the Unified Modeling Language (UML) and the XML Process Definition Language (xPDL). (These are solid standards all, and which seem to be doing what standards should do without the interference of the European Union and Document Freedom Day groupies--. From an open source perspective, Appian comes with JBoss out of the box but of course works with WebSphere and WebLogic. It makes use of Lucene search engine as well. Not open source but Appian’s doing some real interesting stuff with KX Systems Kdb.

But the good news is that users don’t have to worry about all that technology stuff . Appian’s Form and Rules Designers and other real-user-facing components all work vis a straight Web interface (no need for Flash, plug-ins, etc.). That’s important for security requirements, which is key to many of Appian's government customers. But it is also good for ease of use for any customer. More important are the ease of Appian BPM implementation templates developed over the 10 years since it was founded. Examples are available for procurement in federal government, for wealth management with rules for credit scoring, a program with Instill to build a quality management solution for the food/service industry... I think the best place to know about Appian would be seeing its recorded webinars

II) Cordys
Cordys BPMS is a single toolset, built from the ground up to offer comprehensive BPM and SOA capabilities, giving business managers direct control over new and existing processes.And I you see the below listed features,Iam sure everyone will be curios to use and test it for their BPM efforts.And when I see that a utility which I use frequently for my business needs "WebEx", the leading provider of Web communication services has adopted Cordys,I gave it a try.
Features & Benefits :
a)Graphical, browser-based interface
* Accurately draw executable business processes using a Visio-like application
* Bridge the gap between business and IT
* Enable business users to control and quickly change their own processes
* Consolidate and present data from disparate sources as one unified and personalized workspace for higher productivity
b)Intuitive, drag-and-drop business process execution, with virtually no coding
cDistributed, fault-tolerant, and scalable architecture
* Configure nonstop, fault-tolerant runtime environments with no single point of failure on commodity hardware
d)Real-time alerts and notifications
* Accelerate responsiveness to critical events and exceptions
e)Operational intelligence dashboard
* Obtain real-time, enterprise-wide visibility of business process performance and business metrics
f)Historical analysis
* Discover enterprise performance trends for more-informed decision making
g)Composite application framework
* Create Web 2.0 interfaces quickly by visualizing, combining, and manipulating data from disparate sources
h)Composite application developer
* Create needed business services
i)SOA Grid
* Connect incompatible systems together, allowing them to communicate
* Rapidly assemble composite objects based on a variety of previously non-interoperable backends
* Govern and manage Web services, both in design and run time
j)Data manager
* Facilitate template-based reconciliation of differences among disparate data connected to the Cordys platform
k)Secure file transfer
* Provide end-to-end document security, including legal grade non-repudiation and guaranteed integrity of transmitted data

III) Lombardi
Last but not the least is Lombardi.Best place to know about this product is its resource section
Major customer which has adopted Lombardi's Teamworks BPM software is Wells Fargo Financial.

I hope some of the organizations start looking at adopting at either one of these for their BPM implementations,considering how easy they can be understood and used by workflow developers,business folks and Business Analysts.

Developing Secure Web Services

Web Services,SOA,everywhere.Well,it certainly has so much positive impact on current IT community and proving its worth being adopted by leading industry players such as IBM, HP, Oracle, Microsoft, Novell, and Sun for different Web Services products.Yes Iam talking about SOA-Web Services which are here to stay and look set to dominate the deployment of major enterprise applications in the coming years.


IBM’s definition of Web Services states that “Web Services are self-contained, modular applications that can be described, published, located, and invoked over a network, generally, the World Wide Web.” In one of my previous articles,Web Services Patterns we looked at the advantages provided by SOA applications.
When the definition refers to Web Services being invoked over the World Wide Web, it means that they use HTTP as the transport layer and an XML-based message layer. However, Web Services do not actually require HTTP—XML-formatted data can be sent over other transport protocols (message queuing, for example), which may be more suited to mission-critical transactions.

Web Services generally uses the HTTP and SSL ports (TCP ports 80 and 443, respectively) in order to pass through firewalls. In the early days of “Web Services,” vendors would say that their products were “firewall compliant.” This meant that firewalls would not block the Web Services traffic, whereas CORBA traffic attempting to use CORBA-specific ports may be blocked. Web Services make it easier to deploy distributed computing without having to open firewall ports, or having to “punch a hole in the firewall” as network administrators like to say. This “under the radar” deployment has serious security implications. Most firewalls are unable to distinguish Web Services traffic, traveling over HTTP and SSL ports, from Web browser traffic.
The word “Services” in Web Services refers to a Service-Oriented Architecture (SOA). SOA is a recent development in distributed computing, in which applications call functionality from other applications over a network. In an SOA, functionality is “published” on a network where two important capabilities are provided— “discovery,” the ability to find the functionality, and “binding,” the ability to connect to the functionality. In the Web Services architecture, these activities correspond to three roles: Web Service provider, Web Service requester, and Web Service broker, which correspond to the “publish,” “find,” and “bind” aspects of a Service-Oriented Architecture.

Web Services security focuses on the application layer, although security at the lower layers remains important. The implementation technologies on which we focus are HTTP and SOAP, although we will keep SMTP security in mind also since SOAP can be bound to SMTP as well as HTTP.It may not seem immediately obvious why security for SOAP presents such a challenge. After all, SOAP is generally bound to HTTP, which already has SSL for authentication and confidentiality. In addition, many Web authorization tools already exist. It is a reasonable question to ask why these aren’t enough, and the answer is made up of a number of reasons.The first reason is that, although frequently bound to HTTP, SOAP is independent of the underlying communications layers. Many different communications technologies can be used in the context of one multi-hop SOAP message; for example, using HTTP for the first leg, then SMTP for the next leg, and so forth. End-to-end security cannot therefore rely on a security technology that presupposes one particular communications technology. Even in the case of a single SOAP message targeted at a Web Service, transport-level security only deals with the originator of the SOAP request. SOAP requests are generated by machines, not by people. If the Web Service wishes to perform security based on the end user, it must have access to authentication and/or authorization information about the end user on whose behalf the SOAP request is being sent. This is the second reason for Web Services security.

SOAP is a technology used to enable software to talk to other software much easier than was previously possible. End users (that is, humans) do not make SOAP messages themselves. However, if access to the Web Service is to be decided based on the information about the end user, the Web Service must have access to the information that allows it to make this authorization decision. This information does not have to include the end user’s actual identity.How can this information about the end user be conveyed to the Web Service? Session layer or transport layer security between the application server and the Web Service doesn’t convey information about the identity of the end user of the Web Service. It merely conveys information about the application server that is sending the SOAP message. It may be the case that many of the requests to the Web Service originate from that application server.This challenge is addressed by including security information about the end user in the SOAP message itself. This information may concern the end user’s identity, attributes of the end user, or simply an indication that this user has already been authenticated and/or authorized by the Web server. This information allows the Web Service to make an informed authorization decision.This scenario is likely to be widespread where many Web Services are used to implement functionality “behind the scenes.” It shouldn’t be the case that the end user has to reauthenticate each time a SOAP request must be sent on their behalf. The challenge of providing this functionality is sometimes called “single sign-on” or “federated trust.”

WS-Routing provides a means for SOAP messages to route between multiple Web Services. WS-Routing defines how to insert routing information into the header of a SOAP message. This routing information can be thought of as equivalent to routing tables that operate at lower layers of the OSI stack for routing IP packets.WS-Routing means that one SOAP message may traverse multiple SOAP “hops” between the originator and the endpoint. The systems that implement these hops may have nothing in common apart from the ability to parse and route a SOAP message.When routing between Web Services, the requirement for confidentiality can apply from the originator through to the final SOAP endpoint. It may be a requirement that information be kept secret from SOAP intermediaries. There may be a chance that intermediaries may disclose the information either deliberately or through leaving “gaps” between one transport-level security session and the next. While the data is decrypted, it is vulnerable. This is the same problem that plagued the first release of the Wireless Access Protocol (WAP), in which data was decrypted in between the wireless encryption session and encryption on the fixed wire. This so-called “WAP gap” caused a loss of confidence in WAP security and was addressed in later releases of the WAP specification. Implementing encryption only at the transport level makes a “SOAP gap.”It is often noted that most security breaches happen not while data is in transit, but while data is in storage. This is the principle of least resistance—attempting to decrypt eavesdropped encrypted data from an SSL session is much more difficult than simply testing if a Web site maintainer has remembered to block direct access to the database where the credit card numbers are stored. If decrypted data is stolen from a database, the consequences are no less dramatic. Once data has reached its final destination, it must be stored in a secure state. Confidentiality for a SOAP transaction should not involve simply chaining instances of confidentiality together, since “SOAP gaps” of unencrypted data are available between each decryption and encryption.

Web Services Security Specifications
Confidential information in a SOAP message should remain confidential over the course of a number of SOAP hops.A number of industry specifications have been developed for this purpose. These specifications can be organized into two distinct categories:A standardized framework to include XML-formatted security data into SOAP messages.Standards for expressing security data in XML format. This security information should be used for the high-level principles of security: confidentiality, authentication, authorization, integrity, and so forth.

WS-Security
WS-Security has emerged as the de facto method of inserting security data into SOAP messages. Work on WS-Security began in 2001, was published by Microsoft, VeriSign, and IBM in April 2002, and was then submitted in June 2002 to the OASIS standards body in order to be made into an industry standard. WS-Security defines placeholders in the SOAP header in order to insert security data. It defines how to add encryption and digital signatures to SOAP messages, and then a general mechanism for inserting arbitrary security tokens. WS-Security is “tight” enough to present the definitive means of including security data into SOAP messages, but is “loose” enough to not place limits on what that security data can be.

XML Encryption
XML Encryption is a specification from the W3C. It provides not only a way of encrypting portions of XML documents, but also a means of encrypting any data and rendering the encrypted data in XML format. XML Encryption makes encryption functionality easier to deploy.XML Encryption is not a replacement for SSL. SSL is still the de facto choice for confidentiality between two entities that are communicating using HTTP. However, if the security context extends beyond this individual HTTP connection, XML Encryption is ideal for confidentiality. The capability to encrypt XML is nothing new, because XML is just text after all. However, the ability to selectively encrypt XML data is what makes XML Encryption so useful for Web Services. Encrypting an entire SOAP message is counterproductive, because the SOAP message must include enough information to be useful—routing information, for example. Selectively encrypting data in the SOAP message is useful, however. Certain information may be hidden from SOAP intermediaries as it travels from the originator to the destination Web Service.XML Encryption does not introduce any new cryptography algorithms or techniques. Triple-DES or RSA encryption may still be used for the actual encryption. XML Encryption provides a way to format the meta-information about which algorithm was used, and when the encryption occurred. This aids the Web Service in decrypting the data, provided the decryption key is available to it. This is important, because prior to XML Encryption the only standardization of encryption data was for e-mail messages (that is, S/MIME). If an organization wished to send encrypted data to another organization, both organizations would have to agree on the format of the encrypted data, how and which algorithms to use, and possibly also how to send an encrypted key. Now that information can be contained in an XML Encryption block.

XML Signature
XML Signature is a specification produced jointly by the W3C and the Internet Engineering Task Force (IETF). Like XML Encryption, it does not only apply to XML. As well as explaining how to digitally sign portions of an XML document, XML Signature also explains how to express the digital signature of any data as XML. As such, it is an “XML-aware digital signature.” PKCS#7 is a means of rendering encrypted data, and signed data, which predates XML Signature and XML Encryption. Rather than using XML, it uses Abstract Syntax Notation number 1 (ASN.1). ASN.1 is a binary format, renowned for its complexity. Producing or verifying a PKCS#7 signature requires not just cryptography software, but also an ASN.1 interpreter. XML Signature also requires cryptography software, of course, but an XML DOM replaces the ASN.1 interpreter.
The power of XML Signature for Web Services is the ability to selectively sign XML data. For example, a single SOAP parameter passed to a method of a Web Service may be signed. If the SOAP request passes through intermediaries en route to the destination Web Service, XML Signature ensures end-to-end integrity.WS-Security describes how to include XML Signature data in a SOAP message. An important feature of XML Signature is that it can be very selective about what data in an XML instance is signed. This feature is particularly useful for Web Services. For example, if a single SOAP parameter needs to be signed but the SOAP message’s header needs to be changed during routing, an XML Signature can be used that only signs the parameter in question and excludes other parts of the SOAP message. Doing so ensures end-to-end integrity for the SOAP parameter while permitting changes to the SOAP’s header information.

Security Assertions Markup Language (SAML) provides a means of expressing information about authentication and authorization, as well as attributes of an end user (for example, a credit limit) in XML format. SAML data may be inserted into a SOAP message using the WS-Security framework. SAML is used to express information about an act of authentication or authorization that has occurred in the past. It does not provide authentication, but can express information about an authentication event that has occurred in the past; for example, "User X authenticated using a password at time Y.” If an entity is authorized based on the fact that they were previously authorized by another system, this is called “portable trust.” SAML is important to address the challenge of multihop SOAP messages also, because separate authentication to each Web Service is often out of the question. By authenticating once, being authorized, and effectively reusing that authorization for subsequent Web Services, single sign-on for Web Services can be achieved.Note that this information in a SAML assertion may not indicate the end user’s identity. The user may have authenticated using a username and password, and the administrator of the Web site may have no idea of the user’s actual identity. It may simply be an indication that the user presented credentials and was authenticated and authorized. SAML allows information to be placed into a SOAP message to say “this person was authorized according to a certain security policy at a certain time." If the recipient of this SOAP message trusts the issuer of the SAML data, the end user can also be authorized for the Web Service. This SAML data is known as an “assertion” because the issuer is asserting information about the end user. The concept of security assertions has existed before SAML, and is already widely used in existing software.

XML Access Control Markup Language (XACML) is designed to express access control rules in XML format. Although the two technologies are not explicitly linked, XACML may be used in conjunction with SAML. An authorization decision expressed in a SAML assertion may have been based on rules expressed in XACML.

Microsoft’s Passport technology takes a different approach to single sign-on. The user authenticates to the passport infrastructure, either directly through www.passport .com or through an affiliate site that makes use of functionality provided by passport.com. Once the user is authenticated and authorized by Passport, their authentication status is also available to other Web Services that use Passport. Like SAML, this provides single sign-on. However, the model is different, relying on a central point of authentication rather than SAML’s architecture where authentication happens at an individual Web Service. By being implemented at the site of the Web Service itself, SAML authentication and authorization information may be based on role-based security. Role-based security means that access to resources is based on the user’s organizational role; for example, in a medical setting doctors may have access to certain information while nurses have access to different information.

In this article(from Web Services Security),I tried to just give an overview on the different specifications that can be used to achieve Web Services security,for a detailed understanding,I suggest get a good book like this one,"Web Services Security",to whom I owe these excerpts,and get a clear understanding as to implementing and using specifications for securing the web services you develop.And thanks to ,Mark O'Neil,for his inputs and allowing me to use some stuff from his book.

Recommended books :

Suggested Reading

WS-Security Specification

Web Services Standards & Specifications

Web Services Security-by IBM

Implementing Service Firewall Pattern


Suggested Video Tutorial
Secure and Reliable Web Services-by InfoQ

SAML-An Overview

Web Services Attacks & Defense Strategies

Different Design Patterns for Web Services-An Overview

Web Services provide an important building block for integrating disparate computing platforms and, indirectly, provide a mechanism to integrate their global value chains. You can build Web Services after the system was originally deployed, making them similar in many ways to today's EAI software, but you can also build them along with new software as the open Application Programming Interface (API) to the application.

Advantages of using Web Services
Using Web Services , you can build an API which islanguage- neutral and platform-neutral format, programmers can access data from one system and quickly move it to the other through the Web Service. There are several strengths to this approach:

• Programmers can write the data-transfer programs in any language or platform with which they are comfortable.

• The source and target systems can control the requests and updates of data in such a way that they do not interfere with a running system.

Consider the number of ways that a simple problem, such as notifying interested parties of a change to an object's state, are solved with a platform such as Java 2 Standard Edition. Some developers may use an intermediate file to track changes, with interested parties reading the file to find out when and how an object changed. Other developers may construct a point-to-point notification system, or even a set of one-to-many Publish/Subscribe patterns. Some developers may have one type of naming convention for the adding and removing of listeners; other developers may not have any naming convention for the same operations-these are some of the areas where Web Services can be highly useful

Using Design Patterns
Patterns can be applied to any portion of the software cycle which usually involve gathering requirements, creating the architecture, designing the software, and implementing it.Thousands of software design patterns document the common problems encountered by software designers and generic solutions for those problems. For example, an architect may give a system structure that identifies a point in the system where an object change drives listeners to make changes in their own state, or the change kicks off a business process. In these cases, a designer can look and determine that the Publish/Subscribe or the Observer pattern can fulfill the requirements and constraints an architect put on the design. Once identification of patterns is complete, the generic structure given in a pattern drives the design of the particular system structure.

Web Services Design Patterns
The following patterns look at how Web Services implement the service-oriented architecture, how service implementations interact with the Web Service environment, and how to locate and use Web Services:
Service-Oriented Architecture: The Web Services environment is an architecture implementation known as the service-oriented architecture. There are several different implementations of the service-oriented architecture with Web Services having the most penetration in the industry to date. Implementations of service-oriented architectures stress two attributes: implementation transparency and location transparency. Implementation transparency requires a common system structure that applies equally to all possible underlying service implementations and a neutral mechanism for describing services. Location transparency requires the use of agnostic interfaces.
Architecture Adapter: This pattern expands on the GoF Adapter pattern. Although the GoF Adapter pattern resides in object-oriented programming as a way to adapt an exposed interface from a component to an expected dependent interface from another component, the Architectural Adapter pattern is responsible for allowing two completely separate architectures to interoperate.
Service Directory: In statically bound systems, and even in many dynamic systems, companies assume that their choices for the purchaser of software are the right choices. The Web Service paradigm challenges this tradition. Instead, by creating detailed metadata about a service, a service user should be able to locate your service and use it without application modification. The metadata in a service-oriented architecture includes its interface, location for binding, mechanism for communication, and information about the business that created the service. This pattern goes into depth on the Service Directory patterns that are inherent in the leading service architectures and that you will encounter in Web Services.
Business Object: This pattern discusses the typical structure and contents of a single business object. Although the frequency that you will use a single business object for deployment is low, there are substantial lessons you can learn from the exercise of deploying a business object. As with the first three patterns, this pattern is heavy in discussion around the Web Service environment and lessons you can learn from deploying relatively simple objects.
Business Object Collection: In business, you will rarely find business objects that are not collected. Like the business object itself, handling collections with Web Services yields substantial instructional substance as you learn more about the Web Service environment.
Business Process (Composition): Business systems today revolve more around business processes than around supporting business objects. A business process does not necessarily correlate to a single business object but is more abstract in nature. This pattern looks at business processes and lays a general framework for exposing them as Web Services. The business process is also a form of composition. To achieve a business process, multiple business objects and, often, other business processes and activities must run.
Asynchronous Business Process: A world where all business processes are synchronous would be a fine world to live in for programmers. Unfortunately, most important business processes are not synchronous. Even the most basic business processes, such as fulfilling a book order, run into asynchronous complexities. In introducing the Asynchronous Business Process pattern, you will find many similarities to the relationship between business objects and business object collections
Event Monitor: Often, the burden of determining when events occur in a service lies with the client. There are a variety of reasons for this, such as the service not having a reasonable publish/subscribe interface or the client desiring control of the event determination. This is a common, and relatively simple, design pattern to implement that has well- established roots throughout software history.
Observer: Rather than leaving a client to determine when data changed on a server, it is often more efficient to have the server component tell interested clients when data changes. This is especially true when the server component has a low frequency of updates compared to the frequency that clients will want to check. The Observer pattern formalizes the relationship between one or more clients and a Web Service that contains interesting state. The Web Service delivers events to interested clients when an interesting change occurs. The Gang of Four documented the Observer pattern. This implementation is similar to the original documentation of the pattern, with necessary information about Web Services.
Publish/Subscribe: The Publish/Subscribe pattern [Buschmann] is a heavily used pattern in EAI software as well as in many distributed programming paradigms. The Publish/Subscribe pattern is interesting in the context of the definition of Web Services as application components. Using a topic-based mechanism common in very loosely coupled architectures, you create a stand-alone event service that is, in effect, an application component. The event service forwards published events to subscribers without awareness of the application components that use the event service.
Physical Tiers: Throughout the book and the sample implementations in the chapters, you will use a simple Java-based deployment mechanism built into Apache Axis. Therefore, your components live entirely within the process space that Apache Axis uses. This is not an optimal model for enterprise applications. The model discourages runtime reuse and creates a larger footprint than is necessary. Further, the event patterns produced some interesting challenges for a Web Service environment. A client interested in events from a Web Service often exists in its own process. This pattern discusses Web Service implementations that must, and often should, communicate to other processes for their implementation behavior.
Faux Implementation: One of the most fascinating pieces of the Internet is the ability of someone or something to be able to pretend to be something they are not and actually get away with it. As long as an interface and the behavior of a service implementation is what others expect, there is no way to tell what drives the behavior of the service implementation. The Observer and Publish/Subscribe patterns require clients to implement a Web Service to receive event publications. The Faux Implementation pattern shows that as long as the behavior fulfills the contract, there is no reason you have to implement a service with traditional mechanisms
Service Factory: Class factories are common in Java programming. A class factory gives a mechanism to bind to a class implementation at runtime rather than compile time. The same capability is possible with service implementations. For example, there is no reason that a company must use a single package shipper for all shipments. Instead, the service factory illustrates how your application can determine what service to use at runtime.
Data Transfer Object: The Data Transfer Object pattern originated with Java 2 Enterprise Edition (J2EE) patterns. When you move from a single process application to a distributed application, calls between participants in the distributed architecture become more expensive in terms of performance. By giving clients mechanisms to get groups of commonly accessed data in single operations, you can streamline clients and lower the number of accesses necessary to your Web Service.
Partial Population: The Data Transfer Object pattern passes fully populated data structures between programs. This is a great paradigm but creates a proliferation of data structures and relegates the service implementation to determining what the most likely groups of accessed data will be. Partial population takes a different approach to data transfers; it allows clients to tell the server what parts of a data structure to populate. In this way, you can lighten the burden on the communication mechanism as well as the query in the server object. This technique is especially useful for services that contain complex, nested data structures (not something you will typically find in a Web Service environment).

Suggested Reading

Patterns for Service Oriented Architecture

Web Services Integration Patterns-Part 1

Web Services Integration Patterns-Part 2

Enterprise Integration Patterns


Suggested Video Tutorial

Developing SOA applications

Real World Web Services

Web Services Middleware


Web Services Overview


Thats All for now !!