Web Services Performance (WS-Performance) provides policy assertions that can be used to describe Web service performance characteristics and in particular provides set of metrics for already existing Web Services specifications. One of the most important concerns when composing Web Services is impact on performance of each specification. Therefore if there could be a synthetic indicator of performance impact of each specification it could help to automate estimation of composed Web Services performance and that is the role of WS-Performance to provide framework for such estimations.

This specification composes especially well with WS-Goodness to provide Web services that are both good and of reliable performance and although currently may be a bit slow (as all Web Services ...) but WS-Performance helps to estimate how fast (or slow) they are!

From Don Box talk on Services Oriented Architecture (SOA) presented during XML Web Services One conference (based on article from eWeek):

"Objects are to services what ICs [integrated circuits] are to devices. And we're moving into this world where we want services to be replaceable, we want services to be deployed independently from other parts of the application, and there's a lot of work to be done in this space."

If you replaced services by components in the statement above would it not sound like something familiar?

Maybe the way to look on this is that Web Services becomes uber components: components that are not only distributed but work for internet scale applications.

Xydra is a library that uses servlet to provide XHTML based WSDL invoker. Xydra servlet takes WSDL with XML Schema complex types as input, generates XHTML form to allow user to fill content of input message, gathers submitted input values and converts form name-value pairs into XML message that is sent it to Web Service and then finally displays result message.

One could ask: there are other WSDL invokers so what makes Xydra unique? Here is couple reasons:

• Xydra has pluggable data model and currently two backend to represent form and XML message content One is traditional name-value pairs that are structured into tree (called TreePath) and second that is based on Protege engine to use ontology describing web service to allow more reach constraints and relationship validation (called OntoBrew).
• It is very easy to customize Xydra look and feel: just save auto-generated XHTML page, modify it to your needs and tell Xydra to use this XHTML page as template. What makes it really easy is that template is a regular XHTML page that is used by Xydra processing engine (unsurprisingly called Diesel) to annotate it with runtime information.
• Xydra support complex types and generate nice XHTML form UI for arbitrarily nested XHTML forms.
• You get source code so you can improve it :-)

Sample installation is available online to test drive Xydra. It is open source so anybody can play with it, improve it, and give us feedback, patches are gladly accepted, we may even fix some bugs when reported (good bug report that contains all information necessary to reproduce problem and/or unit test greatly increases chances of getting problem fixed ...)

Time is the scariest resource and it should be treated as the most important factor when considering any task. From interview with Jim Gray:

(...) You see this today. Two groups start; one group uses an easy-to-use system, and another uses a not-so-easy-to-use system. The first group gets done first, and the competition is over. The winners move forward and the other guys go home.

That situation is now happening in the Web services space. People who have better tools win.(...)

However it is also important to not simplify the problem we try to solve or we have something very easy-to-use but useless ...

He also talks about phenomenon of scale when doing software development and I find this estimate quite interesting:

David Patterson: What do you think is happening with databases in terms of open source? What is the Linux of databases?

Jim Gray: I think it's exciting. Very small teams built the early database systems. A small team at Oracle built the original Oracle, and there were small teams at Informix, Ingress, Sybase, and IBM.

Twenty-five people can do a pretty full-blown system, and ship it, and support it, and get manuals written, and test it. (...)

Now the trick is to be where action is and to be part of such team :-)

Talip Ozturk writes about J2EE and Jini and what is relationship between them:

(...)They are not truely competing technologies rather complementary technologies. if you are writing a J2EE server, you can use Jini's dynamic, self healing features. if a Jini service needs to persist data in a way that entity beans does, then the Jini service can make use of a J2EE server to do that. if you are writing JMS implementation, you might want to leverage Jini JavaSpaces technology. JNDI might internally be interfacing with Jini Lookup Service to gain some dynamic behaviour.(...)

I think that distributed computing is changing with advent of Web Services and in particular Grids. The feature may be something like distributed container that is dynamically created from available services (similar to Jini but on Internet scale) that guaranteed to have all required resources such as performance, bandwidth, transactions etc. as described in SLA, QoS, ... (in this respect it is meeting and superseding requirements of J2EE).

Anyway only future can really tell and some technologies seem to stay longer (or shorter) than predicted.

(...)Ok, so let's start to talk about the product: It is about SOAP Services. Actually, they still call it Web Services but in fact, it has nothing to do with the web at all. It is only about SOAP anymore - and it is only about SOAP as a framing format anymore. Frankly, I think that this is a very good thing: using HTTP in your mission critical applications might not be the best idea. Wouldn't it be way cooler if you could just take an XML document, wrap it in a SOAP envelope and send it over whatever reliable protocol you like? While still using all WS-* and GXA specifications?

this desription of WSE2 sounds like what WSIF except that WSIF has support for industry standards such as CORBA/IIOP and does not require to send SOAP envlopes.

However the problem with WSIF that it is only client side ...

In RSS: Promise and Peril Tim Bray talks about use of RSS providing notification mechanism to track state changes of Web services such as credit card transactions, weather, traffic reports, sales tracking, ...

This is very useful but what caught my attention is that by using RSS pull mechanism (or similar approaches that are asymmetrical) we may finally achieve p2p functionality (symmetry) that long time ago was promised with ubiquitous IP address (Internet enabled toaster anyone?). This makes sense for clients behind firewalls and other NATs i.e. majority of Internet users, clients that have no public IP address (asymmetrical web ?). Now the problem is really who will pay for it: how to stream commercials in RSS?

NOTE: this is how i designed event/message notification in XEvents/XMessages, to provide maximum flexibility it is based on pulling events matching filters, and application that is pulling may maintain token to allow to recover from disconnections (similar but more powerful than ETag).

There is a bit of controversy about Web services or Web Services (WS). I believe that we should use non capitalized 'services' in Web services to describe broader set of Web related services over HTTP that existed before all hype of WS arrived and SOAP and friends should be written as Web Services to indicate that this is subset of Web services ...

There is lot that Web Services can learn from "simple" HTTP based Web services and one example is Google Clustering as described in Web Search for a Planet: The Google Cluster Architecture , IEEE Micro, March/April 2003 (Vol. 23, No. 2), pp. 22-28 (local cache)

some good observation: first noise reduction and ego maintenance

Blogs have been compared to newsgroups. It is interesting. In newsgroups there is no "uber" member. Everyone is equal. At first that seems great - however it makes it hard for people to filter out the noise. In effect, a blog gives me control over the "major" content of my newsgroup. I can post anything I want on the front page... anyone can add comments, link to me, etc - but no one else gets to be on the front. In this way blogs appeal to the ego of the blog owner, but also gives people visiting a blog a built in filter.

then RSS as Web Service:

The most fundamental building block of blogs is RSS. I don't know how revolutionary RSS is compared to HTML or TCP/IP, but RSS is the heart and soul of blogs. RSS provides a crude "alpha" XML web service. It will evolve and become even better. Today, RSS gives blogs a way to publish their content in a standard way. Sounds simple. Which is what makes it great. With RSS as a standard, you can now have aggregators that troll hundreds of blogs and extract relavant information. You can extend RSS (being XML and all) and add features like full message content, Doublin Core fields, etc.

but finally is this what i think really matters: publish and forget

One reason I believe that blogs are great for corporation internal communication is the question of distribution lists. Inside of Microsoft we live and die by email. However the constant spam of email to large distribution lists ends up drowning out the important information. For many types of communication (but not all) blogs provide a better way of communicating. There are many cases where you as the publisher of a piece of information don't know who would be interested. Blogs are a way to "publish and forget" - you fire the information out there, and interested people will find it. Once I add our internal blog server to the corporate search service, suddenly I could find people that worked on products that I wanted to communicate with. Amazing.

so blogging is simply next generation of communications weapons in our arsenal (like fire and forget!)

I wonder if anything useful will come out of Back to Basics for Sun Software - interesting interview with new CTO John Fowler:

Q: How do you view the integration of Java with Web services?

Fowler: We've looked at the application server and how people use application servers and Web servers in real markets, and have found that current app-server technologies are not aimed at what most people want to do. A large segment of developers want to develop presentation logic and database-connectivity logic but don't necessarily need all the elements of EJBs. And there's no reason why this needs to be so expensive or complicated.

Will Sun be able to create something small, useful, and lightweight or will succumb to marketing and work on another big piece of J2EE machinery. There are some interesting problesm to solve like JAX-RPC that is heavily RPC and CORBA-ish bend people are now more interested with messaging (so we have JAXM) and XML schema defined types (so we have JAXB) with doc/lit encoding as WS-I wants to supersede SOAP 1.1 Section 5 with enhancements over standard XML schema - at least SOAP 1.1 encodign was self contained - so it will be interesting to see if they ca come with anything coherent that is easy to use and allows real flexibility (like AOP and interceptors) and do not finish heavy code generating and packaging just like EJB (and JSR 109 alreayd shown that this can be done for web services in EJB)...

• we need simple (and working) easy to use workflow engine for BPEL4WS that works on grid (for example on top of CoG API but workflow engine hides that it uses any particular grid toolkit ...).
• WSDL as ultimate URL - but how to find correct WSDL needs for permanent URL and in OGSA it is GSH ...
• different computing paradigms: Java is to java specific so now we replace Java with XML and re-implement Jini -> Gird and Web Services ...
• not to forget (note to myself): why we need components?
  
  reusability and etc is nice but why they are really needed is because only few grid users are grid programmers or computing scientist (TODO: check term) instead we need to provide generic tools such as components (and XCAT!)
• XSpaces needs official release, badly! (another note to myself)
• Noted observation: Grid Spam is grid application that sends (XML) messages/events that are automatically converted into emails ...
• PC + Management = Managewoment ???
• new product besides eCluster, eUtility, eDisaster in IBM family is now eWeSolveYurProblemsForSmallFee <blink> <blink> ;-)
• heard on Oprah: nobody talks about what is happening after the wedding? yeah we need to explore this space too ...

another bright(?!) observation: currently Grid (what is grid? similarly to what is matrix?) is currently funded and evolving around huge computations, huge data mining etc. in other words extension of supercomputers and batch systems.

interesting question: when model with shift to more fine grained grids that are closer to peer 2 peer but still can nicely mesh with Grid (Bigger machines) and grids (more personal, small organization grids).

of course as soon as we get security, resource discovery and access (web service and OGSI should be useful), and mobility issues resolved (firewalls etc.)

Third time makes charm (or something like that ...)

Current XSpaces is third reincarnation: initial version was conceived as class project in distrib. computing class and then second version was worked on internally, this final third version is complete redesign and is based on lot of ideas/experiences learnt from doing SoapRMI events and XEvents that led to XMessages design that is backbone that provides for XSpaces reliable delivery, efficient data retrieval (both pull and push) and robust server design that minimizes state that must be maintained by servers moving what can be moved to clients leaving servers to care only about keeping state (state in XSpaces is essentially backboard or Linda "tuple spaces" though we store any XML and not just tuples)

some other things

APIs that are doing essentially the same things are bad ...

Corba: why PL independent

XML integration ...

components as Web Services will help life easier ...

cost of monolithic applications ... what is API

XML schemas (what is target)

SOAP acronym ... no Simple ... no Object ... so what is left ...

CORBA has no abstract protocol