You have a good software product, so why would you make it SOA compatible?
You may want to do this to provide a looser coupling between your data services and your application layer. This will give more flexibility to reuse the service components for other products and allow you to change the underlying service architecture if need be without the need for your application to even know about the change.
Having said all that, I would first want to have an actual business use case that warrants making the switch before making the change. Changing simply to keep up with the latest buzzwords is just a waste of money. If you're starting a new project, however, you may want to consider a service-based architecture if it makes sense for your application.
In my opinion, only one good reason: you need interoperability between different platforms or technologies. Otherwise, save yourself a lot of grief and "just" make a well-mudlarized architecture - tell your boss it is SOA if that's what he wants to hear. Don't do it because you might move to or use other platforms in the future - you don't have an interoperability problem yet.
If you want your product to be integratable with other applications and your customers have actually voiced this wish / requirement then I would consider it, but otherwise it might be a big waste of time and money, especially if doing it might cause some lengthly architectural refactoring to make it work. But with no clear reason, it probably doesn't make sense to follow a trend just because others maybe doing it. Your customers will let you know when this is necessary.
That's a very difficult question to answer without more detail about your "good software product", but speaking in sweeping generalities:
If you implement an SOA scheme on your product, more developers will be able to consume the API services provided by your product because web services work across almost any development platform.
If your product is already a web application that publishes certain data, you might discover that you have readers/consumers of your data that are interested in doing analysis or building additional applications that you never thought of or may not ever have the available time to build.
The fact is: you don't need to.
SOA structure is very complicated to achieve. It requires care and organization style that I believe most companies will not have. (I'm glad if yours has such organization).
Tomas Erls talks about Contemporary SOA and Web Service First Generation. WS-I is the traditional web service style such as asp.net web services. Actually this traditional web services doesn't mean any service oriented; And what happens is people build simple web services and call them SOA.
Contemporary SOA, I believe, is an entire system structured based on services. Inside this "ecosystem", services would call each other to perform some tasks.
SOA analysis is painful and you need care. To build an ecosystem like that, you need to be prepared from the first moment.
Engineering service interfaces (contracts) is also paradigm. If you put some Lean Thinking at your belt, you should cut some desire to make state-of-art design.
If your system already works, fine! If someone will need integration in possible future which you don't know yet about it, don't do it now. But if your system is born to be consumed, them you think about it.
Best
Related
I was recently discussing with colleagues a push toward disciplined n-tier structure for our web application. It struck me that I couldn't think of any alternative.
Is it always the case that one should seperate out web applications into layers?
An alternative to the traditional N-tiered architecture is the Command-Query Responsibility Segregation (CQRS) architecture as discussed by Udi Dahan.
Like all architectural decisions you should really think about when to use it as discussed here
Personally, I tend to see a lot of "over architecture" in my software travels which can really over complicate matters and make things much more difficult to maintain and obviously cost a lot more too. You really need to think a lot about the business problem first rather than just picking an architecture.
Keep things as simple as possible for best results and easy refactoring.
Is it always the case that one should seperate out web applications into layers?
You should separate different logical parts of your system to avoid them being tightly coupled which turns makes them and more reusable. Into what you separate them is not really that important. You can call it layers or whatever.
Actually there could be 2 meanings of those layers:
Physical boundaries: client browser, web server, web services server, backend database, ...
Logical boundaries: GUI, service layer, DAL, ...
You might also take a look at the Onion Architecture. But onions still have layers :-)
It is highly recommended to read Microsoft Application Architecture Guide, 2nd Edition.
Then, you'll realize how important that separation is for every site which is anything more than 2 simple web pages or so.
It is a thorough guide that explains every layer's roles and responsibilities and how they all play together in a robust & scalable application.
You don't have to read it all, but for the beginning take a look at Chapter 5: Layered Application Guidelines.
There is an alternative "pattern" to Layered Architecture.
But it is the anti pattern that the Layered Architecture is trying to solve. Namely the "Big Ball Of Mud" :)
What do people consider scalability? I've always hear people talk about writing scalable apps. But as a developer, I've never really saw any pointers/tips in an article that normal developers dont know. Such as caching db calls, etc. Mostly what I see are options that are configured by system admins or anyone dealing directly with the servers.
So my question is, from a developers perspective, do we really have much effect on a website's scalability? If so, could we be pointed towards articles that aids us on the .net framework. (ASP.NET MVC)
Also, do we have to write our apps differently if we were to accommodate adding new hardware, such as another webserver. (or is it the same app, but more instance of it?)
You can maybe gather some input from here on SO:
What does scalability mean to you?
Engineering scalability into an application
Design Patterns (or techniques) for Scalability
There is the requirement, to write a portal like ASP.NET based web application.
There should be a lightweigted central application, which implements the primary navigation and the authentication. The design is achieved by masterpages.
Then there are several more or less independent applications(old and new ones!!), which should easily and independent be integrated into this central application (which should be the entry point of these applications).
Which ways, architectures, patterns, techniques and possibilities can help and support to achieve these aims? For example makes it sense to run the (sub)applications in an iframe?
Are there (lightweighted and easy to learn) portal frameworks, which can be used (not big things like "DOTNETNUKE")?
Many thanks in advance for you hints, tips and help!
DON'T REINVENT THE WHEEL! The thing about DotNetNuke is that it can be as big or as small as you make it. If you use it properly, you will find that you can limit it to what you need. Don't put yourself through the same pain that others have already put themselves through. Unless of course you are only interested in learning from your pain.
I'm not saying that DNN is the right one for you. It may not be, but do spend the time to investigate a number of open source portals before you decide to write your own one. The features that you describe will take 1000s of hours to develop and test if you write them all from scratch.
#Michael Shimmins makes some good suggests about what to use to implement a portal app with some of the newer technology and best practice patterns. I would say, yes these are very good recommendations, but I would encourage you to either find someone who has already done it this way or start a new open source project on codeplex and get other to help you.
Daniel Dyson makes a fine point, but if you really want to implement it your self (there may be a reason), I would consider the following components:
MVC 2.0
Inversion of Control/Dependency Injection (StructureMap for instance)
Managed Extensibility Framework
NHibernate (either directly or through a library such as Sh#rp or Spring.NET
A service bus (NServiceBus for instance).
This combination gives you flexible user interface through MVC, which can be easily be added to via plugins (exposed and consumed via MEF), a standard data access library (NHibernate) which can be easily configured by the individual plugins to connect to specific databases, an ability to publish events and 'pick them up' by components composed at runtime (NServiceBus).
Using IoC and DI you can pass around interfaces which are resolved at runtime based on your required configuration. MEF gives you the flexibility of defining 'what' each plugin can do, and then leave it up to the plugins to do so, whilst your central application controls cross cutting concerns such as authentication, logging etc.
I am working in a company with huge DotNet team. We currently have MOSS 2007 license which I assume is a costly one and just one administrator working/maintaining all Sharepoint stuff.
I felt that Sharepoint is not being utilized to its potential. Being interested in Sharepoint Development for past 1 year (I am a .NET Developer with 6 years of exp) I offered my help to our Director, his first question was
"Why do I need a Sharepoint Developer?"
Now I need help in selling a "Sharepoint Developer" to my director.
I would be glad to provide any more information you need about the company or current utilization.
EDIT: Just want to elaborate more on my company's scenario. We have sharepoint being used mostly for Internal use like Raising Service Tickets, Maintaining Networking Stuff ( Servers, Sites, clients details), Document Sharing with Clients.
If you want the official “value proposition” of SharePoint, it goes something like this; the product already has a lot of common application behaviours built into it (doc management, access control, search, etc) therefore it streamlines development by being able to build directly on top of these features rather than building them from scratch. It’s a .NET based environment so your current developers can leverage existing skills.
However, it’s not all that simple. There’s a very solid learning curve, you need to develop directly on a Windows Server and the lifecycle and deployment of apps if very different to ASP.NET. Have a read of What are your biggest complaints about Sharepoint? and also The hidden costs of building on enterprise software platforms.
Ask him how much time your team spends coding/planning/worrying with:
Authentication
Security
Document Management
Versioning / Change History
Records Management (on a very light sense)
Backup / Restore support
Load balance
Multi domain support
Separated Content Databases
Content Collaboration and user-created structures
Theme support
Syndication
Outlook integration
??
And how much time you ACTUALLY worry/code/plan implementing your BUSINESS RULES
SharePoint is far from perfect, but in a .NET world it is a hell of a good start to get things done without reinventing the wheel.
Why do you think you need a sharepoint developer? What can more/better sharepoint development offer from a business perspective? Does it do thinks either faster, cheaper or better than you currently do them? You need to be able to verbalize this for management to buy-in.
Does the existing administrator have a technical background? Perhaps as a developer? If not, then yes, there is value in having a "Sharepoint Developer" handy as soon as you want to do anything even remotely outside the box in SharePoint.
Want to extend the functionality of your lists/libraries? You'll need to know how to create a CustomAction in .NET, or know how to combine JavaScript/JQuery with ASP.NET webservices to do so.
Want to create some custom rollups for reporting? Do you folks track tasks/project information in SharePoint? You'll need to understand ASP.NET server control fundamentals, and possibly XSL so that you can whip something together using SharePoint designer.
Maybe you want to standardize your content (calendars, tasks, etc.) through custom content types. You'll need a development background to understand how to provision this using SharePoint's solution/feature mechanisms.
Or perhaps your director would be interested in reporting? If you pick up a third-party reporting tool such as Dundas Charts, good luck making anything remotely complex without having a development background.
These are just some things off the top of my head..
Point out the business benefits that your company would IMMEDIATELY derive by doing / going Sharepoint. In your spare time at the office, create a proof of concept perhaps that you could parody with your director in able to get his/her nod.
As someone who once was a sharepoint developer, it is hard to add value to that product. It will mostly be cosmetic changes or something you find to be really cool, but at the end of the day SP already provides the functionality. Also if you do something amazing with it M$ will eat your lunch.
I worked on MS CMS (which preceded MOSS) and the people who stuck with MOSS are earning good money - but proving business benefits to the skeptical is very difficult.
To sell yourself to your director you need to demonstrate that MOSS will either save the company money or help generate extra cash. From your brief company description I would reckon that cost focus is the way forward.
So ask your boss what are the three biggest cost savings that your company wants to make in the next year (there is always a focus) and (if you think it is worth asking) the three areas where the company is looking to expand.
Then go away and work out how MOSS (or any enterprise level CMS for that matter) can support and possibly improve the chance of meeting these objectives. If you can do that and present the director with some focused, manageable projects then you may be on the way.
I have a web application that is arranged into data, business and UI projects. As the system evolves changes are deployed by building all three projects and deploying them in one package. This has worked well and has allowed the illusion of “three tiers” without tackling the communications, versioning issues of truly separate systems.
So along comes a request for XML summaries of some of the data and my thoughts turn to a fancy WCF service that, one day, could be my “Web API” (ahh… the mind.. what a evil little monkey it is). So, assuming this survives the “is that really the best idea?” test here is my question:
What structure have you had the most success with when posed with two
evolving “clients” serving content from a single evolving “model”?
James, your question is rather board as there are a large number of variables that go into choosing the right type of architecture for your needs. I would recommend reading the patterns & practices Application Architecture Guide 2.0 to better understand the options and pick the best one that suits your individual needs.