|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
News
News
News
|
Messages: 47
Messages: 47
Messages: 47
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
A Service Versioning Covenant
Rocky Lhotka challenges the common concept of contract based services for their inflexibility, particularly with regards to service versioning. His idea instead is to create a covenant based on the semantic contract allowing for maximum flexibility in terms of interaction and loose coupling.Collectively we love contracts. They give us better performance, better debugging, better development experiences and more. Things like Intellisense and compile-time validation exist largely due to contracts. It would be easy to think that contracts and strong typing are nothing but good.
But there is a dark side. A formal contract comes with serious limitations. It can be defined as “a contract made binding by the observance of required formalities regardless of the giving of consideration” (dictionary.com). Consider what this says. It says that there is no flexibility, that the formalities must be observed no matter what. He then talks about the concept of a covenant, a more loosely defined agreement and how it can be implemented in for services .NET.Specifically I’m suggesting that any f() should accept any message. It should then examine the message’s schema to determine its course of action. This is all governed by the covenants into which f() has entered.
I’ll also suggest that there is one covenant to which all methods must adhere, the Exclusive Covenant. If f() receives a schema for which it has no covenant, it will reject the message and take no other action. Methods are exclusive and only handle messages with acceptable schemas. Read A Service Versioning Covenant.
|
|
|
Message #167290
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Design practice
from the article, my impression is it's more of a design practice and not a design pattern. I can't help feeling this is old hat for those who have been working on services for a while.
There are other approaches to handling very dynamic environments. Some of the techniques under research include pi-calculus, and case base reasoning. In situations where the participants take many forms and the messages vary dramtically, it's necessary to have a discovery mechanism and a way of describing how that data is used. In these types of scenarios, the request includes the message and a declarative description of the usage. BPML and the various webservice specs are trying to address these scenarios, but so far I'm not impressed. right now it looks like one big political battle to stamp each companies own implementation as the standard to get a leg up.
peter
|
|
|
Message #167313
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A Service Versioning Covenant
"Rocky Lhotka challenges the common concept of contract based services for their inflexibility, particularly with regards to service versioning. His idea instead is to create a covenant based on the semantic contract allowing for maximum flexibility in terms of interaction and loose coupling."
I have absolutely no idea what that means.
|
|
|
Message #167376
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A Service Versioning Covenant
After reading the article, do you still not understand what it means?
|
|
|
Message #167385
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A Service Versioning Covenant
"After reading the article, do you still not understand what it means?"
I was just being a pain. Opening with that sentence is similar to using a word in its own definition. The article itself was interesting.
|
|
|
Message #167388
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Everybody is a critic
I'll be sure to shoot you an email when the next article is ready and YOU can write up the description. :-)
|
|
|
Message #167391
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I hope thats not the common concept of services
I dont really agree with what Rocky's take on what the common perception is here. He seems to be taking (from what I can see anyway) the starting position that services will be programmed exactly as regular co-located objects are today and will have very chatty, explicit binary interfaces. Anyone who has worked on distributed/decoupled systems will tell you this is a very bad idea. I also get the impression he is taking a very narrow view of the contract interface. Interfaces can be narrowly defined and highly specific but they can also be highly abstract and flexible just as easily.
If services are programmed at the fooBar(string, int, bool) level than yes the versioning issues he raises will always cause problems. Personally I would consider a service with this level of granularity and explicit binary interfaces pretty self defeating though. For me the purpose of services is to decouple, to allow the client to request a handler which matches its needs and to provide freedom of location, implementation and time constraint to the handler to get the job done.
Most people I hope would be familiar with the concept of using some form of lookup to request a service i.e. open negotiations about obtaining a contract, at which point either party can reject the proposal. Once a contract is established we use the inter communication messaging process to decouple the request and associated data transfer in the manner the designer wishes (metadata, DTO wrappers, abstract interface parameters, xml, there is a lot of scope here). The implementation can then decide on receipt of the request how to proceed. Normally this will again involve looking up a handler to act on the request, or deny it if no appropriate handler is found (this handler determination is I believe equivalent to Rocky’s covenant). So in this manner we abstract the entire process as much as possible leaving the implementation till the last possible moment and allowing us implement logic in both lookup an implementation to determine the handler most likely to provide a successful outcome. I would also expect requests be quite coarse grained so the handlers could perform substantial chunks of work (asynchronously if required) in what would appear to the client as an atomic operation. These concepts are nothing new and have been encapsulated in CORBA and messaging systems for years.
This system is not perfect but does allow me create a ‘contract’ which will be stable over time and more importantly allow me for the most part to cater for new requests by adding new handlers. I don’t consider the request as a client invoking an operation on another specific object, more the client sending a message to a service asking it to attempt an operation. How the service, which is really a gateway to the various implementations achieves this irrelevant to the client.
Against that the client may have to provide some metadata as part of the request and as Rocky points out type checking at compile time goes out the window. Across a messaging interface though I don’t necessarily consider a lack of compile time checking a bad thing. If I want to provide maximum flexibility then I don’t want the compiler second guessing what I am trying to do. Naturally I also expect my handlers to perform validation, security, sanity checking etc. If my handler implementation breaks because of versioning issues then I am doing something wrong (and I expect a job offer from Microsoft to work on their data access team :) )
Obviously we can’t cater for every single future requirement but neither can we avoid the fact that at some point in the code we must decide what it is going to be done with the request. IBM spent a huge chunk of cash on polymorphic method resolution trying to resolve this and did not get very far with it, trying to cater for every possible scenario eventually becomes overwhelmingly complex. Abstracting the communication interface and allowing the service freedom of determination alleviates much of this complexity in a very simple and consistent manner.
I suppose in context though historically Microsoft are coming to these concepts with some baggage. COM in itself was not bad as a single process binary protocol once some of the nitty gritty was wrapped and smart pointers were used. Trying to bolt remoting on to it was not a good idea and the less said about version incompatibility the better. I’m sure I’m not alone in having seen seeing applications crash and burn on production servers because of different MDAC versions, JDBC was <insert supreme being here>'s gift to data access after that. Still nice to see Microsoft are moving on.
|
|
|
Message #167399
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ok, Rocky, time for your medicine like all the other authors
You have suggested this middle thing that can say, "if, else" as opposed to this for that.
However, for someone who critizices the complexity of AJAX, how can you not see that this "If, else" covenant can quickly grow out of proportion and it will immediately become un-maintainable. Pretty soon you will have an application that is tailored to one customer....so why have a service then?
Anyone who advocates SOA architecture or SO architecture clearly hasn't been on both sides of this architecture as seen the real world hell.
There was an SAP's article recently thing that said that if you buy into a service orientated architecture, you might not be able to get the service or NEW feature you want 2-3 years from now because the service provider can't simply customize a feature that only 1 or 2 customers need.
Now you are locked in with this service who simply doesn't have the resources OR thinks they know better than the customer does in regards to business logic.
I would love to just hammer away, but you can easily see that SOA is just plain stupid from a business perspective and only fueled by greedy and controlling programmers who get what they deserve in the end. bankrupcty and no customers for their service.
|
|
|
Message #167440
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I hope thats not the common concept of services
Certainly these ideas are not new. Many days I'm convinced that anything really new has been invented for perhaps 20 years... Fortunately, most days I'm not quite so cynical.
However, just because some small number of elite programmers figured out how to make CORBA or DCOM work and version very effectively doesn't mean that the vast majority of programers have it all figured out.
While I think at this point in time most people who've build distributed systems understand the need for course-grained communication, the fact is that there's a serious rush toward building Web services following a component-oriented model rather than a message-based model. And this will lead us rapidly right back to where we were in the 90's. Right back to the state of affairs that led to the adoption of Java and later .NET.
Marty, you might get it. You might even work with people that get it, and you may be building message-based systems and having a great time. But if so you are in the minority. Most people who are creating "services" are really just creating component-based systems comparable to the "distributed object" systems of MTS/COM+ or similar technologies.
And don't kid yourself that it is just in the Microsoft space. I've spoken on SOA at a few Java events this year and I can tell you first-hand that the Java world is about as confused as misguided as the Microsoft world in this space.
Worse, we haven't even reached the parts of service-orientation that I find truly interesting. That comes when services are not only message-based, but are async. Then service-orientation will really shine because we'll be building parallel distributed systems. And THAT is something actually worth getting excited about!
|
|
|
Message #167441
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ok, Rocky, time for your medicine like all the other authors
Heh heh! Obviously you've read my blog, so you know I'm a serious SOA skeptic.
But the fact is that service-orientation, if done right, could be really cool. It will never replace traditional client/server or n-tier concepts - that's not its purpose. Its purpose is to AUGMENT them where appropriate with distributed parallel messaged-based communication.
Do all systems need this? Of course not. A forms-on-data system certainly doesn't need anything this complex or inefficient. But at an enterprise level people need to link multiple monolithic, autonomous systems together in interesting ways, and THAT is where client/server and n-tier concepts really fall apart fast. That's where a message-based model works really well. And to make it work in the broadest sense, the communication also needs to be async so temporal disconnects are acceptable.
Is that hard? Sure. Is it harder than trying to make n-tier concepts work? No. We already know that n-tier concepts don't work across applications. Even if SOA is hard, it has a better chance of working in such scenarios than what we've tried in the past.
|
|
|
Message #167450
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I am constantly being amazed
The author is right but why say it in so many words? For a quite a bit of time now (after being hurt) we have just used one(1) parameter for all web service methods, a delimited string that is parsed at the server. Different courses of action can then be taken depending on type and numbers of parameters.
In other words we are using,
"Inbound messages that are automatically routed to the correct implementation based on schema type and requestMessage and responseMessage that is governed by covenants!"
My God fancy that! ;)
And why use a tool generated proxy on the client when a Soap header is so simple to put together manually?
Am I doing something wrong?
Just wondering
Rolf Tollerud
|
|
|
Message #167467
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
This is very much in line with a solid SOA Entry Point
This has been documented in a bit more specific terms by many authors and I have indeed found that this works well.
To be more specific I need to refer to design patterns. You have a 'Chain of Responsibility (COR)' to take in the variable parameter (you only need one String as that can contain an XML document for example of any complxity. I always opput my Chain of Responsibility in Metadata and use Reflection to find the handler of the message. If there are none, the call fails.
If I understand this brief dialog Rocky is simply extending this idea across all channels. A single entry method with unlimited and variable parameters in the single parameter (as a String or other type) then a COR to find a servicing agent. It makes sense. It's just another design approach.
I'm not sure I'm ready to agree that it will always be more appropriate then a clean Interface where a developer can look at the code an undetstand it instantly. When you have:
public void DoSomething(String ServiceParamaters)
as your only entry poiny.. You've potentially raised the level of abstraction and extensibility but at the cost of easy semantic meaning and compile-time error checking.
Interesting idea if I got it right..As I said I do this all the time for SOA but had not considered going beyong that.
Kind Regards,
Damon Carr
|
|
|
Message #167476
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Linking systems via SOA is asking for trouble, BIG trouble
SOA is a simply a BAD design to begin with, especially with enterprise systems. The bigger the system, the LESS abstraction you want to use. Why? cause this one SOA service will ultimately cause a complete catastrophic melt down of the enterprise system with a SINGLE bug because TOO many systems are linked to it.
Furthermore, once you have an SOA up and running and as more users or systems connect to it, it will NEXT to IMPOSSIBLE to fix things, upgrade things because everyone in the entire organization will have to ready for this ONE upgrade...it will sort of like pushing out SP2 Windows XP.
Say if the arrogant power hungry IT developers of the service think that this field of data is causing problems and needs to be eliminated, now what? Or this field has been replaced with this field or renamed? OR we added a field in replacement with this field? Who is to say it is causing problems or not causing problems? Now you got a LEGACY systems that can never be changed because a single user that will be critically affected by the use of this service. Say if this system goes down because someone got sick, or management had to cut their budget...now what?
Now this is just a SINGLE SOA service......what happens if there are more services? Now what?? The entire enterprise organization is now in a contant SOA patch mode for one service or another service.....
Anyone advocating services is completely clueless of the real world. Remember Passport....that's was a SOA....that died totally, yet you have those on the speaker circuit and a myriad of authors and "wanna-be, I have a certification" developers and architects who are only drones of the consensus wisdom of the software industry. These people on the speaker circuit have ZERO production coding experience and they have absolutely no right to be telling anyone anything about architecture. These people spend all their time at MSDN dev days and tech-ed and practicing powerpoint demos; How can they have an ounce of time to do the "production coding" in a real world to simply give a 1st hand recommendation?
I could on and on and document the absolute HORRORs of SOA's in the real world, but I will let this be enough for now.
As far as I am concerned,
SOA = SPAGHETTI ORIENTATED ARCHITECTURE
Heh heh! Obviously you've read my blog, so you know I'm a serious SOA skeptic........... But at an enterprise level people need to link multiple monolithic, autonomous systems together in interesting ways, and THAT is where client/server and n-tier concepts really fall apart fast. That's where a message-based model works really well. And to make it work in the broadest sense, the communication also needs to be async so temporal disconnects are acceptable.Is that hard? Sure. Is it harder than trying to make n-tier concepts work? No. We already know that n-tier concepts don't work across applications. Even if SOA is hard, it has a better chance of working in such scenarios than what we've tried in the past.
|
|
|
Message #167491
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I guess I don't get it
I guess I don't understand the article, but I get the following so far:
One has to specify N couples of Request/Response schemas, but instead of passing these to N operations it will pass them to one which will route internally to N implementations ...
As the Web service plumbing does the routing automatically for us, I don't really get the point why I should do it myself - is it only because of the soap operations not being overloadable or what? If the client chooses another request/response, it won't be a problem for him to choose an "overloaded" operation (eg. DoWorkWithMoreParams) as well, I guess ;)
|
|
|
Message #167508
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Linking systems via SOA is asking for trouble, BIG trouble
Say if the arrogant power hungry IT developers of the service think that this field of data is causing problems and needs to be eliminated, now what? Or this field has been replaced with this field or renamed? OR we added a field in replacement with this field? Who is to say it is causing problems or not causing problems? Now you got a LEGACY systems that can never be changed because a single user that will be critically affected by the use of this service. Say if this system goes down because someone got sick, or management had to cut their budget...now what?
I think you left out developer being bitten by a rabid dog on way to work, developer succumbing to demonic possession, meteor impact on developers house and front line developer casualties in the alien invasion as more likely SOA disaster scenarios than what you describe RH.
|
|
|
Message #167545
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A couple of issues with this otherwise great article
Great article Rocky. That said, I think you introduce some couplings that keep your implementation of SO closer to COM/CORBA than you'd like. In a messaging system what types of dependencies are there? I can see eight types that fall into two categories: The categories include semantically meaningful, and semantically meaningless. In the semantically meaningful category we find: The functional semantics, reliability, transactionality, and message structure (as in the structure of the message itself, not the schema upon which that structure was based). In the semantically meaningless we find: Envelope, Encoding, Location, Transport, and Security. You cannot change any of these characteristics without some level of your system needing to handle the change. An architecture that meets business needs while remaining adaptable has two mandates regarding these dependencies: 1) don't add new types of dependencies, 2) don't conflate dependencies such that they can't be changed independently. I will try to demnostrate that in your article you do both:
When you say that a service should examine the schema of a message, you introduce another dependency: that dependency is type system. There are several problems with introducing type system as a dependency. First, is the assumption that the client and server make about having a common type system. Second is the fact to overcome the first issue, you need to ship that type system (the schema) around with the message otherwise how do you know that my element of type urn:epinto-mytypes:foo is the same as yours? Most message exchanges aren't designed to include this information, and I'd suggest that they shouldn't be. Never assume that a message has a schema. A message doesn't have a schema, rather, it may or may not conform to a schema. Rather than trying to interpret the schema of the message, a service should validate the structure of an incoming message directly against the schema it has exposed in its erm... covenant.
The second thing you say is that is that there isn't a place for a super router. I think this conflates the semantically meaningful dependencies with the semantically meaningless dependencies. As we manage more and more services, it becomes important to be able to manage the location, transport, and security of that message independent of the semantically meaningful stuff. I would argue that using something like Biztalk to decouple initiators and responders on the axis of location, transport, and sometimes security, is a good thing when that kind of decoupling is needed. When it comes time to build the unit of code that someone calls a service - I agree, it is important to have a coherent set of message handlers. That said, if you can think towards a system that uses super routers like Biztalk, you'll end up factoring the message handling code in a way that keeps the semantically meaningless dependencies separate from the semantically meaningful ones… which is a good thing.
Cheers,
Ed Pinto
|
|
|
Message #167583
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A Service Versioning Covenant
I've been thinking about this topic for over a year and blogged about my thoughts in the past.
I think using a separate versioning service would allow the best of all worlds. You can still develop strongly-typed services (contracts) and benefit from all of the development niceties, and at the same time never stifle the upgrade paths.
The trick is in how you logically group your services so that when you branch one, you bring all of them along with the new version. If you don't do this, your "tree" of services will have branches that intermingle at various points and will be no different than a group of components that share the same common components.
I see no reason to be cheap on the branching part. In the past it was always a concern to carefully upgrade APIs. With a world where disk space isn't a big deal and self-documenting interfaces can be created, there's no need to worry about versioning. Just do it.
Then use a versioning service to tell consumers where their version is and what the contract is.
David Cornelson
http://dave.cornelson.net
|
|
|
Message #167604
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A couple of issues with this otherwise great article
Thanks Ed,
I think your concerns are due to lack of clarity on my part.
When I used the word "schema" it was the little-s rather than the big-S concept. I am not a fan of XSD, nor did I mean to imply doing XML validation of that sort. Rather (and I think you'll agree), it is just that the message router on the server needs to example the message to determine how to route it. This is done by examining the schema/layout/content of the message. Not by looking at some XSD artifact. So I think we're on the same page here, but I should have clarified that I meant little-s schema in the article to start with.
When I talk about a super-router, I didn't really have things like higher-level message patterns in mind. There is no doubt that they remain incredibly valuable.
What I was specifically talking about was the idea of a single, universal endpoint. That you would create a system that has exactly one endpoint that ships orders, updates inventory, does invoicing, manages customer data and so forth. Believe it or not, that idea gets tossed out every time I speak on SOA... Oy!
I didn't mean to imply that MESSAGE-oriented super-routers (or other message-level patterns) are invalid. Rather that creating a single BUSINESS-level endpoint as a super-router is not good.
|
|
|
Message #167640
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The "ROSY" colored glasses of the SOA droids.......
Let me see, do developers stay at the same job for more than a year or two? New developers are arrriving to the same project all the time.
How about developers who don't make mistakes and write bug free software?
Ah, yes, I know who writes bug free software.
It's the software speakers and authors because they never write any production code to begin with; This allows them to say that they can write bug free code with this method because this code will never be run in a production environment to be put to the test in the first place.
Like you really know what you are talking about.....
|
|
|
Message #167660
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
This is uncalled for an incorrect
Your message is rude, incorrect, and unproductive. Please have more respect for this community in NOT posting garbage like this.
Damon Carr
Let me see, do developers stay at the same job for more than a year or two? New developers are arrriving to the same project all the time.How about developers who don't make mistakes and write bug free software?Ah, yes, I know who writes bug free software. It's the software speakers and authors because they never write any production code to begin with; This allows them to say that they can write bug free code with this method because this code will never be run in a production environment to be put to the test in the first place.Like you really know what you are talking about.....
|
|
|
Message #167667
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why don't you face up to reality? Author != Coder
Instead of calling names and making blanket criticism, why don't you look at the FACTS???
It's clear, you can't take the absolute failures of what happens in the REAL world of software development.
Let's get something straight,
AUTHORS != ARCHITECTS. PERIOD
AUTHORS != PRODUCTION DEVELOPERS. PERIOD
BLOGGERS != ARCHITECTS. PERIOD.
DEAR Server SIDE, you want to have a bunch of "YES MEN" like this guy below, go ahead and agree with this guy and all the others who spend all day writing articles and blogs, but don't lift a finger to actually DO what they TALK about doing.
IN the WORLD of MEDICINE, before you get to WRITE and ARTICLE on in medical journal on whether this cure actually works, THEY HAVE TRIALS and HARD TESTS.
THEY ALSO HAVE PLACEBO TESTS AND
*COMPARISIONS of CURRENT METHODS versus NEW METHODS*.
UNLIKE THIS GUY, who can't take the harsh realities of the REAL WORLD OF PRODUCTION CODING, the community needs guys who can actually WRITE PRODUCTION CODE, and who can ACTUALLY GIVE REAL ADVICE.
LET ME SEE, who is REALLY UNPRODUCTIVE here?
WELL, if someone sits around all day writing articles and BOOKS and in the end, DOESN'T write PRODUCTION CODE, is this the person who is really UNPRODUCTIVE??
RESPECT:
RESPECT FOR WHO?
THOSE who write articles OR those who write production code and really know what they are talking about because they spent more time *DOING* instead of TALKING or PRESENTING?
LEGENDS WHO REALIZED THEY WERE NOT LEGENDS and TOOK DOWN
THEIR SITE BECAUSE ALL THEY DO IS WRITE BOOKS, NOT CODE
http://www.softwarelegends.com
ARCHIVE HERE
http://web.archive.org/web/20030803212059/www.softwarelegends.com/legends.html
THIS GUY ACTUALLY PRODUCES SOMETHING
http://www.notalegend.com/
Because this one guy, put up a site, the other 5 guys had to take theirs down because of the what? RUDE, NO RESPECT for the COMMUNITY you so cherrish.....
NEWS FLASH!!!!
WRITING BOOKS DOES NOT MAKE YOU A SOFTWARE LEGEND..
Your message is rude, incorrect, and unproductive. Please have more respect for this community in NOT posting garbage like this.Damon Carr
|
|
|
Message #167668
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
One Parameter?
I'm reminded of projects that have foundered because of bad requirements. After the having the requirements shift one too many times I've seen developers practically paralyzed; they re-design their code making it ever more generalized. All in an effort to avoid a complete re-write.
I can't see any design taking a single parameter - be it raw XML fragment or a delimited string - as anything but defensive programming gone awry.
Mike
|
|
|
Message #167670
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Reality?
Why don't you take your finger off the caps lock and your head out of your a**.
Did you see any where Rocky said he coded bug free using the method he talked about? Did he even say he's actually used what he's proposing? He wrote an article to introduce what he thinks is a good way to design software so others could read it and make their own decesion.
Frankly I don't agree with what he's saying. But at least he spends his time trying to help other developers instead of running around spamming absuive rants.
|
|
|
Message #167690
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
B4 spouting off an idea & getting publicity, why not test it...
B4 spouting off an idea & getting publicity, why not test it IN THE REAL WORLD???
** THE CAPS LOCK IS ON for the DROID PROGRAMMER WHO CAN'T THINK FOR THEMSELVES **
And for wanna be DEVELOPERS who are mindless ROBOTS and think think every article at some web site or even bookstore is the absolute truth.
Dear Serial Software Article/Book Author:
Instead of writing books and articles, why not actually put some of your great ideas to your very own use in your very own production environment where you have to actually maintain it and listen to customer complaints?
In other industries, building architects, doctors, musicians, artists, engineers are held accountable and scrutinized by actual testing and comparisons or by their own audience and NOT by software editors and technical staff and advisors who they themselves don't write a line of production code.
What's really funny AND SCARY is to think that the SOFTWARE industry thinks they can make LESS MISTAKES then doctors.....HA HA HA HA
DEAR AUTHOR, you want to help?
OK, instead of writing articles, WRITE SOME PRODUCTION CODE FIRST BEFORE ASKING any BOOK publisher or e-zine to publish your idea that hasn't been rigously tests, vetted and compared again current methods in the REAL WORLD. NUMBERS, METHODS, critical comparisons, ROI..
You know when an bridge or building is architected or designed, tests are performed, compared, analyzed by TRUE EXPERTS and testing companies in the FIELD who DON'T SPENT ALL THEIR LIVES WRITING BOOKS....
It's amazing to see how awful these so-called authors are in a real environment and not in their rehearsed PowerPoint presentation with sample code. They have an answer for everything but when it comes down to actually writing the code for something they haven't rehearsed, don't even think they will get it done in a week or month or ever.
I guess that's expected when they can't even get their own demo code to work in a rehearse presentation and code in their books are so buggy in the first place even though it's only sample code.....
|
|
|
Message #167693
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The caps lock
The caps lock is on because your substituting capital words for thought; because you'd rather rant mindless drivel instead of contributing to a discussion.
So Dear r h, instead of writing mindless rants why not take some of your great ideas - which I'm sure will have all been tested in real world production systems - and publish them. You can even publish them under your real name.
Try it, it'll be fun; you'll be a real part of the community instead of just being a twit that wastes our time.
|
|
|
Message #167699
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
How are convenants less fraigile than contracts?
Rocky, thanks for the article. Unfortunately I think I'm missing something because convenants seem just as fragile as contracts.
The fragile part of both systems is the un-escapable fact that the client has to be coded to conform to the servers expectations. It doesn't matter if it's a strongly typed contract that can be enforced by the compiler and tools or a soft covenant that you enforce at run time. If a new method signature is required then both the server and the client have to be changed to support it.
In fact the semantic contract you describe seems easier to uphold using strongly typed contracts. As you mentioned clients bind directly to strongly typed contracts. So the client can bind directly to your new method; the old method can be left un-touched. Your covenant based method on the other hand must, at the very least, be re-coded to handle the new routing logic.
And if your routing at a higher level then of course any soap message can be routed.
If anything your article draws attention to the fact that the tool support for web services is still not great. It's much to easy to make a small change to an ASP.NET web service that will result in WSDL changes that will break old clients.
This is not unlike the issues you mentioned with COM. If properly utilized COM actually mitigates some of the problems with DLL hell. In your example the DoWork and DoWorkEx methods - and the interfaces that expose them - could be implemented in separate DLLs so that changes to one did not impact the other at all.
|
|
|
Message #167725
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Software Authors TALK the TALK but don't WALK the WALK
The caps lock is on because your substituting capital words for thought;
And I guess substituting "TALK" FOR "WALK" is OK with you?
Oh, by the way,
TALK != WALK
Try it, it'll be fun; you'll be a real part of the community instead of just being a twit that wastes our time.
You are ask me about "trying" something new and fun?
Would "PRODUCTION CODING" be your definition of new and fun?
Instead of DODGING THE ISSUE of usefullness of the methods being discussed, stop being a mindless robot who thinks everything in an ezine or book is true, especially from authors who don't even production code.
I, for example, can at least see that in other industries, YOU DO SOMETHING before you start talking and writing a book about that something.
BEFORE YOU WRITE A BOOK ON COACHING A SUPERBOWL WIN, FIRST WIN THE SUPERBOWL....
BEFORE DOCTORS OR RESEARCHERS come up with a new cure, FIRST CURE SOMEONE.
Software authors can't walk their talk. PERIOD...
Software Authors are a bunch of TALKERS, NOT WALKERS and for that matter, they are NOT DOERS of what they TALK ABOUT...
Here are some software authors who realized they don't WALK and have the presence of mind to know that don't and took down their site when someone who DID walk pointed out to these others that they didn't.
LEGENDS WHO REALIZED THEY WERE NOT LEGENDS and TOOK DOWN
THEIR SITE BECAUSE ALL THEY DO IS WRITE BOOKS, NOT CODE
http://www.softwarelegends.com
ARCHIVE HERE
http://web.archive.org/web/20030803212059/www.softwarelegends.com/legends.html
THIS GUY ACTUALLY PRODUCES SOMETHING
http://www.notalegend.com/
The caps lock is on because your substituting capital words for thought; because you'd rather rant mindless drivel instead of contributing to a discussion.So Dear r h, instead of writing mindless rants why not take some of your great ideas - which I'm sure will have all been tested in real world production systems - and publish them. You can even publish them under your real name. Try it, it'll be fun; you'll be a real part of the community instead of just being a twit that wastes our time.
|
|
|
Message #167733
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
One Parameter?
Mike, you have a valid point and it has taken me a lot of time (and pain) to come around to realizing that message-based design is better (for service-orientation) than API-based or interface-based design.
I too had a real hard time swallowing the idea that every "method" should accept a single parameter. Until I realized that we're not talking about methods, we're talking about message endpoints.
The term "method" is an OO term. Nothing in service-orientation is object-oriented, thus the word method doesn't apply. Perhaps the word "procedure" would apply, since we're creating procedures that can be invoked remotely, but that's RPC, not SOA.
So when doing service-oriented work, neither "method" nor "procedure" really fit. But message endpoint does fit. And if our code is a message endpoint, then it only makes sense that the only "parameter" our code would accept is the message - which appears as a single parameter if you think of the code as a "method" or "procedure".
This is one reason why I think the industry needs an actual service-oriented language. By misusing VB, C# and Java to write message endpoints too many people get confused. They see the syntax for a method and think "oh, method!" when in reality what they are looking at is a message endpoint disguised as a method...
|
|
|
Message #167734
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Software Authors TALK the TALK but don't WALK the WALK
r h,
The reason you are not getting through is not because of your use of capitals or repetition, but because what you are saying does not make sense.
I'm not going to attempt to logically deconstruct your arguments because it's hard to see what is or isn't rhetoric, but I have some questions for you:
1) Are there any authors/speakers/bloggers you respect or trust?
2) What are your criteria for this respect and trust?
3) Do you think it desirable for software professionals ('production coders' if you insist) to share their experiences in some way?
4) What form do you think this sharing should take?
Finally, it would be nice to know your real name.
Jim
ThoughtWorks
|
|
|
Message #167777
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: One Parameter?
The term "method" is an OO term. Nothing in service-orientation is object-oriented, thus the word method doesn't apply.
Terminology can be an important aid to understanding a problem and I agree that message and endpoint are more precise terms when dicussing SOA. But in this case it doesn't make a lot of difference what you call it.
The client and the service have to agree on how to communicate there's no way around it. So at some point the message must be strongly typed. It can be, and should be, designed to be extensible but it's got to conform to a schema - therefore be strongly typed.
So the question is why is it better to have an endpoint that takes a raw XML fragment and then routes it instead of having it routed implicitly by binding to the correct endpoint?
For example in your article you cite a negative aspect of COM resulted in having more contracts floating around than we knew how to handle. How does burying the contract between the client and the service inside a raw XML fragment help?
Again the endpoint itself may operate under the loose and flexible rules of your covenant but the actual behavior your exposing - where that message gets routed to inside your endpoint - requires a contract. That contract has to be published someplace.
To look at this from another angle. You say:
The service exposes one or more of these method signatures through its WSDL. The client binds to that as a formal contract. This is exactly like COM. Once you’ve got clients bound to your API you can never change it.
Your in the same position with a covenant based API. Once you've agreed that to accept schema A then schema A is no easier to change that a WSDL signature. And follow that through... If you need to add something you create schema B. If a schema A client wants to use schema B they have to change their code. How is changing to support schema B any harder for the client than binding to a new endpoint? Is publishing schema B and modifying your code to route schema B markedly harder than simply publishing a new endpoint?
I'm not sure I agree that a SOAP signature is as inflexible as a COM signature but that would be another topic really. However I do agree with you when you say When it comes to distributed systems, versioning is always the Achilles Heel. But I think your idea of convenants is simply pushing the problem into another layer of the design - and I don't think that's a good thing. In fact in many cases I think it turns out to be a bad thing.
The solutions are not easy however you approach it but more than anything I think this is a tools and education problem. Tools like ASP.NET are designed to make creation easy, not maintenance. They're designed to make it easy to write code not manipulate namespaces and WSDL. And I haven't seen a lot of documentation on how to write extensible web service interfaces that are easy to maintain.
For example how many ASP.NET web services use the automated WSDL generation after they're in production? How many developers keep a copy of the WSDL from their published web services so it can be validated when changes are made? Does your web service test harness get re-bound to your service when changes are made? The list goes on and the easy route when create ASP.NET web services is not the safe route.
|
|
|
Message #167847
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Software Authors TALK the TALK but don't WALK the WALK
rh,
I actually enjoyed your rants. I also agree that the softwarelegends website is annoying; however, some of those guys can write some good code (e.g. chris sells in particular does know what he is doing).
-Mathew Nolton
|
|
|
Message #167889
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: One Parameter?
Again the endpoint itself may operate under the loose and flexible rules of your covenant but the actual behavior your exposing - where that message gets routed to inside your endpoint - requires a contract. That contract has to be published someplace.
Agreed. In proposing the term covenant I was primarily trying to combat complacency. In too many minds, the term contract implies a 1-to-1 relationship, but moreover it implies that the contract is the one and only definition.
All I’m really suggesting is that a given endpoint should support multiple contracts. That the basic OO concept of “method overloading” should translate into SO as well.
Is this radically better than the world of COM? Only time will tell. It is certainly a big difference, since COM has no concept of “overloading”. Beyond that, we know that COM had serious issues. We know that the end result of typical COM design is
ShipOrder()
ShipOrder2()
ShipOrderEx()
ShipOrderEx2()
and so forth. We know that this is a mess since the only way to divine what method does what is via external documentation.
One solution is to support the idea that a given endpoint can accept various contracts. Then we can have ShipOrder() that accepts a variety of messages as required over time.
Another solution is to realize up front that any given endpoint will essentially always end up with many variations over time. Name them appropriately. Never name an endpoint with a simple name like ShipOrder(), because that would be meaningless in short order. Instead, come up with a meaningful naming convention like
ShipOrderByOrderNumberV001()
ShipOrderByCustomerAndDateV001()
ShipOrderByOrderNumberV002()
At least this way we’re honest with ourselves, in that we know that over time we’ll be adding many more endpoints that are functionally equivalent, but which exist primarily to support different variations on the contract.
Note that this second approach means that a “message” could be expressed as an XML message, or a set of strongly typed parameters, just like with conventional procedural design. In that case the client and service programmer don’t have to think in terms of messages, they can think in terms of procedural design, which is much more natural to most people. Only the tool vendors need to think in messages, since they convert the parameter lists into and out of message form behind the scenes.
On the other hand, having a single ShipOrder() endpoint that accepts multiple contracts would work with both a single-message type contract, or the parameter-based contract scheme. Neither is ruled out, so designers could choose to elevate the message concept to a first-class citizen, or to allow their tools to hide the message behind procedural design syntax.
In the end, I personally find the idea of a single endpoint that accepts multiple contracts to be more aesthetically pleasing. And while I do think aesthetics should play a role in software design (just like it does in mathematics, physics and most other disciplines), it isn’t enough to make a truly compelling argument. And of course beauty is in the eye of the beholder…
|
|
|
Message #167895
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA
Rhockford Lhotka,
The article was very good. Also your CSLA framework is ver nice. Anyone who thinks that this guy has no idea what he is doing should go check out the CSLA framework.
I am a big article reader. I am constantly reading articles to see what and how other people are solving problems.
I see n-tier, SOA, and client/server designs as solutions to problems. Each have their pros and cons. There is no single solution to fit all. I believe that best solution is the one that works ** ;). That solution could involve all three of those design patterns or none of them. Each problem is unique.
But one problem that has been around for years of course is DLL hell. I liked how Microsoft has solved that with the DLL versioning but that still does not completely solve the problem. But the problem like you said Rhockford does exist soley in just the API world. It esists in the service world also. Versioning is always a problem and will continue to be one until someone **God Bless that person that figures it out** figures out a better solution.
The problem with versioning is that you want to incorporate new functionaility or need to change existing functionality with a service or DLL. The method, procedure, message endpoint changes and the app breaks. Not always but sometimes. Maybe it was a change to the database or something that resulted in the client app not working. There is nothing we can do about that.
My question to you or anyone else is this: Microsoft has **introduced** DLL versioning. Is it not possbile to bring that versioning up to a method or procedure? Yes you can do overloading but most times overloading results in the same actions being taken with just different paramters being passed in.
Not only could you version the DLL or method/procedure, but is it even possible to version the database table, or the stored procedure? So that way they all stay in **SYNC**.
Eventually you could remove all clients from that old version by having the migrate over to the newer version or something to that effect.
But is it even possible to put **versioning** on that type of level? Is that even a possible solution to that problem??
I do not claim to know a lot. So any answer will be much appreciated from ANYONE. Even the ones who criticize.
Michael
|
|
|
Message #167896
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
SOA -- Correction
I am a bad speller and I have bad grammar and I wrote that response when I was very tired.
I meant that the versioning problem does NOT exist solely in the API world.
Mcihael
|
|
|
Message #167914
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
IF what you say is TRUE....well than why did.............
If who you mention knows what he is doing, why did this person end up working for Microsoft after all these years as an independent?
You would think someone this FAMOUS, and yes, this person is definately well known to say the least, couldn't easily get a a very high paying contract or job with any of the hundreds, if not thousands of people and companies who have heard of him?
rh,I actually enjoyed your rants. I also agree that the softwarelegends website is annoying; however, some of those guys can write some good code (e.g. chris sells in particular does know what he is doing).-Mathew Nolton
|
|
|
Message #168004
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: One Parameter?
All I’m really suggesting is that a given endpoint should support multiple contracts. That the basic OO concept of “method overloading” should translate into SO as well
I think this is a good point because 'method overloading' really doesn't translate well to SOA. C++ overloading is pure syntactic sugar. The actual compiled method names are not overloaded because they can't be. There has to be a 1 to 1 relationship.
Of course you can step in and provide the same semantics at run time by manually disambiguating the call based on the parameters embedded in the message. But this is a far cry from what you where talking about in your article. It's not providing versioning relief or helping to avoid brittle design.
Really I think it boils down to two things. First as you mentioned in the end "beauty is in the eye of the beholder" - I think this style strikes a cord with you. And second I think, with the current tools, this is easier when faced with marginal requirements.
But I think your giving up too much. I think the self documentation provided by the strongly typed parameters and WSDL along with the tool support is more important.
I really wish it was easier to work with the WSDL output of ASP.NET and that it was more obvious how to design extensible web services. But I suspect that's a learning curve we're all going through.
|
|
|
Message #168010
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A Service Versioning Covenant
The Java RMI programming model includes support for mobile code. Mobile code completely separates the versioning issue between the client and service. The service can have any programming model needed and the client can download a delegate object that implements that API that it needs. That downloaded delegate can then use whatever services and associated APIs it needs to execute the functions of the API that the client uses.
The end result is that you can change the service implementation details at any moment, can just deploy new smart proxies at the same moment to provide the translation between the clients' expected APIs and the services' APIs.
This allows certain services to be moved to secondary services to split responsibilities. You can also integrate services into a single API if needed.
If you are not using Java and/or don't have mobile code support on your programming platform, then I guess you will be fighting this issue for a long time to come.
Gregg Wonderly
|
|
|
Message #168026
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JINI
Service versioning has being solved, and it is called:
JINI
When will people listen: JJJIIIIINNNNNNIIIIIIIIII.
|
|
|
Message #168089
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Semantics for orchistrations
I would like to hear a little bit more about your thoughts on semantic contracts in relation to flow languages, such as BPEL. Are there information in covenants to describe the service's semantics (in terms of sequences, exceptions, long running transaction support, compensation, timeouts, etc). Basicly information needed to build an orchistration on top of an arbitrary service.However, there’s also a semantic contract which is often overlooked. The semantic contract says that when I call DoWork() a certain set of things happen. This set of things includes the work being done, but also includes observable side-effects of the work and things like failure conditions. Though not documented or formalized in any way, the semantic contract is every bit as important as the formal contract expressed in IDL (or now in WSDL).
|
|
|
Message #168142
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A Service Versioning Covenant
If you are not using Java and/or don't have mobile code support on your programming platform, then I guess you will be fighting this issue for a long time to come.Gregg Wonderly
Ahh, but here you are abandoning SOA and going to a whole other model. And honestly, you are going to a model that I personally prefer. The idea of mobile objects or agents, where an application exploits the capability of mobile code and mobile data is the most compelling and interesting architecture space going today imo.
This is the specific focus of my business objects books in .NET, and is my true area of passion.
However, it has little bearing on SOA. In fact the ideas are diametrically opposed in most regards. And that’s OK, because mobile agents/objects are trying to solve an entirely different problem from SOA. And having different approaches means we can use the right tool for the right job.
|
|
|
Message #168258
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Semantics for orchistrations
Are there information in covenants to describe the service's semantics (in terms of sequences, exceptions, long running transaction support, compensation, timeouts, etc). Basicly information needed to build an orchistration on top of an arbitrary service.
Perhaps. This is certainly part of the problem with what we think of as a "contract" today in that it only carries basic syntactic information. However, with WSE and Indigo there's other information (a meta-contract?) that is used to negotiate things like transactional support, etc.
But even so, no semantic meaning is ever available. The entirety of the semantic meaning is inferred by the developer of the consumer based on the name of the endpoint. We assume that a ShipOrder endopoint ships orders. Moreover, we assume it ships the type of order we want, and in the way we want. We don’t know though, so we just cross our fingers and hope.
Maybe this is OK. Certainly there’s a lot of pushback to any idea of passing meaning along with data between services. I’m not convinced though, since I am not convinced that data without meaning is ever actually useful.
But, if we can’t have semantic meaning in the contract, and it isn’t clearly expressed in the endpoint or in the meta-contract provided by WSE or Indigo, then the meaning has to go somewhere, so we move it out into other areas like orchestration.
The end result is that the orchestration contains all the meaning (or assumed meaning), and only by looking at the orchestration can you infer what each service probably does. Well, either that, or you look at the code of the service itself – but that breaks the black-block encapsulation goal for services, so you can’t really do that.
This issue really highlights how little service-orientation actually does to solve the underlying problems of software development. It isn’t intended to solve the hard problems, rather SO is intended to provide decoupling at a syntactic level. And that’s nice, but it merely reveals other problems that are much harder to solve (and thus in many ways more interesting).
|
|
|
Message #168329
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A Service Versioning Covenant
This is interesting read. I must say that I know at least one popular web service doing a similar approach and in the direction that Rocky is suggesting. Take a look a the API of PayPal web services for example. It uses the ResposeMsg = f(RequestMsg) pattern however the versioning is a bit different because it is explicit inside the messages.
|
|
|
Message #168345
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Java RMI
If you are not using Java and/or don't have mobile code support on your programming platform, then I guess you will be fighting this issue for a long time to come.
Certainly one of the nice things about the SOA paradigm is that you don't need java or mobile code, or any specific language on either end of the connection.
And of course Java RMI faces the same issues. This isn't a problem do to lack of features; it's a need for solid application design. The issue isn't 'are there techniques to version services with SOA'. Of course there are. Any distributed programming paradigm has versioning.'
|
|
|
Message #168706
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Semantics for orchestrations
Who cares about the implementation details, given an interface defining functionality for a Stack data type? None! The semantics are too trivial. Service implementation (in terms of message end points) on the other hand cannot be replaced in a plug-and-play, polymorphic fashion. Not without more information than wsdl, xsd and the policy give us.
How can a service be replaced with another, without having a semantic contract? The whole idea of SOA is to decouple functionality from huge enterprise applications into small autonomous services. Just having the syntactic contracts will only make us building components on the web. Btw, could you point me in some direction to find more information on the pushbacks to the ideas of having semantic contracts?
Decoupling is nice, I agree. It gives us the foundation to build enterprise services. But since we’re dealing with autonomous applications with end points, there is a need for asynchronous communication. Asynchronous calls on the other hand require us to use long running transactions. LRT actualizing the fact we need something more than syntactic contracts. An effective orchestration should be able to take different actions during a long running transaction. If the service doesn’t respond as we semantically agreed, let’s find one that does. A good BPM implementation will use of AI and strategic decision making within a process or a LRT to get the job done. To be able to do that, service need to expose its semantic behaviour (i.e. notifications, how to make compensations, I-do-this-if-you-give-me-that-agreements (covenants)).
Thanks for an interesting article.
|
|
|
Message #169637
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
In defence of the Super-Router
Interesting article, Rocky - I designed and built something similar last year, except I went for a variation on your super-router idea and passed an xmldocument to it's single method, instead of a string.
My Super-Router variation works by passing class, method and required version info within the XML and then dynamically loading the corresponding Service version via system.reflection using the assembly's full name (inc Assembly Version number) and then executing the required method on the fly. It's not so much a router, as a loader.
The downside is that everything's dynamic, with the associated loss of performance. The upside is the amount of code required is minimal, in terms of original build and future maintainability.
Using the Super-Router/Loader approach, I avoided having to write hundreds of individual routing classes, which would have all looked pretty much the same, but with a hard coded class name. Didn't really seem worth the effort, to be honest, not to mention it violates my personal principles of code replication.
I can see why you might want to avoid the Super-Router/Loader if you're using your technique of versioning via method name rather than using .NET's inbuilt assembly versioning, but following that route leads us to a world where one day we'll be populating Dataset4 from Dataadapter3.fill8 via DBConnection5. Scary.
Also, the Super-Router/Loader benefits from not requiring an update each time any of the underlying classes change. To be fair, not having Intellisense and the lack of compile-time validation isn't going to bother those coders who live in Notepad, but I can see how it might distress those used to working in Visual Studio. I'm guessing it would be possible to write a Visual Studio add-in that did both of those, but I haven't done any exploration in that direction, so don't take that as Gospel.
As for XMLDocument versus String - to be fair, technically I think I prefer your string approach - As most of my Services invariably end up taking and returning XML / Datasets, just call me lazy, I guess ;-)
Finally, glad to find someone else is exploring similar design lines - even if we don't see eye-to-eye on the super-router/Loader. I would love to compare notes on Database Versioning some time - that's where things get *really* interesting, design-wise...
|
|
|
Message #169845
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The more things change...
Interesting article. Ironically, I was doing this same thing (i.e. passing messages through a common interface that the components could then either act upon or not) 7 or 8 years ago before all the sexy "new" technologies were avialable (i.e. SOAP, XML web services, .NET). As I recall, my rationale behind it was more akin to what another poster mentioned (i.e. the ultimate in defensive programming on my part because of a dev manager who decreed that the system shall be so flexibile as to support clients defining their own functionality for certain features of the system), and not really because I planned on doing it that way when I set out designing it. :-)
What I wanted to comment on was that I was really glad to see your disclaimer up front on how your proposal has nothing to do with n-tier design and development. I wish other authors would do the same when proposing ideas in the SO arena because some confuse SOA with n-tier; or worse yet, they equate SOA with using web services for all communication between the interrelated logical tiers of an application.
|
|
|
Message #188786
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A Service Versioning Covenant
It would seem to me that a Covenant precludes a Contact. I would assume that when discovering a service, the Service Description could be defined as a Covenant. A Covenant can also act as a notification.
If the service requestor is able to meet the terms specified in the Covenant, the Contract would be established once request from the consumer is accepted by the provider.
Rather than replacing "Contract" with "Covenant", consider including as a link between Service Discovery and Serviced Contract.
|
|
|
Message #284317
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
business coaching covenant
Software versioning coaching? I've checked a lot contract based services. But is a computer software can really work a contract out?
Lets take for example a business coaching services company like Calcom, It does consultancy, but how a PC software can do covenant?
|
|
|
| |
|
| New content on TheServerSide.NETNew content on TheServerSide.NETNew content on TheServerSide.NET |
|
|
Language "mashups" will become more prominent, and developers will become polyglots, one programmer suggests.
SearchWinDevelopment.com offers an introduction to the language, performance, testing and data management improvements in VS 2008.
VBCode.com code snippets cover all aspects of application development, from data binding to security to the user interface.
Get up to date on XAML best practices with a variety of articles, tutorials and webcasts. [SearchWinDevelopment.com]
One team's experience with the VSTS DB edition suggests that it can improve workflow for dev teams. It also enhanced Agile efforts.
(June 24, Article)
Microsoft has begun to include DSL tools in the VSTS kit. A new book by Steve Cook and other VSTS team members helps set the stage.
(June 24, Article)
Cartoon: Be it ever so humble there is no place like your home after you get a Microsoft Home Server .
(June 18, Cartoon)
Microsoft's Thom Robbins says new technology to highlight in NET 3.5 includes AJAX, LINQ for both C# and VB, as well as tooling enhancements intended to ease the task of building WPF, WF and WCF apps.
(June 29, Podcast)
Venkat Subramaniam discusses AJAX bottlenecks, the tenets of Agile development and more. He spoke at the Ajax Experience.
(June 25, Tech Talk)
In the second of a two-part series, Michele Leroux Bustamente discusses design decisions related to the claims-based security model. Read the story and walk through the process for creating a set of claims-based utilities to encapsulate claims authorization at the service tier.
(May 24, Article)
Understanding why the Entity Framework exists and learning where it can fit into your projects can get you prepared for the eventual release early next year.
(May 10, Article)
Resource: This learning guide gives you quick access to useful links on Windows Communication Foundation security information.
(April 24, Article)
TSS.NET's Jack Vaughan spoke recently spoke with Microsoft's Brad Abrams to find out what he is seeing in the field and what the chefs in Redmond are cooking. Along the way he discusses patterns of AJAX frameworks.
(April 11, Article)
In a two-part series, Michele Leroux Bustamente explains how claims-based security is supported by WCF, and how you can implement a claims-based security model for your services.
(March 29, Article)
Windows Workflow Foundation is a new technology that many developers will need to get their heads around. In a brief excerpt adapted from Programming Windows Workflow Foundation: Practical WF Techniques and Examples using XAML and C#, K.Scott Allen considers aspects of workflow definition.
(March 22, Chapter Excerpt)
|
|
