11th Year of JavaOne, emits more light on SOA, Webservices and .Net with interoperability sessions occupying rooms in between. Most of the SOA, webservices and .Net sessions including subject interoperability were completely full with audience. For the first time, SOA was seen gaining much momentum in the general developer community. Sessions typically concentrated on SOA models. However for SOADevelopers, it committed not many, except for some occasional sessions like SOA Programming model, which did not dive deep anyway. The lump in today’s world of SOA is there are more conceptual modelers who do not speak a developer’s language, while developers are battling management pressures against performance problems, standardizations in document transfers and abstraction within application interfaces. Without this, it would never be a service based model. May it be, but the age of the entities working as independent domain services has arrived. Regulatories will demand the second coming of the SOA. There is no other way except “be-SOA.”

The five days of the JavaOne conference held at Mascone between May 15th to 18th raised dust with software engineers and professionals arriving from distant lands crossing oceans. Beginning with the keynote address, CEO & President Jonathan Schwartz called for openness. Said he is open.
After the crippled open source “movement” for the past two years, by statements like “Open source is dead” coming from open source leaders, this is like getting some fresh air for the community of open source. As was evident, this is simply "the largest JavaOne in the 11-year history. 15000 java enthusiasts warmed up the arena scrolling through display booths, attending sessions, having heated discussions at Birds of-a-feather sessions.
The not so noticeable reduction in booths, at the pavilion could only bee seen as the filtering of core products which finally survived after downfalls in economy and competitions.
Being an attendee for the past 5 years, this year, we see a major thrust in the mobile computing area. Considerable number of high powered WAP devices ha sprouted.
Here are the numbers mobile devices in general. 1 BN+ high-capability cell phones are expected to ship over the next one year. Please note the statement. As wireless broadband, personalized entertainment, and peer-to-peer communication continue to merge, mobile devices are experiencing an explosive period of growth and evolution -- and appear to be the next likely landing spot for such technologies. Ten times as many people bought cell phones in 2004 as bought personal computers. And there are now well over 500 million Java technology-enabled phones in the world -- with over 70 percent of wireless applications under construction using the Java technology runtime environment. Source: Sun Center

Rob Shaddock, corporate vice president and chief technology officer believes, most innovations, will come from "enabling technology." For example, advances in radio technology are on the brink of changing the way a mobile device connects with the Internet. Many devices are becoming multimodal and beginning to incorporate WiFi. Speed. This is also a factor. New high-speed data technologies such as High-Speed Downlink Packet Access (HSDPA) and 1x Evolution-Data Optimized (EVDO) Rev A are bringing DSL-like speeds to the mobile device, causing carriers to optimize their networks for efficient low-latency delivery of data. Next-generation services such as Worldwide Interoperability for Microwave Access (WiMax) take that one step further in performance and cost reduction. With a fast, direct connection to the Internet, these services will challenge the existing operator data services and create new opportunities for developers. The new challenge today, Mr. Shaddock states there is a challenge within developers to keep up with the pace of development of mobile devices. Today, these devices not only enable voice communication but have become de-facto mobile device to manage and share your content and interact with the digital environment.

One interesting display was the Autonomous Dune Buggy, powered with java technology. The java technology vehicle, a research project of the Defense Research Projects Agency(DARPA) was getting great attraction. DARPA grand challenge is a race of unmanned, autonomous vehicles across California desert. DARPA, a forward-looking research agency funded by the pentagon, sponsors the grand challenge to foster innovation in robotic vehicles unmanned by 2015.
Read about it here.
Slot car racing programming challenges contests was interesting. Driven by Real Time Specification for Java ( JSR-01), was fun filled demo.

The SOA Arena.
In all there were 118 technical, BOF and general sessions. There were considerably more SOA sessions which appeared to be focusing on business integration and processes within enterprises.
Some titles of the sessions were thus:-
· What Is Happening With SOA in Open Source?
· Travel Web Services: Marrying Business Innovation with Java™ Technology
· (This concentrated on Travel industry and showcased ian.com)
· Service Component Architecture: Approach to Security, Transactions, and Policy
· Secure Interoperable Webservices Using XML Web Services Security 3.0
· Creating a Digital Ecosystem: Service-Oriented Architectures With Distributed Evolutionary Computing
· The SOA Programming Model – An Interesting session.
Sun’s clarity on open source is becoming clearer.
Many key pieces of an SOA runtime are already becoming available in open source. Various highlights brings together technical experts from Sun, JBoss, Logicblaze, ObjectWeb, Sonic Software, and Tuscany who are working on freely available SOA frameworks.
There was a session on OpenESB., attempting to explain practical SOA Business Integration. Sessions called for composable webservices and deployment. Spanned out of the JBI, JSR 208 session on OpenESB concentrated on developing and running a practical distributed JBI composed services application.
With JSR specifications, JBI, OpenESB and support from organizations, Sun is moving itself up the stack in providing a complete end to end solutions for an SOA.

Glances on some SOA products and complementary.

OpenESB
Based on JBI, Java Business Integration, spec JSR 208, the offering includes an OpenESB with which an SOA environment could be supposedly enabled. This would be a runtime with sample service engines. OpenESB would run on top of runtime project GlassFish.

JBI – Java Business Integration.
Supports existing infrastructure for creating SOA that uses plug-in components for the enterprise integration. Spec JSR 208.

SDO- Service Data Objects.
Working out of JSR-235 SDO, Service Data Objects, provides unifying API and architecture for common enterprise Java technology data programming tasks. SDO implements the common design pattern of using data transfer objects" between logical tiers or components in an enterprise application. Over the past challenges in data retrievals with a service definition in place has open doors of complexity and has not solved the coupling problem.

AJAX – Asynchronous JavaScript and XML
This framework is rapidly changing the way, web development will be ever done. While in the integration lifecycle, enterprises building serviceable components to be deployed will have to adopt this new way of presentation layers. Rich clients have become an intrinsic part of applications having to deliver great volume of data in real time using heavy graphics. With Java server faces and AJAX today this has become seamless.
During the many sessions, there was also a session on SWING. The demo of the application using Flickr was very interesting. Given AJAX having the maximum focus in today’s development scene, whether to go for SWING or AJAX is a question that needed to be asked. Clearly there is more focus on AJAX with even Microsoft supporting it.

Overall the event was organized with schedule builders that were sent out to participants much earlier, organization of the lunch sessions and the evening parties. Duke greeted the visitors and I took a photo or two hand in hand with Duke.
In the end, just a day before the curtains would fall, mythbusters hosted the after dark bash party. Lots and lots of food and two drinks. You could buy more if you paid which is what I did, and finally the chic who was the band of AC/DSHE.

See ya again May 8th 2007. Adios..

Ok. Got some time to upload the images and the listings. There are some documents which are too lengthy and I don't intend to upload it. Please email me if you need it. They are examples. Oh sure! you could download pleanty of them. But if you don't want to run after searches, let me know and here you have these below.
1. Code listings - Zip file
2. WSSE Spec. Case studies
3. SSL/Implementation-step by step.
4. SAML Document
5. How to compose a SOAP for encryption.

Webservice Security Part II
Many standards exist today for implementing webservices security. With standards like WS-Security, XML Signatures, XML Encryption and SAML, it could be a little difficult to decide which way to go, when applications collaborate through webservices.
If we have to just secure a service call, all we need to do is to just implement SSL. Call through HTTPS and client is secured against information being sent across, you know to whom it is being sent etc.
If we need to secure both client and server, we simply implement a two way SSL. By doing so, everything which goes to and fro from client to server and back are all encrypted.
Yes! The SOAP message is now encrypted and is passed through this secured tunnel.
A few questions to ask:
Are service calls completely secured?
Why should I go for any other type of mechanisms when SSL exists?
What is WSSE and why should I implement this?
…More

Like we had discussed in part 1, a webservice call cannot be considered completely secured if we just implement two way secured mechanisms. Sender becomes a trusted party for a receiver and vice versa, but what if the senders receives messages from a third party and there are no secured mechanisms implemented between them? In order to provide total security we need to oversee the following:-
Let there be authentication and authorization mechanisms implemented.
Let there be access control systems in place. This will get down, to a level where system gives access to a specific business processes, based on roles. Yes! This is business centric. Remember, we are talking about securing webservices totally. How can you NOT think of having control over your services? We will discuss this in detail later, the reason.
Let there be message integrity, in other words, message repudiation.
Let encryption methods be standardized.
Let there be prevention methods in place to address DOS attacks.

Figure showing two way SSL implemented:







Drawbacks to the this model.
In the this model, one thing is made sure, the security of the user information, in that nobody can intercept the flow and if at all, they would not be able to sniff out any messages. Data packets would not make any sense to the sniffer. The big question is, are we safe yet? The answer to the question is NO.
Why is it that it is not safe? We are still not sure if the packets contain the appropriate data. A sinffer would have intercepted the messages and would have tampered with the message. What would have been left to flow would have been a corrupted message and so it is still not safe to make a call with just SSL in a two way service call. What else can be done?
A service call is pretty much a SOAP packet. When the envelope is sent to a client, the soap message is embedded inside the packet. We suddenly realize, what is required, is an XML Security.
A network level firewall is deployed at the entry point of a private network . It does the following routines
Monitors all incoming traffic;
Validates the identity of application
Authenticates users based on their identities, which can be the network addresses of service requesters or security tokens;
Checks security and business policies to filter access requests and verify whether the service requester has the right to access the intended resource; and
Provides for encrypted messages so that confidential business information can be sent across the untrusted Internet privately
Although we have the infrastructure in place for all of the above, because webservices send and receive SOAP packets which are XML documents, we still need to fabricate a different secure mechanism to incorporate security for these packets.

XML encryption for Web Services
It is important to know at a high level , features of some of the security protocols from W3C and OASIS.
The XML Signature specification is a joint effort of W3C and IETF. The idea is to provide data integrity and authentication (both message and signer authentication) features, packeted inside XML format.
W3C's XML Encryption specification addresses the issue of data confidentiality using encryption techniques. Encrypted data is packeted inside XML tags defined by the XML Encryption specification.
WS-Security from OASIS defines the mechanism for including integrity, confidentiality, and single message authentication features within a SOAP message. WS-Security makes use of the XML Signature and XML Encryption specifications and defines how to include digital signatures, message digests, and encrypted data in a SOAP message.
Security Assertion Markup Language (SAML) from OASIS provides a means for partner applications to share user authentication and authorization information. This is essentially the single sign-on (SSO) feature being offered by all major vendors in their e-commerce products. In the absence of any standard protocol on sharing authentication information, vendors normally use cookies in HTTP communication to implement SSO. With the advent of SAML, this same data can be wrapped inside XML in a standard way, so that cookies are not needed and interoperable SSO can be achieved. Cookies are considered sometimes even not as safe as it should be.
Check out the following common wellheard of sites.
XML Signature(http://www.w3.org/Signature/,
XML Encryption (http://www.w3.org/Encryption/2001/)
WS Security (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss,
SAML http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security)

There are various kinds of XML-based security standards, XML Signatures, XML Encryption and Web Services Security -- which offer user authentication, message integrity and confidentiality features in SOAP communications.
Please take a note of the red texts above. Those are the important factors in a webservice call. Message repudiation is the biggest challenge in attaining security on a webservice call.
In a world we live in, we hold ‘keys’ to many rooms, boxes, solutions and now for software descriptions.
Asymmetric cryptography is a method in which you hold the private key and the public key is shared. In that, a message is decrypted by the combination of the private and public keys. As long as you hold the private key within yourselves, messages are quite safe.

Symmetric cryptography is a mechanism in which you share the same key for encryption and decryption. Due to overheads in maintaining a Asymmetric cryptographic encryption and decryption for message processing, , it is used often, for sharing the secret shared key for a symmetric cryptography.
With the above said, we will try to understand the need for Digital Signatures. Apart from the above methods of verifying the integrity of the message, concepts called message digest are utilized. Message digests works in a way wherein the sending party sends the message and a digest value along with it. The digest value can be used to verify if the message has been altered or not. The digest value depends upon the data. On receipt of a message, digest value is computed and alteration detected. A problem with this is, it is difficult to know if the data by itself is tampered or not. Since the digest is computed from the data and is send along with the message itself, if both are tampered, it will be difficult to detect.
An application of digital signatures comes here. Along with the message if a digital signature is sent, the receiving party can validate the signature by decrypting it against public key. Once the verification passes, the "message digest" verification, the digital signature is verified. If both passes, we can justify that the communication has been safe. We then confirm that the request is coming from a genuine owner and that the message by itself has not been tampered. Common certificates can be used for digital signatures. This holds the information of the identity of the authority and public key of the owner. The CA will also sign using its private key. This can be used to check for integrity of the certificate.
What we discussed above so far has now been much more standardized. With XML driven requests, the same is being discussed in terms of XML. Thus XMLSignatures are pretty much nothing but utilization of the above using XML.
This gives rise to an interesting subject. The need for XML’s to be processed inside the firewall. Because SOAP message come in as a part of a service call, it is imperative for security reasons to have a processing type of the above nature inside the firewall. Deployment of webservices is a different subject. I would like to explore that next. But at a high level, this is also important.


Thus a typical request will now go through XML Firewall. Here it gets checked with message integrity, passing which user authentication checks are done and business partner validations done, after which the message is passed on to the SOAP server.
XML Digital signature standards are pretty flexible. It can be used anywhere within the SOAP message.
A few examples follows:-
http://riverlog.com/SOA/Listings


Pease note the Canonicalization statement. This is an algorithm applied which is important in XML signatures. It is important to also note that this sequence of attributes matter here while in streaming and message digest validation in XML’s. For this purpose, Canonicalization are utilized. They are meant to produce identical streams for identical XML’s for message digest validation consistency and for attaining accuracy.
WSS relies on XMLDS and XML encryption for low level details and defines a higher-level syntax to wrap security information inside SOAP messages.
WSS describes a mechanism for securely exchanging SOAP messages. It provides the following three main security features:
Message Integrity
User Authentication
Confidentiality
Together, a complete secured service call is made. This obviously does not complete the description on security. Things like SAML, X509 Certificates etc exist.
How secured are we? It could only be imagined the number of attackers sitting beneath the lower grounds of dungeons trying to hack into systems to steal information. But massive attacks on webservie based applications, are yet to begin. They are not there yet. As more standards are being built, many types of implementation exist, thieves are not making such attempts. Lack of that knowledge prevents them from attempting break-in. But we are not so far.

As it is said, the idea is to make a strong feeling, a feeling of being secured!

Thanks for the emails. I will be posting the second part by end of this week.

Sincerely,
Sunny

Webservice Security- Perspectives from an SOA standpoint.

The superior man, when resting in safety, does not forget that danger may come. When in a state of security he does not forget the possibility of ruin. When all is orderly, he does not forget that disorder may come. Thus his person is not endangered, and his States and all their clans are preserved. - Confucius

This is part 1 of the two part article.

As SOA initiatives within enterprise deep roots, a new set of core requirements within various groups arises; the requirement for applications to be made SECURED,in a whole new way. The need for securing applications does not reside just among application groups as it never was. With layered approaches in integration and a services based architecture in place, this now becomes a shared responsibility. Again with new ownership models in place, it even becomes one of the key challenges in the implementation process.

Again, as I have always quoted, this need not be as difficult as it seem.

The two major needs:-
As opposed to dinosaurian age, security is not just a security team's responsibility which often is rippled through application groups. With rigid security measures like inspection of code and underlying architecture approval procedures, above all the rough talks that goes to and fro between application groups, security groups, infrastructure and possibly other groups, during the final few moments of release, has again created a need. Such several needs and the resolutions have put pressure on engineers to opt for a better way in implementing security.
Thus a need for a layered approach has complemented the need for service based architecture.

With this in picture, a new set of requirements raised. This would not make things difficult, but would now need some slight shifts in the way we make applications secure. The good part of the story is, now applications have suddenly become easier to maintain, security is more layered and so it is easy to communicate between stakeholders and what needs to be done to make it tightly secured. No more rough talks and disputes on what went wrong and who did that and so on and so forth.

Need A
From lessons learnt, a great deal of effort has been put in place to see that the new approach is measurably a great approach.


Why would this be different at all? What have thou brought forth?

Today's application requests originate from anywhere. In the sense, the call could be either an internal call or from a totally outside source, both are speeding towards the same destination, coming inside the enterprise seeking data. The life cycle of such a request would travel through various phases and would breeze through several protocols. These requests carry packets of data which in today's world are all XML. The evolvement of XML has bought in so powerful feature for business transactions which are semantically rich and structured data, they are text-based, and ready for web in nature; provide both challenges and opportunities for the application of encryption and digital signature operations to XML-encoded data. The data is business centric. As important as protecting the confidentiality of business messages is ensuring their long-term authenticity, data integrity and support for non-repudiation; in other words, functionality that ubiquitous, existing Internet security technologies (e.g., SSL and username/password) do not provide alone. It is clear to us that data needs to be streamed in through various check points and with a service oriented architecture approach, it is required to be verified and may be even inspected for business validations, at different levels. This could cause bottle necks in performance and throughput to a large extent. Thus, the need for XML data, to be protected at various levels, arises. A common infrastructure that would provide authentication and authorization and final packet delivery of untouched data by sniffers or man in the middle, need to be delivered in real-time. Again, as quoted earlier, this XML will be streamed through several check points where it might require some level of authentication, thus raising a key challenge of overcoming performance overheads and throughputs. It could be so cumbersome in certain cases, where incoming requests are high volume and where payloads are huge, that, it would cause networks to cripple down.

Need B
The requests coming in for seeking data today will carry with it huge XML packets. Therefore, at any point of time, network wires will be carrying and shuttling these XML packets, thus creating a need for XML aware network services to be in place, and they better be secured.

Securing XML

Yes. There is no one way or the other. The need is to secure the XML.
As Gartner says, infiltrating a corporate network by tapping into Web services interfaces is potentially more damaging than simply knocking out a Web site, because business-to-business applications expose valuable corporate information. Because XML messages are wrapped in the IP "envelope" that most firewalls are designed to track, corporate networks inspect the envelope but not the contents. Fraudulent XML messages could therefore enter corporate networks undetected.

Managers at corporations and agencies slowly realize that XML, the standard file format for sharing information in Webservices in a Service Oriented Architecture environment, is susceptible to attacks and viruses. Calls to webservices could be fictitious calls and could cause Denials of services and attacks could place malicious code inside the XML packets. Today, Consultants and officials at companies devoted to Webservices security are raising managers' level of awareness.

There are several vendors who play in this field. There are products like XML Firewall, XML Security gateways, Webservices security products and XML security frameworks. With these and XML accelerators, what was then a difficult task seems more seamless.

The implementation Basics:

With all these existing, within an enterprise, where complex systems which are already proven and in good working condition, to change it, for better support and maintenance perspectives and for that purpose, enforce security becomes more easier said, than done. Such a system needs to be approached in a strategic way and needs to be phased out, which many have begun to do so. Several security mechanisms and standards exist today. From XML Signature, XML Encryption, SSL, Certification to WS Security and SAML, different requirements dictate the implementation.

Whether to use WS Security or just SSL or to use simple two way certification where server and client mutually verify each other, all these depend largely on the type of requirement and may vary from projects to projects.

No matter what you do, simply make it all secured. Hackers are not yet ready for attacking a webservice based environment. Those attacks today, the very few, are NOT yet complex. But such attempts which are destructive in nature can be expected soon.
And hence securing your services is imperative.

In the next article, we will look into some code examples to handle different types of security mechanisms mentioned earlier in the article.

info@riverlog.com.

A Holistic Approach To Business Process Integration, Where Strategy & Architecture Dictates

To stay competitive, companies must be agile in adapting their business processes to the ever-changing market dynamics. The adaptive business process based enterprises should look beyond the traditional enterprises and marketplaces through collaborative interactions and dynamic e-business solution bindings. The enterprise infrastructure has to provide the capability for dynamic discovery of trading partners and service providers as well as enabling federated security mechanisms, solution monitoring and management.

The need to project focus on the emerging business process modeling has to be realized, simulation, integration and management using emerging technologies. With cluster of collaborative business, demanding trading partners to share proprietary data, creates a need to have a system that would integrate applications within and beyond firewalls and would facilitate seamless integration between applications. In a distributed and decentralized process oriented environment, enterprises function within the boundaries as independent business units, but function by itself and serve as separate service domains. Several service domains interact to share proprietary data. These reside in separate operating systems as well. Architecture becomes a key point in solving such an IT environment, where composite applications send and receive data which are proprietary and most importantly requires adaptability to new services.

WebServices

Today’s accelerated time-to-market and focus on costs require rapid implementation of new solutions while leveraging existing IT investments. The number of integrations is exploding—but integration doesn’t have to be overwhelmingly complex. The Integration architecture that unifies the speed and cost-effectiveness of Web Services with various data formats and traditional ways of integrating has to be understood, thus fueling the process of aligning business to IT. Gartner had indicated that only a few will be successful in transformation of legacy systems into new business dynamics in the integration space. Engineers who know new technologies like J2EE, Java or .NET may not be able to understand COBOL systems. The existence of XML and parsing of such documents are evading the requirement for understanding of legacy code. Thus webservices plays a vital role in the overall integration activities across the enterprise.

Challenges in Data conversion

With evolvement of webservices, a standardized way of sharing of data exist, but gives way to a lot of other areas that require a thorough understanding, such as XML parsing issues, XML Security, performance and compliance with policies. With these pass-thru's, the system will now considerably slide down in performance graphs. Overhead in processing time will become a key challenge. Secondly, deployments will demand several other layers to appear raising heavy performance alarms to IT managers who support high availability systems. Through methodologies which revolves around Straight Through Processing harness systems, accelerators and advanced process integration tools and strategies, A reference model for integration between business processes, which would then leverage webservices and visual tools for enabling a process integration framework that would complement a Service Oriented Architecture environment.

The Approach

Enablement of an SOA requires strategic phased approach in planning, identifying projects, defining a path to success and final deployment plans. This requires a great understanding of business domains and all about heterogeneous systems within an enterprise. Not just that, but have in possession, a wealth of visual tools and software. For this, a union of technology partners need to exist. Compliance with IT governance and regulatories for the organizations needs evaluation for these products. Thus, an end to end solution for an SOA is weaved. This addresses key challenges in implementation and works closely with organizations to pave their success path.

The Eco System and foresight.

Webservices will evolve and start clustering. To develop, test and deploy, thus managing the integration modulars, will need a system that would eventually do business process management. This will require document choreography and webservices orchestration for least. Best practices and design principles need to be applied while in the evolvement process. Thus, systems that would react to events will rise. Because of this need, applicaton containers have extended itself to hold integration modulars, like business process integrators, business clients and message bus. Need for application request dispatchers, sensitive to document based systems will arise. Routing of information will use one too many methods and therefore will be unpredictable, unknown at originating points. A total distributed request switching stations will overcome the peer to peer method of delivery and will defeat hub based centralized systems.

We are living in a separate world! - Bob Dylan

A Holistic Approach To Business Process Integration, Where Strategy & Architecture Dictates

To stay competitive, companies must be agile in adapting their business processes to the ever-changing market dynamics. The adaptive business process based enterprises should look beyond the traditional enterprises and marketplaces through collaborative interactions and dynamic e-business solution bindings. The enterprise infrastructure has to provide the capability for dynamic discovery of trading partners and service providers as well as enabling federated security mechanisms, solution monitoring and management.

The need to project focus on the emerging business process modeling has to be realized, simulation, integration and management using emerging technologies. With cluster of collaborative business, demanding trading partners to share proprietary data, creates a need to have a system that would integrate applications within and beyond firewalls and would facilitate seamless integration between applications. In a distributed and decentralized process oriented environment, enterprises function within the boundaries as independent business units, but function by itself and serve as separate service domains. Several service domains interact to share proprietary data. These reside in separate operating systems as well. Architecture becomes a key point in solving such an IT environment, where composite applications send and receive data which are proprietary and most importantly requires adaptability to new services.

WebServices

Today’s accelerated time-to-market and focus on costs require rapid implementation of new solutions while leveraging existing IT investments. The statistical numbers of integration related work is exploding—but integration doesn’t have to be overwhelmingly complex. The Integration architecture that unifies the speed and cost-effectiveness of Web Services with various data formats and traditional ways of integrating has to be understood, thus fueling the process of aligning business to IT. Gartner had indicated that only a few will be successful in transformation of legacy systems into new business dynamics in the integration space. Engineers who know new technologies like J2EE, Java or .NET may not be able to understand COBOL systems. The existence of XML and parsing of such documents are evading the requirement for understanding of legacy code. Thus webservices plays a vital role in the overall integration activities across the enterprise.

Challenges in Data conversion

With evolvement of webservices, a standardized way of sharing of data exist, but gives way to a lot of other areas that require a thorough understanding, such as XML parsing issues, XML Security, performance and compliance with policies. With these pass-thru's, the system will now considerably slide down in performance graphs. Overhead in processing time will become a key challenge. Secondly, deployments will demand several other layers to appear raising heavy performance alarms to IT managers who support high availability systems. Through methodologies which revolves around Straight Through Processing harness systems, accelerators and advanced process integration tools and strategies, A reference model for integration between business processes, which would then leverage webservices and visual tools for enabling a process integration framework could be built. This would then, complement a Service Oriented Architecture environment.

The Approach

Enablement of an SOA requires strategic phased approach in planning, identifying projects, defining a path to success and final deployment plans. This requires a great understanding of business domains and all about heterogeneous systems within an enterprise. Not just that, but have in possession, a wealth of visual tools and software. For this, a union of technology partners need to exist. Compliance with IT governance and regulatories for the organizations needs evaluation for these products. Thus, an end to end solution for an SOA is weaved. This addresses key challenges in implementation.

The Eco System and foresight.

Webservices will evolve and start clustering. To develop, test and deploy, thus managing the integration modulars, will need a system that would eventually do business process management. This will require document choreography and webservices orchestration for least. Best practices and design principles need to be applied while in the evolvement process. Thus, systems that would react to events will rise. Because of this need, applicaton containers have extended itself to hold integration modulars, like business process integrators, business clients and message bus. Need for application request dispatchers, sensitive to document based systems will arise. Routing of information will use one too many methods and therefore will be unpredictable, unknown at originating points. A total distributed request switching stations will overcome the peer to peer method of delivery and will defeat hub based centralized systems.

We are living in a separate world! - Bob Dylan