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.
Friday, August 29, 2003
Offshore Backlash
You know that an offshore backlash is in effect when 'The Economist' publishes pictures of 'Casual Friday' at an offshore company like this:
More confusion on course / fine grained at Syscon
STOP THE MADNESS!!
Yet another article has come out saying that we should write our web services using course grain interfaces. Authors, please stop writing this nonsense.
The course/fine grain issue does not have a 1:1 relationship with web services.
The course/fine grain trade-off is often related to distributed computing, but even that is incomplete.
The course/fine grain trade-off is an issue of latency and usability.
A web service that implements fine grained interfaces and is meant for local invocation is PERFECTLY FINE.
A web service that implements fine grained interfaces and is meant for distributed invocation and is on a low-latency network is also PERFECTLY FINE.
I really wish that Doug Kaye would get on the bandwagon and speak out on this issue - many, many people have misunderstood his book. I do like the SO design guidelines Mr. McDowall has going, note that he doesn't mention asynchronous or course grained (thank God).
Now that both the Microsoft WSE and WebSphere 5.02 both support local in-proc web service calls without hitting the socket or marshalling the data to an XML format, we need people to QUIT saying that web services should be designed with course grained interfaces - it is wrong. Design web services using a course grained interface when you know that there is a latency issue - or when it just plain makes it easier (usability) on the end developer (and has no side effect).
See:
http://sys-con.com/webservices/article.cfm?id=641
Yet another article has come out saying that we should write our web services using course grain interfaces. Authors, please stop writing this nonsense.
The course/fine grain issue does not have a 1:1 relationship with web services.
The course/fine grain trade-off is often related to distributed computing, but even that is incomplete.
The course/fine grain trade-off is an issue of latency and usability.
A web service that implements fine grained interfaces and is meant for local invocation is PERFECTLY FINE.
A web service that implements fine grained interfaces and is meant for distributed invocation and is on a low-latency network is also PERFECTLY FINE.
I really wish that Doug Kaye would get on the bandwagon and speak out on this issue - many, many people have misunderstood his book. I do like the SO design guidelines Mr. McDowall has going, note that he doesn't mention asynchronous or course grained (thank God).
Now that both the Microsoft WSE and WebSphere 5.02 both support local in-proc web service calls without hitting the socket or marshalling the data to an XML format, we need people to QUIT saying that web services should be designed with course grained interfaces - it is wrong. Design web services using a course grained interface when you know that there is a latency issue - or when it just plain makes it easier (usability) on the end developer (and has no side effect).
See:
http://sys-con.com/webservices/article.cfm?id=641
Thursday, August 28, 2003
Stuck in Java Land
I just caught the thread in "The Server Side" where the 50+ people all tried to say that Don Box was full of crap for commenting that SOA will eclipse OO as a programming model, see:
http://www.theserverside.com/home/thread.jsp?thread_id=21132&article_count=39
Well, this seems to be the typical response that Java dudes have to web services and SOA. Now, if it was Bill Joy or James Gosling that made the comment these guys may have taken it seriously. So, BEA is on the SOA bandwagon - they seem to get it (thank Adam?), IBM gets it... but doesn't really have the evangelism going. I look forward to the day when the masses 'get it' and quit dogging on thought leaders like Box.
http://www.theserverside.com/home/thread.jsp?thread_id=21132&article_count=39
Well, this seems to be the typical response that Java dudes have to web services and SOA. Now, if it was Bill Joy or James Gosling that made the comment these guys may have taken it seriously. So, BEA is on the SOA bandwagon - they seem to get it (thank Adam?), IBM gets it... but doesn't really have the evangelism going. I look forward to the day when the masses 'get it' and quit dogging on thought leaders like Box.
Monday, August 25, 2003
Sun sees BPM, just doesn't know what the acronym is...
Sure, 99.9999% of the world believes that BPM stands for Business Process Management, but to SUN it stands for Business Process Machines - good going. Alright, it is no secret that I think that Sun has screwed up their chance to dominate enterprise computing architectures in the coming years. By fighting the web services trend and running after Java-only platforms and CBD style programming, they gave IBM and Microsoft the keys to the kingdom.
In an attempt to get back in the game, Sun is pursuing a strategy called JBI or Java Business Integration. This venture acknowledges that Java needs more than API's for calling web services, thus the JAX solutions are merely bridges between old and new environments (Java CBD and SOA). JBI, however, is a restating of the problem. It acknolwedges that first order concerns in architectural design are interoperability and integrate-ability.
In their words,
JBI is intended to support the full range of integration solutions,including simple,synchronous point-to-point EAI or more complex B2B business process automation incorporating long-running transactions and complex workflows. However, it is especially well suited for business process automation problems, with the goal of enabling much simpler development of solutions that today are complex and time consuming to implement. Examples of the solutions JBI will facilitate include:
•Self-service customer portals
•Enterprise employee portals
•Customer relationship management (CRM)integration
•Supply chain integration
•EDI replacement
And what will the approach look like?
JBI will support an RPC-oriented Web services programming model as well as a message-oriented Web services programming model,in particular,the constructs of:
•Components as services with interfaces that are publicly and explicitly described by standard metadata,for example,the Web Services Description Language (WSDL)
•Document-centric processing where component services act on standard,structured XML documents that contain both business data and metadata,which provides context for service execution
•Asynchronous communication between components with support for long-running transactions
And the scope is?
The current scope of the JBI architecture standard, as described in the approved JSR 208 proposal, is not to specify how components are themselves implemented. Instead, it only specifies the interfaces they must support for plugging into the JBI environment to use its services and interact with one another to request and deliver services. Thus,JBI is at least initially about system programming interfaces (SPIs)and not about application programming interfaces (APIs), and therefore pertains more directly to those who build integration servers and tools than to those who build solutions with them.
You know, I really like this idea. However, I have this bad feeling that Sun will screw it up. They will likely continue to treat their language (Java) and platform (J2EE) as their primary concerns and treat JBI as an add-on (rather than the other way around). Sun will have to throw away their notion that everything is either an API or is Java P-code and move towards protocols and language neutral interfaces. Lastly, they will have to quit fighting IBM on EVERYTHING. If IBM & Microsoft agree on a new specification, just go along - and win with the implementation. They must stop trying to win the ego battle. Perhaps a tough job for a company run by McNealy.
For more on JBI, see: http://www.webservices.org/papers/JBIwp70903.fm.pdf
In an attempt to get back in the game, Sun is pursuing a strategy called JBI or Java Business Integration. This venture acknowledges that Java needs more than API's for calling web services, thus the JAX solutions are merely bridges between old and new environments (Java CBD and SOA). JBI, however, is a restating of the problem. It acknolwedges that first order concerns in architectural design are interoperability and integrate-ability.
In their words,
JBI is intended to support the full range of integration solutions,including simple,synchronous point-to-point EAI or more complex B2B business process automation incorporating long-running transactions and complex workflows. However, it is especially well suited for business process automation problems, with the goal of enabling much simpler development of solutions that today are complex and time consuming to implement. Examples of the solutions JBI will facilitate include:
•Self-service customer portals
•Enterprise employee portals
•Customer relationship management (CRM)integration
•Supply chain integration
•EDI replacement
And what will the approach look like?
JBI will support an RPC-oriented Web services programming model as well as a message-oriented Web services programming model,in particular,the constructs of:
•Components as services with interfaces that are publicly and explicitly described by standard metadata,for example,the Web Services Description Language (WSDL)
•Document-centric processing where component services act on standard,structured XML documents that contain both business data and metadata,which provides context for service execution
•Asynchronous communication between components with support for long-running transactions
And the scope is?
The current scope of the JBI architecture standard, as described in the approved JSR 208 proposal, is not to specify how components are themselves implemented. Instead, it only specifies the interfaces they must support for plugging into the JBI environment to use its services and interact with one another to request and deliver services. Thus,JBI is at least initially about system programming interfaces (SPIs)and not about application programming interfaces (APIs), and therefore pertains more directly to those who build integration servers and tools than to those who build solutions with them.
You know, I really like this idea. However, I have this bad feeling that Sun will screw it up. They will likely continue to treat their language (Java) and platform (J2EE) as their primary concerns and treat JBI as an add-on (rather than the other way around). Sun will have to throw away their notion that everything is either an API or is Java P-code and move towards protocols and language neutral interfaces. Lastly, they will have to quit fighting IBM on EVERYTHING. If IBM & Microsoft agree on a new specification, just go along - and win with the implementation. They must stop trying to win the ego battle. Perhaps a tough job for a company run by McNealy.
For more on JBI, see: http://www.webservices.org/papers/JBIwp70903.fm.pdf
Sunday, August 24, 2003
Microsoft Changes Group Name
The group that housed the MS web services team was known as GXA (Global XML Architecture). They are now called WSA (Web Services Architecture).
Also of interest is that MS has taken WS-Routing off the list of WS standards they support. This should mark the official death of it, with WS-Addressing superceding it:
http://msdn.microsoft.com/webservices/understanding/specs/default.aspx
Also of interest is that MS has taken WS-Routing off the list of WS standards they support. This should mark the official death of it, with WS-Addressing superceding it:
http://msdn.microsoft.com/webservices/understanding/specs/default.aspx
Subscribe to:
Posts (Atom)