I am undergoing BizTalk server training in my company.
I have almost 6 years of experience in both Microsoft and Open Source like PHP mostly in web applications.
Does it make sense to learn Biztalk server for my future career?
In short Will it help me to improve my profile?
Please advise/suggest.
Learning anything that is an active and vibrant technology will help you and your career. I don't see how this could be qualified as a negative in any aspect.
Even if this particular product goes out of use, it's useful to understand the problems it is intended to solve and the general approach. Don't get too hung-up on details though.
You may want to look at New Features in BizTalk Server 2009. It's not dead yet.
i have been doing BizTalk server development for years and it has most certainly helped me be an early adopter of the SOA / Contract first / Loosley coupled application fad that is sweeping through the industry ... why? well because as BizTalk developers we've always done this stuff. it aint new to us.
so yes, learn it. it can't do you any harm at all!
Related
A friend of mine asked me to take a look at using Flex Licensing to protect the distribution of her software. I've spent a bit of time going through the flexera website to see what information I could glean, but I find nothing that tells me how one actually connects their software to the licensing system. Is it an API that allows me to build the functionality into an application? Is it something else? I decided to not put too much time into getting frustrated before asking here if anyone had any experience with this or similar licensing systems.
Regards and thanks!
To answer your question, yes, there is an API.
You can request a trial of their FlexNet Publisher Software to see if it is something you would like to work with. However, I would recommend you contact them to see if their pricing model would fit into your friend's development budget.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
How should an experienced .NET & SQL developer go about becoming a BizTalk expert for a project starting in 1 month? How should I spend my limited time to gain some practical skill & knowledge in BizTalk so I can "walk the talk"?
I am self employed, and would not be willing to spend more than USD300. I have the book "Professional BizTalk Server 2006" by Wrox, but have not found it to be a particularly good learning resource (very dry, needs more real world examples).
The BizTalk Virtual Labs in MSDN are a pretty good place to start with. Pluralsight also has several good BizTalk courses, and their online subscription isn't too expensive; would likely be a good option.
I agree with everything written this far. All solid info.
I have a few addons, coming from a fellow freelancer working with BizTalk since 2002:
Unit testing.
It's not easy to do, but check out BizUnit. A Codeplex based toolset written and maintained by Kevin Smith. One of the early BizTalk heroes :-) http://bizunit.codeplex.com/
Deployment / getting things into production
But also keep in mind that none of the day to day development stuff will prepare you for the part of the project where you have to deploy the app and make sure that it is "manageable" by operations. This can be quite complex, and is a topic in it's own right.
Check out Apress Pro BizTalk 2009, it's got a decent (IMO) chapter on this.
The entire development process around BizTalk.
The first two chapters of the same book will give you a good impression on what a BizTalk project is about. Where to use it, and where to not use it, how to organize projects, and name your stuff. Really a good collection of info that you would only get by reading 5-6 years of blogs back in time :-)
And one last thing. Depending on the roles on the project, you might be asked to optimize and tune BizTalk. And if they don't ask you. Make sure that you ask if others have done that, because you have to do it. BizTalk should always be tuned towards what it is supposed to do. Low latency vs high throughput, tuned according to hardware, correct setup and config of network around the SQL boxes, etc etc etc. This can be hairy stuff, and you should be careful not to jump into it before reading up on it all. But it's a subject we as freelancers are often expected to be able to deal with ... so thought I might bring it up.
Example ... BizTalk x64 processes on an x64 box runs really bad out of the box, actually worse than on the x86 processes. The 64 bit processes need to be tuned to really use all the MEM that are availble to them.
Anyways ... a bag of mixed tips and I hope you can use some of them! And good luck! It can be a tough start, but if used right, BizTalk can be a great product/toolset.
And remember .... if it is ugly, or hard, or both. You are doing it wrong. And don't be afraid to dive into .net code, and bolt it onto the BizTalk box. We all do it ... some just won't admit to it :-D
Start with the advice of tomasr.
Then, try and build something as real as possible. Biztalk is the kind of product where everything seems fine when you read the book and follow the examples, then you sit down to do something and you are thinking "what do I do now".
As per Thomas and Shiraz - set up an environment and get your hands dirty. If you haven't done so already, download and install BizTalk Server 2010 Developer Edition
But just to temper your expectation, IMHO expertise in BizTalk (or any other EAI / BPM / ESB product) can take years to accumulate.
It isn't clear whether you are developing for a client with an established BizTalk installation, or if this is the client's first BizTalk deployment. If so, one thing not to be underestimated is that the operational considerations of running a production BizTalk environment (performance, redundancy, reliability, auditing, tracking, monitoring with SCOM etc) are as complex as the development and testing - but understanding of this will be important to 'walk the talk'.
W.r.t. dev, start with some a simple EAI type mapping project, and then work your way through the SDK samples progress to some common messaging patterns (e.g. batching with aggregator), and then move into the BPM type orchestrations. You can probably leave BAM and the BRE for later.
Good luck!
+1 to tomasr for mentioning the virtual labs. Getting hands-on is definitely the way to go, as Shiraz Bhaiji also mentions. Hopefully you're not starting with BizTalk 2006, and can go with the latest: 2010. If that's the case, you can get the Developer Ed. of BizTalk 2010 for free now (see link from nonnb).
I'd also recommend Richard Seroter's book: 'SOA Patterns with BizTalk Server 2009' (available on Amazon.com). There are many ways to do the "wrong" things with BizTalk, and this book does an excellent job of walking through both the how and the why of building BizTalk solutions (with the code samples available from the publisher's site). And yes, it pretty much takes a whole book to go through it all. It's a good (more readable) companion to the Pro BizTalk 20xx series (which is generally better for very specific questions/tasks).
I've been recently tasked with leading an effort to improve our input (and output) validation with OWASP recommendations and PCI compliance in mind. In the process, I'm trying to assess the value of the ESAPI.NET project which does not appear to have seen any activity since the spring of '09 and as it stands is incomplete.
Does anyone have experience using or extending ESAPI.NET v0.2? Is it a good starting place today for building out an infrastructure to address the targeted vulnerabilities?
FYI: I am looking at MS AntiXSS which, of course, only addresses a portion of ESAPI's scope. We already do a good job with SQL injection though there are improvements we need to make.
(If someone wants to create an ESAPI tag, feel free. I don't have the mojo.)
Looks like there were a couple updates last week: http://code.google.com/p/owasp-esapi-dotnet/source/list
You might contact one of the project leads on that list to ask what's going on.
NOTE: 05/26/2012: the last update on that project was dec 4, 2010. Yes, it is dead.
It looks like ESAPI is dead period. There's nobody using it, there are no questions, no forums, no information, nothing. The listservs (what is this, 1996?) are barren too. The documentation is terrible and the samples in the swingset don't work (server that installs is HTTP not HTTPS, and no transactions can be made in HTTP mode).
Seems to be a dead end project.
The project itself seems dead there are however some people who maintain a github copy with several (minor?) additions...
https://github.com/haldiggs/owasp-esapi-dotnet
https://github.com/jstemerdink/owasp-esapi-dotnet
A friend wants to start a dating website, she wants me to help her. We still haven't discussed on what platform it'll be developed, but I'm thinking she'll suggest LAMP to save a buck (which is one reason already to chose over ASP.NET already). If the dating website does well, it'll potentially hold a large amount of data (I'm not sure if this would be another reason to consider either ASP.NET or LAMP).
Anyway, I ask this from an ASP.NET developer point of view. I have very little, almost null experience with LAMP, and I don't like it very much either, so if she decides to go with PHP odds are I won't help her. So what would be some good points to bring up when deciding which platform to develop on?
Please be objective, I don't want this to be argumentative or anything, try to stick to facts, not opinions alone.
Thanks!
What generally matter in that kind of choice is :
How much time will it require ?
How much money will it cost
Which is often linked to the time ^^
If you have a lot of experience with .NET and none with Linux/Apache/PHP/MySQL, choosing LAMP will mean that you'll need much more time : a whole lot of new stuff to learn.
It'll also mean that your code will probably not be as good as it would be with what you know.
After, the question is : do a couple of week "cost" more than a few licences ?
Only you and her can decide, there ;-)
If LAMP makes you queasy, you can try ASP.NET over Mono.
IMO the only good reason to move away from a programming environment that you are already experienced with is the one you already mentioned: cost.
You would use LAMP specifically to build appliances. If you're not building appliances, the software cost for ONE server is marginal, and is not worth the tradeoff for moving to a totally different development environment, IMO.
I think the first question is: Which is the target programming language and environment that you have experience with?
Imagine the site will become a success - how do you scale then? LAMP can scale, and so can WISC, but in both scenarios you need people who actually know the environment and who can secure it. If you don't know Linux and MySQL and PHP, how are you going to scale and secure it?
So even though LAMP may be significantly cheaper (The SQL Server license is the heavy part in the WISC stack), after the first hacker attack or downtime, that initial savings may seem marginal compared to the damage.
The other thing is of course the PHP vs. ASP.net/C# decision. If you don't know PHP, then it's a decision of "Not having the application at all" and "Having the application on an expensive stack", unless your partner of course decides to hire someone else to develop that.
Technically, both have their pros and cons, but there are huge websites built on both stacks, so it really boils down to "Which platform can you reliably/comfortably setup and maintain?"
I agree with Pascal. Go with what you feel comfortable with in completing the project and don't forget that YOUR TIME EQUALS MONEY. You have to put a $$ value on your time. LAMP may be cheaper up front but if it winds up taking 1000 extra manhours, then suddenly it's more expensive.
Also take into account the lost opportunity cost in not being able to bring something to market b/c you chose a technology you were not familiar with.
At the end, if the plans are for this to be a business that is successful, the cost of using ASP.NET should be negligible or else I would question the seriousness of the effort.
One argument for the Apache/MySQL/PHP stack is that it's available on most major platforms (Windows/Linux/Mac/BSD/...) and most webhosters provide it as well.
You also find many (as in "huge amounts") of good tutorials, books and other educational stuff about PHP/MySQL.
Apart from that all tools used in the LAMP stack are free (as in "free speech" and also as in "free beer"). ASP.NET is still a proprietary technology owned by Microsoft. I'm not a huge open source fan, but knowing that your tools will remain free to use in any way you want is quite nice.
Of course, if you have no experience with PHP at all and much exp. with ASP.NET it's easier for you to stick with ASP.
If your comfortable with Microsoft products there's nothing to stop you from developing code in .NET and using a free database (however you may need to find/develop a custom database adapter if you are not using free versions of SQL server or Oracle). If you are generating a lot of traffic you can swap out the data layer of your code and invest in a better performing database.
Time costs money and if you can develop a better product both from a user and maintenance/performance perspective it will serve you better in the long run.
Some hosting companies include the OS and flexible contracts so I would make fit from your prespective. The market's pretty competitve for that type of site and there's no point throwing a lot of money at it until you get some useful metrics for your site IMO.
The short answer is: it doesn't matter, unless the site is going to do something so amazingly different that one technology is obviously better suited. And I can't think of anything like that off the top of my head.
A big red flag is: if your friend is concerned about the extra $5/month for asp.net hosting instead of LAMP hosting, then you're probably not going to get paid. Ever.
Caveats aside, be realistic: what is the immediate goal? To get something working, or to design something on the scale of plentyoffish.com or facebook.com? [Facebook.com has about 44,000 servers at the moment]
So, what are the chances of your friend's dating web site exploding to the size where scaling is a concern? For most sites, the answer is "very close to zero" - because of the marketing effort required to drive that much traffic.
Now, what is the revenue stream? Is there any expectation that you will get paid to do this? Do you think the site will be profitable? Is the project fully funded?
Friendship is great, but don't let that keep you from asking the appropriate business and client-relationship questions. One sure way to ruin a friendship is to do some work for free and/or without thinking through the full extent of the project. Far too often, you think it is a one-time favor, while they think it is your job!
LAMP is only cheaper until you read the fine print. It's not better or worse technically, just different.
The WebsiteSpark/BizSpark programs will get you all the Microsoft software you need to get started, free for three years. If price is her driving concern, point her to those programs if she's willing to consider the ASP.NET platform.
Hosting will cost a fair amount either way, because for a full-service website you don't want to go shared. You'll need at least one dedicated server to support a dating site. The OS and database will be free either way if you go with one of the *Spark programs I mentioned.
As a small startup company you can get a free 3-year MSDN subscription (well, you have to pay $100 at the end of the 3 years). If you think .Net will be more efficient and this website will make money, seriously consider BizSpark.
Since you are looking for dating site, check out Markus Frind of plentyoffish.com he is running the largest dating site on .net platform with asp.net and sql.
My company (a large organization) is developing a "road-map" for evolving their rather old, tangled confederation of systems to an SOA model. A few people are pushing hard for using Websphere Integration Developer and Websphere Process Server as the defacto platform for developing future applications...because they feel IBM is a stable vendor, the tools are made for the enterprise, they drank the "business agility" BPEL kool-aid, etc.
Does anyone have positive or negative thoughts on this platform? Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
My experience with the IBM Java tool set is pure pain. Days to install lots of different versions of different components all incompatible with each other, discover a bug in component A get told to update to see if it fixes, updating component A breaks component B and C, get told to update these etc.
I find Eclipse with out the IBM extensions far more stable and quicker and provides more features (as its stable versions are a couple releases ahead of WID/RAD).
I would advise against going the IBM way for development tools. As for process server I have less experience but the people in my team using it seemed to enjoy it as much as I enjoyed WID. not a lot.
So far I havent been impressed by any tools with the "SOA" and/or "BPM" labels on them. My "roadmap" would be very very iterative to see some results with the archetecture as fast as possible while trying to grab some of the easy fruits. That way you gain your feel for what works for you and your people.
I would never let any vendor push me anywhere in the "scuplturing" of the architecture.
I agree with other users complaining about WID. The only reason we are using WID is that a decision was made a while back to use IBM products across the board by our sales department.
That's right, our sales department made the decision to use IBM products.
Development has been painful and frustrating. We have lots of stability problems with Process Server, sometimes it doesn't want to start or shutdown properly. Yeah you can easily draw processes in the IDE, but most any toolset provides that functionality these days. It is nothing special or unique to WID or IBM. IBM is a few iterations behind mainstream.
There are plenty of open source implementations out there that offer great support. Checkout JBoss or RedHat, they are pretty good. If that doesn't float your boat, you can always use Apache tools.
Walter
Developers don't choose WID, WMB, or WPS. Managers do, because IBM is a "stable vendor".
Look at JBoss, or K.I.S.S.
WID/WPS is actually pretty simple. The original intention was for analysts and business people to "compose" services (DO NOT LET THEM DO THIS!) so the UI is simple and easy.
Most of the work will be in defineing and implementing the back end services which depending on the platform will mostly involve wrapping existing code in SOA service.
The most important thing to bear in mind is that SOAP is technoligy and SOA is an architecture and a state of mind.
There is a zen to a succesful SOA implementation. Its all about "business services", if you have a service that you cannot describe to a business user in less than six words you have done it wrong! Ideally the service name alone should be enough to describe the functionality of the service.
If you end up with a service called "MyApp.GetContactData" described as "get name, addresses tel fax etc." then you are there. If You have a service called MyAppGetFaxNoFromOldSys" described as "Retrieve current-fax-nmbr from telephony table in legacy system" you are doomed!
Incidently most of the Websphere tooling for WS* is pretty nice. But I would recommend the very wonderful SAOPUI tool from http://www.eviware.com which is very good for compsing/reading WSDL based messages and also function as a useful test client or server.
Do the GUI tools help eliminate monotonous/redundant coding...or just obscure things and make things harder to maintain? Basically, do the benefits justify the complexity?
As a Developer, I find the tools at varying levels of being bug free. 6.0.1 was a pain, 6.2 is so much better. But once you develop with the tool, there is minimal effort to maintain it. I develop in hours what java developers take days to do. It is also easy to maintain as changes can be made very quickly. I cannot answer your question from the perspective of an architect or a Manager but i would agree with comments of some others here.