Could anyone tell me what steps are required to make a good start-up service oriented architecture for departments, example language department?
Actually, i've mastered much better in PHP codeigniter, JQuery and AJAX. But, i still learn about Codeigniter for e-commerce
Expected output: To give the best result once the web service is developed
First, I am sorry that your question didnt catch up. Perhaps I suggest you should re-formulate the question.
SOA as such involves some initial strategic effort to achieve a good service oriented design and a stable implementation plan. Please refer to the SOA MAnifesto to get an insight of the defined service orientation principles and the outcome of SOA as an application of the principles to help organization achieve agility, return on investment, increased federation, reduced IT burden and a standardisation of business logic.
the second paragraph has nothing to do with the question as it mentions different technologies. there is a good reference for writing PHP apps with SOA focus.
from your expected output goal. That goal cant be measured. what do you defined as "best result"? why do you mention only a web service?
Please re-write the question so you can approach your problem in a rather more efficient manner.
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" :)
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.
We are building an ASP.NET application (with C#.net as language) and will be hosting on Windows Server 2003 Operating System with SQL Server 2008 as database.
We are planning to implement the best practices in writing code, dividing the application into logical blocks, services etc.
Would you please guide me on this, if you have an idea?
If would be great if you could also provide a reference document or web references (If needed).
Many Thanks,
Regards,
Venkat.
This isn't what you want to hear, but your best bet might be to bring on a senior asp.net guy who has a lot of experience and put him in charge of this.
But that's an extremely broad question, Venkat. Maybe if you could narrow it down a bit more we could provide a more useful answer.
I would perhaps recommend one book called Framework Design Guidelines, which is published by Microsoft Press. It goes into a lot of best practices on writing code, naming conventions, how to design classes, etc. And there are dialogues in there between Microsoft's top language guys. Sometimes they disagree, and that's always interesting.
But that's just one piece of the puzzle. I could talk for hours about methodologies, architectural patterns, object oriented theory, seperation of concerns, etc. As stated, your question covers all that ground.
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
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.