SOA Delivery

The death of SOA has been greatly exaggerated

Lori MacVittie — Fri, 21 Nov 2008 11:09:37 GMT

Amidst the hype of cloud computing and virtualization have been the publication of several research notes regarding SOA. Adoption, they say, is slowing.

Oh noes! Break out the generators, stock up on water and canned food!

An article from JavaWorld quotes research firm Gartner as saying:

The number of organizations planning to adopt SOA for the first time decreased to 25 percent; it had been 53 percent in last year's survey. Also, the number of organizations with no plans to adopt SOA doubled from 7 percent in 2007 to 16 percent in 2008. This dramatic falloff has been happening since the beginning of 2008, Gartner said.

Some have reacted with much drama to the news, as if the reports indicate that SOA has lost its shine and is disappearing into the realm of legacy technology along with COBOL and fat-clients and CORBA.

Not true at all.

The reports indicate a drop in adoption of SOA, not the use of SOA. That should be unsurprising. At some point the number of organizations who have implemented SOA should reach critical mass, and the number of new organizations adopting the technology will slow down simply because there are fewer of them than there are folks who have already adopted SOA.

As Don pointed out when this discussion came up, the economy is factoring in heavily for IT and technology, and the percentages cited by Gartner are not nearly as bad as they look when applied to real numbers. For example, if you ask 100 organizations about their plans for SOA and 16 say "we're not doing anything with it next year" that doesn't sound nearly as impressive as 16%, especially considering that means that 84% are going to be doing something with SOA next year.

As with most surveys and polls, it's all about how the numbers are presented. Statistics are the devil's playground.

It is also true that most organizations don't consider that by adopting or piloting cloud computing in the next year that they will likely be taking advantage of SOA. Whether it's because their public cloud computing provider requires the use of Web Services (SOA) to deploy and manage applications in the cloud or they are building a private cloud environment and will utilize service-enabled APIs and SOA to integrate virtualization technology with application delivery solutions, SOA remains an integral part of the IT equation.

SOA simply isn't the paradigm shift it was five years ago. Organizations who've implemented SOA are still using it, it's still growing in their organizations as they continue to build new functionality and features for their applications, as they integrate new partners and distributors and applications from inside and outside the data center. As organizations continue to get comfortable with SOA and their implementations, they will inevitably look to governance and management and delivery solutions with which to better manage the architecture.

SOA is not dead yet; it's merely reached the beginning of its productive life and if the benefits of SOA are real (and they are) then organizations are likely to start truly realizing the return on their investments.

Technorati Tags: MacVittie,F5,SOA,cloud computing,virtualization,integration,Gartner,JavaWorld,web services,architecture,application delivery,application,blog

Automating scalability and high availability services

Lori MacVittie — Wed, 15 Oct 2008 12:37:16 GMT

There are a lot of SOA governance solutions out there that fall into two distinct categories of purpose: one is to catalog services and associated security policies and the other is to provide run-time management for services, including enforcement of security and performance-focused policies.

Vendors providing a full "SOA Stack" of functionality across the service lifecycle (design, development, testing, production) often integrate their disparate product sets for a more automated (and thus manageable) SOA infrastructure. But very few integrate those same products and functionality with the underlying network and application delivery infrastructure required to provide high-availability and scalability for those services.

The question should (and must) be asked: why is that?

Today's application delivery infrastructure, a.k.a. application delivery controllers and load-balancers, are generally capable of integration via standards-based APIs. These APIs provide complete control over the configuration and management of these platforms, making the integration of application delivery platforms with the rest of the SOA eco-system a definite reality.

Most registry/repository solutions today offer the ability of external applications to subscribe to events. The events vary from platform to platform, but generally include some commonalities such as "artifact published" or "item changed". This means a listening application can subscribe to these events and take appropriate action when an event occurs.

1. A new WSDL describing a service interface (hosted in the service application infrastructure) is published.

2. The listening application is notified of the event and retrieves the new or modified WSDL.

3. The application parses the WSDL and determines the appropriate endpoint information, then automatically configures the application delivery controller to (a) virtualize the service and (b) load balance requests across applicable servers.

4. The application delivery controller begins automatically load-balancing service requests and providing high-availability and scalability services.

There's some information missing that has to be supplied either via discovery, policy, or manual configuration. That's beyond the scope of this post, but would certainly be a part of the controlling application.

Conceptually, as long as you have (a) a service-enabled application delivery controller and (b) an application capable of listening for events in the SOA registry/repository, you can automate the process of provisioning high-availability and scalability services for those SOA services.

If you combine this with the ability to integrate application delivery control into the application itself, you can provide an even more agile, dynamic application delivery infrastructure than if you just used one concept or the other. And when you get right down to it, this doesn't just work for SOA, it could easily work just as well for any application framework, given the right integration.

There already exist some integration of application delivery infrastructure with SOA governance solutions, like AmberPoint, but there could be more. There could be custom solutions for your unique architecture as well, given that the technology exists to build it.

The question is, why aren't folks leveraging this integration capability to support initiatives like SOA and cloud computing that require a high level of agility and extensibility and upon which the ROI depends at least partially on the ability to reduce management costs and length of deployment cycles through automation?

It's true that there seems to be an increasing awareness of the importance of application delivery infrastructure to architecting a scalable, highly available cloud computing environment. But we never really managed to focus on the importance of an agile, reusable, intelligent application delivery infrastructure to the success of SOA.

Maybe it's time we backtrack a bit and do so, because many of the same architectural and performance issues that will arise in the cloud due to poor choices in application delivery infrastructure are the same as those that adversely impact SOA implementations.

Governance in the Cloud

Reliability does not come from SOA Governance

Building a Cloudbursting Capable Infrastructure

The Next Tech Boom: Infrastructure 2.0

Technorati Tags: MacVittie,F5,SOA,cloud computing,governance,iControl,automation,virtualization,application delivery,web services,internet,web,infrastructure

Governance in the Cloud

Lori MacVittie — Tue, 09 Sep 2008 11:17:54 GMT

David Linthicum of Real World SOA asks whether SOA governance should be delivered as a service, from the cloud.

Core to this proposition is the use of a registry/repository in the cloud:

This repository would provide more than just WSDL, but a complete design time and runtime SOA governance system delivered out of the cloud, perhaps linked with a local slave repository within your firewall.

One of the problems with this, I see, is that in a SOA where governance is actively used and policies enforced, governance becomes crucial to not only the day-to-day development efforts but also to run-time execution. I like David's suggestion of a master-slave relationship, but I think it ought to be reversed. The local repository ought to be your master with the slave repository - and public access - in the cloud.

This has the effect of providing a backup repository for corporate use, supporting business continuity and disaster recovery plans, but also allows services to be shared with partners and the public, if desired, without requiring access to corporate infrastructure. Keeping the master repository inside the corporate infrastructure further reduces the potential impact of latency and service interruptions on the business. A local repository mitigates only the impact of a service interruption, it can't address the potential degradation of performance imposed by integrating policies stored remotely.

There are also security concerns that must be considered, and primary amongst them is the question of whether it is wise to store security policies in a potentially publicly accessible repository, as security policies are necessarily a part of SOA governance, especially for run-time governance.

There are certainly some intriguing possibilities here, and David is right to ask whether the cloud can be leveraged for SOA governance functionality. Given that SOA governance is a service regardless where it is deployed, it would make sense to use the cloud to deliver that service in some circumstances. When services will be shared with the public or partners, it makes a great deal of sense to make use of the cloud to govern and deliver those services. But when they are internal only or highly sensitive, it seems that pushing them out to the cloud would be increasing risk rather than mitigating it.

The hybrid model introduced with Cloud Bursting seems to be a very good fit for SOA governance. While SOA governance would not be using cloud bursting in the same way many web applications would - that is, for additional compute resources on-demand - the core concept of using both corporate and cloud computing resources to architect a more flexible, scalable solution seems highly applicable. If services might be heavily used by partners and/or the public, then taking advantage of the cloud to govern those services would alleviate the need to scale up the corporate infrastructure to support it, essentially offloading the cost of management and maintenance of the required additional hardware and software to the cloud provider.

Technorati Tags: MacVittie,F5,SOA governance,SOA,David Linthicum,cloud computing infrastructure,cloud computing,policies,compliance,security,architecture,web,internet,registry,repository

How AJAX can make a more agile enterprise

Lori MacVittie — Tue, 02 Sep 2008 10:50:54 GMT

In general, we talk a lot about the benefits of SOA in terms of agility, aligning IT with the business, and risk mitigation. Then we talk about WOA (web oriented architecture) separately from SOA (service oriented architecture) but go on to discuss how the two architectures can be blended to create a giant application architecture milkshake that not only tastes good, but looks good.

AJAX (Asynchronous JavaScript and XML) gets lumped under the umbrella of "Web 2.0" technologies. It's neither WOA nor SOA, being capable of participating in both architectural models easily. Some might argue that AJAX, being bound to the browser and therefore the web, is WOA. But WOA and SOA are both architectural models, and AJAX can participate in both - it is neither one or the other.

It's seen as a tool; a means to an end, rather than as an enabling facet of either architectural model. It's seen as a mechanism for building interactive and more responsive user interfaces, as a cool tool to implement interesting tricks in the browser, and as yet another cross-browser incompatible scripting technology that makes developer's lives miserable.

But AJAX, when used to build enterprise applications, can actually enable and encourage a more agile application environment. When AJAX is applied to user-interface elements to manipulate corporate data the applications or scripts on the server-side that interact with the GUI are often distilled into discrete blocks of functionality that can be reused in other applications and scripts in which that particular functionality is required.

And thus services are born. Services that are themselves agile and thus enable broader agility within the application architecture. They aren't SOA services, at least that's what purists would say, but they are services, empowered with the same characteristics of their SOA-based cousins: reusable and granular.

The problem is that AJAX is still seen as an allen wrench in an architecture that requires screwdrivers. It's often viewed only in terms of building a user interface, and the services it creates or takes advantage of on the back-end as being unequal to those specifically architected for inclusion in the enterprise SOA.

Because AJAX drives the development of discrete services on the server-side, it can be a valued assistant in decomposing applications into its composite services. It can force you to think about the services and the operations required because AJAX necessarily interacts with granular functions of a service in a singular fashion.

If we force AJAX development to focus on the user-interface, we lose some of the benefits we can derive from the design and development process by ignoring how well AJAX fits into the service-oriented paradigm. We lose the time and effort that goes into defining the discrete services that will be used by an AJAX-enabled component in the user-interface, and the possibility of reusing those services in the broader SOA.

An SOA necessarily compels us to ignore platform and language and concentrate on the service. Services deployed on a web server utilizing PHP or ASP or Ruby as their implementation language are no different than those deployed on heavy application servers using JSP or Java or .NET. They can and should be included in the architectural design process to ensure they can be reused when possible.

AJAX forces you to think in a service-oriented way. The services required by an AJAX-enabled user-interface should be consistent with the enterprise's architectural model and incorporated into that architecture whenever possible in order to derive agility and reuse from those services.

AJAX is inherently an agile technology. Recognizing that early and incorporating the services required by AJAX-enabled components can help build a more agile, more consistent, more SOA-like application infrastructure.

Technorati Tags: MacVittie,F5,SOA,AJAX,PHP,ASP,Ruby,JSP,Java,.NET,agile,reuse,user-interface,services,internet,web,http,architecture,application infrastructure,Web 2.0

SOA What?

Lori MacVittie — Mon, 25 Aug 2008 14:40:40 GMT

David Bressler of Progress Software, who acquired SOA vendor Actional in January 2006 wrote a very thought provoking post on marketing that really ended up being a post about SOA and where Progress fits into the "SOA continuum". He raises some questions, and problems, with SOA and product categories that ties in nicely with an excellent blog post on the subject Todd Biske wrote a while back containing some concepts that he presented at Burton's Catalyst 2006.

One of the confusing things about any market is the wide variety of names used to describe the products and solutions that fit into the wider technology landscape. There are a distinct set of SOA product categories, or SOA What as David calls them. The problem is that there is a lot of overlap in responsibilities between those categories. For example, SOA gateways and SOA management both provide a similar set of proxy-focused capabilities: content based routing, transformation, even service-enablement, but SOA gateways rarely include the robust monitoring and alerting side of management, choosing instead to integrate with existing network management systems (NMS) like HP OpenView or IBM's Tivoli instead.

That makes it difficult to know what you're getting out of a SOA Management product, because it could mean a completely different set of responsibilities when coming from vendor X as it does from vendor Y.

So after thinking about for a while, I think that by combining the David's SOA What categories with Todd's list of intermediary responsibilities we can come up with two distinct categories that makes the picture of the market a bit clearer and simpler.

It comes down to products falling into two primary focus areas with regards to SOA services: managing them and delivering them. Delivery requires a different focus than management, and vice-versa. Delivery is concerned with protocols, security, and functionality traditionally associated with the network, while management is primarily service-focused, concerned with access, integration, and monitoring and, in the case of design-time governance, managing the service life-cycle.

So maybe one of the ways of clearing up the muddy landscape in SOA-land is for vendors to give a clearer picture of their SOA "focus". For example, F5 is, in this model, clearly focused on SOA delivery and not management, and I'd argue that Progress' portfolio is primarily focused on management, not delivery, with some design-time governance and testing thrown in for good measure (now where does that fit??)

I'm not sure if there's really a good solution to the issues raised by David but I think one way to start would be to delineate responsibility of intermediaries across the infrastructure. It certainly makes the picture a lot clearer and by associating responsibilities (and not features) with a particular category it's easier for someone to understand what a particular vendors' solution offers.

Part of the problem is certainly getting on the same page and using the same language. What's funny about that is that one of the premises of SOA was to get business and IT folks using the same language to better align IT with the business. We need to apply that to the vendor and product landscape, as well, so as vendors we can better align our products with customer needs. If you want high-availability and load-balancing of services, you should be able to easily find a vendor focusing on SOA delivery and not wonder whether those delivery features available in a product that focuses on management or governance is going to be "good enough" or not. And vice-versa.

Technorati Tags: MacVittie,F5,SOA,Progress,Bressler,Todd Biske,infrastructure,SOA delivery,SOA management,web services,intermediaries,internet,services,soa gateway,soa governance

Reliability does not come from SOA Governance

Lori MacVittie — Mon, 18 Aug 2008 12:00:19 GMT

An interesting InformationWeek article asks whether SOA intermediaries such as "enterprise service bus, design-time governance, runtime management, and XML security gateways" are required for an effective SOA. It further posits that SOA governance is a must for any successful SOA initiative.

As usual, the report (offered free courtesy of IBM), focuses on SOA infrastructure that while certainly fitting into the categories of SOA intermediary and governance does very little to assure stability and reliability of those rich Internet applications and composite mashups being built atop the corporate SOA.

Effective SOA Requires Intermediaries via InformationWeek

In addition to attracting new customers with innovative capabilities, it's equally important for businesses to offer stable, trusted services that are capable of delivering the high quality of service that users now demand. Without IT governance, the Web-oriented world of rich Internet applications and composite mashups can easily become unstable and unreliable. To improve your chances for success, establish discipline through a strong IT governance program where quality of service, security, and management issues are of equal importance.

As is often the case, application delivery infrastructure is relegated to "cloud" status; it's depicted as a cloud within the SOA or network and obscured, as though it has very little to do with the successful delivery of services and applications. Application delivery infrastructure is treated on par with layer 2-3 network infrastructure: dumb boxes whose functionality and features have little to do with application development, deployment, or delivery and is therefore beneath the notice of architects and developers alike.

SOA intermediaries, while certainly a foundational aspect of a strong, reliable SOA infrastructure, are only part of the story.

Reliability of services can't be truly offered by SOA intermediaries nor can they be provided by traditional layer 2-3 (switches, routers, hubs) network infrastructure. A dumb load-balancer cannot optimize inter-service communication to ensure higher capacity (availability and reliability) and better performance. A traditional layer 2/3 switch cannot inspect XML/SOAP/JSON messages and intelligently direct those messages to the appropriate ESB or service pool.

But neither can SOA intermediaries provide reliability and stability of services. Like ESB load-balancing and availability services, SOA intermediaries are largely incapable of ensuring the reliable delivery of SOA applications and services because their tasks are focused on runtime governance (authentication, authorization, monitoring, content based routing) and their load-balancing and network-focused delivery capabilities are largely on par with that of traditional l2-3 network infrastructure.

High-availability and failover functionality is rudimentary at best in SOA intermediaries. The author mentions convergence and consolidation of the SOA intermediary market, but that same market has yet to see the issue of performance and reliability truly addressed by any SOA intermediary. Optimization and acceleration services, available to web applications for many years, have yet to be offered to SOA by these intermediaries. That's perfectly acceptable, because it's not their responsibility.

When it comes to increasing capacity of services, ensuring quality of service, and intelligently managing the distribution of requests the answer is not a SOA intermediary or a traditional load-balancer; that requires an application delivery network with an application fluent application delivery controller at its core.

The marriage of Web 2.0 and SOA has crossed the threshold. It's reality. SOA intermediaries are not designed with the capacity and reliability needs of a large-scale Web 2.0 (or any other web-based) application. That chore is left to the "network cloud" in which application delivery currently resides.

But it should be its own "cloud", it's own distinct part of the overall architecture. And it ought to be considered as part of the process rather than an afterthought.

SOA governance solutions can do very little to improve the capacity, reliability, and performance of SOA and applications built atop that SOA. A successful SOA depends on more than governance and SOA intermediaries; it depends on a well-designed architecture that necessarily includes consideration for the reliability, scalability, and security of both services and the applications - Web 2.0 or otherwise - that will take advantage of those services.

That means incorporating an intelligent, dynamic application delivery infrastructure into your SOA before reliability becomes a problem.

Technorati Tags: MacVittie,F5,SOA,application delivery,availability,reliability,security,performance,SOA performance,intermediaries,SOA governance,governance,load-balancing,failover

SOA Security: Chain reactions are bad, mmmkay?

Lori MacVittie — Thu, 14 Aug 2008 10:32:42 GMT

As a child of the 80s's I lived under an umbrella of fear surrounding nuclear everything. Living fairly close to a nuclear power plant, we all heard the words "chain reaction" a lot, and though we didn't understand the science we did know that it was a Very Bad Thing^TM and like children in the 60's we were taught to hide under a desk in the event of a catastrophe.

Now, one of the benefits of SOA is reuse. Business services provide consistency across multiple applications when they are reused both for data and for processes. This is a Very Good Thing^TM.

However, reuse carries with it some fairly onerous consequences that can escalate to IT catastrophe status as well, among them those that come with any device or service becoming a single point of failure.

When one application suffers an outage it's a problem, but not a catastrophe. When five applications suffer an outage at the same time that's a catastrophe. Unfortunately if you're part of an organization in which SOA is being relied upon to provide the backbone of your application infrastructure, the "chain reaction" catastrophe scenario is a lot more likely to happen to you than it ever was to us in the 80's.

Reuse is a huge benefit, but it's also a huge risk. If a single service upon which multiple applications depend suddenly becomes unavailable, then all its dependent applications are also, necessarily, unavailable. A problem with a core business service can leave your entire business offline.

So imagine what might happen if an XML-based attack makes it to one of the core business services that comprise your SOA. Exactly. Catastrophe. And when the IT sirens go off you can't simply hide under a desk and wait for the danger to pass. Well actually you can, but your boss is likely to find you eventually. And he won't be happy when he does.

There are many good reasons to centralize SOA security, performance and agility (flexibility) being two very good ones. But perhaps the best reason of all is risk mitigation; minimizing the risk of catastrophe that could easily befall your organization should a core business service suffer an attack and be left unavailable.

Deploying a comprehensive XML/SOA security solution at the edge of your infrastructure, essentially at entry point into your SOA, is one of the best ways to mitigate the risk of a SOA catastrophe. By preventing XML and general application attacks from reaching critical services you can reduce the risk associated with reuse, SOA, and XML.

Many attacks are simply DoS (Denial of Service) focused: exceedingly large messages, excessively nested elements, and recursive parsing attacks. These attacks will not always - but can - cause a complete denial of service (how apropos, this attack name) across all dependent applications because one service is consumed with parsing a malicious request.

Other attacks are more well understood, as SQL injection looks like SQL injection whether it is transported via URL encoded variables or XML elements.

Regardless of what the attack is, it's best to stop it before it gets anywhere near those critical services that power your applications and, by extension, your business. When the result of a successful attack on a service is a "chain reaction" that can bring down core business applications, failing to mitigate that risk as fully as possible makes about as much sense as believing a wooden desk will stop a nuclear blast from vaporizing you.

Technorati Tags: MacVittie,F5,xml firewall,xml,internet,web,http,soa,application deilvery,application security,DoS,sql injection,xml attacks,soa security,reuse

Layer 7 Switching + Load Balancing = Layer 7 Load Balancing

Lori MacVittie — Tue, 12 Aug 2008 11:44:57 GMT

Modern load balancers (application delivery controllers) blend traditional load-balancing capabilities with advanced, application aware layer 7 switching to support the design of a highly scalable, optimized application delivery network. Here's the difference between the two technologies, and the benefits of combining the two into a single application delivery controller.

LOAD BALANCING

Load balancing is the process of balancing load (application requests) across a number of servers. The load balancer presents to the outside world a "virtual server" that accepts requests on behalf of a pool (also called a cluster or farm) of servers and distributes those requests across all servers based on a load-balancing algorithm. All servers in the pool must contain the same content.

Load balancers generally use one of several industry standard algorithms to distribute request. Some of the most common standard load balancing algorithms are:

round-robin
weighted round-robin
least connections
weighted least connections

Load balancers are used to increase the capacity of a web site or application, ensure availability through failover capabilities, and to improve application performance.

LAYER 7 SWITCHING

Layer 7 switching takes its name from the OSI model, indicating that the device switches requests based on layer 7 (application) data. Layer 7 switching is also known as "request switching", "application switching", and "content based routing".

A layer 7 switch presents to the outside world a "virtual server" that accepts requests on behalf of a number of servers and distributes those requests based on policies that use application data to determine which server should service which request. This allows for the application infrastructure to be specifically tuned/optimized to serve specific types of content. For example, one server can be tuned to serve only images, another for execution of server-side scripting languages like PHP and ASP, and another for static content such as HTML , CSS , and JavaScript.

Unlike load balancing, layer 7 switching does not require that all servers in the pool (farm/cluster) have the same content. In fact, layer 7 switching expects that servers will have different content, thus the need to more deeply inspect requests before determining where they should be directed. Layer 7 switches are capable of directing requests based on URI, host, HTTP headers, and anything in the application message.

The latter capability is what gives layer 7 switches the ability to perform content based routing for ESBs and XML/SOAP services.

LAYER 7 LOAD BALANCING

By combining load balancing with layer 7 switching, we arrive at layer 7 load balancing, a core capability of all modern load balancers (a.k.a. application delivery controllers).

Layer 7 load balancing combines the standard load balancing features of a load balancing to provide failover and improved capacity for specific types of content. This allows the architect to design an application delivery network that is highly optimized to serve specific types of content but is also highly available.

Layer 7 load balancing allows for additional features offered by application delivery controllers to be applied based on content type, which further improves performance by executing only those policies that are applicable to the content. For example, data security in the form of data scrubbing is likely not necessary on JPG or GIF images, so it need only be applied to HTML and PHP.

Layer 7 load balancing also allows for increased efficiency of the application infrastructure. For example, only two highly tuned image servers may be required to meet application performance and user concurrency needs, while three or four optimized servers may be necessary to meet the same requirements for PHP or ASP scripting services. Being able to separate out content based on type, URI, or data allows for better allocation of physical resources in the application infrastructure.

Technorati Tags: MacVittie,F5,load-balancing,layer 7 switching,application delivery,application switching,SOA,XML,SOA delivery,clustering

Redefining SOA

Lori MacVittie — Thu, 07 Aug 2008 12:20:30 GMT

We all know that SOA stands for Service Oriented Architecture, right? Gaurav Sharma over at Infosys-Oracle has another definition of SOA and it really fits well with both the business and IT goals surrounding SOA.

Gaurav redefines SOA as Scalable, Open, and Adaptable, and then walks through how Oracle solutions fit this definition. This actually makes a lot of sense, because open and adaptable are inexorably tied to SOA as an architectural methodology. SOA is built on open standards like SOAP, WSDL, and XML and its meta-data driven execution style is highly adaptable, making it flexible or, in the language of SOA and business goals, agile.

You might recall that Forrester Research's latest SOA adoption study cited flexibility (agility) as a key business driver behind SOA implementations in the enterprise.

You might also recall that the "A" in SOA really stands for architecture, and that a complete enterprise architecture requires - or should require - a complementary application infrastructure. That infrastructure should align itself with the goals of the business just as well as the rest of the architecture in which services play a large role. An adaptable architecture, as Gaurav points out, is necessary to tailor solutions dynamically to meet the needs of both the business and IT.

Application delivery networks align themselves well with SOA, whether it's defined as service-oriented architecture or scalable, open, and adaptable. An application delivery controller is, at its core, about providing scalability. Adding support for open standards, both in delivering SOA applications as well as management, makes it open. And adaptability is yet another core tenet of a modern application delivery controller, whether it's through reusable policies or a customizable platform that can adapt in real-time to changing network and application infrastructure conditions.

I like Gaurav's redefinition of SOA as a description of what a SOA ought to be in terms of its attributes. SOA itself is a methodology, an architectural paradigm that should produce an architecture that is SOA (scalable, open, and adaptable).

Technorati Tags: MacVittie,F5,SOA,internet,web,architecture,infrastructure,Oracle,application delivery,SOA delivery

Interactive F5 SOA Reference Architecture

Lori MacVittie — Tue, 22 Jul 2008 11:17:59 GMT

I do an awful lot of talking about SOA: problems, challenges, concepts, solutions, security, products. But I don't often present "the big picture", and certainly rarely discuss how F5 and SOA go together like ice-cream and pretzels. I know, that isn't a traditional simile, but if you've ever tried hot pretzels and ice-cream you might agree with me in saying that while they don't sound like they go together they really do, and they do so well.

It's also applicable because when you think of ice-cream you don't immediately think of pretzels, and I'm fairly certain when you think of SOA you don't think of F5. But once you've tried ice-cream and pretzels, you probably will associate the two, and the same is true of SOA and F5.

But it's a lot less of an investment to run out and grab a hot pretzel and some ice-cream than it is to invest in all the products that make up an application delivery network. So you probably want to know a bit more before you consider it an option.

SOA reference architectures are nothing new, and there's a fairly well-defined reference architecture model for folks to use in order to fit all the applicable pieces together and understand what each entails. So what this interactive presentation offers is a look at F5 and how it fits into that reference architecture in an interactive Articulate presentation, and the suggestion to go ahead - try the pretzel with some ice-cream.

Launch the Interactive F5 SOA Reference Architecture.

Additional resources:

F5 SOA Reference Architecture (White Paper)

SOA Challenges and Solutions (White Paper)

Technorati Tags: MacVittie,F5,SOA,application delivery,web services,HTTP,internet,web,architecture

SOA Delivery

The death of SOA has been greatly exaggerated

Related articles by Zemanta

Automating scalability and high availability services

Governance in the Cloud

How AJAX can make a more agile enterprise

SOA What?

Reliability does not come from SOA Governance

SOA Security: Chain reactions are bad, mmmkay?

Layer 7 Switching + Load Balancing = Layer 7 Load Balancing

Redefining SOA

Interactive F5 SOA Reference Architecture