What is the standard .wsdl for a workflow engine to expose its state?
What is the standard .wsdl to expose a message queue? What about a pub/sub topic?
What is the standard .wsdl to expose LDAP?
What is the standard .wsdl to expose POP? SMTP? FTP?
You know, it's great to have one-off wsdl's over at xMethods. But at some point we are going to have to pull together a 'library' (or profile) of wsdl's to expose the technology architecture. The library should be consistent in style. After we finish it we should throw it away - because it will be wrong. Then we should start over.
Tuesday, September 30, 2003
The end of BPM-1, the beginning of BPM-2
I dropped a few comments on BPM-2 at 'Loosely Coupled'. I'll try to elaborate on this article in the coming days.
Also, I seem to be losing the battle to change the name of an ESB to something that makes sense. So, if you can't beat'em join'em. Message oriented services with durable load tempering devices is a solid concept. It's still a stupid name - but I'll get over it.
Also, I seem to be losing the battle to change the name of an ESB to something that makes sense. So, if you can't beat'em join'em. Message oriented services with durable load tempering devices is a solid concept. It's still a stupid name - but I'll get over it.
Saturday, September 27, 2003
7 Things Great Software Architects Have
1. Friends that are also great architects
2. Loyal associates that are great designers and programmers that will work with them no matter what the project is
3. Extensive experience on at least 3 platforms (mainframe, J2EE, .net, CORBA, TOGAF, etc.)
4. A bookshelf that is about to topple over and a mechanism for demoting bad books
5. 3 or more candidate architectures or software architecture documents (SAD's) on your hard drive
6. Your personal ontology of non-functional requirements
7. 'Success Patterns' - things you know which have worked on previous engagements
2. Loyal associates that are great designers and programmers that will work with them no matter what the project is
3. Extensive experience on at least 3 platforms (mainframe, J2EE, .net, CORBA, TOGAF, etc.)
4. A bookshelf that is about to topple over and a mechanism for demoting bad books
5. 3 or more candidate architectures or software architecture documents (SAD's) on your hard drive
6. Your personal ontology of non-functional requirements
7. 'Success Patterns' - things you know which have worked on previous engagements
Thursday, September 25, 2003
Lou Dobbs - Exporting America
WOW - I just watched Lou Dobbs. He is running a special series called, "Exporting America". He is spot lighting the overwhelming move of American jobs to low wage countries like India and China. Lou is one of only a small handful of people that have had the balls to stand up and fight for the American I.T. worker and the current unfair trade policies that exist.
Tonight, he had Adam Smith, congressman from Washington on the show. Adam has initiated a study with the GAO to look into the effect of the multi-national corporations decision to fire American workers and hire cheap offshore labor.
What was extremely disturbing was that Adam Smith seemed to already have his mind made up. He commented that he didn't have any issues with the H1B program, and thought that there *might* be some issues with the L1B program. Adam Smith are you nuts? The American I.T. worker has taken it up the ass.
Last week my company had some job openings and I did the interviewing. I had three candidates in a row all come in who were on an L1B program, hadn't had a job in months, continued to stay in America and were commenting that they would work for "whatever I wanted to pay". I asked them who sponsored their visa and they all told me names of different Indian based 'body shops'. Naturally, I asked if the shops that brought them in employed them. They then explained to me that the Indian shop provided them a plane ticket. In exchange for the ticket, the individual would have to pay the sponsor 20% of all of their wages while in the U.S. It was the individuals responsibility to go and get a 'real employer'. In essence, they were indentured servants to the company that bought their ticket. Adam Smith this is reality. Don't believe me? Get an employers account on Monster.com, do a search for "Java" - you pick the city, call the first ten results and ask the individuals their situation. I dare you.
Here is the contact page for Adam Smith:
http://www.house.gov/adamsmith/contact/contact.html#
Take the time and fill out the form. Please.
Tonight, he had Adam Smith, congressman from Washington on the show. Adam has initiated a study with the GAO to look into the effect of the multi-national corporations decision to fire American workers and hire cheap offshore labor.
What was extremely disturbing was that Adam Smith seemed to already have his mind made up. He commented that he didn't have any issues with the H1B program, and thought that there *might* be some issues with the L1B program. Adam Smith are you nuts? The American I.T. worker has taken it up the ass.
Last week my company had some job openings and I did the interviewing. I had three candidates in a row all come in who were on an L1B program, hadn't had a job in months, continued to stay in America and were commenting that they would work for "whatever I wanted to pay". I asked them who sponsored their visa and they all told me names of different Indian based 'body shops'. Naturally, I asked if the shops that brought them in employed them. They then explained to me that the Indian shop provided them a plane ticket. In exchange for the ticket, the individual would have to pay the sponsor 20% of all of their wages while in the U.S. It was the individuals responsibility to go and get a 'real employer'. In essence, they were indentured servants to the company that bought their ticket. Adam Smith this is reality. Don't believe me? Get an employers account on Monster.com, do a search for "Java" - you pick the city, call the first ten results and ask the individuals their situation. I dare you.
Here is the contact page for Adam Smith:
http://www.house.gov/adamsmith/contact/contact.html#
Take the time and fill out the form. Please.
Wednesday, September 24, 2003
The 2-pin theory.
Sean McGrath wrote a thought provoking piece.
I caught myself responding on one of the news groups & thought I'd share...
===================================
Wow - nice piece from Sean. Thought provoking.
Is the *magic* of the interface related to the *2-pin* theory (i.e., do(x)) or it related to advancements in protocol negotiation? Does USB work better because of the number of pins or because of the structured negotiation between participating components? What about BlueTooth?
WS-* is moving into a world where dynamic protocol negotiation for non-functional requirements will be able to happen on the fly.
An example of two web services talking to each other (think consumer:producer) :
Service 1: Can you do encrypted?
Service 2: Yes, I do TripleDES, Do you?
Service 1: Yes, let's do it!
Service 1: Do you do Reliable Messaging?
Service 2: No, not for this operation.
Service 1: Can you treat this operatin as part of a transaction?
Service 2: No, I can't, but I do have a compensating mechanism, see URI:xxx.wsdl
Service 1. Great, I'm going to use it.
Now, an interesting question is how did databases servers get away with a small number of interfaces / operations? The answer is that they created languages which could be shipped across a wire to perform more complex functionality. Thus, the database has the notion of the do(x) - or if you'd like, you could say that it had:
do(DDL)
do(ANSI SQL 92)
do(stored procedure), etc.
Back to the conversation:
Service 1: Now, it is time for us to do some real work, I need some data, do you support XQuery 2.0?
Service 2: Of course! Send your query on over!
Service 1: Ok, here it is: (query blah, blah, blah)
Service 2: Great! Here is your result (some data, ....)
Now, of course, you wouldn't want the conversation to be anywhere near this verbose... but you get the idea. Simplicity in interface doesn't just happen by creating a magic "do(x)" - you have to actually have some meat behind the operation. Web service protocol designers are attacking both of these fronts (NFR protocol negotiation and ubiquitous, shippable languages like XQuery).
IMHO, looking for simplified interfaces is good - just be careful not to throw away your meta-data just to make a clean WSDL.
Jeff
I caught myself responding on one of the news groups & thought I'd share...
===================================
Wow - nice piece from Sean. Thought provoking.
Is the *magic* of the interface related to the *2-pin* theory (i.e., do(x)) or it related to advancements in protocol negotiation? Does USB work better because of the number of pins or because of the structured negotiation between participating components? What about BlueTooth?
WS-* is moving into a world where dynamic protocol negotiation for non-functional requirements will be able to happen on the fly.
An example of two web services talking to each other (think consumer:producer) :
Service 1: Can you do encrypted?
Service 2: Yes, I do TripleDES, Do you?
Service 1: Yes, let's do it!
Service 1: Do you do Reliable Messaging?
Service 2: No, not for this operation.
Service 1: Can you treat this operatin as part of a transaction?
Service 2: No, I can't, but I do have a compensating mechanism, see URI:xxx.wsdl
Service 1. Great, I'm going to use it.
Now, an interesting question is how did databases servers get away with a small number of interfaces / operations? The answer is that they created languages which could be shipped across a wire to perform more complex functionality. Thus, the database has the notion of the do(x) - or if you'd like, you could say that it had:
do(DDL)
do(ANSI SQL 92)
do(stored procedure), etc.
Back to the conversation:
Service 1: Now, it is time for us to do some real work, I need some data, do you support XQuery 2.0?
Service 2: Of course! Send your query on over!
Service 1: Ok, here it is: (query blah, blah, blah)
Service 2: Great! Here is your result (some data, ....)
Now, of course, you wouldn't want the conversation to be anywhere near this verbose... but you get the idea. Simplicity in interface doesn't just happen by creating a magic "do(x)" - you have to actually have some meat behind the operation. Web service protocol designers are attacking both of these fronts (NFR protocol negotiation and ubiquitous, shippable languages like XQuery).
IMHO, looking for simplified interfaces is good - just be careful not to throw away your meta-data just to make a clean WSDL.
Jeff
Saturday, September 20, 2003
WSDL of the Day?
If Don Box can do a Win32 API of the Day... surely I could do a 'WSDL of the Day' !
Hmmm... sounds like a lot of work. Anyone want to help? (If not, it will likely turn into WSDL of the Month :-)
Hmmm... sounds like a lot of work. Anyone want to help? (If not, it will likely turn into WSDL of the Month :-)
Friday, September 19, 2003
OASIS to look at EVERYTHING
I just stopped by the OASIS Messaging and Coordination page and got a good laugh. It appears that Karl Best and friends have decided to take on a few more specs. So, in addition to BPEL, we have:
Business Transaction Protocol (BTP)
OASIS Asynchronous Service Access Protocol TC
OASIS Web Services Composite Application Framework (WS-CAF) Technical Committee
W3C Web Services Choreography Working Group
Web Service Choreography Interface (WSCI)
Web Service Composite Applications Framework (WS-CAF)
Web Service Context (WS-CTX)
Web Service Coordination Framework (WS-CF)
Web Services Transaction Management (WS-TXM)
Web Services Choreography Description Language (WS-CDL)
Web Services Conversation Language (WSCL)
Web Services Transaction Framework
Web Services Atomic Transaction (WS-AtomicTransaction) [replaces WS-Transaction-V1, Part I]
Web Services Coordination (WS-Coordination) [Version 2]
Web Services Business Activity (WS-BusinessActivity) [to replace WS-Transaction-V1, Part II]
Web Services Transaction (WS-Transaction) [Version 1]
Web Services Coordination (WS-Coordination) [Version 1]
WS Choreography
A Bounty
Ok, enough is enough. Can we put out a bounty to be paid to anyone that manages to kill a working group? Honestly, I will kick in my fair share. For starters, let's whack WS-Choreography - I'll pay $500 USD to the person that disassembles this working group. Surely there are others that will kick in too... My fear is that as quick as we knock them down, the fine folks at Oracle, Sun and Iona will create new ones to replace the old ones. Hence, I propose that we find the professional spec writers at the aforementioned companies new jobs. Got a startup? Offer one of these guys a job! Not because you need them... because you'll have to spend less on marketing to educate the world on why your product doesn't support some bullshit specification that these people made up. In the end... it will all pay off
:-)
Business Transaction Protocol (BTP)
OASIS Asynchronous Service Access Protocol TC
OASIS Web Services Composite Application Framework (WS-CAF) Technical Committee
W3C Web Services Choreography Working Group
Web Service Choreography Interface (WSCI)
Web Service Composite Applications Framework (WS-CAF)
Web Service Context (WS-CTX)
Web Service Coordination Framework (WS-CF)
Web Services Transaction Management (WS-TXM)
Web Services Choreography Description Language (WS-CDL)
Web Services Conversation Language (WSCL)
Web Services Transaction Framework
Web Services Atomic Transaction (WS-AtomicTransaction) [replaces WS-Transaction-V1, Part I]
Web Services Coordination (WS-Coordination) [Version 2]
Web Services Business Activity (WS-BusinessActivity) [to replace WS-Transaction-V1, Part II]
Web Services Transaction (WS-Transaction) [Version 1]
Web Services Coordination (WS-Coordination) [Version 1]
WS Choreography
A Bounty
Ok, enough is enough. Can we put out a bounty to be paid to anyone that manages to kill a working group? Honestly, I will kick in my fair share. For starters, let's whack WS-Choreography - I'll pay $500 USD to the person that disassembles this working group. Surely there are others that will kick in too... My fear is that as quick as we knock them down, the fine folks at Oracle, Sun and Iona will create new ones to replace the old ones. Hence, I propose that we find the professional spec writers at the aforementioned companies new jobs. Got a startup? Offer one of these guys a job! Not because you need them... because you'll have to spend less on marketing to educate the world on why your product doesn't support some bullshit specification that these people made up. In the end... it will all pay off
:-)
Tuesday, September 16, 2003
OASIS to look at Methodology
Name of the TC: OASIS Framework for Web Services Implementation (FWSI)
Technical Committee
Statement of Purpose
The purpose of OASIS FWSI TC is to facilitate implementation of robust
Web Services by defining a practical and extensible methodology
consisting of implementation processes and common functional elements
that practitioners can adopt to create high quality Web Services systems
without re-inventing them for each implementation.
It solves the problem of the slow adoption of Web Services because of
lack of methodologies to implement Web Services, and a lack of
understanding of whether solutions proposed by vendors have the
necessary components to reliably implement an application based on Web
Services.
Technical Committee
Statement of Purpose
The purpose of OASIS FWSI TC is to facilitate implementation of robust
Web Services by defining a practical and extensible methodology
consisting of implementation processes and common functional elements
that practitioners can adopt to create high quality Web Services systems
without re-inventing them for each implementation.
It solves the problem of the slow adoption of Web Services because of
lack of methodologies to implement Web Services, and a lack of
understanding of whether solutions proposed by vendors have the
necessary components to reliably implement an application based on Web
Services.
Monday, September 15, 2003
Model Driven Services
The model for creating business software has leveraged the concept of utilizing a base engine (or server) and extending its functionality with specialized models, templates or other consumable metadata. In J2EE, we use a JSP template engine to consume JSP's, we use an EJB container to consume EJB's, etc. Typically we then chain together engines (JSP engines + EJB engine + DB engine) to fulfill some use case.
Many of the web services that I have created were "home grown", that is to say that they were written from scratch and didn't leverage any engine. The more I looked around, the more I realized that others (including vendors) seemed to be caught in the same boat. Moving web services into the (model + engine) world is obvious.
I found myself asking how come we haven't seen more model driven services? I think one reason is that many developers are too concerned about the SOA triangle (producer, consumer, directory). The SOA triangle is an architectural pattern that will be used over and over again inside of service-based applications. However, it isn't the end. Extending the triangle, or leveraging other patterns is absolutely necessary.
So, here are some interesting questions to ponder....
1. To what extent does one attempt to standardize authoring environment interfaces?
2. Does an authoring environment service provide a default UI customizer that is shippable (JNLP style)?
3. Should the customizers (models, meta data, etc.) be logically held together at the use-case / scenario level?
Many of the web services that I have created were "home grown", that is to say that they were written from scratch and didn't leverage any engine. The more I looked around, the more I realized that others (including vendors) seemed to be caught in the same boat. Moving web services into the (model + engine) world is obvious.
I found myself asking how come we haven't seen more model driven services? I think one reason is that many developers are too concerned about the SOA triangle (producer, consumer, directory). The SOA triangle is an architectural pattern that will be used over and over again inside of service-based applications. However, it isn't the end. Extending the triangle, or leveraging other patterns is absolutely necessary.
So, here are some interesting questions to ponder....
1. To what extent does one attempt to standardize authoring environment interfaces?
2. Does an authoring environment service provide a default UI customizer that is shippable (JNLP style)?
3. Should the customizers (models, meta data, etc.) be logically held together at the use-case / scenario level?
Sunday, September 14, 2003
IBM, Batty, Autonomic Computing
I've been blogging how IBM is Batty on a few subjects... most recently on web services, grid (OGSA), model driven architecture (MDA)... and now autonomic computing.
See:
http://www.research.ibm.com/autonomic/
The convergence of the aforementioned technologies could create one interesting model!
See:
http://www.research.ibm.com/autonomic/
The convergence of the aforementioned technologies could create one interesting model!
From UML to BPEL
Keith Mantell at IBM wrote an article on using UML and MDA concepts to gen your bpel. See:
http://www-106.ibm.com/developerworks/webservices/library/ws-uml2bpel/
He creates a UML profile that has the semantics to represent bpel and then discusses making a map from the model to the bpel code. The base process is represented as a class and the orchestration is modeled as an Activity Diagram.
All in all, it is an interesting concept. One concern that I have is that people don't try too hard to shove a square peg (UML) into a triangular hole (SOA & BPEL). The base UML models were developed some time back and don't always represent the concepts that we need. For instance, I use a Service-Based Sequence Diagram rather than Activity Diagrams to represent orchestrations... just seems easier.
http://www-106.ibm.com/developerworks/webservices/library/ws-uml2bpel/
He creates a UML profile that has the semantics to represent bpel and then discusses making a map from the model to the bpel code. The base process is represented as a class and the orchestration is modeled as an Activity Diagram.
All in all, it is an interesting concept. One concern that I have is that people don't try too hard to shove a square peg (UML) into a triangular hole (SOA & BPEL). The base UML models were developed some time back and don't always represent the concepts that we need. For instance, I use a Service-Based Sequence Diagram rather than Activity Diagrams to represent orchestrations... just seems easier.
Wednesday, September 03, 2003
Web service testing ... no fun
Anyone that has had to serious testing of web services knows that it is no fun - just noticed that Optimyz has put out version 2.0 of their tool:
http://www.optimyz.com/product_overview.html
and not to forget the fine folks at Mindreef who have released version 2.0 as well:
http://sdtimes.com/news/085/story13.htm
http://www.optimyz.com/product_overview.html
and not to forget the fine folks at Mindreef who have released version 2.0 as well:
http://sdtimes.com/news/085/story13.htm
Web Services Enable New Front Ends
I've seen a couple of these now... new portals that use web services to collect information from a variety of sources:
http://www.anacubis.com/amazondemo/
Although still early, I anticipate many sites to begin incorporating cross-site, cross-database integration.
http://www.anacubis.com/amazondemo/
Although still early, I anticipate many sites to begin incorporating cross-site, cross-database integration.
Monday, September 01, 2003
StrikeIron Web Services Analyzer
I've been playing with a tool to invoke web services from StrikeIron. Overall, I think they did a pretty good job!
One thing I like is how they are displaying the results in a grid-format, rather than having you traverse a tree. One thing I don't like is that you can't abend run-away queries.
One thing I like is how they are displaying the results in a grid-format, rather than having you traverse a tree. One thing I don't like is that you can't abend run-away queries.
Subscribe to:
Posts (Atom)