On the standards front, groups such as the Event Processing Technical Society are working on developing common languages, formats and more for CEP tools. In the meantime, enterprise IT managers today should work with their business intelligence, BPM, middleware or SOA vendors on how they can make CEP work in their environments. Enterprise users need to understand the technologies they have today that could augment or enable more advanced CEP capabilities before selecting a vendor or tool, Kobielus says.

"If users want to bring CEP in, they need to ask their vendors to what extent their CEP technology implementation would be consistent or interoperable with their current SOA stack. Without set standards, each user has to understand what they have before they bring in more tools," he says. "It is entirely possible to create more of a mess with multiple [enterprise service buses], SOA governance tools and CEP products."

Security in a dynamic environment

The advent of SOA represents many changes for IT environments, not the least of which involves security.

The nature of SOA introduces flexibility and transitions an environment from being static to behaving in a dynamic fashion to meet business needs. SOA applications are loosely coupled and reuse components scattered about an environment, which is not ideal for the locked-down nature of most enterprise security technologies in use today. The impending issue of security in an SOA environment has some industry watchers looking for technologies and tools that could fall into a bigger category of security-oriented architecture or put simply, security for SOA.

"The fundamental security challenge that SOA presents is that by abstracting IT capabilities and data as services, the security for those capabilities is at risk of being lost," says Jason Bloomberg, principal and senior analyst at ZapThink. "As a result, SOA essentially necessitates enterprisewide identity and access management to maintain the security context for users as they interact with abstracted services -- essentially allowing the right users to do what they're supposed to do. Services must also be protected from threats, as well -- preventing the wrong users from doing what they're not supposed to do."

That means instead of locking down systems, IT security executives need to learn how to attach security measures to components that operate independently in the environment. One way to provide such protection is with XML firewalls or content-level protection (such as the technology Citrix just acquired with QuickTree) and endpoint security tools, such as antivirus, network access control and intrusion-prevention tools. Other options include an up-and-coming extension of identity and access management technologies dubbed entitlement management that includes fine-grained, role-based access controls. These technologies require granular policies for access rights to applications, which could be extended into an SOA environment.

"Security is becoming identity-centric, and this goes well beyond simply directories and into detailed entitlements. That is a move in the right direction," says Andreas Antonopoulos, a founding partner at Nemertes Research. "We have to move away from the security model of the past that involved one vendor and closed systems with little ability to do anything outside of that system. In an SOA environment, you may have one primary security vendor, but that vendor can accept data from multiple sources to make security more fluid to better address subtle threats and to ensure protection across the components."

But the issue around securing SOA environments today isn't the lack of promising concepts; it's the absence of standards, industry watchers say. Stand-alone SOA security vendors such as Forum Systems and Layer 7 have emerged to augment the market and security efforts by SOA providers such as SOA Software and Software AG. Yet pure-play security vendors haven't quite come on board with the effort, which stalls standards and prevents true security-oriented architectures from being developed, Antonopoulos says. For now, that leaves enterprises cobbling together their identity and access management and single sign-on deployments to SOA initiatives.

"SOA and applications vendors are working more and more for security, but security vendors simply aren't getting involved. That is a problem, because you need all your security components to be able to talk to each other. Start-ups addressing the issue of SOA security can only take it so far," Antonopoulos says.

Essentially, security-oriented architecture technologies would be similar to SOA technologies: not one product, but several products equipped to communicate, integrate and secure the overall environment. While OASIS and other standards bodies are working on standards such as Web-Services Security, or WS-Security, without security vendors signing on to comply there isn't much headway in terms of integrated security across an SOA environment yet.

"Most systems can talk SOAP for instance. But typical security systems are deaf, dumb and blind to SOAP. Buyers need to make SOA features critical to their security buying decisions going forward," Antonopoulos says. "2008 will bring a higher level of adoption for SOA and that is going to put pressure on security infrastructure to adapt and security vendors would be well served to work on those integrations and standards that would enable the exchange of information security-oriented architecture requires."