Okay, maybe this is just my “rookie” strongly typed dataset skills showing but why is it such a pain in the ass to map hiarchial schemas to datasets? I have this wonderful schema that I designed for the online donation site. I wanted to move data around from place to place using a dataset. (note: I am not trying to ignite the dataset vs. custom classes/ilist debate here). I chose datasets and that's that. However, when I got into trying to use xsd.exe to build the custom dataset wrapper class, it chokes on any nested complex type that has the same name.
Now the thing that drives me nuts is that it takes out the option of using user-defined complex types in the schema. For example, if you have a type that defines say an address block. If you keep the types simple in the block, life is good. However, if you add anything that makes the elements within the block complextypes you are screwed. I added an attribute of ID for the element so I can store something like the “City” and the “Id” that corresponds with that database value. Once you do that, the City element becomes a complexType and xsd.exe will map that to a DataTable and as everyone knows a dataset cannot have two DataTables with the same name. If you use the AddressType which defines City on another element that you want to be of type Address....Poof! It explodes.
Now, I know that I could write my own class generator. I really don't want to deal with doing that. I hardly have enough time in the schedule to use the restroom. I hope that they build on xsd.exe in 2005, and make it a little smarter when it comes to creating these classes.
It didn't take long for me to realize that our new house is not ready for children. Now, let me clearly state that I do not have any nor are in the process of having any. I do want them, we are just not quite ready for them yet. Enter my brother in law, his wife and my two beautiful nieces.
When they arrived the first thing they went for were the glass vases and picture frames that my wife has on tables low enough for them to reach. Yikes!!! What's this? Does it make a sound? What happens when I throw it on the floor? Oh boy. We failed to make the house child safe.
This reminds me of what its like when a project begins with a group of eager developers. What tools can I use? I don't have to design, lets just build? What happens when I do this? Lets just build it and see what happens! This is what happens when the house is actually the development department and management and lead developers have just not made the environment developer safe.
Watching the NBA Finals, I am numb to the fact that American TV has gone down hill so fast that Mark Cuban has a reality show. The concept: Give someone a million dollars by playing a game that has no rules.
:o Please shoot me in the face.
So when does the next Survivor start?
We (Amercian Red Cross) recently spent several months deciding and implementing a broker for ecommerce transactions for the enterprise, lovingly name TQE or Transaction Queing Engine. I know...I know...really original. One thing that I am actually not taking credit for. Basically this system allowed any application that wished to publish transactions to the broker using the correct schema process a credit card or some other finanical payment. The first two clients for this broker are two very different applications.
The first is the Online Donation System. This system is a .Net application with an ASP.Net front end a .Net Windows Service running in the background. The second is a J2EE based Health and Safey Course scheduling application. This system runs on Weblogic and communicates with our PeopleSoft implementations. Both of these applications must send credit card transactions to TQE for processing. TQE then makes external calls to various gateway systems for processing and internal systems for logging, etc.
After spending a good deal of time meeting and meeting and meeting about meetings, we decided that this was the perfect fit for a service based application. Each step in the process made sense as a service. And that this was not your typical spoke and wheel scenario. That each application would post messages to endpoints as necessary and not necessarily be tied into the system.
So how do you build this thing?
That was the magic question. We orginally went the Microsoft route with Biztalk 2004 (Early adopter program). that had great promise and was going very well. We had awesome support from Microsoft and our internal development team. No worries...right? We would have be able to leverage all the greate SOA features that BizTalk provided. We could expand the services using Web Services and other components. All written in any language that supports SOAP. Sounds too good to be true...
Well, shortly after getting things rolling our Archicitecture commitee decided that BizTalk 2004 could not be used due to the fact that it was not released yet. Don't get me started on this one. BizTalk 2004 has been released for 4 months now and we are still not in production.
So enter Sonic. Sonic ESB and Sonic MQ. If you are not familiar with Sonic, its a company that is focused on Enterprise messaging and the Service Bus concept. They have been out of the gate for a while now with SOA.
Okay, to make a long story short we used Sonic, wrote Java service containers and functions and have been struggling to implement the thing for the last 3 months. And how do the ultimately interop with our ASP.Net app? Through http acceptors. Not even standard SOAP protocol. Just plain ole' http posts. Craziness...
Thank goodness our Architecture Commitee is out there to protect us.
Well, if you missed TechEd 2004 this year than you had better save your pennies for next year. This year was packed with 2005 stuff, which lets face it, is what is truly interesting at this point. You already know .Net, you just want to know how to do it better, faster and more efficient.
Well what with what I saw for ASP.Net, WinForms and Testing in VS.Net 2005 all of your dreams will come true. Now don't get to excited, its still a bit off. However, we got the beta bits in hand and I am sure that production 2.0 sites will start rising from the ashes.