I work in a software company that delivers a software product. Many times we must integrate with other applications. 70% of the time we integrate with a single application. Currently we do not use middleware (MuleESB, Biztalk, ...) in these situations: the data conversion, transport conversion, etc is handled inside the applications.
Wouldn't it be better to ALWAYS use a middleware solution? (no matter if your integrating with 1 or more systems) This way, all the customizations (data formatting, restructuring, transport conversions) of both parties, can be handled by the middleware, instead of by the applications.
Logically this seems to me the right approach. But I ask myself: Is middleware in the case of two applications justifiable?
In practical terms, you will always be using a "Middleware" solution, either custom or packaged.
I'd look at it this way, rather than requireing a "middleware" package, I'd focus on making the app itself integration friendly by using a consistent and as-standard-as-practical API for exchanging data.
Then the decision on what "middleware" to use is more driven by the circumstance on site. If the customer has only one app to integrate, then a simple custom solution might be perfectly serviceable. If they have 5 apps and defined processes for each, then a package makes more sense.
I don't always use middleware, but when I do, I use BizTalk. ;)
I found this to be a useful read when considering appropriate architecture. If you get a chance to see Richard Seroter's "Decision Framework" presentation, you should.
Wiki site on Publish subscribe pattern http://en.wikipedia.org/wiki/Publish/subscribe shows an interesting comparison between how publish subscribe relates to client server.
Related
I have been getting a bit lost in the creation of my program architecture and I want to take a step back to see if I'm approaching it correctly.
I am wondering if my setup makes sense. I'm starting to think it doesn't.
I am creating intranet applications (We were creating Internet applications, but now the scope has changed). We use an onsite Active Directory (Windows Server 2012 R2). We have a SQL Server Database.
I have been building Front End Angular applications and ASP.NET Web API's to push and pull data. I am now implementing Authentication with Auth0 and it's been a nightmare.
What kind of program architecture would you setup in this scenario?
Much Appreciated.
SQL Server + Asp.Net Web Api + Angular JS forms a perfect architecture for building Single Page Applications (SPAs). This architecture is useful for building desktop like web applications, i.e. apps that runs over web but works like desktop apps.
If you can be more specific about the problem you are facing, you will be able to get better recommendations from so.
This architecture is widely adopted in many scenarios such as SPAs. With it, you will be able to keep your front-end highly decoupled from your backend services being able to support multiple front-ends on the same set of services and run quite a few integration scenarios.
Some of the downsides of such an approach will be the extra layer of complexity added to the application (which might force you to write more tests and handle different failure scenarios that wouldn't happen otherwise, for an example) and authentication routines since you will need to authenticate two heterogeneous environments (the .NET/IIS one and the JS/Angular one).
As for the authentication pain, token-based auth schemes seem the current way to go (such as Auth0) since they let you keep and send an environment-agnostic token which will be used by different layers of your architecture.
In that sense, your architecture makes sense.
However, since you're feeling some pain in its implementation, you might want to ask yourself if you really needed all of these. When you choose an architecture, you do so trying to accomplish some specific goals (multiple front-ends? specific performance requirements? maintainability? auditability?) and the more goals you try to accommodate in your architecture the more complex will become up to a point where the pains start outweighing the benefits.
So, what were you trying to achieve in the first place?
I am implementing a IIS Hosted WCF web service to accept leads from third parties. There are plenty of operations that may happen pre/post saving the information. I am thinking of implementing this as plug-in based architecture.
Example of pre-save operations are
duplicate checking before saving
making sure the information is valid (not mickey mouse)
Post-save operations are
zipcode based routing to correct warehouse
lead assignment.
I have been reading about MEF, but i have been unable to decide if this is actually worth implementing MEF where loading and unloading of plugins for every call will likely increase the overhead? Is there a way to just load all your plugins in some magic application_start?
I agree with Steven that you don't need a plugin architecture for this. You are good to go with just properly designed services. There are some very good hints about this in Steven's blog post - Writing Highly Maintainable WCF Services.
Nonetheless, to answer the second part of the question, there is nothing stopping you from initializing the MEF composition container in your Application_Start and store it statically (other than that it introduces a global state, which is often a bad design decision). Then it would be shared across the requests and you could use it to compose parts as needed without the overhead of repeated exports discovery.
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 on a website and this website contains games and this games will need to submit score to the website so the website will handle saving the user game score in the database.
So i am asking about the standards and common techniques to do this communications between the website and the flash games, is it better to let the flash files call javascript functions or call server side code? i have no idea how this can be done
Note: i can ask the flash games creator to edit the flash files to call some functions.
Also may be 'not sure yet' i will need to send from the server to the flash some variables.
It would be better for you if you create some javascript api that the game creators can hook into. Then it is entirely up to you what you do with it: ajax calls to webservices springs to mind.
This would protect you from having to learn Flex or Action script and if you can get the agreement of the game developers on the api, then you have abstracted this interface and your implementation in the browser will be de-coupled from what happens in Flash.
Well, the way I'm used to it, is that firstly, you design an API for the service the game developers should use. Obviously, you have to actually implement the service. :)
The next step is to provide an SDK, that further encapsulates the API and makes working with it easy, bridging the semantic gap between the API and the client, and sparing the developers the dull work of marshalling calls and parsing return values.
You can provide the SDK for use as a runtime shared library, so that you can provide bug-fixes and other interal changes without requiring recompiles and updates.
The reason, why I cannot really agree with Daniel is, that I don't really see a benefit in introducing an intermediary layer. It is just one more source of errors and security issues. From my experience, the most dramatical changes I know to APIs is deprecation of calls, change of call signatures or structure of returned data. Since you're writing this from scratch, it is very likely to happen.
In conclusion, the best practices for me are:
a well designed API
documentation
an SDK
developer support
greetz
back2dos
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