-
-
I have always been a great fan of the offline MSDN Library. I always have a very recent version installed on my PC and promoted it to every developer.
But I've been disappointed by the July 2004 edition twice now. It both lacks the complete BizTalk 2004 documentation (a version is available since march, a decent one since April 2) and the complete Reporting Services documentation (the tool is around at least as long as BizTalk). It means that we have to wait at least half a year between product launch and offline MSDN documentation. I find that unbelieveable.
-
-
I found this visio stencil from the EAI Bible site http://www.enterpriseintegrationpatterns.com great to help describe the problems I'm trying to solve in my current project. It contains 'standard' icons to represent all the patterns, like request/response, message filtering, content based routing, found in the book and on the website.
I'm still looking for a visio stencil to describe the standard elements of a BizTalk 2004 solution, like Ports, Filters, Orchestrations, Messagebox, etc. Anyone aware of such a stencil?
-
-
I recently read this post (second epiphany) from Clemens Vasters about the huge impact Service Orientation will have on the way we look at applications.
That started me thinking and I was just wondering last week, what if the main application we use would look something like this…
All users have a browser based application with three main parts. An inbox, an outbox and a library of message templates. Users can receive requests with stuff they need to do in the inbox, they can act on those requests with some intelligent activity and send out resulting messages through the outbox. They can also create new messages with the message templates. That sounds pretty much like email.
But what if I tell you that the messages and the message template are based on XML. The XML-messages are of course based on schemas and those schemas are tight to functional forms that you can use to fill out the XML.
Imagine you are employed at a HR-department, the message templates might be called like this: HireEmployee, FireEmployee, RelocateEmployee. An incoming message might be based on template called RequestRaise. An outgoing message might be based on a template called ResponseOnRaiseRequest. Next to that, the HR-employee might also have the option to send the RequestVacation message and get a ResponseOnVacationRequest message.
Now let's assume that the inbox and outbox are maintained by some XML-based middleware application that integrates the user's activity with the services available inside and outside the organisation and describes the processes needed for that. So this middleware decides that a RequestVacation needs to go to the inbox of the Employees Manager and the HireEmployee message will either result in a CompleteEmployeeInfo message in some other HR's inbox (f.i. in case of a missing Social Security Number) or an AddEmployee call to the HR Service and maybe even an AddUser call to the IT Service when information is complete.
Sounds very promising, doesn't it? What I like about this scenario are two things:
-
The application is very activity oriented and very flexible. New functionality can easily be added by adding templates or possible incoming or outgoing message. And the user is really asked to do his intelligent work and is helped with that.
-
You can really do this today. InfoPath enables you that create rich XML-based form, Windows SharePoint Services enables you to create a browser-based interface with an inbox, an outbox and a template library, based on forms libraries and BizTalk Server enables you to read from and post to SharePoint-based inboxes and outboxes and describe the processes that binds them. And that's me with my Microsoft-glasses on, but I bet Microsoft's competitors will deliver similar functionality too.
The more I think about this, the more I like it. Of course, it doesn't fit to all applications (imagine to write a document this way ;-), but that's not the point. It does fit for all those business processes that can be highly but not completely automated. An it does it in such a way that we can really decouple UI from Process and Process from Service and create flexibility in every layer.