October 2003 - Posts
Just posting the announcement on the Axis mailing list here:
We are proud to announce the release of Apache Axis C++ v1.0 (Alpha).
This implementation of a C++ SOAP engine provides a stable platform
for developing Web services using C/C++ as well as a client side
library for developing C/C++ client applications. This release
includes the following features:
- SOAP engine with both client and server support
- Partial support for both SOAP 1.1 and SOAP 1.2
- WSDD based deployment with dynamic deployment tools.
- Support for all basic types, complex types and arrays
- WSDL2WS tool for building C/C++ components from WSDL
Server side - Skeletons and Wrappers
Client side - Stubs
- WSDL2WS tool generated wrappers act as RPC Providers and they perform
Serialization
Deserialization
Method invocation
- WSDLs hosted statistically in the server.
- Standalone SOAP server (HTTP)
- Web server modules for Apache HTTPD 1.3 (Linux/Windows)
- Web interface to the deployed services and their WSDLs.
- Sample web services and client applications.
- Supportive documentation for developers and users.
Both binary and source are available at Apache mirror sites:
http://www.apache.org/dyn/closer.cgi/ws/axis-c/
We invite all interested Web services developers and users to
evaluate Axis C++ and give us feedback and help improve Axis C++
to be the best C/C++ SOAP engine.
Man, I really cannot get that sound and chorus out of my head. For the third time within three days I heard at least Don Box sing "All we are saying, is give SOAP a chance" (the first two gigs were together with the Band on the Runtime). Today he and some of the Indigo team chimed into the song together with the crowd attending the Indigo panel discussion at PDC. Especially Doug was very excited about that and thought that a large German non-musician could help in singing ... kinda.
Well, PDC is now over. Close the chapter.
It's a
Wiki and it's full of invaluable information. Topics include Common Questions, Development Questions, Ant Integration, Logging, Attachments, Bugs and Patches, Interoperability, Mailing List, Security, WSDL, Upgrading.
It does not say anything about when they will support which spec, sadly:
http://nagoya.apache.org/wiki/apachewiki.cgi?AxisProjectPages
No, nothing is dead, nothing is deprecated - it is a matter of what to use when and why ... and how! Please burn this into your head. The central messsage again and again regarding the new features and cool things in Indigo:
.NET Remoting will keep working from now till the end of time
- nothing will be deprecated
ASMX will keep working from now till the end of time
- nothing will be deprecated
.NET Enterprise Services will keep working from now till the end of time
- nothing will be deprecated
It is just that the productivity sweetspot is the SOA thing - and this is what Indigo is for.
SoapMail Sample for Web Services Enhancements 2.0 Tech Preview from Microsoft.
SoapMail is a sample application that uses WS-Addressing and Web Services Enhancements 2.0 Tech Preview to enable Web services over email transports.
[...]
The SoapMail sample shows how to send a SOAP message to an HTTP Web service via email and to receive the Web service's response via email.
Be sure to read the whitepaper about how they did it and why WS-Addressing is one of the most important sepcs in WS-* world: Expanding the Communications Capabilities of Web Services with WS-Addressing
Take then, read them ... think! Really a lot of work here at the PDC ... and there are billions of bloggers covering nearly everything. Wow.
Longhorn Developer Center: The Road to Indigo Technology Roadmap
http://msdn.microsoft.com/longhorn/understanding/pillars/indigo/migratevideo/
MSDN Magazine, Don Box: A Guide to Developing and Running Connected Systems with Indigo
http://msdn.microsoft.com/longhorn/default.aspx?pull=/msdnmag/issues/04/01/Indigo/print.asp
Longhorn Developer Center: Indigo
http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/default.aspx
Longhorn docs: Distributed Applications Using "Indigo" Services
http://longhorn.msdn.microsoft.com/lhsdk/indigo/condistributedapplicationsusingmessagebusservices.aspx
Longhorn docs: Choosing Between "Indigo" RemoteObject and Web Services
http://longhorn.msdn.microsoft.com/lhsdk/indigo/conchoosingbetweenmessagebusremoteobjectwebservices.aspx
Steve Maine: Indigo hands-On Labs
http://hyperthink.net/blog/PermaLink.aspx?guid=24c7e74b-6a31-4d03-8760-c72b7fc45740
Benjamin Mitchell: WS-Transaction et. al.
http://benjaminm.net/PermaLink.aspx?guid=38da4e16-d18f-40c2-8ac0-4257dbbbb3c3
Dave Bettin: The System.MessageBus Begins its Travel to Service Orientation Paradise
http://davebettin.com/me/posts/208.aspx
Steve Maine: Indigo and wire formats
http://hyperthink.net/blog/PermaLink.aspx?guid=7e62d706-84eb-4ad0-9250-90c2656f9a01
Drew Marsh: Indigo: Building Services (Part 1) - The Fundamentals
http://weblogs.asp.net/dmarsh/posts/34219.aspx
Drew Marsh: Indigo: Building Services (Part 2) - Secure, Reliable, Transacted Services
http://weblogs.asp.net/dmarsh/posts/34232.aspx
Drew Marsh: Indigo: Using XSD, CLR Types and Serialization in Web Services
http://weblogs.asp.net/dmarsh/posts/34308.aspx
Oh my god, what a mass of people in this room. They actually cannot find enough seats. And is really hot ... no AC?
The session starts about 7 minutes late.
Note: There are differences between M4 and what he was talking about. A Connector is for the 'SOAP dial tone': how to get SOAP messages into and out of an AppDomain.
Concepts: Messages, Services, Ports, Channels
All code runs unchanged on Indigo: ASMX, Remoting, ES, MSMQ, ... if you want.
Messages:
- SOAP, SOAP, SOAP (1.1 and 1.2)
- Full support of SOAP data model
- Support for 'binary XML'
- No reason to linearize SOAP message for in AppDomain communication - fully supported
- It is all about the XML InfoSet, not necessarily angle brackets flying around.
- Message object model: Message and MessageHeader classes
- Body, Header members in Message - similar (really only similar to the object model in WSE 2.0)
Port and Channels:
- Ports are location in network space. Rendevouz point between my code and the outside world
- Ports as a factory for channels
- Messages flow through a port via channels
- So nothing new here - just a few simple but essential design patterns applied in Indigo
- Transport channels are the first (service) or last (client) channel in a stack
- Extensible channel stack (compare to Remoting architecture)
- Object model: Port, IChannel, IOutputChannel, IInputChannel, IDuplexChannel, IRequestChannel, IReplyChannel (the last two for request/response pattern)
- IDuplexChannel for building a 'dialog channel'
Services and Addresses:
- ServiceReferences are used to identify message recipients (based on WS-Addressing), absolute URI of service + fixed headers; essential concept for Indigo
- ServiceAddress for a relativr version
- Map ServiceAddress to in-memory object with IService interface
Shows a demo - code won't most probably not work with the PDC build
- able to specify the policies in Port.CreateListenerChannel() - e.g. RM, security, Tx, ...
Hosting:
- Services can be self-hosted or activated on demand via ASP.NET
- Shares activation with ASP.NET process model
- .msgx files implement this (.svc in Beta 1)
- PDC build somehow limited re: hosting in ASP.NET (only low level messaging apps)
- But Indigo is not tied to ASP.NET and HTTP!
Service model:
- Integrates ASMX, ES, Remoting
- Message based and method based programming (similar to WSE) supported
- First class WSDL support
- Session supported (compare conceptually with HTTP session or COM+ ObjectContext)
Defining contract in a service:
- Service oriented programming model; use [Service] and [ServiceMethod] attributes
- Opt-In contract
- Schema-based integration
- Broad interop - already tested or in theory?
- Several interop modes: BP 1.0 compliance mode, pure HTTP 'legacy' compliance mode, ...
- You can support common assemblies between the endpoints (sharing the code assemblies betwenn the communication partners)
- Code first and contract first supported
- Great support for this: [ServiceContract] - can only be applied to interfaces
- But did not mention tool support to generate code interface 'skeleton' from WSDL et. al. ...
You can use RPC, async or message based programming model - just what you want
.NET Remoting-like programming with [RemoteObject] approach:
- No interop, CLR focused - just between two CLRs
- Still MarshalByRefObject ... for the goofy internals things going on
Building a pipeline of code before sending and/or receiving messages made easy.
What to do now? Use ASMX to prepare for Indigo and leverage ES inside your services. Use .NET Remoting only if really necessary ;-)
Details following in the other talks ...
Sidenote: The demos were not the best, sorry to say that ... somehow the talk was perhaps a bit too 'complicated' and confusing (?) for most of the people in the room. Would have been better to show it more on a 'VB level' to illustrate the SOA approach in Indigo?!
Here are some picture of LA and PDC 2003. Enjoy! If you have questions re: the pics, shoot them in the comments.
For those non-German speaking readers: don't mind about the German words on the page ;-)
Combine best of web, best of Windows developer experience
Parts of the demos show functionality that has been around for years with Flash, PDFand the like. Will there be a major platform lock-in in the future (read: it only works on Longhorn and above)?
XAML:
- one-to-one correspondance with object model
- enables interoperation between UI authoring and dev tools
- 'just' a persistence format for .NET classes (majorly UI related)
- code behind for Windows apps
Puh - it is a hard talk to listen to. Very introductory level, not much details. Quit just 15 minutes before the end ...
More Posts
Next page »