Category: Standards Watch
November 18th, 2009
Posted by Joe McKendrick @ 1:34 pm
Categories: Case Studies, Data managemetnt, Enterprise Architecture, Management, Standards Watch, Web Services, business process management
Tags: SOA, Simple Object Access Protocol, United States Coast Guard, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
This is the third of three installments of my discussion with Jim Jennis, chief technology officer for the US Coast Guard Operations Systems Center, and Steve Munson, SOA branch chief for the US Coast Guard, about the department’s growing roster of service-orientation initiatives. In the first post, Munson and Jennis described the business case for SOA within the Coast Guard. In the second post, they discussed how they built organizational support.
Coast Guard opts for ‘lightweight’ services; now tackling governance and security issues
The US Coast Guard prefers more lightweight services for its maritime and inventory tracking systems. “We are very REST oriented,” Munson explains. “We like the REST model very much. So where applicable, we have leveraged it in a significant way to develop our service oriented architecture. Internally, Munson points out, the prevailing standard is POX, or Plain Old XML for message exchange. “We do not subscribe to the extra wrappers and envelopes and overhead that’s required to serve out SOAP-based services.”
“What we have found within the Coast Guard is that the Web services model, particularly the traditional RPC-style Web services, are not suitable for implementation in the Coast Guard’s architecture,” he explains. “Our architecture is fundamentally message based. Where we do implement Web services interfaces, they’re all document-driven Web services for external users, where those kinds of interfaces are required.”
Munson and Jennis are also seeing some reusability in its SOA-aware services, particularly for lower-level services. However, Munson cautions, “we certainly don’t want to oversell that yet.”
That’s because the SOA team is still wrestling with the technical aspects of service governance. “The issue around SOA governance is still a challenge for us as it is with any organization,” he explains. “We have not implemented, for example, any formal service registry or automated service discovery. Were continuing to look at how we want to do that.”
The issue with registry and repository solutions on the market, he says, is that they are oriented toward the traditional SOAP-based Web services. “Most of them are still tailored to the Web services approach,” he says. “Many of them don’t have good answers for non-WS-* type of registration.”
Data security is another challenge for the Coast Guard’s SOA team, and this is holding back the ability to offer services to port partners and other outside parties. “One of the challenges in an enterprise service bus, and an SOA architecture in and of itself doesn’t solve this, are all the security challenges surrounding data services, particularly once you get outside of your organization,” Munson says. Internally, within the Coast Guard organization, the security around services is pretty straightforward. But starting with sharing with external partners at any level, security rapidly becomes a challenge for us. Like other folks, were still looking at how to crack that nut, and we still don’t have a silver bullet for that yet.”
The Coast Guard soon intends to make some services available to other federal agencies and its port partners. For example, the Coast Guard is participating in an inter-agency program called Watchkeeper, in which data is provided as part of a homeland security system. “We have probably a dozen or more services that are in testing that will be deployed as part of that system,” Munson says.
Additional services being piloted — and still in development — will feed data to and from WatchKeeper to other Coast Guard systems, such as MISLE, MAGNet, MASI and others, Munson adds. Additional services leveraging the Coast Guard’s ESB and SOA include systems for the National Oceanic and Atmospheric Administration surrounding Right Whale speed enforcement zones, as well as a system for monitoring and tracking Self-Locating Data Marker Buoys (SLDMB) for Search and Rescue.
The Coast Guard is making substantial progress with its SOA effort, and Jennis and Munson credit this to the close coordination between their teams and the Coast Guard management. “If you define what SOA means for your organization, and go forward with that, you’ll get SOA right,” Jennis advises. “In our case, we’re very much tied to the Coast Guard’s mission, and the doctrine of the Coast Guard. But if you go with a lot of the buzzwords, and you don’t have a clearly defined meaning for what your SOA will look like, you’ll get in great trouble in a hurry.”
November 9th, 2009
Posted by Joe McKendrick @ 6:52 pm
Categories: Business ROI, Management, Standards Watch, Vendor Watch, Web 2.0-Enterprise 2.0, Web Services
Tags: Enterprise Mashup, Joe McKendrick
Kudos to JackBe’s Luis Derechin for his refreshingly candid admission and personal journey of discovery in an effort to arrive at the definitive definition of “enterprise mashup.”
You may recall that last spring, following a TV news interview, Luis was not happy with the explanation he gave to describe enterprise mashups. JackBe sponsored a couple of contests, along with a lot of discussion among practitioners and analysts.
Here, at last, is the working definition Luis and his team have arrived at:
“Enterprise Mashups are secure, visually rich Web applications that expose actionable information from diverse internal and external information sources.”
Wait — that’s not all. The JackBe crew also sought to answer the question of “why” people need enterprise mashups. They didn’t want enterprise mashups to be solutions in search of problems, as has been the case with many a technology initiative:
“Poor decisions are often made because decision-makers do not have the right information at the right time. Enterprise mashups deliver new insights and enable better decisions through personalized access to the right, real-time information for the specific problem at hand.”
And finally, the JackBe crew also addressed the “how” aspect — as in how enterprise mashups can be created:
“An enterprise mashup platform is a technology suite that enables the rapid, collaborative, user-driven creation of Enterprise mashups without the complexities, costs and risks of traditional information integration projects.”
In this last passage, the user-created aspect of enterprise mashups are included in the definition. This is where mashups can potentially deliver business benefits, as more flexibility can be put into users’ hands. And, as the “why” part of this definition shows, enterprise mashups put decision makers in touch with performance data from across the organization. The greatest challenge to delivery of information at this time is the time it takes to prepare and deliver reports. Let’s give end-users the tools to quickly and configure their interfaces to back-end enterprise applications and data.
October 29th, 2009
Posted by Joe McKendrick @ 7:15 am
Categories: Links, Standards Watch, Web Services
Tags: IPv4, IPv6, IP, Internet, Networking, Telecommunications, Joe McKendrick
The impending changeover from IP version 4 to IP version 6 won’t really be a big deal, and most people won’t even notice it as it happens. But the Internet will be running on both protocols for a while, and the head of the American Registry for Internet Numbers (ARIN) cautions that some online applications may run slow as a result. Online content providers need to start preparing as well.
In a recent interview, John Curran, president and CEO of ARIN, explained why businesses need to sit up and take notice of the impending shift that is taking place as we move from Internet Protocol version 4 (IPv4) to the more expansive IP version 6.
What’s happening is the original Internet numbering system — which assigns addresses such as 192.168.1.1 — is running out of numbers. IPv4 is a 32-bit system with four billion possible combinations. “That sounds like a lot of numbers, but it really isn’t when you think about the size of the globe and the number of devices being connected these days,” Curran says. In fact, we’re due to run out of numbers within 700 days, he warns. IPv6, with 128-bit addressing space, enables “numbering of all of the molecules in the galaxy,” he says.
As soon as the last IPv4 number is used up, every new device or site that comes along after that uses IPv6. Don’t loose too much sleep over your systems, however. Industry planners have been aware of this matter since the 1990s. Most hardware and software has been ready for IPv6 for some time.
However, Curran advises businesses to check their configurations before the changeover takes place, as glitches may come up. “We can’t actually get an IPv6 host and an IPv4 server to talk to each other, because the IPv4 server only knows 32 bits. It’s much like if your telephone was set up to only ever dial seven digits, and it wouldn’t let you dial 10. Sure you could almost have a conversation, but you couldn’t call most of the world.”
When the changeover occurs, “ISPs are going to have to start using IPv6 to connect customers,” he explains. “Then, they’re going to have to put IPv6 gateways in, boxes that work like network address boxes, to translate IPv6-connected customers to the IPv4 websites on the Internet. That will work, but that’s going to be suboptimal, because those are gateways doing the translation.” This may slow down online applications such as Skype, Voice over IP, real-time video games, which “won’t necessarily run smoothly going through those translators.”
Curran points out that the Internet will be running on two protocols for some time. “If you really want to start a business that’s Internet based, you’re going to want to take your equipment, and make it connected by both IPv4 and IPv6.”
Some businesses have more of a challenge ahead of them than others, Curran continues. While the major ISPs have been underway with IPv6, “the content providers are just beginning to work on this,” Curran says. “And that’s going to take a lot of work, and they need to enable a lot of software that we think of as the Web 2.0 software infrastructure. While all the parts may run IPv6, that doesn’t mean your infrastructure is ready.”
Consider the two years remaining to address IPv6 configuration issues as an opportunity to get a jump on the competition, says Curran. “I would recommend that people start thinking about the fact that the IPv4 Internet has a fixed size, and the global Internet is going to keep growing. What this means that you don’t want to be left behind on the fixed-size network. You don’t want to be left behind on a fixed-sized network in an Internet ‘backwater.”
By the way, the interviewer, Howard Greenstein, said it’s important to get this cautionary message out on ZDNet and other popular channels — so there you go, Howard!
October 26th, 2009
Posted by Joe McKendrick @ 10:17 am
Categories: Enterprise Architecture, SOA Events, Standards Watch
Tags: SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
Service oriented architecture is not a thing that you do, and it definitely isn’t a thing that you buy. But it is something tangible, a style if you will, just as Roman, Greek or Modern are styles of architecture.
Why the fussing about semantics? This was a key point discussed over and over again by members of the SOA Manifesto Working Group, and an issue that is endlessly creating confusion in the market. In fact, it’s a semantic slip that even members of the group had to work at to keep in check.
There have been some comments raised about the Manifesto’s preamble, which said the following:
“Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.”
Yes this opening statement may seem like a statement of the blindingly obvious, like “the sky is blue” or “the ocean is wet” or “Hollywood makes crappy movies” or something like that. But there was a lot of discussion around this statement, and the intent was to dispel the notion that SOA is this thing that you do or can buy. In fact, vendors and consultants have been abusing these semantics and milking millions from customers with this notion for years.
That makes as much sense as the Romans going out and buying their architecture. It was important to put this notion to rest (definitely no pun intended) once and for all, and it was felt by the group that this was such an important statement that it was elevated from originally being a principle to the preamble to the entire document. And “applying service orientation” is the action that goes into building an SOA-enabled infrastructure.
October 23rd, 2009
Posted by Joe McKendrick @ 4:32 pm
Categories: Business ROI, Enterprise Architecture, Links, Management, SOA Events, Standards Watch
Tags: SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
As mentioned earlier, I had the opportunity to join a group of highly motivated and very smart people at the SOA Symposium in Rotterdam to formulate what is being called the SOA Manifesto. Here is the final version of the document, spelling out the core values and related principles that should be part of service orientation and SOA. Hopefully, they will help guide your thinking on the SOA journey:
SOA Manifesto
Service orientation is a paradigm that frames what you do. Service-oriented architecture (SOA) is a type of architecture that results from applying service orientation.
We have been applying service orientation to help organizations consistently deliver sustainable business value, with increased agility and cost effectiveness, in line with changing business needs.
Through our work we have come to prioritize:
- Business value over technical strategy
- Strategic goals over project-specific benefits
- Intrinsic interoperability over custom integration
- Shared services over specific-purpose implementations
- Flexibility over optimization
- Evolutionary refinement over pursuit of initial perfection
That is, while we value the items on the right, we value the items on the left more.
SOA Manifesto Guiding Principles
We follow these principles:
- Respect the social and power structure of the organization.
- Recognize that SOA ultimately demands change on many levels.
- The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.
- Products and standards alone will neither give you SOA nor apply the service orientation paradigm for you.
- SOA can be realized through a variety of technologies and standards.
- Establish a uniform set of enterprise standards and policies based on industry, de facto, and community standards.
- Pursue uniformity on the outside while allowing diversity on the inside.
- Identify services through collaboration with business and technology stakeholders.
- Maximize service usage by considering the current and future scope of utilization.
- Verify that services satisfy business requirements and goals.
- Evolve services and their organization in response to real use.
- Separate the different aspects of a system that change at different rates.
- Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change.
- At every level of abstraction, organize each service around a cohesive and manageable unit of functionality.
October 12th, 2009
Posted by Joe McKendrick @ 3:00 am
Categories: Business ROI, Links, Management, Standards Watch, Vendor Watch, business process management, cloud computing
Tags: Software, Information Technology, Lean IT, Strategy, Management, Joe McKendrick
Customer in a restaurant: Waiter, bring me a steak, and make it lean.
Waiter: Okay, sir. Which way?
As reported in my last post, Sandy Kemsley has done a great job of covering Forrester’s Business Technology Forum, which focused on Lean IT.
But which way is IT supposed to lean? Alas, it seems Forrester is helping to heap another buzzphrase on the world that seems to describe things that have already been in motion for years. (Some say this is the case with service oriented architecture as well, by the way.)
What, exactly, is ‘Lean IT’? Wikipedia’s definition of Lean IT is vague and convoluted:
“Lean IT is the extension of lean principles to the development and management of information technology (IT) products and services. Its central concern, applied in the context of IT, is the elimination of waste, where waste is work that adds no value to a product or service.”
Yeah, so? Again, haven’t organizations been battling waste in IT since day one?
I don’t know who coined the phrase “Lean IT,” but it takes a page from “Lean Manufacturing,” which tightened up that sector in the 1980s and 1990s to survive the onslaught from more efficient and quality-driven overseas competition. Noah B. Kindler, Vasantha Krishnakanthan, and Ranjit Tinaikar of McKinsey & Company discussed the concept back in May 2007, claiming that application development and maintenance (ADM) productivity can be boosted up to 40% by eliminating waste from routine processes. “Application development and maintenance is a prime candidate for lean methods not only because it involves a great many processes with the potential to be optimized but also because large differences in productivity among organizations suggest that some are far less efficient than others,” they said. As they put it:
“Each category of waste in manufacturing has a counterpart in ADM, which can be thought of as a kind of factory that develops new applications according to business requirements. Changes to an application’s requirements are one common source of ADM waste, causing many of the classic varieties identified in lean: designers rework their specifications, coders wait for specifications to stabilize, testers overproduce as their testing environments have to be set up repeatedly, unmet requirements pile up in a large backlog. As in manufacturing, systematically eliminating these sources of waste improves the delivery time, quality, and efficiency of the ADM end product.”
So they equate IT operations with a manufacturing process. Which makes sense, and is something we’ve discussed in this blogsite before (here, here, and here). By introducing assembly-line processes and greater automation to software development, we can definitely tighten up the process.
In past posts, I quoted IBM’s Dr. Irving Wladawsky-Berger and Microsoft’s Jack Greenfield, both who said we were at the dawn of a new era of IT — “industrialization.” Wladawsky-Berger said that IT-delivered services are starting to become more componentized, standardized, and mass-consumable across the spectrum, just as manufactured goods were a century ago. Greenfield talked about the concept of the “software factory,” defined as “a development environment configured to support the rapid development of a specific type of application. While software factories are really just the logical next step in the continuing evolution of software development methods and practices… introducing patterns of industrialization.”
He said, however, that “our IT infrastructures are nowhere near ready to handle this explosive growth of information and service. Much of IT, - including applications, data centers, systems management, and so on, - is way too ad-hoc and custom designed, sort of like manufacturing was decades ago….”
So, is Lean IT the right thing at the right time to seize upon this impending industrial revolution of IT services? The McKinsey authors identify the following areas for “waste reduction” in software assembly: flow processing to reduce overcapacity or excess inventory; release schedules to help prioritize projects; staff and supplier workload balancing; greater standardization; segmentation of projects by complexity to route projects to the proper resources; and and by avoiding unnecessary overhead for simple tasks; and quality ownership that extends to all groups involved in software production — not just QA.
These are are well and good goals, and I’m sure every organization can benefit greatly by applying these principles to their IT operations. But is there anyone who hasn’t been already trying to move these efforts forward? What does Lean IT bring to the table? Consider everything that has been underway in recent years:
- Service oriented architecture: Formerly siloed applications are decomposed into reusable services that are made available across enterprises.
- Agile development: Developers work side by side in an iterative way with business users throughout the process.
- Virtualization: Physical IT systems and resources are abstracted into a software-based enterprise service layer.
- IT automation: Routine IT processes formerly handled manually are handled on a systematic basis by the software and machines themselves.
- Cloud computing/outsourcing: Non-critical IT tasks and applications are acquired from more specialized providers, mainly on a pay-per-use or contractual basis.
- Business process management: Business workloads are decomposed and automated.
- ITIL: Best practices and principles for IT services applied uniformly across organizations.
References I’ve been seeing to Lean IT seem quite provincial — optimizing IT processes at the ground level without bringing in the larger picture — the transformation of the business. Lean IT lacks the expansive thinking that Wladawsky-Berger and Greenfield have in mind for the coming industrial revolution in IT services.
And, again, it begs the question: what does Lean IT offer that we haven’t been trying to do already?
September 24th, 2009
Posted by Joe McKendrick @ 8:45 am
Categories: Data managemetnt, Links, Standards Watch, Vendor Watch, Web 2.0-Enterprise 2.0, Web Services, cloud computing
Tags: Enterprise Mashup, Enterprise Mashup Markup Language, Joe McKendrick
As reported a couple of days ago, the enterprise mashup market promises to be a huge one, growing to almost $2 billion in a few years. So it’s high time people involved in this space start organizing and working around some standards everyone can agree on.
Can enterprise mashup proponents avoid the mistakes made with ESBs?
A new consortium, called the Open Mashup Alliance, is the first effort to coalesce around this growing phenomenon. The group’s stated mission is to promote “the successful use of Enterprise Mashup technologies and adoption of an open language that promotes Enterprise Mashup interoperability and portability.”
One of the founding members is ZDNet’s resident Enterprise Web 2.0 guru, Dion Hinchcliffe. Additional charter members include Adobe, Bank of America, Capgemini, HP, Intel, JackBe, Kapow Technologies, ProgrammableWeb, Synteractive, and Xignite.
One of the OMA’s first endeavors is to shepherd the budding Enterprise Mashup Markup Language (EMML) specification for submission to a standards body. EMML is an XML-based, domain-specific language that was designed to address the characteristics that make mashups easier to create and reuse.
There were a bunch of supporting quotes included with the OMA’s announcement, but I think Michael Ogrinz, principal architect at Bank of America and author of the book Mashup Patterns, said it best: “For enterprise mashups to take hold, we need to remove the ‘vendor lock-in’ concerns raised by today’s proprietary toolsets. We also need to inspire the innovative minds of the open-source community to start working in this space. By establishing an open standard for mashups, the OMA and EMML addresses both of these issues.”
Perhaps the industry learned some lessons from another development that proliferated without guiding standards — the enterprise service bus. One of the fiercest criticisms of ESBs has been the way vendors took off in all different directions with their implementations before standards could be established. Perhaps we can avoid this with enterprise mashups. But the looming market size must be a huge temptation.
September 16th, 2009
Posted by Joe McKendrick @ 9:33 am
Categories: Links, Standards Watch, Vendor Watch, Web 2.0-Enterprise 2.0, Web Services
Tags: Red Hat Inc., Specification, RESTful, Standards, REST-*, REST, Quality, Open Source, Business Operations, Joe McKendrick
Should we call it “REST-star” or “REST-splat”?
Paul Krill reports that Red Hat has launched a community-based standards set it is calling REST-*, which could serve as a counterpoint to the WS-* specifications for Web services. Red Hat says it hopes to work with major vendors such as IBM and Microsoft, “to define standards or recommendations for REST-based system integration.”
Mark Little, CTO of JBoss/Red Hat, announced the new initiative at the recent JBoss World conference in Chicago, noting that the WS-* series of Web services have become complex. “Maybe REST is a better way of doing certainly Internet-scale integration, but one of the problems of REST is it lacks clear guidelines,” for enterprise capabilities, such as security, transactions, and high availability.”
Red Hat even now has a home page for the REST-* effort, which outlines the vision, specifications, and community for the standards set.
Red Hatter Bill Burke makes the case for REST-* thusly:
“While REST has gained huge momentum in the SOA community, there hasn’t been a lot of standardization of traditional middleware services. The REST-* community aims to introduce new REST-based standards for these traditional services where none exist and provide well-defined guidelines where protocols do exist.”
There are two efforts now underway as part of the REST-* set:
REST-* Transactions: A specification that attempts to define a RESTful interface for transactions. “It describes the interaction between coordinator services and transaction participants as well as how transactions can propagate in distributed applications. It defines both a 2-Phase-Commit model as well as a Forward-Compensation protocol.”
REST-* Messaging: Messaging encompases publish and subscribe and point-to-point protocols. This specification defines a RESTful interface for queues (p2p) and topics (pub/sub).
Not everyone is welcoming the new initiative with open arms. Anne Thomas Manes, for one, says she’s “got a bad feeling about this.” She points out that REST-* may stray from REST principles, and “you won’t attain the desirable RESTful characteristics (scalability, serendipity, network effects, etc) that REST is supposed to enable.”
“A more useful effort would be one that defines RESTful patterns that support and enable mission-critical capabilities like reliable delivery, transactional integrity, and the like. But please, let’s not reinvent CORBA on REST. Here’s hoping the whole REST-* thing just dies out.”
Sure, mistakes were made with SOAP and WS-*, and Burke admits that “blind idealism,” combined with Red Hat’s experience with communities, will guide this latest effort past obstacles, complexities, and pitfalls. Red Hat is “jumpstarting and founding the standards body itself,” and is “battle tested in specifications efforts at the JCP and other bodies.” Burke adds that “we’ve often been frustrated by the closed and inflexible attributes of these organizations. We feel our open source roots and ideals make us an excellent candidate to drive and host standardization efforts.”
September 15th, 2009
Posted by Joe McKendrick @ 9:16 am
Categories: Enterprise Architecture, Links, SOA Surveys and Research, Standards Watch, Web Services
Tags: Enterprise Service Bus, SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, EAI, Enterprise Software, Software, Joe McKendrick
Thomas Rischbeck, a contributor to Thomas Erl’s SOA Design Patterns, wants to clear the air on some of the confusion and controversy that has been associated with enterprise service buses (ESBs).
From day one, ESBs have suffered from lack of standards
That is, he writes in a new article, “The essence of an ESB can be much more easily grasped by talking about the ESB as a pattern: the pattern of applying an intermediate proxy to service communication. The ESB pattern is about performing integration tasks and adding value to client-service communication in an SOA – all completely transparent to the participants.”
The confusion with ESBs date back to their very start, when vendors took the lead with pushing these products out to market. But they rushed things because they were under the gun, Thomas says:
“Faced with market domination by IBM, [message-oriented middleware vendors were the first to jumpstart the ESB concept with the aim of developing a unique selling proposition. They added Web service and EAI capabilities on top of existing message broker capabilities, and with analyst support coined the term ESB. ESB was positioned as a low-cost alternative to EAI and panacea for all integration needs – tell-tale signs of hype. Unfortunately, the standards community was too late to get on the bandwagon. In the absence of standards guidance and the lack of a clear definition, each vendor interpreted ESB to its advantage. As a result, comparing ESBs is like comparing apples and oranges. No two products are compatible today with severe consequences (in terms of vendor lock-in) for end users.”
As a result of all this vendor confusion and FUD-creation, ESBs mean a lot of different things to different people. Instead of thinking of ESBs in terms of what vendors say they are, Thomas urges thinking of ESBs as a pattern — as he puts it, “the pattern of applying an intermediate proxy to service communication.”
He provides a more detailed definition for the ESB pattern:
“The ESB pattern is about performing integration tasks and adding value to client-service communication in an SOA – all completely transparent to the participants. …The ESB is a compound pattern that pulls together many enablement and enforcement capabilities that come in handy to the SOA practitioner. Reliable Messaging, Message Manipulation, Data Format and Data Model Transformation as well as Protocol Bridging are just some sub-patterns examples under the ESB umbrella. These are all enablement aspects where the ESB allows communication between endpoints not possible otherwise.”
There are two major alternatives to ESBs, Thomas adds — either application servers everywhere or nothing at all. While doable, this makes efforts to support delivery of services more complicated than they are, he says. Of course, there are many SOA proponents that say ESBs are essentially useless appendages that do more harm than good in the long run. Perhaps elevating the discussion to more vendor-neutral territory will help clarify what, if any, roles ESBs could play in tomorrow’s SOAs.
September 3rd, 2009
Posted by Joe McKendrick @ 8:12 pm
Categories: Links, Standards Watch, Web 2.0-Enterprise 2.0, Web Services
Tags: SOA, Simple Object Access Protocol, REST, SOAP, Service-Oriented Architecture (SOA), Web Services, Software Development, Research & Development, Middleware, Enterprise Software
Speak now or forever hold your peace…
Has anyone ever actually heard someone disrupt a wedding ceremony by voicing an objection to the proposed union?
Has anyone ever heard someone object to an SOA plan because its based on SOAP, and not enough REST?
In an interesting new post, Justin Cormack says not enough people speak up when corporate decisions are made to adopt of SOAP-base Web services as the foundation of SOA, before the deal is sealed and things really start to get messy:
“I went to a meeting a while back with a company starting to move to a Web service based, internal API based architecture, and there was a minute where the CTO said (more or less) “does anyone know of any let or hindrance to this being a SOAP API?”. Like those moments at weddings, no one spoke out. But I do object. SOAP is not the backbone of a happy architecture, but we do not have the strength to say no right now.”
Justin says this is the time for enterprises to move from SOAP to REST, and transition their service oriented architecture (SOA) to a resource oriented architecture (ROA).
Not a bad nomenclature — and he makes his case for a RESTful ROA:
- Web developers favor REST. “It is more productive. It does not involve programs to generate huge chunks of useless code. It involves hypertext, not opaque documents that are mappings of database schemas.”
- REST is less expensive, as it requires fewer application development resources.
Look at modeling systems as resources, Justin continues. “Resources are much easier to work with than services, as they share uniform semantics, and they are addressable, two keys to making application design simple.” A CRM system is an example of something that needs to be modeled as resources, he says. “You need API calls that can find products a customer has bought, support tickets, all the core data that you would need to build customer service portals, internal support applications.”
REST enables a resource oriented architecture based on HATEOS or Hypertext as the Engine of Application State. HATEOS “involves is moving the vague and very expensive field of business logic from code (often code that is not even owned or understood by the enterprise, as it has been embodied into code written into systems from suppliers) into hypertext documents,” Justin explains.
Thanks to Dilip Krishnan for pointing to this post.
August 26th, 2009
Posted by Joe McKendrick @ 9:09 am
Categories: Links, Management, Standards Watch, Web Services, business process management
Tags: Security, SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
Mark O’Neill picked up on my recent post on SOA security and asks a very logical question: Why aren’t we looking at SOA as an enabler of security, versus worrying about the security of SOA approaches?
We’re asking the wrong question about SOA security
A very good question indeed. Mark calls this the “neglected flipside of SOA security,” observing that “SOA Security” is two separate things, solving two separate problems — securing SOA-based infrastructures, and applying SOA principles to security. “I think that too many SOA Security articles focus only on the first meaning of SOA Security (making SOA more secure) than on the second (applying SOA principles to security to make it more easy to deploy and manage),” Mark says.
He explains:
“‘SOA-flavored Security’ means making security more management and easy to deploy by isolating re-usable components of security and providing them as managed services. For example, the OASIS DSS standard explains how digital signature services can be used in order to provide signing and signature validation services over the network, accessed using a Web Services interface. This solves a knotty problem, and provides a good framework for key management. Similarly, specifications such as XKMS, XACML, and WS-Trust are really all about applying SOA to security, to solve interoperability problems, not about ‘making SOA secure.’”
A few weeks back, I quoted Open Group’s Dr. Chris Harding, who also pondered whether we’ve been looking at the SOA security problem “the wrong way around.” Chris suggests SOA and the use of shared services may actually solve more security problems than it creates.
The beauty of a service-oriented approach is that it provides for common mechanisms — security services — that can be developed and tested and applied against many types of applications or scenarios. Individual domain or application owners no longer need to reinvent the wheel, rely on jury-rigged approaches, or cross their fingers if common SOA-based security is available within the enterprise to secure their application and data assets.
Again, SOA may solve more security issues than it creates.
August 25th, 2009
Posted by Joe McKendrick @ 9:43 am
Categories: SOA Surveys and Research, Standards Watch, business process management
Tags: BPM, SOA, Service-Oriented Architecture (SOA), Business Process Automation, Operational Planning, Enterprise Software, Web Services, Strategy, Middleware, Software
In the wake of Software AG’s acquisition of IDS-Scheer, Dana Gardner raised this question at a recent BriefingsDirect podcast: “Is the SOA landscape is being driven by folks trying to do it all?” As he put it: “I thought the whole notion of SOA was being able to include more players and more components to interact and interoperate. What’s going on?”
SOA-BPM merger is inevitable, but is not being rushed
There’s been a trend toward consolidations and acquisitions in which vendors are scooping up or adding capabilities in hopes of being able to offer end-to-end SOA suites. Of course, Dana is right, in that the whole idea of SOA is independence from these catch-all solutions, and being able to pick and choose, swap in and swap out interchangeable solutions as needed.
What caught the panel’s attention with the Software AG-IDS Scheer acquisition was the possibility that vendors may start forcing business process management solutions into that end-to-end SOA mix as well. However, in this case, it’s likely that Software AG may keep BPM focused on the BPM side of its product line.
For example, Jason Bloomberg, who joined the panel, pointed out that the acquisition itself actually had little to do with SOA. “With the IDS Scheer acquisition, if you read through what Software AG is saying about this, they’re not connecting it with their SOA story. This is part of their BPM story. This is a way for them to build their vertical BPM expertise. That’s the missing piece.”
It may take time for the SOA and BPM worlds to come together anyway. It’s like the separate Francophone and Anglophone cultures that exist in Canada; the Scotts, Welsh, English, and Irish in the UK; the Flemish and Francophones in Belgium; or the residents of North and South New Jersey. They’ll all agree to exist under one roof, but that’s about it — they still want their own ways of doing things.
But as Tony Baer put it, there’s a new emerging element that may force the BPMers and SOAphones to talk, at least a bit: “There has always been a huge cultural divide between the business folks, who felt that they own BPM, versus the IT folks, who own the architecture or the technology architecture, which would be SOA. What’s really interesting and what’s going to stir up the pot some more — and this is still on the horizon — is BPMN 2.0, which is supposed to support direct execution.”
Until then, we can conclude that it’s not likely we’ll be seeing a lot of BPM stuff being shoe-horned into SOA suites. But, it is inevitable that SOA will rely more on BPM; and BPM will rely more on SOA. It’s inevitable.
August 20th, 2009
Posted by Joe McKendrick @ 3:19 pm
Categories: Data managemetnt, General, Links, Management, SOA Surveys and Research, Standards Watch, cloud computing
Tags: SOA, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
Two recent posts by leading SOA thinkers have different takes on the state of SOA security. Is it a monstrosity that is almost impossible to secure end to end, or is it something that can be started relatively simply and grown with proper attention and management?
Will SOA outgrow its insecurity?
Forrester’s Randy Heffner says we have reached a point where SOA is secure enough for prime time. However, he cautions, while WS-Security has helped standard Web services using SOAP, some careful navigation is required for full-blown SOA. But it’s doable. “Advanced SOA security - involving federation among partners, nonrepudiation, and propagation of user identities across multiple layers of service implementations - is in its early days,” Randy points out. Still, the need for robust SOA security will be inevitable. “Many user organizations will find that advanced SOA security becomes mandatory - especially with increasing data privacy and other regulations.”
JP Morgenthal takes a dimmer view on SOA security, pointing out the world really hasn’t agreed on a consistent definition of SOA, and, therefore, there may be issues with attempting to provide security. As he points out: “If you can’t define it, you cannot secure it!”
JP adds that while there is plenty of research and literature on the topic of cybersecurity, there’s very little that connects SOA and cybersecurity. The problem is that SOA touches so many parts of the technology stack, and each has its own security solutions and protocols.
“If you’re tasked with focusing on cybersecurity for your SOA, you could focus on locking down access to your Web services, stopping SQL injection attacks, addressing DDoS attacks against the service, etc. Each of these areas requires considerable knowledge of the entire computing stack from telecom through the hardware through the operating system and into the application. Holy rotten fish Batman! That’s a tall order for even the most adept team, but it’s made even more difficult by the fact that there aren’t that many cybersecurity experts available that understands this entire domain.”
Still, Randy Heffner takes a stab at designing SOA security, starting with virtual private networks and two-way Secure Sockets Layer (SSL) at the simplest level. “Hackers cannot even connect to an SOA-based service unless they steal a certificate and key from a service consumer,” he says. Move up a step or two, and the next option is to leverage “existing SOA security features in Java or .NET application platforms and concentrating SOA security within an SOA specialty product such as an enterprise service bus, SOA and Web services management solution, SOA security server, or SOA appliance,” Randy says.
Ultimately, even when starting with a simple SOA security such as VPNs or SSL, SOA proponents need to recognize that the process will develop into something more intricate. The key is “to anticipate the need for and leave paths open to build additional, deeper security functionality as business requirements demand and SOA security maturity allows,” Randy says. We’ll grow and learn as we go along, he believes:
“Typically not all applications need all of your security requirements; initial applications may be able to do with a lighter-weight pass on building your SOA security solution, while later applications require you to fill in your solution with additional features…. Each time you make a pass through, you will learn more about how to build the most effective SOA security solution with the pieces that you have.”
Still, JP says the current crop of tools and protocols are too immature for top-to-bottom SOA. Things will only get more complicated as SOA-enabled services become part of cloud offerings. “What I have experience in with regard to the WS-* security mechanisms, security tools and technologies for securing Web-based and non-Web-based applications, still do not begin to address the real hard issues regarding cybersecurity in an SOA; especially as we expand the notion of service.”
SOA raises issues that never arose in the days of siloed applications and point-to-point Web services. Both Randy and JP recognize that securing a complex network that touches many parts of the stack is going to take work. Where they disagree is whether current approaches are at least a place to get started. JP adds that SOA is too much of an amorphous, changing entity on which to base solid security decisions.
August 10th, 2009
Posted by Joe McKendrick @ 6:00 am
Categories: Business ROI, Enterprise Architecture, General, Links, Standards Watch
Tags: Watson Co., SOA, Service, Service Modeling, Service-Oriented Architecture (SOA), Research & Development, Web Services, Middleware, Enterprise Software, Software
Richard Watson says there is too much hand wringing over service protocols and standards (REST, WS-*, etc.), and not enough thought given to why a service may be needed by the business in the first place. In a new post, he states that while “debates about whether to use REST or WS-* interface styles are seductive. But, these are the wrong questions to ask first.”
Instead, Watson urges the creation of services using a service model that will provide the business context to projects.
This is the essence of service oriented architecture, he says. “If context is not driving you to create the right services, then they are most likely not adding value to your applications architecture, they are making it worse.”
Build services that add value, he says. Forget about the protocol issues:
“Should I use WS-* or REST? Should a service provide access over HTTP, MOM, or XMPP? These are the wrong questions for architects to ask when first conceiving a service. By concentrating on how to build, we lose focus on what to build.”
Watson points out that when he talks about service modeling, he isn’t talking about things such as formalism, notation, and tools.
Service modeling is a smart idea for SOA environments because it encourages that services be mapped to business requirements, and not take on a life of their own as technology for technology’s sake.
July 29th, 2009
Posted by Joe McKendrick @ 8:45 pm
Categories: General, Standards Watch, Vendor Watch
Tags: Service Component Architecture, Loraine, Service-Oriented Architecture (SOA), Web Services, Enterprise Software, Software, Joe McKendrick
There’s been a blogstorm swirling around Service Component Architecture (SCA), and Loraine Lawson has done a great job of summing up both sides of the discussion.
To sum up, there are two points of view on the efficacy of SCA:
Anti-SCA: “SCA is heavily being driven by the vendor community and SCA breaks many of the rules of SOA that have been touted by these same vendors for the past six years…. SCA is a step backwards in software engineering. It’s an abandonment of the SOA principles that have failed because of lack of investment in proper architecture toward a pure programming model driven by software engineers. Thus, the goal here is once again to allow poorly-designed systems to be built by software engineers with very little architecture experience so they can claim to have some attributes of SOA.” -JP Morgenthal
Pro-SCA: “SCA is a key new technology that will help people achieve… greater simplicity, better service design, higher productivity and less dependence on large software stacks. I hope anyone… interested in these goals takes the time to take a closer look at the technology.” - Michael Crowley, author of Understanding SCA: Revolutionize How You Build BPM Applications.
Loraine observes that organizations need to concentrate on business requirements, not tools — and nurturing the skills that can help meet those needs.
June 24th, 2009
Posted by Joe McKendrick @ 3:28 pm
Categories: Business ROI, General, Management, Standards Watch, Web 2.0-Enterprise 2.0, Web Services, cloud computing
Tags: API, SOA, Dion Hinchliffe, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
We probably could argue for another 10 years about the ROI of SOA. Is there ROI? If so, why isn’t there more of it? How do we measure it? How should SOA be sold to the business? Why won’t the business provide more funding?
Or, we could move to a model proposed by Dion Hinchliffe, who proposes that SOA-based services be deployed the same way cloud businesses deploy their open APIs. In other words, managing an SOA effort as an internal business, providing services to the rest of the enterprise, with profits or losses, a la cloud.
As Dion points out, cloud providers face the rigors of the marketplace and have to prove their value every day. So why not model internal service orientation efforts after the experiences of those external providers? As Dion observes:
“The most obvious successes with service-oriented approaches aren’t classical organizations at all. They are Web companies that offer APIs out of a basic need: To build a network of partnerships quickly and cheaply as well as tap into external innovation and inexpensive third-party investment.”
This makes sense, as companies are becoming both consumers and providers of services. This providing and consuming also occurs internally as well as outside of the corporate boundaries. Dion proposes six ways to run an SOA effort along the same lines as a cloud business that has to meet market demands. Is the internal market any different?
Make services easy to use. These should be lightweight, Web-based services, versus the more complex technologies that have been associated with traditional SOA.
Itemize costs and charge as an outside provider would.
Manage internal customer accounts. “Open APIs are all strongly keyed to who is using them and is used for providing customer service, tracking usage, and creating accountability,” Dion says.
Provide for self-service. Public APIs can be used “without a lengthy company-to-company negotiation and partnership process” — it’s all automated and online to accommodate as many customers as possible.
Build a developer community. Today’s APIs nurture developers that build application that consume their services. This is the best way for SOA take off as well.
Allow for flexible use of the API by other business units. Nothing kills an SOA faster than if business units put the kibosh on the way their data is being deployed elsewhere. Dion says “an ideal license is one that gives permission for the consumers of API services to re-use its capabilities in running their business will provide the legal ability to use the API in as flexible a manner as possible.”
There’s another dynamic that Dion doesn’t mention, but worth mentioning. It’s not too far-fetched to imagine that IT departments deploying SOA-based services may end up competing with outside service providers. But IT departments have a supreme advantage that the outside providers will never have with their customers. That is, IT executives are often in high-level partnership roles with the business leaders. There’s no reason why internal services can’t be well-focused and well-targeted to pressing business problems or opportunities, the kind only an insider would understand. (An insider would have a better grasp of the politics behind an implementation as well.) IT and SOA proponents need to really leverage and continually demonstrate this advantage to the business. Know the business.
May 13th, 2009
Posted by Joe McKendrick @ 1:34 pm
Categories: Enterprise Architecture, General, Links, Standards Watch, Vendor Watch
Tags: Open Standard, Seth Godin, Enterprise, Service-Oriented Architecture (SOA), Enterprise Software, Web Services, Software, Joe McKendrick
“Open” is what we would like every piece of code to aspire to, and “enterprise” means a harmonious collection of industrious people and purring machines. They are the magical marketing words, evoking images of all that is good and wholesome. But perhaps they are getting overused.
Everything that’s anything in information technology these days is branded as “open.” Of course, when comes to implementation and pulling systems, services or software together, some of that “openness” tends to fall by the wayside.
In his latest post, Seth Godin drew up a list (inspired by Michal Migurski) of all the “open” things associated with IT, from open source to open infrastructure to open architecture. I want to also add open systems to his list, which used to mean Unix, and now pertains to any distributed system.
Of course, here in the service oriented architecture world, open standards is the word everybody loves.
(Come to think of it, isn’t “open standards” a redundancy, like a “free gift” or “unexpected surprise”? Or, here’s a couple I’ve spotted from time to time — “BPEL language” and “RDBMS system.”)
Godin observes that open standards mean “relying on rules that are widely used, consensus based, published and maintained by recognized industry standards organizations. It means that you’re not in charge, the standards guys are.” Hmm.
Then there’s that other overused word, “enterprise.” Miko Matsumura says its time to take the word back, and here’s why:
“In the context of software, the word ‘Enterprise’ has now officially come to mean software that sucks. Enterprise Software hit the nadir of suckitude at the launch of ‘Enjoy SAP’ This is like the American Dental Association launching ‘Enjoy Root Canal.’ SAP is certainly an easy target, but lets face it, ‘Enterprise Software’ is generally a poorly integrated mess. Working with Enterprise Software feels a bit like walking through an industrial landfill or an airport hangar. Nothing is built to human scale.”
Miko proposes changing the term to “The Human Enterprise.” I like the concept, but there may just be a tad bit of redundancy in there as well, unless we want to separate it out from the completely automated enterprise — and there may even be a few of them around.
Hey, how about “Open Enterprise”?
May 1st, 2009
Posted by Joe McKendrick @ 8:53 am
Categories: General, Links, Standards Watch, Vendor Watch, Web 2.0-Enterprise 2.0, cloud computing
Tags: SOA, IBM Corp., Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software, Software, Joe McKendrick
Many years ago, I was speaking with the founder of a small client-to-host access platform provider shortly after IBM announced its own tool in the space. I asked him if he was worried about being crushed by the huge Blue competition, but he actually welcomed it. He explained that his company was too small to evangelize and educate the market on why they needed the solution, and now IBM will be pouring its massive resources into market education. As he put it: “IBM just sprinkled ‘holy water’ over the concept. The same effect is also seen by smaller vendors competing with the likes of Microsoft and Oracle, of course.
Now, it looks like IBM is sprinkling its ‘holy water’ over an emerging trend we’ve been discussing a lot across the blogosphere and conferencesphere — that SOA as we knew it is morphing into the support structure for private clouds.
Yesterday, Big Blue announced two products — WebSphere CloudBurst Appliance and WebSphere Application Server Hypervisor Edition — that enable customers, in IBM’s words, to “extend their investment in service-oriented architecture (SOA) into a cloud services environment. These new offerings enable clients to easily create application environments that can be deployed and managed in a ‘private cloud.’”
As IBM GM Tom Rosamilia put it: “Like SOA, cloud computing is about re-use, service flexibility and standardization of processes.”
As clouds grow, we’re likely to see they are built on service-oriented foundations.
April 20th, 2009
Posted by Joe McKendrick @ 9:42 am
Categories: Data managemetnt, Enterprise Architecture, General, Standards Watch, Vendor Watch, Web Services, cloud computing
Tags: Oracle Corp., Sun Microsystems Inc., IBM Corp., Dana, Miko, Programming Languages, Java, Service-Oriented Architecture (SOA), Mergers & Acquisitions, Databases
“Thanks Larry for finally putting us out of our misery.”
-Tony Baer
There’s been a firehose of commentary to be found about today’s announcement that Oracle intends to buy Sun, so I won’t add to the noise. But I will point to some insightful remarks from fellow analysts and commentators.
Here at ZDNet, Larry Dignan points out the fact that Oracle now owns Java. Larry also notes that “Oracle gets to annoy IBM—and own Java—over a few pennies a share more than Big Blue was willing to pay.” Plus, Larry adds, there’s the matter of MySQL, the leading open source database owned by Sun, which Larry refers to as “MyToast.” Good news for PostgreSQL and Ingres?
And, I might add, the other side of the Java coup is that Oracle now controls Java Enterprise Edition, the core app server for many, if not most, enterprise SOA deployments. Hmm.
Then there’s Glassfish, the Sun-washed open source application server project, which Sun openly positioned as “an open-source alternative to WebLogic” (now one of Oracle’s app servers, of course). Will Glassfish be shattered and sunk, or be positioned as an entry-level environment, as IBM has done with WebSphere Community Edition?
I knew my pals Dana Gardner, Tony Baer, Miko Matsumura, and Dave Linthicum would have lots of meaty takes on the announcement, and I wasn’t disappointed.
Dana sees the acquisition as a pretty good thing, offering a weighty “global counter weight” to IBM’s dominance of the enterprise data center and IT services market. “This is truly healthy for IT and the global IT marketplace,” he says. “IBM’s earlier purported bid for Sun always smelled bad to me.” Watch competition in the private cloud space heat up as well, Dana says.
Tony parsed the various components of the acquisition in his post on the matter. (And there’s plenty to be parsed — it seems every day, Sun was trying to be in a different business.) Tony agrees with Dana that Oracle-Sun offers a competitive stack against Big Blue, and sees plenty of value left in the Solaris operating system. Watch what Oracle does with Sun’s JavaFX, which it may position more strongly as a lightweight Java-naïve rich client alternative, Tony says.
Miko refers to the new combined company as “Snorkel” and predicts the whole thing will be a “bloody mess.” Oracle is not experienced in managing hardware, and MySQL lost some key leaders most of its staff under Sun anyway, he says. Miko, who was Java Evangelist at Sun a few years back, speculates that Oracle may be favoring a systems approach over the software strategy that has gotten the company to where it is. “This is not a terribly optimistic acquisition in my opinion,” he says. “On the one hand, it shows Oracle as acquisitive and opportunistic–but we knew that. But I bet there are many forces inside of Oracle who are dead set against this deal. Oracle doesn’t have the skills to pull this off, and if there is a rationale for the deal, it’s being driven out of the CFO side of the shop, not from the software product side…. This means that the game continues to be owned by consolidators and life is bitterly hard for the innovators.”
Finally, Dave Linthicum chimed in by stating that he will not be chiming in. In today’s Real World SOA post, he starts off announcing that “By the way, I’m not talking about the whole Oracle-buys-Sun thing on purpose.” (And proceeds to expand upon my recent ebizQ post on measuring SOA value. Thanks for the call-out, Dave!)
March 13th, 2009
Posted by Joe McKendrick @ 9:05 am
Categories: General, Links, Standards Watch, Vendor Watch, Web 2.0-Enterprise 2.0
Tags: Gift Card, Enterprise Mashup, Chris, Web 2.0, Internet, Joe McKendrick
In this space, we argue a lot about definitions (or lack thereof) of terms and buzzwords, so it’s refreshing to see that someone is willing to ante up a reward for a good, working definition of at least one emerging term.
Chris Warner over at JackBe just announced that his company is offering a $50 Amazon gift card a week, along with the honorary title of ‘Mashup CEO,’ to anyone who can provide a nice, solid, definition of “enterprise mashup” — and put it in terms a beginner can understand.
What inspired this effort? Chris says that a few weeks ago, JackBe CEO and co-founder Luis Derechin appeared on Fox Business News to explain to the world the meaning of enterprise mashups. But Luis wasn’t entirely happy with the way he described it. (Chris provides a link to the original program here.)
Luis described it this way, which, actually, I think was a pretty good way to put it:
“A mashup is a dynamic Web application that brings together data stored in many different applications for better decision making. … A good example is data stored in a customer relationship management application, then an accounting application, and then maybe a production application. Bringing those together to get a 360-degree view, along with with news about your customer… in order to be able to make a clear and precise decision at any moment.”
Chris also adds that his company came up with the following definition a couple of years ago:
“Dynamic Web-based applications that combine multiple data sources in real-time for increased awareness and improved decision-making while meeting the stringent governance and data security requirements of enterprises.”
But Chris says that there needs to be a better way to explain the concept to the rest of the world: “Not bad, I think. But we need something a bit sexier for the next time we end up on TV. Remember, our goal is to craft something for the non-techy, the non-insider, the uninitiated.”
Hence the “Beat the CEO” to define enterprise mashups contest. I like Chris’s tweet-able suggestion: “Web 2.0 meets Excel.” But, as my colleague Dion Hunchcliffe then pointed out to him, you still need to define “Web 2.0.”
Joe McKendrick is an author and consultant with deep knowledge and insights regarding trends and developments in the technology industry. See his full profile and disclosure of his industry affiliations.
Email Joe McKendrick
Subscribe to Service Oriented via
Email alerts or .
SponsoredWhite Papers, Webcasts, and Downloads
