|
| DevCentral > Weblogs > - Two Different Socks
|
SOA
There are 70 entries for the tag SOA
 |
A recent blog on EBPML.ORG entitled “REST 2010 - Where are We?” very aggressively stated: “REST is just a "NO WS-*" movement.” The arguments presented are definitely interesting but the most compelling point made is in the way that REST APIs are constructed, namely that unlike the “ideal” REST API described where HTTP methods are used to define action (verb) and the path the resource (noun), practical implementations of REST are using a strange combination of both actions (verbs) and resources (nouns) in URIs. What this does is simulate very closely SOA services, in which the endpoint...
posted @ Tuesday, March 02, 2010 4:04 AM |
|
|
What is needed to customize the cloud is a pair of data center ruby slippers called Infrastructure 2.0. Frank Gens of IDC discussed the “New IDC IT Cloud Services Survey: Top Benefits and Challenges” in his blog and what is not surprising is that security continues to top the challenges associated with cloud services. What may be surprising to some is the increasing focus on customization. It shouldn’t be. As customers continue to push at the boundaries of the cloud computing model they will inevitably find it unable to meet some need they have, such as customization....
posted @ Friday, February 26, 2010 3:31 AM |
|
|
There’s a difference between automation and orchestration, and knowing which one you’re really doing is half the battle in achieving a truly dynamic data center. Randy Heffner on CIO.Com wrote an excellent article on SOA and its value, “SOA: Think Business Transformation, Not Code Reuse.” The problem I had with the article was not in any way related to its advice, conclusions, or suggestions. The problem I had was that I kept thinking about how perfectly much of his article could be applied to data center orchestration, operational transformation, and automation. Simply replace “SOA” with “orchestration”, “software reuse”...
posted @ Monday, February 22, 2010 3:43 AM |
|
|
Preparing for the upcoming Cloud Connect conference several speakers and presenters have put forth the proposal that no one should attempt to define cloud yet again. After all, if you’re attending the conference (and you are attending, of course, aren’t you?) then you certainly have a firm understanding of what cloud computing is and what it can do. But most end-users and business stakeholders won’t be attending and don’t have a firm understanding of cloud computing. Even the technology pundits to whom these constituents turn to learn about the technology often fail to really “get” cloud computing, as evinced...
posted @ Friday, February 12, 2010 3:50 AM |
|
|
One of the concerns with cloud bursting specifically for the use of addressing seasonal scaling needs is that cloud computing environments are not necessarily PCI-friendly. But there may be a solution that allows the application to maintain its PCI-compliance and still make use of cloud computing environments for seasonal scaling efficiency. Cloud bursting, a.k.a. overdraft protection, is a great concept but in some situations, such as those involving PCI-compliance, it can be difficult if not impossible to actually implement. The financial advantages to cloud bursting for organizations requiring additional capacity on only a seasonal basis are well understood,...
posted @ Thursday, January 21, 2010 5:54 AM |
|
|
A recent tweet about a free, Linux-based XML Security suite reminded me that we do not opine on the subject of XML security and its importance enough. SOA has certainly been dethroned as the technology darling du jour by cloud computing and virtualization and with that forced abdication has unfortunately also come a reduction in the focus on XML and security. That’s particularly disturbing when you recognize that what’s replaced SOA – primarily WOA and RESTful APIs – exchange data primarily via one of two formats: XML and JSON. Whether you prefer one over the other is...
posted @ Friday, December 11, 2009 3:51 AM |
|
|
The question is whether that impact is positive (a reduction) or negative (an increase). One of the biggest threats to data integrity is the introduction of malicious content via SQLi (SQL Injection) attacks. Traditional database access methods don’t provide a lot in the way of validating requests and like HTML the vagaries of SQL allow for myriad ways in which a statement can be constructed – and thus exploited. These vagaries, of course, are one factor in the reason why SQLi continues to plague applications and sites driven by user generated content. Another factor is certainly...
posted @ Monday, November 16, 2009 4:52 AM |
|
|
These three things have a lot more in common than you might think and all three tend to evoke similar levels of frustration. A very real problem women face when shopping is this: no two brands define a size the same. If you usually wear a size 8 in “Brand X” you might actually wear a size 10 or 6 in “Brand Y”, depending on how the brand decided to define its sizing. Customers, women in this case, cannot count on consistency in sizes across brands. This makes shopping annoying because every time you change brands you’re never...
posted @ Thursday, November 12, 2009 4:05 AM |
|
|
Cloud computing management functionality and standards are right now laser-focused on virtual machines, and most APIs include the ability to stop,start,launch,etc…at that level of the infrastructure. This is because the application is still insulated by its virtualized environment. The “depth” of management and standards efforts today stops at the hard shell of the virtualization layer and leaves the soft, chewy application center alone. This means nothing is really all that different for developers. But it could, and some might argue should, be different. The development of a web-application for a cloud computing environment today is really...
posted @ Monday, November 09, 2009 3:57 AM |
|
|
Amazon’s ELB is an exciting mix of well-executed infrastructure 2.0 and the proper application of SOA, but it takes a lot of work to make anything infrastructure look that easy. The notion of Elastic Load Balancing, as recently brought to public attention by Amazon’s offering of the capability, is nothing new. The basic concept is pure Infrastructure 2.0 and the functionality offered via the API has long been available on several application delivery controllers for many years. In fact, looking through the options for Amazon’s offering leaves me feeling a bit, oh, 1999. As if load balancing hasn’t...
posted @ Thursday, October 15, 2009 3:50 AM |
|
|
AJAX enables the use of network-side scripting enabled application delivery solutions to offload client-side functionality and improve capacity and performance of dynamic (Web 2.0/AJAX) applications. In the last couple of weeks I’ve embarked on a home project to rewrite – from scratch – a couple of web applications that Don and I and friends use on a regular basis. Consider it a very restricted (in terms of users) social networking application, because that’s basically what it is. I made heavy use of AJAX for one component in the past version but have been really leveraging it a lot more...
posted @ Wednesday, September 16, 2009 5:02 AM |
|
|
A load balancing algorithm can make or break your application’s performance and availability It is a (wrong) belief that “users” of cloud computing and before that “users” of corporate data center infrastructure didn’t need to understand any of that infrastructure. Caution: proceed with infrastructure ignorance at the (very real) risk of your application’s performance and availability. Think I’m kidding? Stefan’s SOA & Enterprise Architecture Blog has a detailed and very explanatory post on Load Balancing Strategies for SOA Infrastructures that may change your mind. This post grew, apparently, out of some (perceived) bad behavior on...
posted @ Tuesday, September 08, 2009 4:11 AM |
|
|
The real power behind cloud is processes, and those don’t come out of a box VMworld, in case you’ve been out of touch, is approaching fairly quickly. As with any trade show/conference there’s likely to be a lot of announcements about this and that and oh, of course, that too. What is interesting about cloud computing and virtualization is that most of the really exciting announcements are not going to be about new products or new features. You heard me, they aren’t going to be about new products or features. The foundations for cloud...
posted @ Tuesday, August 25, 2009 3:41 AM |
|
|
Why Carr’s analogy doesn’t describe today’s cloud environments and how SOA can get us closer to what he describes Back when cloud first starting drifting in to obscure the computing landscape there were a lot of parallels drawn between it and grid, and a lot of analogies used to explain the concept behind it. Cloud computing is most often analogized using Nicolas Carr’s analogy of the cloud as an electrical grid; that’s always bothered me at almost a visceral level. But I could never articulate why well enough and a lot of smart people told me that if I...
posted @ Monday, August 10, 2009 3:57 AM |
|
|
The “replace” in “rip and replace” essentially means getting rid of old security problems and replacing them with new ones. Twittergate is (thankfully) behind us but it’s almost assuredly going to be the case that we’ll be rehashing this one for a while. This certainly isn’t the first time Twitter and security issues have clashed, and as in the past Twitter (and really any very public application in a similar situation) is the clear loser. And of course there comes the unsolicited advice offered regarding what Twitter needs to do to address its security issues. I am, of...
posted @ Monday, July 20, 2009 3:43 AM |
|
|
Is ESB just an expensive integration hub or is there more to the story than we heard… In the beginning, the ESB (Enterprise Service Bus), was marketed as much more than an integration technology. While the core of an ESB is certainly about connectivity between services, there was – and still is – so much more to an ESB than just integrating disparate protocols and technologies. Transformation, parallel processing, content based routing, and service orchestration are among the more useful and beneficial capabilities of an ESB. That’s why it was somewhat surprising to see the CTO of...
posted @ Friday, July 17, 2009 3:26 AM |
|
|
One of the interesting points that discussions around intercloud brings up is the need for infrastructure to, if you’ll pardon the use of marketing jargon, align with the business. What that really means is that applications and their supporting infrastructure need to be more business-aware. Thing is you don’t really need intercloud or even cloud or even virtualization for many of these business-aware capabilities. They are certainly a boon, but solutions that include application delivery functionality don’t need to wait for a fully-baked cloud or intercloud implementation. Consider, for example, the potential of business-layer load...
posted @ Wednesday, July 15, 2009 3:55 AM |
|
|
No, that isn’t a homophonic mistake. Dan directed my attention to an interesting article recently, “Are 3-tier web architecture models too rigid?” in which the author postulates that “maybe it is time to finally break out of the old 3-tier web architecture box and retire the concept…” In addition to a great mention of F5 and an “application delivery tier” in web architecture models (the concept of which deserves its very own blog post), the author inadvertently, I think, brings to the fore one of the reasons SOA might have failed to dominate the world: service...
posted @ Monday, July 13, 2009 3:22 AM |
|
|
Can the inherent abstraction of virtualization succeed where SOA did not? My first read through a post on the Cloud Front Office led me to scoff disdainfully at the re-emergence of a concept central to a successful SOA implementation: the service catalog. Oh, we called it "registry" and then "registry/repository (reg/rep)" and finally "governance" but the concept behind it was exactly the same. Take a gander at the description of a cloud service catalog apparently growing out of discussions that began at Structure 09: Last week I attended Structure 09, one of the...
posted @ Thursday, July 02, 2009 3:39 AM |
|
|
I was chatting with my mother a couple weeks ago about cloud (she’s a used-to-be programmer turned project manager for a Fortune 500. Don’t look at me like that, I keep telling you it runs in the family) and one of the problems she lamented about was that folks don’t seem to understand how entrenched COBOL and the mainframe is in the organization. It’s so entrenched that given the choice between a client-server application and a COBOL application that did the same thing they chose the COBOL program because it was less expensive and they had the knowledge on staff...
posted @ Friday, June 26, 2009 2:50 AM |
|
|
There is a tendency to describe every device on a network as simply “the network” regardless of whether that device is dedicated to security, or application delivery (layer 4-7), or actual network (layer 2-3) functionality. It’s an artifact of aging data center architecture models that there exists an artificial line of demarcation between web and application servers and everything else. We used to depict “everything else” as a cloud, but with the emergence of The Cloud doing so simply complicates discussions even further because the “network” necessary to support a dynamic, on-demand operational model of computing like “cloud” is more...
posted @ Friday, May 29, 2009 3:49 AM |
|
|
This whole Web 2.0-sucking-the-life-out-of-servers problem? Yeah, it’s nothing new if you’ve been paying attention. I am not one prone to fits of smug arrogance. I don’t generally ever say “I told you so” (even if I did) or tsk-tsk when you failed to listen to some nugget of wisdom and it bites you some place…unpleasant. Don often tells me I should, and he will if I won’t, but most of the time I simply bite my tongue and let it pass on by. It’s my job to offer up the information, not force it down your throat....
posted @ Thursday, April 16, 2009 3:46 AM |
|
|
Finding new life for SOA in the cloud We’ve been having quite a few discussions with analysts over the past few months on the subject of “cloud”. The interesting thing about these discussions is the vast array of points of view from which those analysts are viewing “cloud”. Some are focused on the network aspects, others on pricing/differentiation, and some are even very focused on what “cloud” means to applications – and the organizations that will, allegedly, take advantage of the cloud as a means of application deployment. One such analyst is Daryl Plummer of Gartner. Daryl...
posted @ Tuesday, April 07, 2009 3:37 AM |
|
|
The year 2009 may be remembered as the year technologies died. First Anne Thomas Maynes of Burton Group declared SOA dead, and more recently Mark Fabbi of Gartner announced the death of load balancers. The difference in the obituaries is striking: Maynes declare an entire architectural model dead while Fabbi merely declares the death of a product, not the technological concepts behind it. Load balancers may be dead, the concept of load balancing lives on as a critical foundation for more advanced and valuable features available in the load balancer’s evolutionary replacement: the application delivery controller. Where Maynes gives...
posted @ Monday, February 16, 2009 5:10 AM |
|
|
Infrastructure 2.0 is, at its core, about evolving to a new level of interconnectedness, one in which the underlying infrastructure becomes as flexible and adaptable as the applications and virtualization infrastructure it is responsible for managing and delivering. In order to be connected, however, you need a way in which disparate infrastructure components can communicate, either directly or via a third party (coordination | management | orchestration) server. That communication is almost certainly going to take (and in many cases has already taken) the form of service-enabled control planes. These "services" are necessary in order to provide the...
posted @ Tuesday, January 20, 2009 5:42 AM |
|
|
The spirit of SOA and its core principles are still very much alive, but we can't call it SOA any more because, well, SOA is (pretty much) officially dead, at least according to folks on the tubes and we all know that if you hear it on the tubes it must be true. Anne Thomas Manes of the Burton Group declared SOA officially dead on January 1, 2009, but maintains that "although the word “SOA” is dead, the requirement for service-oriented architecture is stronger than ever." Ms. Manes blames the death of SOA on the failure to...
posted @ Wednesday, January 07, 2009 9:07 AM |
|
|
SOA is, at its core, a design and development methodology. It embraces reuse through decomposition of business processes and functions into core services. It enables agility by wrapping services in an accessible interface that is decoupled from its implementation. It provides a standard mechanism for application integration that can be used internally or externally. It is, as they say, what it is. SOA is not necessarily SOAP, though until the recent rise of social networking and Web 2.0 there was little real competition against the rising standard. But of late the adoption of REST...
posted @ Friday, December 05, 2008 3:33 AM |
|
|
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...
posted @ Friday, November 21, 2008 3:09 AM |
|
|
Whenever there is a shift in architectural thinking about technology, such as is happening right now with cloud computing and virtualization, we start thinking forward, past the now, and into the future about how that technology might be leveraged. We start looking at the impact to architecture from the top of the stack to the bottom. For a company that's focused on application delivery, that means taking a good hard look at how that new technology might impact the architecture of applications. It's been suggested that perhaps, just maybe, we'll see service-oriented clouds; that the concepts of SOA...
posted @ Wednesday, November 12, 2008 8:52 AM |
|
|
When SOA was the hot topic of the day (not that long ago) everyone was pumped up about the ability finally align IT with the business. Reusability, agility, and risk mitigation were benefits that would enable the business itself to be more agile and react dynamically to the constant maelstrom that is "the market". But only half of IT saw those benefits; the application half. Even though pundits tried to remind folks that the "A" in SOA stood for "architecture", and that it necessarily included more than just applications, still the primary beneficiary of SOA has been applications...
posted @ Monday, November 10, 2008 8:23 AM |
|
|
The VirtualDC has asked the same question that's been roaming about in every technophile's head since the beginning of the cloud computing craze: what defines a cloud? We've chatted internally about this very question, which led to Alan's questions in a recent blog post. Lori and others have suggested that the cloud comes down to how a service is delivered rather than what is delivered, and I’m fine with that as a long term definition or categorization. I don’t think it’s narrow enough, though, to answer the question “Is Gmail a cloud service?” because...
posted @ Wednesday, November 05, 2008 6:53 AM |
|
|
How the cloud acts and is used is more important than where it physically resides Cloud computing and SOA suffer from the same lack of prescriptive architectures. They are defined by how they act rather than what they are, or from what they are composed. They are, in a way, existential technology that cannot be confined to a simple architectural diagram but require instead a set of properties or ways of acting in order to be recognized. To over simplify and paraphrase Jean-Paul Sartre's concepts of existentialism, we define ourselves (mankind) through our actions. To apply this to...
posted @ Monday, November 03, 2008 3:29 AM |
|
|
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...
posted @ Wednesday, October 15, 2008 5:37 AM |
|
|
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...
posted @ Tuesday, September 09, 2008 4:17 AM |
|
|
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...
posted @ Tuesday, September 02, 2008 3:50 AM |
|
|
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...
posted @ Monday, August 25, 2008 7:40 AM |
|
|
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 ...
posted @ Monday, August 18, 2008 5:00 AM |
|
|
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 ThingTM 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...
posted @ Thursday, August 14, 2008 3:32 AM |
|
|
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...
posted @ Tuesday, August 12, 2008 4:44 AM |
|
|
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...
posted @ Thursday, August 07, 2008 5:20 AM |
|
|
In reading through ZapThink's latest post regarding the "Great ESB Controversy of 2008" it occurred to me that it is quite possible, and probably likely, that the issue of ESB use primarily revolves around whether you're doing SEA or SOA. Yes, I know. You've never heard of "SEA" before. That's because I just made it up to describe the difference between a service-enabled architecture and a service-oriented architecture. And there is a difference. A SOA (service oriented architecture) implies that an architecture has been designed around the concept of services. A SEA (service enabled architecture) implies...
posted @ Friday, August 01, 2008 8:02 AM |
|
|
I read with interest an article on port knocking as a mechanism for securing SOA services on CIO.com. If you aren't familiar with port knocking (I wasn't) then you'll find it somewhat interesting: From Nicholas Petreley's "There is More to SOA Security Than Authorization and Authentication" For the sake of argument, let's say you have an SOA server component for your custom client software that uses port 4000. Port knocking can close off port 4000 (and every other port) to anyone who doesn't know the "secret method" for opening it. Any cracker who scans your...
posted @ Tuesday, July 29, 2008 9:21 AM |
|
|
Outside of the technology world a lot of products are billed as "one size fits all". Anyone who's purchased such a product generally knows, no, no they don't. They're close, but never a truly good fit. Inside the technology world we know better. Software and solutions are never a "one size fits all" proposition, that's why so many business software solutions are "customizable": ERP (enterprise resource planning), CRM (customer relationship management), workflow, automation, and portals. Just about every software solution you can purchase these days takes a customizable approach to actually meeting the needs of the business. ...
posted @ Monday, July 28, 2008 6:46 AM |
|
|
There is an interesting war being fought in the blogosphere over the use (or overuse) of ESB (enterprise service buses) to build out a SOA (service oriented architecture). It certainly appears that Dave Linthicum is taking on the role of Leonidas and the Spartans at the battle of Thermopylae while everyone else is on the side of Xerxes and the Persians. Dave is defending his view that ESBs are overused and often, apparently, misused against a host of ESB and SOA focused bloggers like Joe McKendrick and Jeff Schneider. But everyone is talking in abstractions, and...
posted @ Thursday, July 24, 2008 5:35 AM |
|
|
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...
posted @ Tuesday, July 22, 2008 4:17 AM |
|
|
Back in the "winter review from hell" I installed, configured, integrated, orchestrated, tested, and evaluated eight separate ESB (enterprise service bus) products for Network Computing Magazine. Yes, I was a busy gal. I've tested some difficult products in the past, but nothing - not even CRM suites - compared to this review. One of those products was Progress Software's Sonic ESB. One of them was not IONA's Artix. That was because IONA's Artix was just preparing to make its entry into the ESB market, while the Sonic ESB was already well-established, like its competitors. Throughout the...
posted @ Wednesday, June 25, 2008 1:33 PM |
|
|
Remember way back when we talked about dynamically updating a WSDL to present the appropriate endpoint when being delivered through a BIG-IP? You may recall the basic problem: automatically generated WSDL docs contain the local web/application server's IP address/FQDN as the endpoint and not the IP address/FQDN of the BIG-IP, leaving clients with a non-reachable service endpoint. Since that original blog post, a couple of users have asked for the appropriate iRule to dynamically update those auto-generated WSDL docs. Colin was kind enough to code up just such an iRule, and wrap it up with some...
posted @ Monday, June 23, 2008 5:52 AM |
|
|
A recent article discussing the recent challenges to enterprise service bus (ESB) products by XML/SOA gateway products contained a sentence that I found extremely puzzling. Puzzling sentence ...the technology behind both solution-sets is based on deep XML packet visibility and manipulation capabilities. I know what the author was trying to say, but this sentence really is full of epic fail. "Packet" visibility is even more irrelevant to XML than it is for HTML or any other application layer protocol, for that matter. The problem with putting "XML" and "packet" together is...
posted @ Thursday, May 22, 2008 12:12 PM |
|
|
Anyone who's listened to Bob Rivers' Twisted The Twelve Pains of Christmas can probably relate to the angry husband screaming, "When one light goes out they all go out!" because, yeah, we've all been there. Imagine now, if you will, a data center. A data center filled with servers humming along, each running three or four applications in virtual machines a la VMWare. Imagine now - it shouldn't be hard at all - that one of those servers suddenly just stops working. Let's say the drive crashes. After the blue smoke dissipates and the screams of...
posted @ Tuesday, May 13, 2008 6:07 AM |
|
|
With apologies to the writers of Amadeus MOZART [The fresh SOA Architect] But it's new, it's entirely new. It's so new, people will go mad for it. For example, I have an activity in the second step - it requires calls to two services in parallel. Then a third service is called to verify the name of the customer, and a fourth to perform some security checks. Then a logging service makes five and so on. On and on, six, seven, eight! How long do you think I can sustain that? ...
posted @ Thursday, May 08, 2008 10:56 AM |
|
|
I read with some interest a short announcement that Symantec was acquiring AppStream. Using application streaming enables end users to perform functions by accessing parts of a software program over the network as needed, without having the program fully installed on the client computer. OH RLY? In the past I've sat through many a briefing on "application streaming" products. The description offered of application streaming is exactly the same story I've been sold during those briefings. But when you read that description it suddenly appears that what's being sold is almost a form of SOA (Service Oriented Architecture), or...
posted @ Thursday, April 10, 2008 10:35 AM |
|
|
I was listening to some Primus yesterday - To Defy The Laws of Tradition, to be precise- and it got me thinking about architectures and decisions that defy the laws of (IT) tradition. One IT tradition that seems extremely difficult to overcome is that applications should authorize users. After all, the application should control, based on some kind of policy, what users can and cannot do while interacting with it. In fact it's almost a law within IT that while applications may accept the authentication of a user from a trusted source, it is still the authoritative source for authorizing...
posted @ Monday, April 07, 2008 10:23 AM |
|
|
You keep using that word. I do not think it means what you think it means. Integration isn't a four letter word, but for many hapless IT folks stuck with the chore of integrating applications, it probably should be. SOA promised to make the world of application integration a painless, happy process in which the traditional basement sacrifice of live chickens and wild gyrations near a glowing rack of servers were no longer necessary. In many cases, the live chicken sacrifice was no longer necessary, but the wild gyrations were still a fact of integration experts' lives, mostly executed out of pain and frustration when systems failed...
posted @ Tuesday, March 25, 2008 12:17 PM |
|
|
Last week we dove into the use of application delivery as a way to apply the SOA benefits of loose-coupling to "legacy" web applications. This week we'll dive into how to achieve similar benefits by applying loose-coupling to security for legacy applications. Loose-coupling of security general requires the use of a service to apply - or enforce - security policies outside the application or service. At a minimum, the decoupling of security policies from actual services preserves the ability to reuse services in multiple applications, many of which may have different security needs. For example, applying authentication and authorization...
posted @ Tuesday, March 18, 2008 12:24 PM |
|
|
How to apply SOA principles to traditional web application architecture I promised kudos and comments last week for Ronald Schmelzer's ZapNote on the requirement for a service proxy in SOA implementations and so I shall right now. While Ron didn't come right out and say it, a major reason the service proxy is an essential component of a successful SOA implementation is that it protects the concept of loose-coupling, a primary foundational principle of SOA. Loose-coupling is generally applied to consumer-producer relationships and essentially requires that there be no code or logic on the consumer (client) that binds it tightly...
posted @ Tuesday, March 11, 2008 9:49 AM |
|
|
The language of application delivery and SOA finally meets in the middle Ronald Schmelzer at ZapThink wrote a recent ZapFlash titled, "Why Service Consumers and Service Providers Should Never Directly Communicate." Yes, I agree, the title is way too long, but you should read it anyway. The basic premise of this one is that there is a need for a service proxy to protect your investment in SOA. I'll save my kudos and comments for another post, but in general I agree with Ron and his vision of SOA and the need for a proxy/intermediary to prevent the loss...
posted @ Tuesday, March 04, 2008 9:33 AM |
|
|
It was Socrates who first forwarded the notion of "everything in moderation", which happened to be inscribed over the entrance of the temple of Apollo at Delphi along with the maxim "Know thyself." Though we often utter these famous words of wisdom when declining a second drink or while indulging in a particularly fattening dessert, these maxims should be considered by every organization currently facing the challenge of implementing SOA Governance. Know Thyself Governance is about policy and maintaining organizational standards/requirements surrounding services and service usage. Because SOA Governance is about the implementation of a process through...
posted @ Friday, February 29, 2008 9:18 AM |
|
|
A Quick History Lesson Back in the day, server-load balancing vendors figured out that connection management (the setup and teardown of TCP/IP connections) was actually quite a burden on servers. You see, the server not only had to spend time setting up and tearing down the connection, but it also had to keep track of those connections in something we like to call a "session state table". The problem was, and still is, that a server has a limited amount of memory and can only manage X number of connections concurrently. This is primarily a matter of configuration of...
posted @ Thursday, February 21, 2008 9:13 AM |
|
|
Over the past three weeks Don and I have had a lot of time to chat whilst making the trek back and forth between home and the hospital where the newest member of our family was keeping residence. Mostly we talked about our new son and speculating as to when he might be allowed to come home (Feb 17), but as is our wont we often ended up talking about work. That's one of the benefits of working "together" and in the same field, at least we think so. One of those discussions revolved around iControl and the fact that...
posted @ Tuesday, February 19, 2008 9:42 AM |
|
|
Did you ever notice that "governance" and "compliance" have the same nearly ominous tone to them? It's as if they should be preceded by some dark music normally associated with a Vincent Price movie. The two are also similar in that they both focus on process, not product. I know that sounds nearly heretical, and I'm sure some of those entrenched in the world of SOA Governance might take umbrage with that statement, but after a few drinks I'm sure they'd agree that fundamentally SOA governance, like compliance, is really about the process - and enforcement of the...
posted @ Thursday, January 17, 2008 7:54 AM |
|
|
Google. Amazon. Facebook. LinkedIn. Salesforce.com. While certainly not an all inclusive list, these very recognizable web monsters all offer access to their "platforms" via a web-based API, a.k.a. services. With the notable exception of Salesforce.com, most have implemented these services as a REST (Representational State Transfer) or REST-like set of interfaces, but in general these APIs meet the criteria necessary to be referred to as services. They're SOA as surely as any other service out there. These services are being incorporated at a rapid pace into other web-based (dare I say Web 2.0) applications, and a plethora of others...
posted @ Friday, January 04, 2008 10:09 AM |
|
|
Most people, upon hearing the term "load balancing" immediately think of web and application servers deployed at the edge of the network. After all, that's where load balancing is most often used - to ensure that a public facing web site is always as available and fast as possible. What many architects don't consider, however, is that in the process of deploying a SOA (Service Oriented Architecture) those same web and application servers end up residing deeper in the data center, away from the edge of the network. These web and application servers are hosting the services that make...
posted @ Wednesday, November 14, 2007 9:19 AM |
|
|
This article is just full of interesting ideas. First we're told that the only way to secure Web 2.0/SOA/Web applications is to rewrite the code. This "rewrite the application code" to address any number of delivery issues - security, performance, availability - is old and busted. There are other more efficient mechanisms that can certainly be used to address application delivery issues, such as an application delivery network comprising appropriate intelligent, application aware devices capable of ensuring that all applications are fast, secure, and available. These solutions do not require that the application be rewritten, and in fact in...
posted @ Tuesday, November 06, 2007 1:22 PM |
|
|
Is to head on over to Michael Botis' blog and read this entry on the impact of Web Services on the network. The reason is because Michael is looking at the impact from a global perspective whereas I've primarily concetrated on the affect of services on the local network and infrastructure. Michael points out that BIG-IP Global Traffic Manager (GTM) can assist in ensuring reliable access to servers across geographically disperse locations. Two scenarios come to mind that take advantage of GTM: global failover and distribution of services. The former is a fairly straightforward use-case, the latter is more complex...
posted @ Friday, September 14, 2007 10:56 AM |
|
|
Occassionally I get to chat with the guys in the trenches about ongoing implementations involving BIG-IP. Often these involve deploying BIG-IP in front of XML/SOA gateways for load balancing and high-availability (a la failover) duties, as well as session management capabilities. This is primarily due to a lack of support for these options on the part of XML/SOA gateways combined with the need to horizontally scale out the gateways to deal with high volume throughput. I got to thinking about this deployment scenario during a chat with very smart SOA guys Tony Bishop and Jim Haughton and we decided that...
posted @ Wednesday, August 29, 2007 3:39 PM |
|
|
ZapThink has a great article regarding the granularity of services; that is, how fine or coarse grained services are in terms of the services and interactions available.
What is mentioned, but not highlighted, and appears to be somewhat assumed (at least in this article), is that the end-result, regardless of the process used to build services, revolves around business processes.
[The] concept of granularity is incredibly important to the enterprise architect because it has a direct impact on two major goals of Service-orientation: the composability of loosely-coupled Services, and the reusability of individual Services in different contexts. Before an architect...
posted @ Friday, August 03, 2007 11:56 AM |
|
|
KPI (Key Performance Indicators) are quantifiable metrics that can be measured against organizational goals. KPIs vary from business to business, based on what the company does. If it's a sales oriented company, a KPI might be something like "increase sales by X% year over year"; if it's a retail company it might be both "increase sales" and "increase customer retention". The key is that a KPI must be measurable in some way. That's why most KPIs are directly related to revenue, customer retention/churn, and other quantifiable aspects of doing business. Aggregating this measurable data is generally the responsibility of...
posted @ Friday, July 13, 2007 9:36 AM |
|
|
When being chased by a dragon, you don't need to be faster than the dragon. You just need to be faster than the halfling behind you.
I had a lot of discussions at RSA this past week, and of course some of them centered on performance. One of the challenges often associated with pure proxy-based application anything involves dealing with the argument that proxies degrade performance, especially in something as intense as an application firewall. That's because of the associated computational cost of buffering input, reassembling packets, and parsing through data in addition to the requirement of managing TCP connections...
posted @ Monday, February 12, 2007 12:49 PM |
|
|
No Service is An Island
No one has ever claimed that processing of XML was speedy. Indeed, my reaction to the results of the first test I ever conducted on SOA Security Gateways back in 2003 was to test them again. And again. It turns out that this was actually okay, as a subsequent review of the application servers these devices were protecting weren't capable of keeping up anyway.
But that was back in 2003, right? Things have gotten better, haven't they?
Well, yes and no. Another round of testing in 2005 showed that while the devices offloading XML processing...
posted @ Friday, January 19, 2007 12:09 PM |
|
|
Is the pipe half-full or half-empty?
David Linthicum does a good job of pointing out the factors that can affect performance of your SOA in his recent Real World SOA entry: When to Consider SOA Performance.
I particularly liked rule #3:
"Third, use of too many fine grained services may cause performance problems. Indeed, you should not be afraid to leverage fine grained services within your SOA. However, you need to understand the performance issues with doing so, taking careful consideration of the network bandwidth and how other applications leverage the services."
You should indeed take the network into careful consideration when...
posted @ Wednesday, December 20, 2006 1:27 PM |
|
|
|
|
|
|
