So here is a simple picture to describe how I think people should expose internal functionality to external consumers. There are a couple of things here- Internal Services have "business" interfaces, these are what the developers, analysts, architects and the business understand in terms of the capabilities being offered. This is the "code" interface (not XML)
- NEVER EVER EVER expose this directly. This means you now have tightly bound your internal code to your external customers
Then you sit down and decide how to expose it externally. Will it be REST, will it be WS? Will you decide to use pub/sub notifications, will you decide to use flying monkeys? Quite frankly who cares?
This external service is the one where you will decide to plump for WS or REST, or hell why not go mad and support both. Now converting a business interface into REST probably means having multi URI points to represent different managed resources, but that isn't exactly difficult either.
All we nmultio do in this case is to run three external interfaces, which are just doing data exchange, there is no actually functionality here as that lives down in the backend.This way as our backend functionality changes we can prevent our clients having to directly upgradebackendan in fact use thisbackendch to support multiple interfaces concurrently, based on a single business service implementation.
Equally we can make changes to the external interface, to add security (always a good idea), to optimise the interface or to move it from a custom schema to an industry standard one. The important bit here is that you've modelled your business service correctly and it has the right capabilities which you are then choosing to expose. The mechanism that you use for exposure isn't important at all and 100% isn't where the flexibility comes from.
Flexibility comes from that internal service being able to react to the business and change with the business. That is the architectural challenge. REST v WS is an implementation challenge, which is something to worry about (its part of SOD IT) but its not what gives business agility or flexibility.
I'd really strongly recommend that people always use the pattern above, its saved me lots of pain over the years.
Technorati Tags: SOA, REST, WS, Service Architecture
30 comments:
REST is an *architectural* style. It's most definitely architecture, and the choice to use it or not most definitely affects "business agility".
Some people use it as a synonym for "HTTP & URIs (and sometimes XML)", but it's not. It's an abstract description of an architecture, akin to "client/server" or "pipe and filter".
Just because someone says something is an architectural style doesn't actually mean it is....
client/server and pipe/filter aren't architectural styles, way back when in the 90s people said they would "design" something to be client/server or "3 tier" or "n-tier".
What I'm trying to say is that where REST/WS matters is at the external interaction point, not in terms of the internal business service architecture and in the "code" (where PUT/GET/POST et al would make rubbish classes).
The problem is that design is now a "dirty" word and we have to dress it up in bigger words. REST is still a technology solution to a problem of shifting bits across wires. It has nothing to do with how you define the business architecture of a system.
Well, let's try and avoid the word "architecture" then, because we seem to mean different things by it.
But I maintain; the choice to use REST, MOM, RPC, pipe and filter, or whatever, affects "business agility & flexibility" because each of those options contributes different degrees of each property. RPC, for example, is notoriously non-agile & inflexible.
Picking the wrong approach always causes issues. RPC might be the right approach in some cases (in cluster component to component comms for instance).
Picking the wrong (or right) approach will hinder or help deliver some flexibility, but if you've got the business services wrong then its just going to be lipstick on the pig. That's why I say WS v REST is pointless, as we need to focus on the big picture part of SOA and stop obsessing around the technology.
You ask the questions: "Will it be REST, will it be WS? Will you decide to use pub/sub notifications, will you decide to use flying monkeys? Quite frankly who cares?" Answer: the client cares.
Your entire discussion focuses on loosely coupling the external service from the internal service. What you neglect, and what violates the REST architectural constraints, is the coupling between the client internal consumer and the external service.
REST imposes a number of vital constraints to ensure loose coupling that you seem to think are a "who cares": statelessness, global identifiers, uniform interfaces, etc. These have all proven to be vital in loosely coupling the client from the external service. If you think the interdependencies between 10 thousand clients and your external service interface are a who cares, then THAT's rubbish.
What do you mean by "if you've got the business services wrong", and do you not believe that choice of "approach" may help or hinder that?
I've yet to see any REST approaches that help in the definition of business services in terms of the language of the business which is where Services based approaches are very strong.
I haven't neglected the internal to external split, that is where the facade and the dual mediation element comes in (how de-coupled do you want something?)
REST doesn't at a business level have a consistent interface, and elements like statelessness being "good" are certainly not something that REST has defined (and sometimes you do actually have to be stateful, for instance when negotiating a security credential).
If someone can point me to the REST article or book that enables me to model Vendor Managed Inventory with the business in a REST (rather than services) approach, I'd love to read it. So far what I've seen has focused on the implementation of the execution context.
And to the last point.. who cares? The client (the business) 100% does not care what technology solution you use, as long as its cost effective, easy to maintain and meets their business objectives.
I agree that these are technology issues and not relevant to the service definition and design - however I do not think its irrelevant - behind all SOA there has to be some level of technology (though I have long believed that it is currently far too weighted toward technology).
As to the point of implementing both - it does sound wonderful to simply make the technology magically appear however considering the definition of external services so non-functional requirements, as well as external client technology choices can be met, is obviously a part of the technical implementation?
If someone can point me to the REST article or book that enables me to model Vendor Managed Inventory with the business in a REST (rather than services) approach, I'd love to read it. So far what I've seen has focused on the implementation of the execution context.
Your now saying REST is not the same as a services approach now thats really dumb. Especially as in previous posting you've said whether you expose a service as WS or REST its the same thing.
Also having used both WS and REST they have different architectural constracts (around security and transactions) that do affect your business so not to care about which one is pretty silly.
N
Philip, I completely agree on the non-funcs for external services, this is one reason for putting in the facade so you can look at active caching and the like. Its certainly part of the implementation challenge, which is my point, WS and REST are implementation challenges. SOA is about the architectural and business challenge.
To anonymous, I've obviously not made myself clear. REST is an implementation pattern or software design approach for Service implementation. What I am implying is that REST isn't architectural as a style as it doesn't enable you to create business architectures, its focus is on the implementation of those architectures.
At implementation maybe you will care, at a technical level, but you won't care at a business level. I'm not advocating the blind use of technology, but that WS v REST isn't actually an important debate (its hard to image something in REST that is impossible, or even difficult, to implement using WS), you might build the REST interface differently from the WS one, but so what? The important bit is the service and capabilities you are offering, not the mechanmism via which they are offered.
NOONE EVER EVER interacts with a service because of its technical implementation, its ALWAYS because of what it actually DOES.
The technique can apply also protocol choices - e.g WS vs. JMS.
See post
http://blogs.ittoolbox.com/eai/business/archives/service-interface-protocol-choices-11720
Ok, again, let's try and avoid words like "implementation" and "architecture" because we don't agree what those mean.
You say;
"REST doesn't at a business level have a consistent interface"
Why not? REST says that, for example, both individual orders and individual invoices, can be requested by the party that wants them, from the party that has them, via the common GET operation.
How would parties request those documents from a "business interface" POV?
"GET" isn't really a business interface. If you are company A buying stuff from company B, then the odds are you want to see them provide an order service, you'll want to see things like "request a quote", "place order". You might then like to see something that provides order tracking features (note its quite normal for business to view the order creation element as completely separated from fulfilment).
GET is a technical mechanism for exchange, its not going to mean too much to two business folks who are buying and selling apples.
This is what I mean by a business interface, one that makes sense to the business people, that models both the services (e.g. order management & fulfillment) and the capabilities in the manner that the business operates. This is how to give flexibility to a system.
There is then the question how you exchange the information, and for that you could choose WS or REST (although WS will probably be more "business" like than REST).
Sure, I agree with the pattern you describe here, though I still ahve issues with some of your commentary here.
From a business architecture angle, it doesn't really matter what mechanism defines your service contract, as long as there *is* a well defined service contract that is mediated among multiple mechanisms.
Having said this, there is a lot to learn from REST as an abstract architecture. Many business and technical issues are intertwingled.
Here's something I'll throw out as a challenge: business identifiers. How do I identify a customer, or an account or a product? How are those identifiers managed? How do I use, reference, or dereference them in a business process?
Now, is that a technology challenge, or a business challenge? I think it's a business challenge because it doesn't necessarily have anything to do with computers (same issue with pen, paper & filing cabinets). And thousands of companies are dealing with a lack of consistent way to identify a customer due to a fragmented business architecture.
Given the above, and assuming we come up with a workable business architecture, aren't there some implementation mechanisms that are better suited to handle this business challenge at a broad scale?
One final note:
"NOONE EVER EVER interacts with a service because of its technical implementation, its ALWAYS because of what it actually DOES."
Web search engines are the counter example to this. They interact with other services because they all have the same technical implementation, regardless of what the service actually does (if it's a static information page or dynamic, etc.), and they seem to have derived several billion dollars in revenue from it.
My point is that agreement & uniformity has a lot of benefit at a variety of levels & specialties. You're absolutely correct that a technology solution will not guide, fix, or work with a bad business architecture.
But we are not just dealing with business SMEs, we're dealing with technologists, too. They both have to understand and align their intent, which continually diverges. Some technological constraints may be better suited than others to keeping that alignment or "hygiene" in place....
Stu, I'm not going to disagree with anything up until the stuff about the Search Engines its all spot on in my book. But with Search Engines, although their technical implementation is made much better because of the single mechanism available to them, the end-users don't really care about that (when people did old style autonomy stuff it didn't matter) they just care about the value they are getting from searching. For the consumer there is absolute business value independent of the implementation of search.
100% agree on the identifiers challenge. Are they just data, or are they behavioural as well? Are some in fact agent services that flow through other process oriented services?
Again I agree on the last paragraph, but I've tended to find that the biggest issue is getting the technologists away from the technology, not getting the business guys to understand services.
"
You say that "request a quote" and "place order" are both business interfaces, but that GET is not. Let's explore that.
What about a stock quote service, which only gives out data to those that ask? Would you say that "get stock quote" is a business interface but "GET" isn't?
Get Stock Quote would be a capability on the service yes.
GET on its own isn't a business language thing as it doesn't tell you what is being "GOT".
To be clear, on its own GET isn't a service, its a capability of a service.
But GetStockQuote doesn't tell you whether it's a real time or delayed quote. Does that mean that only GetRealtimeStockQuote is a capability of the service and GetStockQuote isn't?
Similarly, would GetQuote - which can return stock quotes, auto insurance quotes, etc.. - not be a capability of a service?
I don't see why generic capabilities like GET aren't capabilities in the same sense as GetStockQuote.
GetStockQuote would be the capability, its timeliness of information is probably going to be down to the business policy in place for the service.
I can't really see the point of a GetQuote service which is polymorphic based on entry, that seems a pretty inelegant solution. Creating a generic Quote service that then does the routing.... not something I'd advise if you want flexibility.
GET is a capability of the HTTP Server, its a capability plain and simple. But what HTTP GET isn't is a reasonable business capability that will actually make sense to people.
The purpose of a service should be to prevent a consumer friendly representation of the service, its capabilities and policies. This means describing the purpose, intent and data that the service and its capabilities use.
Straight "GET" doesn't do that.
So GetStockQuote is a capability but GetRealtimeStockQuote isn't? That's a pretty fuzzy line you've got there.
Let's draw the progression here, from very specific to very generic;
GetGOOGRealtimeStockQuote
GetRealtimeStockQuote
GetStockQuote
GetQuote
Get
Why is it not the case that "Get" is a "capability" and the timeliness, type of quote, and ticker symbol are all "business policy" issues? The line that you drew at GetStockQuote is completely arbitrary.
REST says you draw the line at the most general operations. Like GET/Get. That's not arbitrary.
GetStockQuote is not a service. Its a capability on the service (like a method on a class). So the line isn't very arbitary at all. The Stock service, which has a number of methods
"GetQuote", "Buy", "Short", "Long" etc.
Now you could then create an external facing facade on it which caches the GetQuote requests for 15 minutes to reduce the load on the internal server.
But there really isn't a great deal of complexity here. The line is drawn when the Service doesn't make sense to its consumers. And while a StockQuote service with a single capability of getting a time-delayed quote is something that does make sense, having something just called "Get" without the context of the service is meaningless.
Defining things as their most abstract is 100% useless for end users, after all GET isn't the most general, I could have a PUT operation which includes a header of "GET" to do gets etc etc.
The purpose surely is to create things that mean something to end users, mainly the business. That has to be the goal of a decent systems design otherwise its just lots of time farting about with technology.
"The line is drawn when the Service doesn't make sense to its consumers."
Which is arbitrary, because it depends on the consumers, and the consumers of a service change over time. The more specific the operation, the more likely it is to need to change, which is why generic is a better choice for building evolvable systems.
Anyhow, I don't know how you can claim that GetStockQuote is "meaningful" to users, but "Get" isn't. And PUT with a GET header? WTF?! Let's just talk in terms of operations; GET/Get is one, just like GetStockQuote is one. Period.
Phone up a non-technology friend and say
"If I said 'GET' what would you think?"
The try with another non-tech friend
"If I said "GetStockQuote" what would you think?"
There is the difference. One means nothing, the other says what it is. You appear to be confusing a technical mechanism (GET) with something that consumers interact with (GetStockQuote), the purpose of evolution in systems isn't to make it easy for the technology, its to make it easy for the users. Saying "GET" and the users will figure it out isn't an acceptable solution.
If you said "Get Stock Quote" to a person, that person would have a bunch of follow-on questions for you, such as which ticker symbol, realtime or delayed, etc..
If you said "Get", they'd just have to ask you more questions, but they'd still know you're requesting some data from them, because that's what the "Get" part means (in both cases).
Stop thinking of HTTP GET. I'm just talking about "Get" here - what you get when you generalize "GetStockQuote" a little further. Forget the Web for a sec and let's just talk about operations invoked over a network.
I'm really not seeing your point here.
In one case you have to define the data formats (which WSDL does quite nicely) and the policy (which no-one does)
And in the other you have to explain everything. Why is requiring additional questions of consumers a good thing?
A full description that requires little additional information for a consumer must be preferable over something where they don't have a Scooby Doo about why they should even bother asking questions.
If you walk into a bank and say "PUT", it means nothing. If you say "Deposit Money" or "Deposit Cheque" then it means something. If my bank had the "GET/PUT/POST" approach because that is more generic they would drive me even more nuts than they do today.
I really don't understand why its better to have less descriptive descriptions and expect people to "work it out" for themselves.
I think you're taking the speak-to-the-bank analogy a bit too far.
My point is that "Get" is the same kind of thing (operation, "Capability", whatever) as "GetStockQuote", it's just more general and therefore more reusable; software implementing it can evolve in a wider variety of ways before the interface needs to change.
To risk another analogy, could you imagine how difficult it would be to use a database where each table had its own interface; if the Employee table supported SelectEmployee, and the Customer table supported SelectCustomer? It's a *good* thing that they all support SELECT for some of the same reasons that GET is better than GetStockQuote.
Ah, the wonder of SQL, a language that was once promoted as being "business user friendly". Using SQL SELECT as an example of flexibility really doesn't hold up, because its a programming language. Its like saying that brackets are flexible because of LISP.
The point is whether descriptive names are better than non-descriptive names, and I'm firmly in the descriptive camp.
Which is better
SELECT User.name, User.age, Address.line1, Address.line2 from User, Address where User.id = 4 and Address.id = User.address_id;
GET
or GetUserDetails
I find it really hard to understand why its better to have a consumer method that doesn't just do what it says on the tin.
"I find it really hard to understand why its better to have a consumer method that doesn't just do what it says on the tin."
It does do it. "GET/Get" is a request for data. "GetStockQuote" is a request for a specific type of data; but the "Get" part of "GetStockQuote" means exactly the same thing as "GET/Get".
Why is this so hard? Ergh.
Anyhow, it seems you at least agree that "Get" is the same kind of thing - capability, operation, .. - as GetStockQuote. So we've made some progress here! 8-)
And here in lies the point. To me "GetStockQuote" is a good name as it says what it does, "Get" is a rubbish name as it doesn't, as the verb has no noun on which to act.
Moving towards the broader quoting challenge, for instance Insurance, people's language changes here and they aren't "Getting" quotes anymore they are "Requesting" so a good name for an insurance quote would be
"RequestInsuranceQuote".
Verbose names are good, they make it easier to understand for the consumer. A name like "GET" is bad as it doesn't help the consumer, and it isn't the most appropriate verb to describe requests, retrieval, or even to do techy things like "peek" over removal.
GET in REST is dictated as being idempotent IIRC, which means that a Queue couldn't have the GET method actually removing something from the queue... which doesn't seem to make sense to me as Queue.Get clearly will remove an element from the queue.
English is a rich language, limiting yourself to 4 or 5 words is a tragic waste. REST v WS is a technology debate, what ever you use the consumer should be seeing something sensible to themselves.
Its a very nice blog for...
architects in bangalore , architects in bangalore , interior designers in Bangalore , interior designers in Bangalore , architects in bangalore , architects in bangalore , interior designers in bangalore
Post a Comment