11/04/07 :: [SOA] Stefan on REST [permalink]
Another group that wants to kill SOA is some of the REST folks. Stefan posted a pointer to one of his REST presentation. Since you don't see the slides in the video you may want to GET them ahead of time.
Ok, so I said, I won't participate in a REST debate again, I apologize, it is just that I respect Stefan a lot and at the same time I was very uneasy about his presentation. I read it as yet another attempt to kill Web Services and with it SOA, because if all we had was REST we would be unable to build a Service Oriented Architecture. As a starter, I'd like to disclose, I like REST, it's brilliant, surely enough the web would be very different if it had been designed on OO/Corba principles.
In his presentation, Stefan makes a very good point about resources vs services, REST sees the world as "un-gated" resources, while services are the gate to a parking lot full of resources. I fully support this view and this argument, but is it enough?
I start to part from him on the "application semantics". He ends his talk by saying "HTTP is good enough", meaning that all you'll ever need to do to construct a distributed application, you can do it with HTTP. I must admit I am an application semantics freak. I don't think people should be coding their breath away, I do think that application semantics should be defined to write as little code as possible (this does not mean zero code). I come from a NeXT background, that might explain why.
To illustrate how HTTP application semantics were enough, Stefan sent me a link that describes a "stock trader" application. For sure, the paper is full of "additional" semantics not directly supported by HTTP (in other words you have to code them in, each time) such as reliable messaging semantics or "operation hacking". The Reliable Messaging solution that is provided assume that the server talks to a "client".
Operation Hacking consist in mapping "business operations" to URI, here is a sample from the article:
| URI | Method | Collection | Operation | Business Operation |
|---|---|---|---|---|
| /acct/ | POST | accounts | create | register |
| /acct/{acct_id} | GET | accounts | retrieve | getAccountData |
| /acct/{acct_id};profile | GET | profile | retrieve | getAccountProfileData |
Note, that I am making fun of this but I do believe that this is a great design pattern for SOA. I am making fun of it, because REST claims its opposition to SOA (resources first, smash the services -the ugly services lock the poor resources behind doors). But, how do I read the URI? Well there is an /acct service which has a getAccountByID operation,... because at the end of the day, this is really how you will end up implementing it, with a service (the system of record for this resource type), not one resource at a time. What Stefan is saying though, is that why do you need WSDL and WS-* when I can give you a URI and without anything else you can interact with the resource behind. Just like WSDL you don't need binaries, but since your agreed on most of the contract already (GET, POST, PUT, DELETE) you don't need to generate a client from the contract to get at the resource, your infrastructure can do it out of the box just with a URI. It's like being able to invoke the account service without having to expose and consume the "Business Interface". This is why he claims "HTTP can do it out of the box". Again, this is great, this is profound, but this is not "exposing" resources, this is a transcoding of operations into a mechanism that can invoke them without creating and using all this messy WS-* goop. IMHO, the /acct service is still there. REST does not introduce "magical semantics" that somehow remove the complexity of a business interface, it simply removes the need to use WSDL and SOAP to invoke a business operation. Nothing else. The business operation (and supporting semantics such as reliability, security, transaction -a.k.a. STAR ;-) still remains and must be understood "clearly" by all parties. In the Web 1.0, well we didn't really have "business operations". Roy's vision was to create "applications" from document navigations. Makes sense, this is a very important class of applications. Actually so important that all other types of applications are being dissolved in it (rightfully so). In other word, a business application + content is far superior to a business application alone. We all experienced that, we all know that. But does it really mean that the semantics of Web 1.0 are enough to write all possible applications? Is it the wholly grail of application models?
Frankly, I can see easily why WS-* will never make it to the browser and why PHP and the like don't care about it. But does this means that we should trash WS-* all together and re-invent (or worse not re-invent) a RS-* stack (granted that it is pretty much in place today and just needs a bit more formalism).
My answer to this question is three-fold:
a) not everything is a resource
Stefan claims that Google has an API that is now totally RESTful. I can easily admit the limits of my intellect, but I'd be curious to understand how you map a "search" operation to a resource. Is a search result really a resource? sure anything can be a resource if you say "as long as I can write a URI, it must be a resource", but semantically, is it really? I "searched" the example for a search method but could not find one.
Another example of "not everything is a resource" is this mashup I wrote to help my children learn how to read. My daughter had trouble in first grade and I came up with this idea of creating flash cards with the words she had trouble to read (not rocket science by any means). It was so effective for her and my son later that I put it on the web to use. The mash up is using Google pictures, a dictionary, sounds, wikipedia and other "resources" (spelling sheets. I feel that this little application shows well how the "everything is a resource" simply does not work. As a starter, what is a "word" in a flashcard for REST? a resource? but it is not, it is unique for sure. I can use a "word" to access resources such as a definition or say a spelling sheet for that word. Similarly, when I make a request to Google pictures from a word, do I really invoke the uniform interface to a resource? Do I really get a resource back? What are those semantics for REST? All I see is services with business operations.
The elephant in the REST room is "resource update". REST claims that PUTing or POSTing an updated resource representation back to the server is enough. But that's a pretty naive view of update, let alone a distributed transactional update. The reality is that the client does not hold necessarily a pristine copy of the resource representation like it would do of a web page and it does not know what's allowed to add to the resource representation. This handshake, including exceptions, can be very costly to implement. SDO (and ADO.Net) offer an elegant solution to the problem, REST does not have anything even close.
b) There is too much of a client/server paradigm embedded in REST
The REST folks are making too much assumptions on "one side" of the pipe is a browser. Even Roy himself explains that you need to "relax" the REST constraints to create a peer-to-peer relationship. Ok, you are going to tell me that WS-I Basic Profile forbids peer-to-peer relationships between services and only an heretic like me can claim that the world is not flat, (client-server), and is rather round (peer-to-peer). But, somehow, WS-* is ready for peer-to-peer. Except for one isolated vendor, nowadays, nobody else believes that peer-to-peer is useless.
Peer-to-peer is more than having a URI to call back to. True peer-to-peer is about creating an assembly of network accessible resources working together. In the REST model the consumer of the resource has no interface, it has no opportunity to expose an interface. It is not a resource from the server point of view. So if a client GETs a resource representation and somehow this resource representation needs to be updated by the server, you are out of luck (the client did not send you back the resource representation's URI on its side, it has no way to do that).
REST does not know what an "event" is either.
REST does not know what an intermediary is.
Do you know how much code worldwide is written to go around these three limitations (server can't talk to the client, intermediaries and events)? And I am not even throwing orchestration in the mix.
c) REST gives you a small piece of WS-* and it is not credible to think you can create a vast distributed system without further semantics
I am looking at the InnoQ's poster and this is what REST would need to do to really make its WSDL+SOAP short cut really worth while to the community, assuming events and peer-to-peer can somehow be embedded in the REST model
- REST-DL (I need so specify somewhere the schema of my resources)
- REST-DO (as in SDO)
- REST-Assembly
- REST-Eventing
- REST-Intermediary (can HTTP do that? so you might also need REST-OP at some point)
- REST-Security, Privacy, DSig
- REST-Orchestration Language (you don't need it today because you code everything by hand)
- REST-TX
- REST basic profile to clean up all the previous specs
So overall, even though I see REST principles with the highest consideration and I have nothing to sell (I work for an IT organization). I am very skeptical about Stefan's rationale.
Does REST has a point? yes, is REST going to own the browser-service relationship at Google, Yahoo and Amazon, yes definitely.
Is the barrier of entry lower, well yes and no. Sure it looks really low compared to WS-*, but considering all your developers are going to code behind the scene, I am not sure that this is an accurate statement. They will shoot themselves in the foot faster that's for sure. But REST gives me a lot more reason to shoot myself in the foot.
So, I am sorry, I don't see why I would use REST for free when I would have to write so much code that I get with WS-*. The productivity of REST is simply not there for writing modern distributed systems. WS-* gives you true and modern application semantics to write complex distributed information systems.
Stefan, my conclusion is that both WS-* and REST have room to grow and make sense. It makes no sense to oppose them: they need to learn from each other. I don't think it makes sense to have them converge today either, maybe in two or three years we'll revisit the question.
11/03/07 :: [SOA] JJ's World [permalink]
Some of the recent comments on SOA tickled me. Whether it is Nick Malik or Joe McEndrick. I am sure there are others that want to waste your time on the topic of Enterprise SOA (which is actually SAP's new moniker -I learned tremendously -maybe too much- at SAP on where SOA is going).
I am starting to wonder what Dorothy is thinking about all that. I am sure she needs some explanation.
"Wow, Dorothy, look at all the fun things to do, go ahead pick something..."
"Dorothy has a question"... Where are we with SOA today? Today SOA touches mainly EAI, B2B and BPM. This is where companies started to apply Web Services technologies over the last few years, probably successfully. Did it mandate all this cool new stuff? probably not, except for a few vexing interoperability issues, we probably could have done just fine with your traditional EAI suite. B2B? Well, Web Services offered a Reliable, Secure and Transacted message exchange capability in 2007 (only :-), so you probably had to build a lot of home grown stuff to make it work or you used ebXML. BPM is still emerging but you immediately found some support from SOA each time you needed to get to a back-end system.
"Dorothy has a question" ... What kind of crayons did you use to do that? Most likely one (or more) 3rd party service container (home grown is great too). WCF is a service container, so is your favorite ESB. You choose a service container based on its capabilities. However, you are going to need more crayons if you want to have more fun.
"Dorothy has a question" ... Is there much ROI there? Probably nothing out of the ordinary. If people want to call that "pragmatic SOA", I have no issue with it. Should you start there? It is by far reasonable, this is where most people started.
"Dorothy has a question" ... Will SOA stop there? If any one doubts it, we got the answer this week with Oslo when Microsoft announced it will take Composite Applications to the mainstream in 2009 and quadrupling their SOA investment. If I recall correctly, I remember Don Box saying WCF's team was 275 people, BizTalk's team is probably around 200 as well, so if the math is right MS is charging ahead with 2000 people to deliver this capability. SAP has had a Composite Application capability since 2003 (xApps). IBM now offers a mature Composite Application infrastructure (I learned a lot using it). And BEA just announced no less than the Genesis.
As a side note, it is quite surprising that Oracle did not
pay BEA's price. Where are they going to find the workforce and
technologies to catch up after SAP, IBM and Microsoft and of course BEA?
Another side note, looking at it that way, it is almost as if Microsoft
is coming
"Après
la bataille" and they could end up just being able to
blow the
cap off. For them SOA was not even EAI+B2B+BPM it was simply and only
about interoperability. It was strategic to enable and control the interop pipe. Their goal was to get a foot in the door and then build on
the merits of .Net. This strategy worked but somehow they did not see the
elephant in the "interop" room until earlier this year.
Incidentally you also see the importance of the ecosystem for a
large software vendor. The SOA .Net ecosystem has been abysmally empty.
This has hurt Microsoft greatly because they have nothing to buy to keep
pace with IBM. Look at all the acquisition IBM did to get there:
CrossWorlds, BowStreet, Ascential, DataPower, Webify, Holosofix... (I
forgot, there are probably many more). If I were Microsoft I would set aside quite a bit of money to
seed the ecosystem such that in 3 years they can acquire what they
will inevitably fail to deliver or think about. You simply can't predict
where the market will be in 3 years, even if you are Microsoft, and
especially if your infrastructure strategy is guided by only a very
small group of people.
If you want to further your understanding of composite applications, I have written an ebook on "Composite Software Construction" that will be available for download on InfoQ in less than two weeks now. I also wrote this note in 2002, "The end in mind..." that I would like to think predicted where we are in 2007.
"Dorothy has a question" ... Does it even makes sense to think of SOA outside an enterprise framework? Well everything is possible. We like to think that we somehow live in a free society that is even capable of defying the laws of physics.
"Dorothy has a question" ... Do you think someone could still be able to deploy such an infrastructure tactically? for one project? and then never use it again? How can I say it ... with nuance? Some people are nuts.
Ok, some are going to respond to me and say "you are the nut". Fair enough. But, this picture is not as complicated as it looks. It is just a service container, a process container and a task container supported by the traditional aspects of enterprise software, we make a big deal of it because the concepts are new and unfamiliar, but in five years most of us will wonder how we could have built anything without it.
"Dorothy has a question" ... Does it cost big bucks? not as much as one might think, and of course if you don't get robbed in the process. Shop around and ask yourself what is going to happen to this vendor and its products over the next 5 years.
"Dorothy has a question" ... What do you get for the money? What does the business want?
a) a solution delivery capability that is far superior to today's programming models (lowers the level of effort and risk)
b) the ability to change the solution as requirements and needs evolve (which is very difficult with today's programming models) - projects will become smaller if you can change without risk later.
c) the ability to tell the business in their own terms what is currently running (the As-Is view is easy to build)
d) the ability to tell the business with great precision how it is running (KPIs and other operational metrics or business events)
e) Sorry, I am not a believer in giving the capability to change the solution to the business except in specific cases when parameterization is necessary. Composite Applications will be built by developers and architects.
This is in line with Jack's remark: the business doesn't ask for SOA. They don't care how you deliver the five capabilities. It is your job.
"Dorothy has a question" ... if you want to deliver these capabilities consistently for all aspects of your business don't you have to do it at the enterprise level? you can't do that just for a project, even though it is totally fine to build these capabilities projects after projects with the end in mind.
"Dorothy has a question"... Do you think you can enable your business to continuously evolve the business model and to consolidate your assets, as needed (and of course avoid duplicating assets) if you go at it tactically?
Right-sourcing is a key enabler to help you innovate, adapt and optimize while consolidating your assets. Right-Sourcing is about being able to utilize assets wherever it is the most cost effective to operate them. This is SaaS with a business friendly level of granularity. Instead of outsourcing entire solutions, SOA (i.e. Composite Applications) gives you the opportunity to keep complete control of your processes (if you desire to do so) and leverage services and tasks or even sub processes wherever it is the most cost effective to operate them (In May 2006 I wrote an article on the topic in SAP Info Magazine). This is why I am a bit at odd with a post from Dave Linthicum on "Core Value of SOA is the ability to Reuse Services? Not a Chance" because Dave does not push the reasoning to the end, even though his argument is worth considering and mitigating. I would agree with Dave's math in an SOA=EAI+B2B+BPM world. In a right-sourced composite application model the opportunities for reuse are far greater. Entity services for one (the one that manage the system of records for your business entities) and Master Data services are the core to reuse.
Over the next few months -it has started already- all the Mr. Noodles of the IT world will be promptly offering their most polished conclusions to their favorite CIO (I said it and say it again, it makes you look smart to trash something important) even though "mature" Composite Application platforms have really been around for 12 months or less and hardly anyone has had time to collect decent metrics, let alone achieve a full enterprise implementation. It has been so hard (:-) to get where we are today, yet, some people that blog all day come up with an anecdote, a "someone said so", a "one-enterprise-example" with the goal of toppling the whole thing. This attitude is simply irresponsible. Now if they are talking about SOA = EAI + B2B + BPM, whatever, but I don't care about that, this is the tip of the iceberg.
This is my world (not as in mine, but the world I live in, as I see it and understand it), this is what I think and care deeply about in my professional life. Do I have a dose of skepticism about all this? You bet. It keeps me awake at night. What if the skills barrier is too high? what if a model-only approach will make this whole thing inflexible, what if the products are standards are not stable enough? ... the list is long. This is why I started wsper: lower the skills barrier, make the concepts clear more accessible to developers and architects, reduce the dependence on products and standards variations.
10/29/07 :: [SOA] An Inconvenient Truth [permalink]
Richard reacted to my exchange with Nick. Let me be very clear, I am not here to hide anything, mislead or lie. I think my track record over the last 6 years or so of blogging speaks for itself. I am not here to prevent people to speak up in any way either (how could I?). I am proud to be a citizen of the country of Voltaire (and Sarkozy) and I will always defend anyone's right to speak even if his or her ideas could be inconvenient to me.
It is not however because you have a blog that you bear no responsibilities and you can use and abuse the rhetoric to inject guidance without rationale. If you want to call this censorship or self-censorship you are free to do so, but we must be careful using this kind of words. They bear power. You say: "Nick didn't say that Enterprise SOA was impossible, he implied that it was difficult." Really? Are you sure that most of the readers did in fact understood difficult and not impossible?
I don't have issue with the statement in itself: "Enterprise SOA [is] a distant fantasy for many enterprises". A statement can be true or false (even both depending on context). I do take issue however when someone comes up with a 3 line example, a catchy term "semantic dissonance" and then conclude so lightly that Enterprise SOA is a distant fantasy for many. Who wins with this kind of language? Who pays the price for this kind of language? Is that statement representing the necessary dose of pessimism that we all need? Is it the adequate level to debate? What if all debates were at that level?
I do think that this industry will make a major step forward for itself and for its customers when this kind of language will become a distant noise. If you want to call it censorship, call it so, but it is not. A debate has value when arguments have merit, otherwise the debate does not exist, it is just two people babbling. If people want to start a debate on Enterprise SOA, bring it on. Debates are both healthy and necessary -entertaining too. If SOA is the wrong direction, so be it. I don't mind being proven wrong, because I consider it a win each time the truth surfaces, no matter how inconvenient it is.
Finally, you will note that Nick never went back to his example and looked at how it could be solved with SOA technologies or even clarified to show that in fact it cannot be solved. In other words, the central piece of argumentation did not matter to him, he went on in all directions except the definitive one, the solution to the problem he exposed. Are you telling me that no one at Microsoft can solve that process variant problem? BS.
(I wanted to add some humor using the theme of "Global Melting of IT" but considering what I have said, I tried to keep humor away for today).
10/26/07 :: [SOA] To Biz or not to Biz, is that the question?[permalink]
As you probably noticed, Nick and I are going to agree to disagree. I will remain upset at his rationale, I find it as corrosive to our industry as he feels my comments are to him. I would recommend you listen to Dave Linthicum's latest podcast on "Who is killing SOA?", IMHO, Nick is one of them. Dave nails it with talent and precision.
As I understand it, Nick is now advising us to ask LOBs to align with each other (Semantic, Process, States, Events ... but not BPM tools) before we can start SOAtize them. My advice is keep the business as far away from SOA as you can. Spend all your time convincing your delivery team to use SOA as a new architecture to implement solutions that does not require LOBs to align. SOA is about enabling IT to support any business model and functional organization. The programming model of SOA is new and innovative, above all characteristics, composition is the most important one. My ebook on Composite Software Construction is at InfoQ.com, getting ready for publication. As usual, I appreciate the feedback good or bad.
That being said, here is my answer to Nick:
The very reason why enterprises are divided in LOBs is precisely to avoid dependencies at the business model level and give them the maximum freedom to grow their business. Two LOBs won’t spontaneously align unless it makes business sense to both from their respective business model point of view. That’s Business 101. Do you think LOBs just to create inefficiencies?
Now, if you go back to your example and you tell your two favorite business units that they have to align otherwise SOA won’t be possible, they gonna laugh at you like there is no tomorrow. The business can’t care less about SOA. SOA is a new way to deliver solution to the business enable them to optimize, adapt and optimize.
The CISR model is interesting, no doubt about it, and I whole heartedly agree that there are different SOAs for different types of companies. I don’t support one view, nor will ever support one view. I equally share the vision of Microsoft (that Dino explained so well recently) of pragmatic SOA and the one from IBM which is a bit heavier. Both styles are valid and each IT organization should decide which fit them best based on their culture, organization, budget, goals…. I actually welcome any model in between too. Anytime a company implements a successful SOA, it is a win for everybody, no matter how they built it, and again I support all successful ways to achieve it, I don’t have a preferred one and the more the better as it will guarantee that we find eventually the best ways through selections.
Why I find it so important for SOA to win? Well, unless you have infinitely deep pockets, your IT organization is screaming for dramatic productivity increases. ASP.Net, MOSS, WCF and .Net to a certain extend (and Spring, GWT…in the java world) are successful because they offer genuine productivity gains. This is not enough. The way you build a solution is (see Intentional Software) is not well supported by all these ancient programming model.
However, even if we had a very productive development model, it would not be enough. SOA offers another dimension of efficiency via asset reuse. What does asset reuse means? It means that you can create and operate assets where the cost of operation is the lowest. This is profound. I think this is also where a S+S strategy is better as compared to a pure SaaS model. This gives the enterprise the opportunity to “right-source” its IT assets, processes, tasks and decisions. Right-source is outsourcing with a smaller level of granularity. When you SaaS a solution, you lose control of it, you are at the mercy of a SalesForce.com or an outsourcer to do the right thing for you. You might even lay-off some talents that you wanted to keep because you had to outsource the entire solution. SOA gives you options while you retain complete control over your processes. You can outsource a service (invoked by your process), you can outsource a task off-shore if it makes sense. The key is that if you find a better service or want to change your process, you can do so in a timely fashion.
I am fighting vigorously any attempt to kill that picture because I believe in it. I can see the damage every day of what not being able to “right-source” does to organizations.
Your “rhetoric” is gravely compromising this picture, you are going one by one after the arguments that would make people successful with SOA: governance, EA, BPM, funding models… It is not because there is a risk that it will be realized. Risks are identified to be mitigated. It is not because some practices are common that you can’t change practices. The bottom line is that you can do pragmatic SOA with an enterprise mind. Microsoft does not need to fight this battle
The reality is that if you plan to do SOA other than at the enterprise level you are simply wasting your time. The question is does SOA offers a better delivery mechanism to create solutions to solve business problems? The question is not is SOA the solution?
“That is a fantasy. It's a good goal, but it is absurd on its face in the coordination model.” You keep mixing risks, goals and practices. As you point out this is the right goal. The question is whether and how you can mitigate it in the coordination model?
10/25/07 :: [SOA] NoT A Clue[permalink]
So Nick responded. Just to be clear, I am fighting this statement: "This makes Enterprise SOA a distant fantasy for many enterprises".
Sadly enough, you do not seem to measure the consequences of what you write. You don't have a single clue of how a statement like this can get parsed and analyzed in an IT organization. How do you go in front of you CIO or you CTO and explain that SOA makes sense when someone in three sentences and a basic use case can call it a distant fantasy. What? SOA does not work for that? Why would I want to invest millions if someone from Microsoft IT comes so easily to these conclusions.
You don't even make a difference between the specification of the use case and its implementation. You are saying in your response that: " The "state of creation" is from a business viewpoint, and I picked an example that even a sophomore in business school would understand."
Not only your problem is not expressed in business terms. Not only you don't realize that "states" are the most intuitive concepts for business analysts. But, the tragic reality is that you are arguing that since you can't articulate the solution, then SOA is a distant fantasy for everyone else on the planet. This is even worse that I had imagined.
How much do you know about me? How much do you think I can talk to the business? it one more of your guidance/rationale Diracs? JJ can put UML class diagram together, therefore he can't talk to the business. Now you claim: "I'm talking about semantic dissonance in how BUSINESS talks to BUSINESS.". Hum.. you were talking about Semantic dissonance in the data, indicating that there were ambiguity in identifying purchase orders that were "created". Now you are saying two lines of business can't use the same semantics. Who cares what the business think about states as long as you can implement everyone's solutions? The business is not asking you to think for them. I bet you don't even have a single clue about what a reference data model is and how you use it in a Service Oriented Architecture.
What are you suggesting now? are you saying that the "business" should talk to the "business" to resolve their differences even before they can talk to the delivery teams? What the ... are you talking about? Do you think a LOB is going to swallow that? Each LOB have their own objectives and they not going to align with each other. It is IT which is going to build the Service Oriented Architecture to solve business problems. I don't think any LOB will want to create any kind of dependencies with others unless it makes business sense. Your recommendation: "that businesses align around some common understanding of business events, not just at the end (where all models align... in the money) but in the middle" is simply ludicrous. BTW, an event is the occurrence of a state, so please don't bring events in the mix, states is what the business understands most naturally.
The kinds of things people like you write are outrageous, you are wasting everyone's time by injecting tremendous amounts of FUDs based on bogus rationale that only show your ignorance of the "real world".
I am sorry to say that the whole post is flawed, Nick, every guidance you give only applies to LaLaLand and is the root cause of today's IT inefficacies.
Your other recommendations express "risks" as "facts". I you identify a risk you put a mitigation plan for it. You don't recommend a risk:
a) "there is little business value behind forcing all business units to use the same BPM tool", how smart is that from an EA, cost, operations, skills perspective?
b) "This is important because the businesses themselves are quite likely to affect the amount of governance they want to occur", isn't it the goal of the governance organization to be able to "govern" without impacting the budget and schedule of a project. Why suggest people not even "try" to govern. By making this recommendation you are compromising the most important value of SOA: reuse.
... sorry I don't see any silver lining. I can only express sadness to this post.
10/24/07 :: [SOA] No Clue[permalink]
The reason why I quit working for ISVs is because 95% of the people I worked with: senior executive, product managers, developers and architects had no clue and more importantly did not care to have a clue about what they were doing. Call it bad luck or statistically significant (ok the p-value is kind of high based on my sample), this simply became something I could not no longer stand. I have heard everything in my career from a developer thinking UML activity diagram were the perfect and ultimate business process model, then admitting he was wrong and campaigned for using UML state diagrams instead, to a product manager explaining to me that we did not need any business logic to implement composite applications, we could directly hardwire the user interface to the data model (not even the service interface, directly at the database table level). I don't think there is another engineering discipline where people can get away with stupid thinking: bridges would collapse daily, cars would crash or explode, water would not be drinkable... Product managers expect Product Marketing will brainwash customers and if that doesn't succeed, they have found the ultimate argument: they often try to hide between the stupidity of users (How many time have I heard "our users are stupid"). Note that nobody is immune to saying something stupid, but every one should be able to figure it out -even with the help of others.
A great example of somebody having no clue at all is Nick Malick. He seems to work hard every day to post gigantic posts about SOA. His blog claims to provide a view “inside architecture”. How misleading ! Please note that I am not saying that everyone at Microsoft has no clue. I am trying to point out a movement that started a few months ago without any ground and is propagating on fallacious arguments. This is the "it makes me look smart to trash something important" syndrome: industry pundits start injecting FUD in SOA initiatives. What if the benefits were not there? What if SOA was to complex? Too expensive? Required too much change? These questions are music to the hears of some Product Managers, since they could not figure out what customers needed, they promptly bag the whole thing and move on. SOA is annoying, it requires that you think.
Jeff said it eloquently in his post today:
Many of these individuals are the ones responsible for silo-oriented thinking in the first place. They proposed small (agile) projects where we captured just enough requirements to begin coding and releasing. Guess what? This style of development doesn't jive with the concept of shared services. It is the cause of the problem, not the solution.
In
his post, Nick starts to talk about “Semantic Dissonance in the
Data”. He nailed it right, there before our eyes: “This makes Enterprise
SOA a distant fantasy for many enterprises.“.Taa…Daa… Why didn’t I think
of that before? Who knew the hidden relationship between chords and SOA?
What’s next? Semantic Relativity? Quantum Data Integration? Connector
(String) theory? Nanodocuments? Cold Middleware Fusion?
His scenario is described as follows:
For example, in one business, a purchase order may be created by anyone but is followed by an approval process if it exceeds a threshold. In another business, the purchase order cannot be created until the approvals have occurred, and perhaps, all purchase orders require approval.
So, if you look in a database and you see a purchase order... has it been approved or not? The answer depends on the business unit that created it.
So let’s try to understand Nick’s argument. There is not much there so my interpretation might fill in some of the blanks. So we have two business units which have two different procurement processes -not unheard of. I see a “state” “Purchase Order Created”. There is one business entity: Purchase Order and therefore a service managing the system of record for purchase orders. Nick is telling us that “Semantic Dissonance in the Data” is preventing us to design a single service that can support these variants of the procurement process. A “Created” state is very innocuous. I would argue that in order to be reviewed, “something” has to be created. The “Submitted” state that follow is a lot more consequential. Nick, it would really help if you got your states right. In the first variant, the service can be implemented with an conditional transition to “Submitted” provided the amount in within a certain range, while in the second case, the transition is always routed to the approval step. So Nick is telling us that the Purchase Order service cannot be implemented to support two variants of its lifecycle based on the requesitioner’s group? I would bet that even Workflow Foundation can do that.
But of course, Nick concludes : “This makes Enterprise SOA a distant fantasy for many enterprises”. Isn’t it clear for everyone? Let’s stop all SOA initiatives, we are wasting our time we reached the point of Semantic Dissonance. I feel sorry to work for such an industry. IT does not matter because software companies charge too much for their product to put in charge people that pontificate all day instead of getting their hands dirty and spending time with the customer. I am sorry to just pick on Nick, he just exemplifies this FUD movement and consistently produces Diracs of Guidance/Rationale ratios (i.e. infinite amounts of guidance from zero rationale). I’ll pick on other people next time. I don’t think I’ll spend much more time reading his blog.
10/21/07 :: [Other] Northwest Digest [permalink]
I love the Pacific Northwest. Sure, I could talk about all the postcards (Mont Rainier, Beaches, Sound, Whalers, San Juan, Olympic Mountains and the Cascades, the wine...) but I love the people most, not just the international mix, the people that grew up here.
This week-end, someone from my town made me proud to live here. A mom started a "Green Halloween" movement that made it to the Sunday paper. I really don't enjoy that day. She found a great idea to make it fun for everyone. We live in a "me too" society.
Ok, one thing I don't like are the drivers. They are so sloooow. I mean don't get me wrong, I never got a speeding ticket in my life because I drive a the speed limit (Ok I drive 130 mph in Germany only). In any other state I am a pure annoyance, that pretty much everybody passes. Not in Washington. I mean people slow down when it's green, just in case it might turn yellow. When they stop, they stop, just in case there would be some car coming out from another dimension. They other day, I was coming back from a class I take at UW. It was 9pm on 520 (a two lane highway), there were two cars racing at 55 mph in a 60 mph zone. Couldn't pass either. It is so bad that we have a word here: the slog.
Ah yes, if you wonder, it rained for the past 10 days or so. But
10/21/07 :: [BPM] BPMN 1.0 and BPEL4PEOPLE Metamodels Published [permalink]
I published the BPMN metamodel here and the bpel4people one here.
10/09/07 :: [SOA] Microcosmic debates: the return [permalink]
Looks like SOA has its "microcosm": some people including me, who keep talking about the same thing over and over without any new arguments, boring to death everybody else. I am amazed at the fact that nobody told us to get a life. I bet by now no one is reading these posts but us.
So for the nth time:
a) REST is a dead end to write applications because it has no semantics whatsoever. What I mean by that is well illustrated by Stefan's latest presentation on REST: he is hard coding a purchase order date in the purchase order URL:
http://example.com/orders/2007/10/776654
This is what people end up doing, reifying all their familiar programming concepts (another example in stefan's presentation is an entity relation) within the URL syntax. REST Worked well for browsers, pages and servers. Even Roy tells us that it cannot handle peer-to-peer. REST concepts are brilliant, Roy is a great guy, we should thank him for giving us HTTP and HTML. REST principles should be followed when practical and ignored every other time.
b) ESB: I said it many times, take a cab, not the bus. The communication infrastructure of ESBs, you can throw away (the bus) because you already have one, but keep the service container. I think everybody is saying that but they just like to argue.
That's the last time I ever talk about ESB or REST, promise.
10/08/07 :: [SCA] To Assemble or Not To Assemble, That Seems to be the Question [permalink]
Dave Chappell and I are having this discussion about SCA and interoperability. To make my position clear, I am not giving any advice to Microsoft about joining/supporting or not joining/supporting SCA.
I am simply arguing that SOA requires a web service assembly model and SCA assembly model (reduced to web services only) does the job. Dave has written an outstanding tutorial on SCA. As usual he can transform a complex subject into something that's a breeze to understand. However, if I had one thing to say about his tutorial is that it would have benefited to have a longer section on the assembly model. If you are not convinced here are my arguments:
Here are a couple of facts:
a) From both the WS-I Basic Profile 1.0 and 1.1: "R2303 A DESCRIPTION MUST NOT use Solicit-Response and Notification type operations in a wsdl:portType definition"
b) from the WSDL Schema 2.0 (or WSDL 1.1. for that matter):
<service name="xs:NCName"
interface="xs:QName" >
<endpoint />+
</service>
If you prefer a UML notation.
The schema or the diagram shows that “a service must have at least one end-point”.
WSDL was designed to "describe" a service from its own point of view (message types, interface and message listeners). This works in a client/server mode because the provider does not need to know anything about the consumer. However, if indeed a provider has outbound operations (notification and solicit-response or out and out-in using the 2.0 vocabulary) you are kind of stuck.
The reason I say “kind of” is because WSDL 2.0 allows you to associate multiple endpoints to different bindings which are themselves associated to specific operations of the interface. So technically, I could express that, but in the end, if I use the endpoint/bindings for that purpose I lose the “Service” concept. I say I “lose” the service concept because now, I am going to have to create a different service element for each assembly in which “my service” participates. I am not sure this was what the authors of WSDL 2.0 had in mind. No matter how you look at it, as soon as you are using peer services rather than client/server ones you need to distinguish between a service and an assembly of services, you can’t have both in one concept, at least I don’t know how to do that.
Let’s imagine a scenario where I need to assemble arbitrary services which have any number of in-out and out-in operations. How do I do that in an "interoperable" way, i.e. a .Net Service and a Java Service each need to have some information about where to send the "out-in" and "out" operations. Right?
There is only two solutions to correct this defect:
a) Remove outbound operations from WSDL (since they are forbidden by WS-I, why are they even there in 2.0?)
b) Externalize the endpoint definitions like SCA is doing it today.
In other words the <endpoint> element of WSDL need to be defined at assembly time. Service containers such as WCF already support multiple endpoints "per service" so that's fairly trivial to do. Now that the endpoints are defined at assembly time, you can of course "inject" the inbound counterpart into the outbound operation. This means that an outbound operation of a service may target two different endpoints as the service participates in two different assemblies. This is what an SCA assembly definition is doing. You just need to “distribute” an SCA definition to all the services involved in the assembly and they can configure themselves to receive messages from other participants in the assembly.
If you look on this SCA UML diagram: you can see that SCA enables a separate binding between reference and service. This means that the "service" can have access to the endpoint definition that is the target of a given outbound operation. Of course you could have a different endpoint for each operation.
This is 100% interoperability, again if your .Net service does not know anything about outbound references, well, you are going to have to do that by hand.
I regret that the SCA assembly model is convoluted with a larger component model because this give some people excuses to discard it completely and leave end-users like me to pay the price of not having this technology. The good news is that the Java community understands this problem and has lined up to solve it.
10/07/07 :: [SOA] SOA Misconceptions II [permalink]
Richard disagreed with my post today. I forgot that if "you can't google something" or "people were not blogging about it" it does not mean it did not happen. So I am ready to believe that some of the principles of SOA were used before 1998 (after all SGML was invented in 1969). I don't want to open a large debate, I just want to point out that in the last 10 years there has been a wave of innovations that made it simpler to build a Service Oriented Architecture. SOA is a systematic approach of factoring IT assets into reusable elements which can be composed into different solutions. If we can leave it there I'd be happy.
The point I was trying to make earlier is that a lot of people would like others to believe that SOA is easy, "you have done it before and by the way, it's as simple as assembling Legos". The reality, as Richard points it out is that hardly anybody has done it before. I think he would also agree that these new technologies are not that easy to master. Individually, yes they are not rocket science (by far), but as a whole they are challenging for developers and architects accustomed to do things a certain way. When I look at the CBDI SAE SOA Metamodel, the last thing I can think about is "Legos". The metamodel captures very well the information related to a service. To me this looks a lot more like a "part's" description rather than a "common Lego interface". With real parts, I can construct real helicopters, with Legos I can construct mockups.
I like Jeff's point as he discusses SOA budgets:
I've said it before and I'll say it again... SOA Transformations cost big bucks, take years to complete but in the end are worth the investment.
10/07/07 :: [SOA] SOA Misconceptions [permalink]
For some years I have been fighting two SOA misconceptions:
A) SOA is not new, people were doing SOA 30 years ago
B) Services are like lego blocks
Richard Tews shows a nifty picture of an an Helicopter (a real one) and one built with Legos. I think the picture shows eloquently which one you want to buy if you want to go from point A to point B. The bottom line is that you can't make something useful with Legos unless you have lots of skills and lots of Lego blocks. Ultimately a Lego construction is brittle and can't be changed easily... hum, the reality is that "code and libraries" are like Legos and services are like specialized parts of which you construct real things.
Each time you would have to produce a helicopter, you would have to re-build every individual parts with Legos, no reuse is possible. Services are functional components from which you can rapidly assemble complex solutions, Legos are not, they are a lot closer to lines of code that you painstakingly need to write by the thousands to get anything useful out of it.
Now, did people really do SOA 30 years ago? well I must admit that 30 years ago I was programming on my TI-58 and for sure I could not write services on it, for once is was not connected to anything, so no one but me could reuse my little programs saved on a magnetic strip. Then I moved on to write "code" on my TRS-80. One of the first program I wrote (in 10th Grade) was a program that would display the chemical structure of hydrocarbons based on their composition: C2H2 would display something like this H-C=C-H (imagine three lines instead of =). Anyways, no services there either. My dad worked in a bank where they had an IBM 390, but I never heard him talking about "services". They were lucky to never let me touch that thing. So my point here is that I was not in the position to know if people were doing SOA 30 years ago, but it sures does not look like it.
For me SOA is about constructing network accessible, reusable IT assets (NARITA) which can be composed into solutions. I am sure that there was a few network accessible, reusable IT assets 30 years ago (a very few since there was not that much network back then). However, I would like to argue that the technologies of SOA such as XML, XML Schema, SOAP (and HTTP), WSDL, WS-BPEL, SCA, WS-Security that enable us to build true NARITAs simply did not exist 30 or even 10 years ago. SOA as we know it today started in early 1998 with XML and XML-RPC. For me the SOA pioneer is a company called BowStreet that was based in Portsmouth, NH and which was bought by IBM 2 years ago. Its CTO Andy Roberts had build by 1998 a composite application framework using XML and XSLT. They were so ahead of their time that nobody understood what they were doing (including me).
So please, no more Lego analogies and no more "my grandpa was doing SOA too".
10/03/07 :: [SCA] SCA: the last mile of interoperability [permalink]
Dave Chappell reopened the SCA debate arguing that there was no reason for Microsoft to join the SCA working group. Harmut summarized some of the discussions here.
I think this point that was made: “The assembly model, which is defined by the Service Component Definition Language (SCDL), does not add to interoperability either” is, IMHO, incorrect.
The Web Services standard stack does not support an “interoperable” assembly mechanism. As a matter of fact, if you are adopting the WS-I Basic Profile, you are forbidden to use “outbound” operations, so your services cannot expose “references” (using SCA lingo). The only assemblies Web Services can support are of the Client/Server type (this is tenet if you build a SOA with WS only).
Further if you want your service to participate in multiple assemblies simultaneously you have to code a an assembly context management layer between your soap stack and your business logic. This layer is thin and is low value for an infrastructure software vendor like Microsoft, but it has a huge value for a customer building connected systems at the presentation, process and information layers.
SCA is two distinct pieces, IBM should probably have separated them more clearly, but Assemblies are the “last mile” of interoperability, while the programming model is purely about portability.
At the end of the day it is inconsequential that Microsoft's participate or not in SCA, because someone, if not Microsoft, will build this thin layer on top of WCF to enable the creation of SCA components running in the CLR. Incidentally, SCA is offering a distributed CLR system for any language, not just Microsoft's CLR languages. Being able to assemble Java, BPEL, php, C++ components is a powerful value proposition for a customers.
This is how I compare a SCA world with the "interoperable" world of .Net :
| SCA world | Microsoft World |
| Any language support CLR | MS languages support |
| Distributed CLR with local optimization | Local CLR, intercommunication via WCF |
| Peer-to-peer assemblies | Binary assemblies |
| Homogeneous progr. model | Homogeneous prog. model |
Putting it that way, I don't see what the folks in Redmond have left to lose in adopting SCA's assembly model, unless it is an ego thing.
09/30/07 :: [FOA] A simple scenario [permalink]
Ok, the rainy season has started in Seattle, I often joke that we have about 10 months of winter and two months of spring around here (but I don't mind, the area is spectacular because of that, and bright sunny day are well worth a few raindrops). So the work in the yard is winding down. I got to think a bit more about "Feed Oriented Architecture". I came up with a very simple metamodel:
and started to build an example. It looks to me that there are lots of Feed-like object that can be used to represent the states and activities of business entities.
09/23/07 :: [SOA] Common STP Metamodel [permalink]
I stumbled on the common STP metamodel last night because they had added a reference to wsper on their page (thanks !). These days it is really hard to keep track of all the good stuff that's going on. STP is definitely a great valuable project.
However, I would like to point out what I think, IMHO, is a mistake in the C-STP-M. Their metamodel (first figure) expresses that a process is composed of a series of steps which may invoke a service. I am not sure this is the right approach. Sure enough some processes might look like that but in general the relationship between process and service is more complex. I have written an ebook over the summer that will be available for download on InfoQ shortly that kind of explain my position on it.
09/23/07 :: [Hollywood] Greg the architect [permalink]
I often thought that I had seen it all, that there was no bottom below the bottom. Enterprise Software is the prototypical example of "wealthy cluelessness". Enterprise software vendors are loaded, sometimes, it's sickening how much money flows through them with the benevolence of some CIOs. When money is of no concern, some vendors reach the promised LaLaLand where everything you do makes sense, every product you make will finds buyers, where product management and product marketing replace customer focus with self belief and sales people can always say "yes" to customer requests.
If Tibco has way too much money to spend, why not giving it to charities? Pathetic.
09/23/07 :: [SOA] Service Funding: the better model [permalink]
When it comes to Service Funding, people generally have no clue. Latest example comes from Nick. He takes issue with the statement "When IT is bought like other services, IT can become a business within the business". Ok, I don't like the word "charge back", it really does not sound appealing to be "charged back".
The thing I find funny is that a business unit finds it perfectly OK to pay monthly fees to SalesForce.com or SAP byDesign. Actually, they love SaaS's business model so much that SAP's CEO, Henning Kagermann, calls it the better model (as compared to a costly, complex and risky ERP implementation). But when it comes to SOA, all the sudden this would be a stupid model.
There are also many industries where competitors often share services they provide to their customers (you often have no idea that this is happening), and again the business thinks it is just fine to "pay as you use" while they rebrand and market the "service".
Let's bring back sanity to this debate (and avoid long billable consulting hours of discussion on the topic). "Pay as you use" does not necessarily mean that you are "charged back" for every transaction you make. But at the end of the day SalesForce.com's business model is about charging more the customers that use more resources, whether the formula is linear or not does not matter.
Nick is funny, he says charge back is bad on the other hand he suggests to use a "Transaction Funding Ratio". TRF works as follows:
For example, if team 1 hosts 20,000 transactions against their shared services, and team 2 hosts 30,000 transactions, then team 1 would get 20000/50000 or 40% of the operating budget, while team 2 gets the other 60%.
Hum... let me thing that again, ok, his point is that if you make 22,000 transaction and 51,000 the ratio don't change that much. So this is not "charge back", well it sure has the feel of it. I bet that next year around, they will adjust the ratio. I would argue that TRF is nothing more than "delayed charge back" (DCB).
At the end of the day, whichever model you choose (or not choose any model), there is only one thing that counts, the business must see it as a bargain (because sharing services is indeed a bargain). Things like "change once, everybody benefits instantly" has tremendous benefit both psychologically and financially. SalesForce.com understood that better than anybody else, so why re-invent the wheel?
So indeed, SOA will facilitate the notion of "When IT is bought like other services, IT can become a business within the business". By a better factoring of solutions it is easier to identify what is line of business specific from what it is not.
Nick's post is not just plain stupid, it is misleading because it fails to relate the funding mechanism to the level of maturity of your organization with respect to SOA. I would advise you to think about the funding model when you have effectively proven that services can be reused and showed the benefits of it to the business. Any time spent on this question before you reach that point is simply wasted, not to mention that it brings confusion to the business. Revisit the question when you have a "delivery" team and a SOA infrastructure that makes developing, operating, monitoring and changing services a breeze.
09/20/07 :: [FOA] Feed oriented Architecture [permalink]
I work downtown Seattle, and I kind of have a view on the Puget Sound (this is not uncommon). I saw a cargo ship today, probably coming from China. I was wondering what was involved to make this ship appear at this time and this location in its current state. First, lots of work. Ok. Lots of state capture, alignment and communication too. But the essence of information systems is to "synchronize" state (I am talking about the state of the physical world): you tell me what you can do, and I tell you what I want you to do.
The only kind of productivity gains brought by information systems are associated to resource optimization via state capture, alignment and communication. They capture the state of the physical world and keep communicating it (inside and outside) to whoever needs it for the purpose of reaching alignment. If they are smart enough, they are also good at predicting future state.
If I could summarized what I have been doing in the last 10 years in one sentence, it would be "look for a better programming model to build information systems". In one split second I started to see feeds everywhere. Feeds are great at capturing, aligning and communicating state. A ship, a container, a purchase order, a shopping cart, a bank account (a double feed), a class, a school, I franticly searched on my favorite engine if someone had came up with something like Feed Oriented Architecture. Nothing.
There are few objects that actually don't exhibit feed like behavior. They are mostly master data. A catalog is not exactly a feed, but a catalog update it. A customer is not a feed either, but some aspects are, such as support incidents, purchases, returns...
Some feeds time out or may be closed (for updates), other behave like a stack, may be sorted, may be updated... All the sudden data did not appear as much relational as it used to be. Don't get me wrong, relational data is not going away anytime soon, but it looks like the programming model of information systems could be greatly simplified if this construct was available to developers.
09/16/07 :: [SOA] Mash IT up [permalink]
I created my first mashup in 1999 and it was love at first sight. I knew for sure back then that it would be a crime to leave the presentation layer out of SOA. 99ers would tell you that it was the golden days of procurement and everyone was talking about about catalog aggregation, assembling all kinds of feeds into one majestic catalog. This was incredibly complicated. PhDs were debating on taxonomies and overlaping codes, when, well, huh... how about mashing them up? Ah yes, small detail, how do you deal with a shopping cart in that case? Mash it up too ! I had built a solution using XML fragments embedded behind catalog elements that people could drag an drop into a shopping cart. Not only the UX was wonderful, but the solution was incredibly more efficient. All the components were running where it was most efficient to run them. Suppliers had complete control over their catalogs. We could sell a unified procurement solutions for our clients. We could even pass back some of the XML the suppliers had given us in the cart in case they wanted to track back some promotions.
Cost of all this? a few weeks of work. Management? completely distributed. Is this service oriented architecture? hum... well you have a bunch of catalog services on one side, you have a procurement service on the other, composed of a shopping cart service and some ordering service. Ah... the user is in the loop. So ? I meant SO? you are telling me the user is the orchestrator of all this, how can it be SO? who said SO couldn't be mediated by a user? Ok, if I have not lost you, yes, this is a well-formed service oriented solution that nowadays people call mashups.
IT is in great need of mashups. There are three levels of mash ups (maybe more) that are relevant for IT: presentation, process and information. If most people love mash ups these days it is because they are a gold mine of productivity. You can take any user activity in your organization and do a mash up analysis. How many systems does this user need? What other pieces of information could we provide him or her to do his or her job better? If the answer is more than one system, this is a great candidate for mash ups. ROI is easy to calculate, prove and get back.
But don't stop here, look at your processes, and check where additional service invocations (internal or external) could improve the quality and performance of the process. You can mash information up too. EII is starting to become mainstream and nobody says that all mashups have to be done at the presentation layer. You can preemptively send or consume the data that makes the presentation layer easier to build.
Not convinced? I have built a little mashup to help my children learn how to read (flashreader.org). The principle is easy, let them type in some flashcards and then look at what you can do with a word on the web:
- dictionary & thesaurus
- translate in French, Italian or Spanish
- get some information from wikipedia
- sound it out
- get a picture that represents the word (that my child has chosen from many)
- build a spelling sheet
- build little word games
- ...
endless. Now if I had to go to each of these web site for every word and have to type it in each time, not to mention having to navigate through several pages... well I would not do it, let alone my children who would pass on tons of experience around a single word. Don't try that at home. It would take years to recreate the same app that I wrote in 3 weeks on my spare time.
So mash IT up ! today !
09/14/07 :: [SOA] wsper: an abstract SOA Framework [permalink]
When I stopped blogging here in 2005, I expressed some sadness with respect to the way SOA standards and products were developed. I don't want to debate too much about this point, I'd rather do something about it. I have long argued that the end goal was to create a service oriented, process centric, model driven programming model. I have not changed by a iota.
So in the past few months, I have started to work on an abstract SOA framework that defines a programming model for SOA. I can't say, yet another one, because to the best of my knowledge (and I may be wrong), I don't know any other. I called this abstract framework, wsper ("whisper") because the web, services, processes, events and resources are key elements of the language. I have written a primer at the end of June that can be found here. Over the summer I have written an e-book that InfoQ.com has kindly accepted to publish (it will be available shortly). In this book, I explain my views on "Composite Software Construction" and the need for a new programming model.
I just wanted to give you a few ideas about the origins of wsper:
a) I like Dave Chappell's idea that what we have accomplished so far in building technologies for SOA is the "byte code" level. He talks just about BPEL, I talk about the whole stack, XML Schema, WSDL, BPEL,.... Who is the developer who is going program at the byte code level on a regular basis?
b) If you were to try to implement your SOA at this level you would have to learn tons of technologies, best practices,... you have a million chance to shoot yourself in the foot for any service you write. Don't get me wrong, this is not an attack on the stack, it had to be designed that way. The products that have been built with it are great, but they are at the VM level
c) what's missing is a programming model to construct composite software, this is wsper.
d) wsper is abstract because I am expecting that some big IT organizations will implement their own VM goop on top of their best of breed SOA technologies, while injecting their best practices in it. Some vendors may also decide to use wsper to offer a SOA programming model on top of their product stack.
e) wsper is about helping you write your business logic independently of the standards and products that you are using. Because, beyond the complexity that requires lots of training, you know the story, right? you have been there and done that? It's the U... word, when it is going to be time to upgrade a tiny bit of the infrastructure or to a new version of a standard, say XML Schema 1.1, well you know what happens then when you have 50 moving parts.
f) wsper is a programming model that has 3 key constructs services, assemblies and resources. The programming language itself introduces "messages" as a first class citizens along data and control structures. There is also a bunch of "state" constructs, because, well, state is also a first class citizen in the language.
g) wsper ties together the declarative and imperative styles of programming. In the past they have been often opposed, in reality there is a continuum, and one can't leave without the other. In the wsper primer I demonstrate that the continuum already exists in OO and I show how the OO metamodel can be evolved without breaking the principles that have made it so popular.
h) Syntax? wsper is syntax neutral. It is a metamodel from which you can generate as many syntaxes as you like. Pick your favorite, mix them up. They are isomorphic.
i) once I formalize the language, I will build a small reference implementation based on open source stack.
If you like what you hear or what you see, and maybe would like to contribute drop me a note gmail/jdubray
The real work starts now.
09/12/07 :: [New Roll] Blogging again... [permalink]
I have decided to blog again, 2007 is definitely a great year for SOA Standards (the family has grown quite a bit) and the future of Composite Applications has never looked brighter. More later.