Blogger: Anne Thomas Manes
WS-I is sponsoring an interoperability demonstration of the Basic Security Profile on June 28 at Burton Group's Catalyst Conference in San Francisco. The Basic Security Profile provides guidance for implementing interoperable web services with basic security features, including authentication, message integrity, and message confidentiality, using SSL and/or WS-Security. Demo participants include IBM, Microsoft, Novell, SAP, and Sun.
Blogger: Anne Thomas Manes
VP & Research Director
Application Platform Strategies
I often hear questions such as:
If SOA is about "services" and REST is about "resources", aren't they fundamentally different things?
I also often hear the REST proponents claim that SOA is not really an architecture because it does not define specific architectural constraints.
But that's because SOA and REST operate at different levels in the architectural spectrum.
It should be clear that SOA and REST are complementary.
Mike Glendenning puts it beautifully in this post to the service-orientated-architecture discussion list in Yahoo! Groups.
The language of business design is very much about services, or the three questions of:
1) What will you do for me (the service)?
2) How will this help my business?
3) How much will it cost?So, we might have marketing services, finance services, HR services,
manufacturing services and customer support services all making up
our business. In choosing service suppliers, you care only
incidentally (through the SLA) about how the service is implemented.
Instead, services are considered as self-contained "black boxes".Historically, the language of IT has been all about implementation
platforms and technology, with terms such as the mainframe,
client/server, SQL, Java, WSDL, REST and so on. In the context of
trying to design the [whole] business, this is largely irrelevant.Now, if we can use the same language to talk about the operation of
the business as well as the IT systems then we are in a much better
position to understand and decide what IT systems are needed to
support the business. We can see immediately how these IT systems
will work with the other parts of the organisation to achieve the
aims of the business. And we can use the same methods for evaluating
the financial cost and benefits as we use elsewhere.
The rest of Mike's post is excellent, so I recommend you read it all.
If you're interested in learning more about REST, I highly recommend attending a half-day workshop, REST Easy, that Burton Group's Pete Lacey will be giving at Catalyst next week in San Francisco.
Blogger: Anne Thomas Manes
The APS team has been involved in a vigorous debate about REST for the last two months. Certain members of the team contend that WS-* has become bloated, unwieldy, and overly complex, and they fervently believe that we should not be recommending it any longer. Our resident RESTian also cites the fact that WS-* has no contraints, and therefore there's no way to ensure the properties and characteristics of applications built with it.
So if WS-* is a tragic mistake, does that mean REST is the next big thing?
Perhaps so. Vendors like IBM and Microsoft are starting to make major investments into technologies and frameworks that facilitate development using the REST architectural style. But for the moment, a steep learning curve and the dearth of available frameworks will stymie adoption. (For those looking to get started with REST, I recommend RESTlets.)
REST is not simply technology--it's an architectural style that's fundamentally different from they way most developers design systems today. It requires a noun-oriented approach to designing systems rather than one based on verbs. I know quite a few people that have been studying REST for years who still struggle with RESTful design practices. Understanding the basics of the style is easy. Truly groking it and being able to apply it to real-world situations is much harder.
Here are the basics:
Note that REST is not the same as "plain old XML" (POX). POX refers to the format of a message payload, and it says nothing about architectural style. It just says that you don't wrap an XML message with an XML envelope (e.g., SOAP or Atom). More to the point, not all POX applications are RESTful, and not all RESTful applications are POX.
Likewise, REST is not the same as HTTP. HTTP is an application protocol. It's middleware, not an architectural style. It just so happens that HTTP is the only application protocol that fully supports the REST constraints. But a developer isn't forced to adhere to those constraints. In fact, not all HTTP applications are RESTful, and developers frequently use POST to tunnel method invocations (verb-oriented style). Also note that REST doesn't mandate HTTP, but it is the only standard protocol that implements REST constraints.
For those interesting in learning more about REST, I encourage you to sign up for Pete Lacey's half-day workshop, REST Easy, at Catalyst on Tuesday, June 26, 2007, in San Francisco.
Blogger: Chris Haddad
Catalyst attendees experience truthful and thought provoking discourse that influences how technology champions and decision makers shape IT strategy. This will be my fourth year at Catalyst (and my first as a master of ceremonies), and I am excited about the opportunity to catch-up with perennial attendees and hear about the challenges, opportunities, and progress real-world enterprise projects are making towards reducing complexity, delivering a rich user experience, and realizing their path towards SOA nirvana. Transforming IT architecture and gaining solution delivery team adoption is a non-trivial task (if it was easy, the terms 'guru', 'wizard', and 'expert' wouldn't be associated with the technology domain). Change agents are searching for answers, and Catalyst delivers a real-world perspective. For example, sessions will factually address the popular questions I hear while out in the field; “Is anyone successful at SOA?” and “How does a COTS strategy impact my architecture plans?” Over the next twelve months, many organizations will decide if SOA and architecture transformation is a dream, distraction, or a nightmarish project fraught with too many pitfalls. Catalyst attendees have a unique opportunity to question Burton Group consultants, analysts, and peers and learn if a service-oriented led IT transformation, a rationalized architecture, and a unified user experience are fantasies or realities. I look forward to talking with you at Catalyst!
Blogger: Lyn Robison
In my previous post, I talked about the value of logical data modeling. But what do you do if a big portion of your data model is locked inside COTS or SaaS applications?
Many enterprise applications are tightly coupled with their data. Valuable information is often trapped inside enterprise applications. This is unfortunate because to maximize their value, applications and information are best managed separately.
The fist step to liberating enterprise information from the grip of applications is to model that information at a logical level, even if – especially if – it is buried inside of enterprise applications.
Application vendors could do a lot more than they are doing to help you create logical models of the information that they hold. I will present more on this topic at Catalyst in June, but it turns out that some SaaS vendors are doing more to make their information readily available to you than COTS vendors are.
You might think that you can get at the information more readily from COTS applications then you can from SaaS applications. After all, COTS applications store their data inside the walls of your enterprise and SaaS applications store data outside the walls of your enterprise in their own data centers. But the truth may surprise you.
Some prominent SaaS vendors offer APIs for accessing your information directly, outside of the application. Through these APIs, SaaS vendors are in essence publishing a logical data model. The data model is probably incomplete, and must be inferred from the API, but at least it is there.
The majority of COTS vendors provide absolutely nothing for you in terms of a logical data model. With a typical COTS application, you have to try to infer the logical data model from the database schema, from data entry screens, and from reports. Not an easy task. Progressive COTS vendors will provide a service-based data access layer for their applications, but those vendors are few and far between.
Logical data modeling can be messy and difficult to do, and the reward is the ability to decouple your information from your enterprise applications so you can manage them separately and optimize them both. Application vendors could help you do this. Through my Catalyst talk and through reports that I will publish in the coming months, I will try to talk application vendors into making logical data modeling easier for you to do.
